Die Nachfrage nach Werkzeugen für Enterprise Application Integration (EAI) wächst. Einerseits steigt die Fusionsaktivität der Wirtschaft. Andererseits bringen hoch skalierbare Server und schnelle, preisgünstige Netze die "Economies of Scale" wieder zur Geltung; Konsolidierung der IT-Aktivitäten von Konzernen ist angesagt, wobei die oftmals eigenständigen IT-Systeme in den Tochtergesellschaften, Niederlassungen und Werken in einem oder in wenigen Rechenzentren zusammengeführt werden.
Vor diesem Hintergrund wird der Bedarf an Techniken für Datenaustausch in einem Maß zunehmen, das konventionelle Vorgehensweisen wie die Eigenentwicklung kleiner JCL-Scripts oder Programmerweiterungen zum Scheitern verurteilt. Denn all diese Routinen müssen gepflegt, ergänzt angepasst und pünktlich ausgeführt werden, soll das Integrationsgebäude nicht wie ein Kartenhaus zusammenstürzen.
Direktzugriff: Ideal, aber aufwändigDrei Schichten des Datenaustauschs lassen sich unterscheiden: Direktzugriff, Datenübersetzung und Datentransport (siehe Abbildung "Datenaustausch"). Datentransfer zwischen Applikationen auf der Direktzugriffsschicht wäre natürlich ideal, weil dabei die höchste Integrationsstufe erreicht wird. Unglücklicherweise hat sie aber einen gewaltigen Aufwand zur Folge, da jede der betroffenen Applikationen im Programmcode verändert werden muss.
Denn der Direktzugriff bedingt eine synchrone Verbindung der Applikationen, die direkt über einen Programmaufruf verbunden werden. Das aufrufende Programm wartet auf die Ergebnisse, die eine aufgerufene Funktion, eine entfernte Prozedur oder ein anderes Programm liefert. Die auszutauschenden Daten werden dabei als Parameter übergeben.
Wegen des beträchtlichen Aufwands ist diese höchste Integrationsform nur dort wirtschaftlich sinnvoll, wo Hochverfügbarkeit und schnellste Reaktionszeiten nötig sind. Das ist zum Beispiel im Wertpapier- und Börsenhandel, bei Buchungssystemen und Finanztransaktionen der Fall. Außerdem bedingt die synchrone Form des Datenaustauschs, dass alle beteiligten Systeme gleichzeitig aktiv sein müssen - ein Hemmnis für globale Systeme, die über verschiedene Zeitzonen hinweg funktionieren müssen, oder bei der Einbindung mobiler Rechner, etwa für den Außendienst.
Abhilfe schafft hier die Technik der "Datenübersetzung" als zweite Form des Datenaustauschs: Sie erlaubt asynchrone Kommunikation und vermeidet direkte Änderungen am Programmcode der beteiligten Systeme. Hier wird eine Middleware zwischengeschaltet, die die zu verbindenden Datenstrukturen und die dazugehörigen Übersetzungsregeln kennt. Sie übernimmt den Empfang, das Umformen und die Weiterleitung der Daten. Dies erfolgt zwar asynchron zum technischen Ablauf, doch lässt sich eine "Ablaufsynchronisierung" im Sinne eines Workflows und eines Scheduling realisieren.
Ein typischer Einsatzbereich solcher Middleware ist das Füllen von Data Marts und Data Warehouses, in denen aus unterschiedlichsten operativen Systemen zentral und einheitlich strukturierte Informationen für Analysezwecke bereitgestellt werden. Hier wird gern von "Datenpumpen" oder "Datentransformatoren" geredet. Aber auch bei Firmenzusammenschlüssen, der Verknüpfung von Kundeninformationssystemen oder Auftragsbearbeitungssystemen ist eine Übersetzungsfunktionalität zwischen Daten sinnvoll. Allerdings hat auch die Datenübersetzung einen gravierenden Nachteil: Sie vermeidet die Änderung des Programmcodes nur dadurch, dass die Daten selbst modifiziert werden.
Beschränkung auf reinen Datentransport reicht oftEine Manipulation der Daten selbst wird beim reinen Datentransport vermieden, mit dem sich 90 Prozent der Anwendungsfälle beim EAI abdecken lassen. Hier kommen bewährte Techniken wie File-Transfer, Messaging oder Electronic Data Interchange (EDI) zum Einsatz. Sie arbeiten mit Dateien oder Messages, die die Applikationen unverändert austauschen. Um die Daten verarbeiten zu können, müssen allerdings einheitliche Datenstrukturen für den Austausch zwischen den beteiligten Applikationen vereinbart werden.
Hier liegt die Crux. Bei externen Partnern, die möglicherweise häufig wechseln, und insbesondere bei E-Business-Transaktionen ist eine Einigung auf gemeinsame Datenstrukturen schwierig, manchmal unmöglich. Zumeist ist darüber hinaus der Datentransfer nur zwischen genau zwei Anwendungen oder Plattformen definiert, so dass im Lauf der Zeit eine Fülle verschiedenster File-Transfer-Lösungen entsteht: homogen zwischen PC-Servern, zwischen Mainframe-Systemen und zwischen Unix-Rechnern und heterogen zwischen diesen verschiedenen Plattformen. Das sind mindestens sechs Varianten des File-Transfers - bei der Vielfalt der Unix-Systeme und proprietären Host-Rechner sogar rasch viel mehr.
Die Nachteile sind offensichtlich: Der Datenfluss lässt sich nur schwer nachvollziehen und kontrollieren. Sicherheitsrisiken sind mangels firmenweiter Übersicht über die Datentransfers ebenso wenig zu vermeiden wie Wartungsaufwände für die Inhouse-Entwicklung. Der geringe Automatisierungsgrad hat zudem einen beträchtlichen Arbeitsaufwand zur Folge, und auch die Plattformabhängigkeit zwingt zu kostenintensiven Serviceverträgen.
Hilfe gegen einen Teil dieser Probleme bieten spezialisierte Management-Systeme für den Datentransfer. Häufig wird allerdings auch noch das seit Mitte der 80er Jahre existierende FTP-Protokoll für TCP/IP-Netze eingesetzt. Allerdings fehlen ihm einige Eigenschaften, die an einen wirklich professionellen File-Transfer gestellt werden, wie etwa die volle Automatisierbarkeit und Revisionsfähigkeit der durchgeführten Transfers.
Moderne Datentransfersysteme haben mit dem simplen File-Transfer der 80er Jahre ebenso wenig zu tun wie eine moderne Limousine mit dem T-Model von Ford. Sie funktionieren zwar noch nach dem gleichen Prinzip, haben aber eine neue Stufe der Funktionalität erreicht. Zu ihren Aufgaben gehört das automatische Verteilen der Dateien, gesteuert durch Geschäftsereignisse oder individuell durch Sender beziehungsweise Empfänger, unabhängig von den beteiligten Netzen, Protokollen und Rechnersystemen.
Die Unabhängigkeit von Netzprotokollen (neben TCP/IP sind auch ISDN, X.25, SNA und andere von Bedeutung) sollte ebenso selbstverständlich sein wie eine Offenheit gegenüber Transferprotokollen angesichts der Vielzahl von proprietären Standards.
Auch der Austausch von Daten über Inter-, Intra- und Extranets muss heutzutage unterstützt werden, um entfernte Filialen oder Partner ohne spezielles Know-how in die unternehmensweiten Datenflüsse einbinden zu können. Geschäftspartner werden nur über einen Browser an das globale Datennetz gekoppelt und sind nicht gezwungen, eine Datentransfersoftware selbst zu installieren.
Administration der DatenflüsseDie kurz skizzierte Fülle der mit dem Datentransfer verknüpften Aufgaben lässt erwarten, dass sich in den nächsten Jahren ein neues Berufsbild herausschälen wird: der Datenfluss-Administrator. Denn hatte man in den frühen 90ern oft noch die Notwendigkeit von "Datenverantwortlichen" als Herren über die Datenstrukturen mit dem Hinweis auf moderne Datenbanken und 4GL-Sprachen belächelt, so ist dies heute eine etablierte Rolle in den IT-Organisationen.
Von einem praxisnahen Standpunkt aus gesehen, lässt sich feststellen, dass das Gros der Geschäftsvorfälle vollkommen zufrieden stellend mit einer zeitnahen asynchronen Datenübertragung zwischen Applikationen bedient werden kann, die die beschriebenen Merkmale aufweist. Der Aufwand für eine Realisierung in der Datenübersetzungs- oder Direktzugriffsschicht wird sich bei näherer Betrachtung meist als so hoch erweisen, dass er einem Business Case in 90 Prozent der Fälle nicht standhalten wird.
*Harald Weyerich ist Leiter Technik bei der Sopra Software GmbH in Frankfurt am Main.
Abb: Dreischichtige Architektur für Enterprise Application Integration (EAI) auf Basis von Datentransfer. Quelle: Sopra Software GmbH