Es gibt grundsätzlich zwei Verfahren, Anwendungen miteinander zu integrieren: die datentechnische Verbindung auf der Ebene von Datenbanken oder eine Brücke via Application Programming Interfaces (APIs). Bei der Auswahl der passenden Methode muß geklärt werden, ob die Verbindung ereignis- oder zeitgesteuert sein soll und ob eine Batch-Integration oder eine Echtzeitverbindung benötigt wird. Unternehmen können ausgehend von diesen Möglichkeiten vier unterschiedliche Techniken einsetzen, um ihre Anwendungen zu verbinden:

1. Individuelle Integration

Dieses Konzept basiert auf dem Einsatz von Middleware als Transportmedium und ist individuell programmiert. Diese Möglichkeit wird zunehmend vereinfacht, da die Endpunkte des Workflows mit Hilfe von Standard-Connectoren, wie sie etwa Neon liefert, an ein Enterprise-Resource-Planning-(ERP-)Paket angebunden werden können.

2. Traditionelle Datenbankintegration:

Die Technik ist seit vielen Jahren im Einsatz und durch einen hohen Anteil an Individualentwicklung gekennzeichnet. Heute bieten einige EAI-Hersteller wie Constellar zusätzlich vorgefertigte Datenbank-Connectoren an, so daß sich der Programmieraufwand reduzieren läßt. Die Daten werden periodisch extrahiert, eventuell umgeformt und in der Zieldatenbank gespeichert. Dieses Konzept ist auch als Drehscheibentechnik (Hub) bekannt. Dabei schreibt eine Anwendung in die Datenbank hinein, und die nächste Anwendung liest diese Sätze aus dem Speicher wieder aus.

3. EAI-Framework:

Hersteller wie Active oder Oberon bieten ein Entwicklungs- und Runtime-Framework, um über die APIs der beteiligten Anwendungen die erforderliche Integration zu bewerkstelligen, sofern eine API überhaupt vorhanden ist. Diese Integration umfaßt sowohl den Workflow als auch den Transport der benötigten Daten zwischen den Applikationen. Über die APIs der Anwendungen wird in der EAI-Middleware die erforderliche Intelligenz bereitgestellt, um Datenveränderungen allen betroffenen Anwendungen ereignisgesteuert mitzuteilen. Bei einer Entscheidung für dieses Verfahren ist allerdings die Frage wichtig, mit welchem Aufwand sich diese Middleware erstellen läßt. Dabei darf nicht übersehen werden, daß bei einer Vielzahl installierter individueller Anwendungen eine Integration auch nur mit individueller Programmierung möglich ist, da es für diese Applikationen keine Standard-Connectoren gibt.

4. Prozeßintegration:

Die Verbindung auf dem Niveau von Geschäftsprozessen ist die fortschrittlichste, aber auch komplexeste. Bei diesem Verfahren lassen sich sowohl die Adapter erstellen, also die Anschlüsse an Standardprodukte, als auch eine eigene Anwendungslogik definieren. Beides ist strikt getrennt voneinander.

So können eigenständige "neue" Anwendungsfunktionen entwickeln werden, die in den Einzelanwendungen so nicht vorgesehen sind. Gebildet werden diese neuen Funktionen, indem die Programmlogik der Prozeß- Middleware auf die unterschiedlichen zu integrierenden Softwarepakete zurückgreift und die dort vorhandenen Prozesse zu einem neuen virtuellen Vorgang verbindet.

Somit lassen sich beispielsweise Call-Center-Software und ERP-Pakete so verknüpfen, daß ein Mix aus beiden Systemen entstehen kann. Zu klären ist im Vorwege allerdings, welche Geschäftsprozesse mit welchen Durchlaufvarianten unterstützen und welche Daten dazu zu transportieren sind.

Prozeß-Middleware basiert auf einem zentralen Applikations-Server, mit dessen Hilfe sich der Workflow und alle dazugehörenden Regeln definieren lassen. Dazu bietet er die Möglichkeit, Geschäftslogik in Form eines ablauffähigen Codes zu generieren.

Ausgehend von den vier theoretischen Integrationsansätzen stehen Anwendern nun vier technische Verfahren zur Verfügung, um die Integration in die Tat umzusetzen:

Die Point-to-Point-Implementierung, das Bus- oder Pipline-Verfahren, die Hub-and-Spoke-Technik sowie die Realisierung auf Basis von Prozeß-Middleware.

Die Punkt-zu-Punkt-Implementierung verknüpft zwei Anwendungen durch eine direkte Middleware-Kopplung. Ob diese über individuelle Programmierung realisiert oder ob bereits Standard-Connectoren eingesetzt werden, ist eine Frage des benötigten Programmieraufwands. Ist er gering, lohnt die Anschaffung eines Standardadapters nicht. In der Regel fußt diese Lösung auf einer synchronen Middleware-Verknüpfung. Genutzt wird dieses Verfahren bei der individuellen Integration und wenn nur wenige Schnittstellen sowie wenige unterschiedliche Systeme zu verbinden sind.

Für Integrationsanforderungen, die eine direkte Verteilung von Informationen entlang einer linearen Workflow-Kette in Form eines Publish- und Subscribe-Mechanismus benötigen, bieten sich die Bus- und Pipeline-Implementierung als direkte Verteilung an.

So kann ein Messaging-System die Auftragsdaten von einer Fabrik zur anderen transportieren - wenn nötig rund um den Erdball. Damit ließe sich ein Produktionsprozeß ausreichend gut integrieren. Auch für die Verteilung von Börsenkursen anhand vorab definierter Ereignisse an bestimmte Empfänger ist dieses Verfahren geeignet. Die Architektur ist dabei in der Regel datenbankorientiert, da die beiden Endpunkte des Workflows Datenspeicher sind.

Bei der Hub-and-Spoke-Implementierung verbindet ein zentraler Softwarebaustein unterschiedliche Anwendungen über diverse Hardware- und Betriebssystem-Plattformen hinweg. Der Hub steuert sowohl den Geschäftsprozeß als auch die Umsetzung der Integrationsregeln. Deshalb gibt es hier keine Trennung zwischen Workflow und Geschäftslogik. Für viele Integrationsanforderungen ist das ausreichend; problematisch wird es allerdings, wenn neue Geschäftsprozesse hinzukommen oder sich Abläufe oft verändern. In diesem Fall sind die Interfaces permanent anzupassen. Es lohnt sich daher, die späteren Wartungskosten bereits vor der Entscheidung für eine Lösung rechtzeitig zu berücksichtigen. Als Middleware kommen häufig asynchrone Messaging-Systeme zum Einsatz. EAI-Frameworks bilden die Architektur, weil damit die Integration unterschiedlicher Anwendungen mit geringstem Aufwand möglich ist.

Die Realisierung mittels Prozeß-Middleware umfaßt eine Trennung zwischen Connectoren, die die technische Anbindung der Anwendungen gewährleisten, und der Definition des Workflows, um die Regeln aufzustellen, nach denen ein bestimmter Geschäftsprozeß abläuft.

Dabei gehören Connectoren entweder zum Standardumfang der EAI-Produkte oder müssen mit Hilfe einer von einigen Herstellern mitgelieferten Entwicklungsumgebung individuell für unternehmensspezifische Anwendungen gebaut werden. Diesen Abläufen werden wiederum Programme mit bestimmter Geschäftslogik zugeordnet, um die Integrationslogik zwischen allen angeschlossenen Anwendungen an einer zentralen Stelle programmieren und kontrollieren zu können.

Der Ansatz mittels Prozeß-Middleware ist sinnvoll, wenn viele Anwendungen gleichzeitig miteinander integriert werden müssen. Vor allem auch unter dem Gesichtspunkt der späteren Erweiterung beziehungsweise der Notwendigkeit, Geschäftsprozesse und deren Abläufe ändern zu können, ohne immer wieder von vorn beginnen zu müssen. Lohnen soll sich der EAI-Einsatz ab fünf zu integrierenden Systemen.

Viele Hersteller bieten mittlerweile EAI-orientierte Middleware an (siehe Tabelle "Marktüberblick"). Es handelt sich jedoch meist um junge Firmen, so daß Anwendern klar sein sollte, daß die Lösungen oft noch reifen müssen. Diese Zeit sollte man den Herstellern einräumen und die eigene Projektplanung darauf abstellen - es lohnt sich.

EAI-Termine

16. und 17. August in Wiesbaden,

30. und 31. August in München,

14. und 15. September in Düsseldorf: "Enterprise Application Integration", Management Circle, anmeldungmanagementcircle.de

21. bis 24. September in London: "Integrating Applications 99", Giga Information Group, www.gigaweb.com

29. und 30. September in Nürnberg: "Anwendungsintegration in komplexen IT-Umgebungen", IIR Deutschland GmbH, www.iir.de

2. bis 4. November in Offenbach: "EAI-Forum 99", IIR in Zusammenarbeit mit Meta Group, yrengeriir.de

10. November in Frankfurt: "Application Integration Konferenz", Butler Group, www.butlergroup.com

*Richard Nußdorfer ist Geschäftsführer der CSA Consulting GmbH in München, www.csaconsult.com.