Die evolutionsgeschichtlich ältesten Teile unseres Gehirns interagieren, vom Bewusstsein unbemerkt, reibungslos mit den neuesten Technologien im menschlichen Zentralnervensystem, obwohl diese "Systemwelten" durch Millionen Entwicklungsjahre voneinander getrennt sind. Die Evolution hat einfach genug Zeit gehabt, die erforderlichen Schnittstellen gleich mitwachsen zu lassen.
Komplexe HerausforderungenGanz ähnlichen Aufgaben müssen sich Unternehmen stellen, die beispielsweise Applikationen ins Internet stellen wollen und dafür auf Mainframe-gestützte Programmteile zugreifen müssen, deren Codes niemand mehr kennt und die sich genauso wenig umschreiben lassen wie die Reaktionsmuster des menschlichen Stammhirns. Nur ist Zeit heute eine knapper bemessene Ressource. So bieten alle großen IT-Häuser Lösungen an, die es dem Anwender ersparen, individuelle Schnittstellen zwischen Legacy-Systemkomponenten und zukunftsweisenden Programmierwelten zu schreiben.
Zwar kann es sinnvoll sein, hausintern APIs zu programmieren, wenn es um eng begrenzte Integrationsaufgaben geht und das betreffende Projekt damit definitiv abgeschlossen ist. Meist aber sind die Herausforderungen komplexer, sei es im oben beschriebenen Beispiel, sei es, dass mobile Anwendungen in eine bestehende IT-Infrastruktur eingebettet werden sollen oder dass durch Fusionen und Übernahmen eine sehr heterogene IT-Landschaft entstanden ist. Möglicherweise möchte auch ein Unternehmen neue Technologien einführen, ohne die Investitionen in Legacy-Systeme abschreiben zu müssen. Häufig entsteht Integrationsbedarf auch aus Anforderungen des Managements, wenn es etwa darum geht, IT-Landschaften flexibler an die Entwicklung der Geschäftsprozesse anzupassen.
Welchen Weg man wählt, hängt ebenso von technischen wie von kaufmännischen Erwägungen ab, von Prognosen für die Entwicklung des Unternehmens und den empfundenen Mängeln der bestehenden IT-Struktur.
In vielen Unternehmen sind - historisch bedingt - Daten in getrennten Systemen gespeichert und werden in unterschiedlichen Systemwelten generiert. Brauchen nun verteilte Applikationen Zugriff auf diese Daten, so ist das Problem häufig mit einer einfachen Datenintegration durch Replikations-Server gelöst (siehe Grafik "Datenbankintegration"). Dabei sollte es aus Client-Sicht nicht mehr spürbar sein, wenn Tabellen für eine Anwendung aus ganz unterschiedlichen Datenbanken aufgerufen werden. Vor allem darf sich dies nicht auf die Leistung auswirken.
Über Replikationsmechanismen lassen sich allerdings nicht die hinter den Applikationen steckenden Geschäftsprozesse abbil-den. Zwar besteht die Möglichkeit, auf der Replikationsebene Messages zu generieren, die in bestimmten Zielsystemen Prozesse anstoßen. Soll die Geschäftslogik aber tatsächlich integriert werden, so muss man einen Schritt weiter gehen. Von den unternehmerischen Zielen hängt es ab, ob eine Komponenten- beziehungsweise Methodenintegration oder eine nachrichtenbasierte Adapterlösung die bessere Wahl ist.
Die erste Option führt in eine Mehrschicht-Architektur, bei der ein Applikationsserver auf die Datenbank(en) aufsetzt und beliebige Clients auf die hier abgelegte Business-Logik zugreifen (auch mobile Endgeräte, Web-Clients etc.). Diese mittlere Schicht weist stets zwei Bestandteile auf: einen Page Server, der HTML-Seiten für Browser generiert, und einen Komponenten-Transaktionsserver.
Die Integration auf diesem Wege erfordert auf der einen Seite einigen Aufwand, denn die Business-Logik muss in die Applikations-Server-Schicht migrieren. Dafür sind alle Applikationen zunächst in Komponenten zu zerlegen. Auf der anderen Seite erkauft man sich mit diesem Aufwand einen erheblichen Zugewinn an Skalierbarkeit und Offenheit.
Ein Höchstmaß an OffenheitAllerdings kommen diese Stärken nur zum Tragen, wenn die gewählte Applikations-Server-Technologie tatsächlich ein Höchstmaß an Offenheit aufweist. Sie sollte also Corba- und J2EE-fähig sein und eine freie Definition dessen zulassen, was im Sinne der Architektur als Komponente aufgefasst wird: beispielsweise komplette Applikationen, ganze SAP-Systeme, eine aus der Legacy-Welt stammende Bibliothek, ein Objekt oder eine Funktion, die vor Urzeiten einmal zur Mehrwertsteuerberechnung geschrieben wurde. Nur wenn sich all diese Systembestandteile beliebig als Komponenten im Applikations-Server abbilden lassen, kann das Systemdesign flexibel an die Geschäftsprozesse angeschmiegt werden.
Dafür muss man auch Bausteine integrieren können, die sich nicht in Komponenten zerlegen lassen (zum Beispiel SAP oder Mainframe-Applikationen). Eine elegante Lösung besteht darin, lediglich einen "Platzhalter" für die gewünschten Bestandteile der Business-Logik abzubilden. Die damit verbundenen Aufgaben werden dann weiterhin zum Beispiel in SAP abgearbeitet, aber der Zugriff auf diese Funktion ist eine Komponente des Applikations-Servers.
Interessante AlternativeWenn Time to Market ein besonders kritischer Faktor ist, kann eine nachrichtenbasierende Adapterlösung die interessantere Alternative darstellen. Dabei kommunizieren alle zu integrierenden Systembestandteile über einen zentralen "Hub" miteinander, einen Integrations-Server, den man sich als Drehscheibe für ein- und ausgehende Nachrichten vorstellen muss.
Die Server-Technologie sorgt dafür, dass die Messageformate so "übersetzt" werden, dass das jeweils angesprochene System entsprechend der Geschäftsprozesslogik reagiert. Ferner ist ein Regelwerk hinterlegt, das festlegt, in welche Systembestandteile eingehende Nachrichten zu replizieren sind oder wo eine angesprochene Applikation zusätzliche Daten zur Bearbeitung eines Vorgangs abruft. Mit dieser Technik lassen sich Geschäftsprozesse einfach und sicher für B-to-B-Lösungen oder die Direktanbindung mobiler Komponenten gegenüber Dritten öffnen. Applikations-Server benötigen dafür zusätzlich Web-Service-Technologien wie SOAP, die entsprechende Adaptermechanismen simulieren.
Da alle Systembestandteile unverändert bleiben, entsteht kein Migrationsaufwand. Aber aus demselben Grund skaliert ein rein nachrichtenbasierendes System nur schwerfällig. Außerdem muss man sich auf eine Vendor-Technologie festlegen und bleibt nicht so unabhängig von Anbietern wie bei der Integration mittels Applikations-Server. Im Übrigen sollten Kunden vor der Entscheidung für eine bestimmte Adapterlösungen folgende Fragen stellen: Erlaubt die angebotene Technik die Verwendung verschiedenster Message-Systeme? Wie wirkt sich eine steigende Anzahl von Messages auf die Leistung aus? Wie transparent lassen sich die Geschäftsprozesse auf einer über Formatierungs- und Regelwerk angesiedelten Prozess-Server-Schicht abbilden?
Unabhängig vom gewählten Weg zur Integration der Backend-Systeme sollte die Vereinheitlichung der Oberfläche nicht vergessen werden. Die Konsolidierung der verschiedenen Benutzerschnittstellen und Sichten (etwa Geschäftspartner, Kunden und Mitarbeiter) über ein Portal bietet sich als das sprichwörtliche Tüpfelchen auf dem "i" an, um die Integration im Frontend-Bereich abzurunden. (bi)
*Frank Irnich ist Presales Manager E-Business Division Europe bei Sybase in Düsseldorf.
AngeklicktAuf die ständige Weiterentwicklung der Geschäftsanforderungen ihrer Kunden reagiert die IT-Branche mit immer wieder neuen Software- und Systemdesignlösungen. Deren Integration mit den Legacy-Systemen wird zu einer immer komplexeren Aufgabe. Einen Königsweg gibt es nicht, denn je nach Erwartungen, Zielen und Zeithorizont kann die jeweils effizienteste Antwort ganz unterschiedlich ausfallen. Die Palette reicht von individuellen Schnittstellen über Datenintegration und Replikationsmechanismen bis zur nachrichtenbasierenden Adaptertechnologie.
Abb.: Datenbankintegration
Integration auf Datenebene kann durch einen einfachen Replikationsmechanismus bewirkt werden. Quelle: Sybase