Heterogene Anwendungen führen dazu, dass Geschäftsprozesse nicht immer durchgängig und ohne Systembrüche von der IT unterstützt werden. Mitarbeiter des Unternehmens müssen nicht selten durch manuelle Dateneingaben die fragmentierten Prozesse ergänzen. Neue Kooperationsmodelle wie E-Business, E-Commerce und B-to-B benötigen jedoch technische Abläufe, die möglichst vollständig durch die IT unterstützt werden. Unternehmen sind deshalb gezwungen, ihre Geschäftsstrategie ständig den Marktgegebenheiten anzupassen und die geänderten Strategien unverzüglich in effiziente Geschäftsprozesse umzusetzen.
Die bestehenden Anwendungen können hierzu aber nicht immer wieder mit großem Aufwand neu entwickelt werden. Vielmehr sollten sich die vorhandenen Dienste möglichst unverändert in den neuen beziehungsweise geänderten Geschäftsprozessen ohne hohen Programmieraufwand weiterverwenden lassen. Wünschenswert ist dabei eine Unterstützung durch grafische Werkzeuge, aus denen die Geschäftsprozesse unter Einbeziehung der vorhandenen Anwendungen definiert und generiert werden können.
Betrachtet man die im Laufe der Zeit entstandenen, heterogenen Anwendungen, so zeigt sich, dass sie in der Regel jeweils eigene Datenbestände verwenden. Diese werden mit zum Teil unterschiedlichen Technologien verwaltet wie relationale Datenbanken bei offenen Sytemen, Codasyl-Datenbanken bei älteren Mainframe-Anwendungen, einfache Dateisysteme, Excel-Sheets und Ähnliches. Die darauf aufbauenden Architekturmodelle lassen sich grob wie folgt untergliedern: Monolithische Anwendungen, die meist auf Mainframe- oder älteren Unix-Systemen laufen und Terminalzugriff bieten. Client-Server-Anwendungen hingegen verwenden ein zentrales Datenbank-Management-System (zum Beispiel Oracle, SQL Server, DB2) und dezentrale PC-Systeme mit der Präsentations- und Anwendungslogik. Drei- und mehrschichtige Client-Server-Architekturen schließlich nutzen Standards wie Corba oder Transaktionssysteme wie "Tuxedo" oder "Open UTM". Daneben werden immer häufiger Standardanwendungen wie SAP R/3, Siebel, Baan oder I2 eingesetzt, die selbst eigene, integrierte Datenmodelle mitbringen.
Problem redundanter DatenDurch die skizzierte Anwendungsvielfalt entstehen in der Regel redundante Daten, die mehr oder weniger zeitnah untereinander abzugleichen sind. Oft werden gleichartige Daten mit unterschiedlichen Verfahren mehrfach erfasst. So wird beispielsweise ein Kundenauftrag für die Produktion, den Vertrieb, die Provisionierung des Vertriebs und das Rechnungswesen jeweils gesondert bearbeitet.
Diese ähnlichen, doch unterschiedlichen Prozesse werden dann oft von Sachbearbeitern innerhalb der Abteilungen des Unternehmens so verwendet, dass entweder ein Sachbearbeiter an seinem Arbeitsplatz mehrere von ihnen gleichzeitig bedient - oft über unterschiedliche Fenster und Formulare an einem Bildschirm - oder die Daten werden auf Papier von einer Abteilung an die andere weitergereicht. Prozesse mit derartigen System- und Medienbrüchen können so externen Partnern nicht zur Verfügung gestellt werden.
Aus dieser misslichen und oft nicht zu behebenden Heterogenität das Beste zu machen - dies ist das Ziel von EAI. Es gibt inzwischen eine Vielzahl von Herstellern mit Produkt- und Serviceangeboten, die das Problem der heterogen verteilten Daten lösen wollen und die Integration der Verfahren zu einheitlichen Prozessen unterstützen. Schematisch betrachtet bieten die dafür angebotenen Produkte drei Arten von Integration: Datenintegration, Message oder Information Brokering sowie Composite Applications (Produkte, die die beiden ersten Aspekte abdecken, werden meist als "Integration Broker" bezeichnet, Anm. der Red.).
Bei der Datenintegration können heterogen verteilte Daten logisch konsistent gehalten, das heißt abgeglichen werden, indem Daten aus der Quellanwendung extrahiert und in die Zielsysteme importiert werden. Die Extraktion erfolgt entweder über Export-Tools der Datenbankhersteller, spezielle Extraktions-Tools oder vom Anwender selbst erstellte Batch-Prozesse. Die extrahierten Daten gelangen meist mittels File-Transfer in die Zielsysteme und dann über Folgeverarbeitung in deren Datenhaltung. Die Daten müssen entweder im Quellsystem oder in den Zielsystemen auf die dort notwendigen Datenstrukturen und Datentypen umformatiert werden. Auch ist es möglich, im Quellsystem eine neutrale Metadatenstruktur zu erzeugen, beispielsweise in Form von XML-Dokumenten. Letztere werden dann auf die Zielsysteme verteilt und dort in die jeweilige Struktur umgewandelt.
Je nach Art der Daten erfolgt der Datenabgleich in bestimmten Zeitintervallen, zum Beispiel täglich oder monatlich. Sinnvoll ist diese Art der Integration bei all den Daten, die nicht unbedingt zu einem fixem Zeitpunkt in allen Anwendungen den gleichen Grad an Aktualität benötigen. Beispielsweise muss die Änderung einer Kundenadresse nicht unbedingt sofort in jeder Anwendung sichtbar werden, sofern der Empfänger einen Nachsendeauftrag erteilt hat. Stücklisten oder Kataloginformationen werden ohnehin nur zu bestimmten Zeiten geändert.
Intelligentes MessagingMessage oder Information Broker greifen nicht direkt auf die Daten der heterogenen Anwendungen zu, sondern nur indirekt über die vorhandenen Verfahren. Eine detaillierte Kenntnis der Strukturen und Datentypen ist daher nicht nötig. In die Quellanwendung wird ein Business Event Trigger eingefügt, der bei einem bestimmten Ereignis ein Business Event an den Broker sendet. Die Daten des Events werden umformatiert und anhand des Dateninhalts bewertet. Mit Hilfe von Regeln (Business Rules) erfolgt dabei eine Identifizierung der in Frage kommenden Zielsysteme.
Das Business Event kann auf zwei Arten erzeugt werden: entweder im Quellsystem durch die "invasive" Änderung der bestehenden Anwendung. Dazu werden die Daten des Business Events gesammelt und über Bibliotheksfunktionen an den Message Broker weiter gereicht. Der zweite Weg, einen Business Event zu erzeugen, ist über eine Triggerfunktion des Datenbanksystems, das ihn daraufhin an den Message Broker weiterleitet.
Die weitere Behandlung des Business Events im Message Broker erfolgt dann in der Regel asynchron zur Quellanwendung, meist mit Hilfe eines Message-Queuing-Systems. Business Rules, die zuvor mit Hilfe von Tools formal (oft grafisch) definiert wurden, beschreiben dabei die Analyse, Umformatierung und Verteilung der Events. Zur Identifizierung und Adressierung der Zielanwendungen werden zudem oft Publish/Subscribe-Modelle verwendet. Ins Zielsystem gelangen die Daten schließlich ebenfalls auf zwei Wegen: Das Zielsystem kann entweder die bereits passend formatierten Daten aus einer Message Queue lesen und sie unter Nutzung vorhandener Anwendungslogik in den Datenbestand einfügen. Dazu ist meist eine bestehende Anwendung zu modifizieren.
Integration mit AdapternIst ein Eingriff in das System hingegen nicht gewünscht (nicht-invasiv), so kann ein Adapter - als zweite Möglichkeit - auf dem Message Broker die Nachricht aus der Message Queue lesen und die Zielanwendung über vorhandene externe Interfaces etwa mit Hilfe von Terminalemulation oder über Client-Server-Schnittstellen beziehungsweise -protokolle aufrufen. Da die Zielanwendung unverändert aufgerufen wird, spricht man auch von einer non-invasiven Integration. Hersteller von EAI-Produkten bieten Adapter für diverse Standardanwendungen wie beispielsweise für SAP R/3-BAPIs oder RFCs, für Siebel, Baan oder I2 an. Für Individuallösungen wie alle Mainframe-Anwendungen, die üblicherweise nicht über wohldefinierte externe Schnittstellen verfügen, müssen hingegen spezielle Adapter hergestellt werden. Die EAI-Anbieter offerieren dafür Software Development Kits (SDKs) oder Werkzeuge, die aus Mitschnitten die passenden Adapter generieren.
Neben der reinen Verteilung der Daten ist ein Business Event auch in der Lage, eine komplette Prozesskette (Process Flow) anzustoßen. Dies kann zum Beispiel die Abwicklung einer Bestellung sein, deren vollständige Verarbeitung sich möglicherweise über einen längeren Zeitraum erstreckt. Da hier die Prozesse komplett durch die Process Flow Engine gesteuert werden, sind hohe Anforderungen an solche Systeme zu stellen. So müssen ein sicherer Datentransfer ("exactly once") und die Transaktionssicherheit ebenso gewährleistet sein wie Recovery- und Restart-Funktionen, eine Exception-Behandlung, Revisionslogging sowie System-Management-Funktionen.
Im Gegensatz zu Message Brokern stehen als dritte Integrationsart Anwendungen bereit, welche die Analysten von Gartner als "Composite Applications" bezeichnen. Dies sind Anwendungen, bei denen Funktionen aus existierenden Systemen zu neuen Lösungen in Echtzeit kombiniert und erweitert werden und einen neuen "Superservice" entstehen lassen. Die Dienste stehen den interaktiven Benutzern im Unternehmen sowie externen Kunden und Partnern zur Verfügung. Typische Anwendungsfälle sind Online-Systeme für das Customer-Relationship-Management (CRM), Call-Center sowie Helpdesk-Lösungen.
Die zu integrierenden Anwendungen werden über Wrapping-Techniken in eine einheitliche Zugriffsmethode überführt. Dies können zum einen Business Objects sein, die auf den Spezifikationen der Objektmodelle Component Object Model (COM), Component Object Request Broker Architecture (Corba) oder Enterprise Javabeans (EJB) basieren. Oder es sind XML-Dokumente, zum Beispiel als Web-Services. Die Zielanwendungen können dabei meist unverändert verwendet werden. Ähnlich den Adaptern realisieren die Wrapper die Kopplung mit der Zielanwendung, übernehmen die Nachrichtenformatierung, die Steuerung des interaktivem Verhaltens (Dialogsequenzen) sowie die Abbildung auf das entsprechende Objekt- oder Dokumentenmodell. Die Wrapper sollten auch für Individualanwendungen möglichst ohne größeren Programmieraufwand erstellt werden können. Composite Applications sind in der Lage, neben den gewrappten Programmen auch neue Anwendungen und Komponenten zu integrieren. Die Regeln für den Daten- und Kontrollfluss werden oft mittels grafischer Tools definiert. Dadurch lassen sich die Geschäftsprozesse flexibel an die Erfordernisse der Geschäftsstrategie angepassen.
ComponentwareEine weitere interessante Entwicklung im Zusammenhang mit EAI ist das Entstehen eines Marktes für EJB-Komponenten (Componentware). Einzelne solcher Bausteine ergeben jedoch noch keine vollständige Anwendung, sondern sind grob granulare Komponenten, die erst noch zu konkreten Lösungen zusammengefügt werden müssen. Der EJB-Standard spricht hier von Application Assembly. Um mit Componentware möglichst flexibel Geschäftsprozesse abzubilden, die leicht an die sich ändernden Erfordernisse der Geschäftsstrategie angepasst werden können, empfiehlt es sich, Technologien und Werkzeuge gängiger EAI-Produkte für Process Flow oder Composite Applications zu nutzen. Dieser Ansatz eröffnet außerdem die Möglichkeit, später die Nachfolgetechnologien mit in die Geschäftsprozesse zu integrieren.
Darüber hinaus machen Web-Services in der letzten Zeit viel von sich reden. Sie basieren auf XML-Standards wie etwa dem Soap-Protokoll und sind ähnlich der EJB-Componentware nur Bausteine für den Aufbau vollständiger Prozesse. So ist beispielsweise in der von Sun Microsystems vorgeschlagenen Referenzarchitektur "Open Net Environment" (ONE) von "Micro Services" die Rede, aus denen erst durch Integration "Macro Services" entstehen. Ähnliche Ansätze findet man bei Microsoft .NET. Erste Tools für solche Aufgaben, mit denen der Daten- und Kontrollfluss grafisch definiert und daraus ablauffähige Macro Services generiert werden können, sind derzeit im Entstehen.
*Herbert Sattler ist Systemarchitekt bei Fujitsu-Siemens in München.
Abb.1: Ausprägungen der Anwendungsintegration
Schematisch lassen sich bei EAI drei Formen der Integration beschreiben: Auf Datenbankebene, über intelligente Messaging- und Routing-Software oder über Anwendungskomponenten. Quelle: Sattler
Abb.2: Integration über Prozesse
Broker steuern die zum Teil komplexen Message- oder Information-Geschäftsprozesse im Unternehmen. Quelle: Sattler