Die Welt spricht von E-Business zwischen Geschäftspartnern unter Verwendung normierter Kommunikationsvorgänge und -inhalte (ebXML, cXML, EDI, Rosettanet und Biztalk), doch innerhalb der Unternehmen ist man von einer gegenseitigen Verständigung der Systeme noch weit entfernt. Jede Anwendung benutzt andere Datenbezeichner für dieselben Daten und verschiedene Namen für die gleichen Funktionen. Hinzu kommt, dass Geschäftsprozesse quer durch alle Anwendungen laufen können. Ein "E"-Auftrag benötigt Informationen und Dienste von diversen Anwendungen, was voraussetzt, dass diese miteinander reden können. Wie soll aber eine Kommunikation zwischen einem alten Cobol-System und einer neuen Java-Anwendung stattfinden? Bestimmt nicht auf der Bit- und Byte-Ebene. Es müssen normierte High-Level-Schnittstellen zwischen allen Systemen vorhanden sein.

Hierin liegt die Bedeutung von Enterprise Application Integration (EAI). Es dient dazu, sämtliche IT-Anwendungen eines Unternehmens in die Lage zu versetzen, miteinander zu kommunizieren. Jedes Anwendungssystem soll die Möglichkeit haben, auf jede Datenbank zuzugreifen, auf die sie ein Zugriffsrecht hat, und jede öffentliche Funktion in jeder fremden Komponente aufzurufen, zu deren Nutzung sie berechtigt ist. EAI soll die Mauern zwischen betriebsinternen Anwendungen abreißen.

Leider sind die meisten deutschen Anwenderbetriebe weit entfernt von diesem Ziel. Sie ähneln dem Heiligen Römischen Reich am Ausgang des Mittelalters mit vielen konkurrierenden Fürstentümern und freien Reichsstädten, die nur darauf bedacht sind, ihre Unabhängigkeit zu bewahren. Das Reich beziehungsweise die IT-Landschaft ist über die Jahre immer bunter geworden, das obere Management, der Kaiser, hat schon längst die Kontrolle darüber und über die darin streitenden Parteien verloren.

Die IT-Welt sieht aus wie eine völlig zerstückelte Landkarte: Neben den Hostanwendungen in den klassischen Sprachen wie Assembler, PL/I und Cobol finden sich 4GL-Anwendungen, Client-Server-Systeme in C/C++ und neuerdings auch Web-Anwendungen in Java oder C#. Die Daten sind in verschiedenen Datenbanksystemen gespeichert, von hierarchisch oder netzartig bis zu relational oder objektrelational. Die Benutzeroberflächen reichen von 3270-Masken über Windows-GUIs bis hin zu gestaffelten Web-Seiten mit Animation und Hyperlinks.

Technikspektrum von 30 Jahren integrieren

Es ist alles vorhanden, was uns die IT-Technologie über die vergangenen 30 Jahre beschert hat, und alles dient seinem Zweck, weshalb die einzelnen Systeme auch erhaltenswert sind. Als Mittel für eine "End-to-End-Integration" dienen Standards, Frameworks, genormte Schnittstellen sowie die Interface Definition Language (IDL) und die Extensible Markup Language (XML), Middleware-Produkte und Source-Transformationswerkzeuge:

-Workflow-Steuerungsrahmen sorgen für den ordnungsgemäßen Ablauf der Geschäftstransaktionen über Systemgrenzen hinweg,

-Frameworks für den Zusammenhalt der eigenen Anwendungen und

-die Schnittstellen-Sprachen für den reibungslosen Datenaustausch.

-Middleware dient der effizienten und sicheren Verbindung der Systeme, und

-die Transformationswerkzeuge sorgen für die nötigen Anpassungen der alten Programme sowie die Schaffung der neuen Schnittstellen.

EAI ist somit der Oberbegriff für die Zusammenarbeit aller Systeme untereinander, setzt allerdings eine gewisse IT-Architektur voraus. Die Hauptursache des Integrationsproblems liegt nämlich in der vertikalen Organisation der IT-Systeme. Sie sind in der Regel nach Sachgebieten mit einem eigenen Anwendungssystem aufgeteilt. Nicht selten haben sie auch eine eigene Datenhaltung. Man darf nicht vergessen, dass noch bis vor kurzem die konzernübergreifende Integration der Geschäftsprozesse keine signifikante Rolle gespielt hat. Jetzt ist das Ziel, einen einzigen Großraum zu schaffen, in dem alle Abläufe nahtlos ineinander übergehen. Dies hat schon mit der Einführung von ERP-Systemen begonnen, aber spätestens seit der Verbreitung der Web-Technologie ist das Pionierzeitalter der vertikalen IT-Organisation vorbei.

Eine Voraussetzung für Enterprise Application Integration ist eine horizontale IT-Architektur. In einem Leitartikel für die "Communications of the ACM" beschreibt Professor Wilhelm Hasselbring vom Fachbereich Informatik der Universität Oldenburg ein dreiteiliges Schichtenmodell:

-Business Architecture Layer,

-Application Architecture Layer und

-Technology Architecture Layer.

Im Business Architecture Layer sind die Geschäftsobjekte und Geschäftsprozesse samt Regeln und Anwendungsfällen quer durch alle Geschäftsgebiete definiert und modelliert. Diese Schicht ist der so genannte Überbau der IT-Architektur mit den dazugehörigen Geschäftsprozessen beziehungsweise Workflows. Die hier ablaufenden Prozesse verwenden die Geschäftsobjekte, die in der darunter liegenden Applikationsarchitektur angesiedelt sind.

Die horizontale IT-Organisation

Im Application Architecture Layer liegen die alten und neuen Anwendungssysteme samt Komponenten, Modulen, Klassen, Daten und Funktionen. Hierher gehören auch die EAI-Frameworks etwa von Tibco und Websphere. Sie bilden den Rahmen für die eigenen Objekte, die größtenteils aus den bestehenden Anwendungen gewonnen werden.

Im Technology Architecture Layer ist die Informations- und Kommunikationsinfrastruktur des Unternehmens angesiedelt. Dazu gehören Datenbanken, System-Schnittstellen, Oberflächenrahmen, Kommunikationsprotokolle, Middleware und Rechnerarchitektur.

Dieses Schichtenmodell ist das Ergebnis eines Business-Process-Reengineering-Projekts, das sich quer durch alle Sachgebiete zieht und dabei die einzelnen Anwendungen untersucht, die Redundanzen entfernt und die Kernfunktionen herauszieht und verbindet.

Ein weiterer Anlass für die Einführung einer horizontalen IT-Organisation ist moderne Middleware. Techniken auf Basis von Corba oder DCOM, Datenbank-Gateways und Online-Transaktionsmonitore verbinden entfernte Systeme über gemeinsame Transaktionen, die über mehrere Anwendungen laufen und verschiedene Datenbanken verändern. Solche "langen" Transaktionen sind das Pendant zu sachgebietsübergreifenden Geschäftsabläufen.

Schließlich die Web-Techniken als treibende Kraft in Richtung Unternehmens- und Systemintegration: Im Inter- beziehungsweise Intranet herrscht die Peer-to-Peer-Kommunikation. Jeder Knoten im Netz kann im Prinzip mit jedem anderen Knoten kommunizieren, das heißt ihn auffordern, eine Funktion auszuführen oder eine Information zu liefern. Knoten sind die Geschäftsstellen beziehungsweise die Komponenten und Datenbanken. Sie müssen in der Lage sein, Aufträge zu empfangen und Ergebnisse zu senden, und zwar über einheitlich genormte Schnittstellen.

In seinem CACM-Beitrag sieht Hasselbring drei Haupthindernisse auf dem Weg zu einer horizontalen IT-Schichtenarchitektur: Verteilung, Heterogenität und Autonomie.

Die Verteilung an sich ist kein Hindernis - wenn sie geplant und gesteuert wäre. Letztlich ist die Dezentralisierung auch ein Ziel der IT-Restrukturierung. Leider ist die Verteilung in den neuesten IT-Bereichen eher zufällig entstanden. Es wurden Systeme in diversen Umgebungen ohne Rücksicht auf Interoperabilität und Kompatibilität entwickelt. Solche Stand-alone-Applikationen sind die Folge unkoordinierter externer Anforderungen und eines ungebändigten innerbetrieblichen Aktionismus: Es galt, ein Anwendungsvakuum zu füllen, und die Projektverantwortlichen waren nur auf dieses eine Problem fokussiert.

Heterogenität ist eine Folge der unkontrollierten Verteilung. Dort, wo IT-Projekte ohne Abstimmung untereinander aufgesetzt wurden, konnte jedes Projekt eine andere IT-Technologie anwenden. Es entstand ein Wildwuchs an Entwicklungsumgebungen, Programmiersprachen und Datenbanksystemen.

Die Autonomie der Geschäftseinheiten, beziehungsweise ihre Freiheit, eigene Geschäftsobjekte, Geschäftsregeln und Dateninhalte zu definieren, führte dazu, dass viele Daten redundant gehalten werden und viele Geschäftsregeln widersprüchlich sind. Innerhalb der einen Anwendung mag alles stimmig und redundanzfrei sein, aber im Zusammenspiel mit anderen Anwendungen kommen Namenskollisionen und Regelunverträglichkeiten vor.

Bestandsaufnahme der Systeme

Der Weg hin zur Enterprise Applikation Integration beginnt deshalb zunächst mit einer Bestandsaufnahme aller vorhandener Systeme. Sämtliche Anwendungssysteme sind zu erfassen und in Bezug auf ihre fachlichen Funktionen, technischen Komponenten, Benutzeroberflächen, System-Schnittstellen und verwendeten Datenbanken beziehungsweise Dateien zu beschreiben. Es muss entschieden werden, welche Systeme in welcher Reihenfolge zu integrieren sind.

Um die EAI-Kosten zu kalkulieren, wird es auch nötig sein, in einem zweiten Schritt die Sourcecodes, die Schnittstellen und die Datenbank-Beschreibungen zu analysieren. Hier werden mit Hilfe eines Code-Auditors Quantität, Qualität und Komplexität der Systeme gemessen. Die wichtigsten Größenmaße sind die Code-Zeilen, Anweisungen, Schnittstellen, Module, Dateien, Datenbanken, Datenattribute, Data-Points und Function-Points. Die wichtigsten Komplexitätsmaße sind die Schnittstellen-, die Zugriffs- und die Datenkomplexität. In der Qualitätsmetrik tauchen Aspekte wie Modularität, Flexibilität, Wiederverwendbarkeit und Kapselung auf. Diese Softwaremetriken dienen dazu, den Aufwand für die Integration einzuschätzen und das Integrationsprojekt zu planen.

Im dritten Schritt werden die zu integrierenden Anwendungssysteme nachdokumentiert und in einem gemeinsamen Software-Repository abgebildet. In erster Linie geht es dabei um die Beziehungen zwischen den Programmen und den Datenbanken, zwischen den Programmen und Schnittstellen sowie zwischen den Programmen untereinander. Es wird angestrebt, die Architektur der vorhandenen Systeme aus deren Quelldateien abzuleiten. Falls die Systeme nach unterschiedlichen Prinzipien strukturiert sind, zum Beispiel prozedural- oder objektorientiert, muss ihre Darstellung auf einen gemeinsamen Nenner gebracht beziehungsweise die eine Struktur in die andere transformiert werden. Wichtig ist, dass zum Schluss eine einheitliche Systemdokumentation steht - möglichst in der UML.

Die Auswahl und Einführung eines EAI-Frameworks steht im Mittelpunkt des vierten Schrittes. Das Produkt soll in die IT-Landschaft des Anwenders und zu den bestehenden Systemen passen. Außerdem muss es ausreichend Performance und Zuverlässigkeit anbieten. Dazu wird es nötig sein, jedes Produkt verschiedenen Tests zu unterziehen, ehe man eine Entscheidung trifft. Hier darf auf keinen Fall gespart werden, denn von der Wahl des richtigen Frameworks hängt der Erfolg des Integrationsprojekts ab.

Schnittstellen müssen kompatibel sein

Im fünften Schritt werden die Programme und Datenbanken der bestehenden Systeme hinter genormten Schnittstellen gekapselt. Die Schnittstellen könnten in IDL oder XML kodiert sein. Wichtig ist, dass sie alle einheitlich und kompatibel sind. Im Hinblick auf die E-Business-Anforderungen werden XML-Schnittstellen heute vorgezogen. Mit Hilfe von Wrapping-Tools ist es möglich, die Schnittstellen (Masken, Dateien und Linkage-Parameter) aus den Programmen herauszuschneiden und in XML-Schemen beziehungsweise IDL-Schnittstellen umzusetzen. Über diese Interfaces wird auf die Funktionen der vorhandenen Programme sowie auf die bestehenden Datenbanken zugegriffen. Die Legacy-Programme bilden dann die Geschäftsobjekte der Applikationsschicht.

Die übergeordnete Workflow-Steuerung der neuen Geschäftsprozesse wird im sechsten Schritt implementiert. Diese Steuerung bewirkt die Zuteilung der Geschäftsressourcen und die Aufrufe der Funktionen in den Geschäftsobjekten. Die Workflow-Parameter bestimmen, welche Funktionen welcher Geschäftsobjekte in welcher Reihenfolge aufgerufen werden. Mit dem geeigneten EAI-Rahmen ist es relativ einfach, diese Geschäftsprozesse umzusetzen und zu verändern. Die Steuerungsprozesse können in Standardsprachen wie Java oder C# oder in speziellen Skriptsprachen verfasst werden.

Verknüpfung mit Geschäftsprozessen

Im siebten Schritt werden die EAI-Schnittstellen mit den übergeordneten Geschäftsprozess-Steuerungskomponenten sowie mit den untergeordneten Geschäftsobjekt-Komponenten beziehungsweise mit den Legacy-Programmen verknüpft, damit diese untereinander Aufträge und Daten austauschen können. Dieser Link-Vorgang erfolgt mittels Tools, die aus den alten Programmen XML- oder IDL-Schnittstellen generieren.

Der letzte und wohl aufwändigste Schritt ist der Integrationstest. Nicht nur alle Schnittstellen müssen gezielt in allen Variationen geprüft werden. Es gilt, sämtliche Geschäftsprozesse mit allen Anwendungsfällen und deren Ausprägungen zu bestätigen. Für jede Schnittstelle und für jeden Anwendungsfall werden etliche Testfälle spezifiziert, generiert, durchgeführt und validiert. Bei komplexen EAI-Umgebungen wird es ohne entsprechende Testautomation nicht gehen. Der Test sollte mindestens die Hälfte der Gesamtintegrationskosten betragen. (ue)

*Harry Sneed ist Chief Technology Scientist der CC GmbH in Wiesbaden.

Die EAI-Schritte

1. Bestandsaufnahme der vorhandenen Systeme;2. Messung der vorhandenen Systeme;

3. Nachdokumentation der vorhandenen Systeme;

4. Einführung eines EAI-Framework;

5. Kapselung der vorhandenen Komponenten;

6. Workflow-Steuerung der Geschäftsprozesse;

7. Bindung der Geschäftsprozesse mit den Geschäftsobjekten;

8. Test der Systemintegration.

Abb: EAI-Schichtenmodell

Das Schichtenmodell beschreibt eine sachgebietsübergreifende IT-Organisation. Quelle: Case Consult