2014/11 | Fachbeitrag | Integrationsplattform
IT-Integration: Die Architektur entscheidet, nicht das Werkzeug
Inhaltsübersicht:
- Enterprise Application Integration – ein Ausweg aus der Komplexitätsfalle?
- Von SOA lernen: Integrationsplattform als Glueware
- Hybride Lösungen sichern Mehrwert in unterschiedlichen Szenarien
Eine effiziente Integrationsplattform ist zum entscheidenden Wettbewerbsvorteil in der vernetzten Wirtschaft geworden. Sich ständig verändernde Marktbedingungen, neue Kunden oder wechselnde Lieferanten und vor allem der steigende Druck zu mehr Effizienz erfordern eine immer höhere Reaktionsgeschwindigkeit und insbesondere mehr Flexibilität in der IT. Unternehmen, die gezielt ihre Fähigkeiten zur Integration verbessert haben, sind hier klar im Vorteil. Denn sie verfügen über schnellere Prozesse, einen einheitlichen Informationsstand über unterschiedliche Systeme hinweg und über die Fähigkeit zur flexiblen Einbindung von neuen Geschäftspartnern in ihre bestehenden Abläufe.
Die traditionelle Lösung für Integrationsanforderungen waren lange Zeit simple Punkt-zu-Punkt-Verbindungen zwischen den zu integrierenden Systemen – und zwar entweder direkt auf Datenbankebene, über Import-/Exportdateien oder aber mittels direkter API-Aufrufe. Der Vorteil solcher direkten Verbindungen ist, dass diese einfach und schnell im Bedarfsfall erstellt werden können. Ihr entscheidender Nachteil dagegen: Sie skalieren nicht. Mit jeder weiteren Einzelverbindung nimmt die Komplexität des Gesamtsystems bei Punkt-zu-Punkt-Verbindungen exponentiell zu. Experten sprechen in diesem Zusammenhang auch vom Spaghetti-Integrations-Dilemma: Würde man die Punkt-zu-Punkt-Integration grafisch darstellen, sähe sie aus wie sich kreuz und quer überlagernde Spaghetti, deren Anfangs- und Endpunkte nur noch schwer auszumachen sind.
Was im Einzelfall eine bequeme und schnelle Lösung darstellen kann, wird als strategischer Ansatz bei unternehmerischem Wachstum zwingend zur Komplexitätsfalle. Ein Beispiel: Sollen 50 verschiedene Systemschnittstellen miteinander verbunden werden, führt das zu stolzen 1.225 Einzelverbindungen. Und mit jeder hinzukommenden Verbindung wächst die Komplexität der IT-Architektur entsprechend. Unternehmen mit diesem Integrationskonzept werden auf Dauer durch ihre eigene IT also ausgebremst statt beflügelt – und vor allem durch neue IT-Investitionen, die doch eigentlich die Effizienz steigern sollen, immer unflexibler und anpassungsunfähiger.
Enterprise Application Integration – ein Ausweg aus der Komplexitätsfalle?
Mit dem Aufkommen von Enterprise-Application-Integration-Plattformen (kurz: EAI) verband sich die Hoffnung, einen Ausweg aus dem Spaghetti-Integrations-Dilemma zu finden. Theoretisch reduziert ein EAI-Hub tatsächlich die Komplexität der Integration in einem Hub-and-Spoke-Szenario, weil es – mathematisch gesprochen – die Anzahl der Verbindungen von n-mal m auf n Verbindungen reduziert. Alle Systeme werden jeweils einmalig über Adapter an die Integrationsplattform angebunden. Diese kann dann zentral so konfiguriert werden,, dass alle Daten eines Geschäftsprozesses zwischen den angebundenen Systemen in der richtigen Reihenfolge an die einzelnen Funktionen übermittelt werden.
Trotz der scheinbaren Verschlankung der IT ist das Ergebnis von EAI-Projekten häufig jedoch das Gleiche wie bei Punkt-zu-Punkt-Verbindungen – wenn nicht gar schlimmer: Aufgrund einer falschen zugrunde gelegten Architektur stehen am Ende vieler EAI-Projekte wieder nur Einzelverbindungen, die nur eben nicht mehr direkt zwischen den Endpunkten, sondern nun über den zwischengeschalteten Integrationsserver verlaufen. Aus Punkt-zu-Punkt wird in einer falsch implementierten Hub-and-Spoke-Integrationsarchitektur häufig eine Punkt-zu-Hub-zu-Punkt-Integrationslösung, die nicht weniger komplex ist als die oben genannte Spaghetti-Architektur und die gleichen Nachteile mit sich bringt. Eine Änderung an einem Endpunkt bedeutet die Änderung von n-Schnittstellen (die über den Integrationsserver laufen). Auch für EAI-Plattformen gilt also: Entscheidend ist nicht das Werkzeug, sondern dessen Verwendung. Die gewählte Architektur innerhalb der EAI-Plattform entscheidet über die Effizienz der darüber realisierten Anbindungen.
Von SOA lernen: Integrationsplattform als Glueware
Für die nötige Effizienz in der Integration von Systemlandschaften, die auch bei späterer Erweiterung flexibel, funktional und übersichtlich bleiben, sorgt dagegen die konsequente Anwendung der Prinzipien Serviceorientierter Architekturen (kurz: SOA) im Bereich der Integration. Leitidee einer solchen SOA ist die lose Kopplung gekapselter Komponenten über dynamische Bindungen. Überträgt man diesen Ansatz auf die Konzeption einer Integrationsplattform, wird diese zu einer Schicht, welche Anwendungen, Systeme und Prozesse zu Bausteinen einer übergreifenden IT-Struktur (Enterprise Architecture) abstrahiert und gleichzeitig die Glueware für deren Verknüpfung liefert (in Form von zentralen Diensten etc.).
Im Gegensatz zu einer Hub-and-Spoke-EAI-Plattform abstrahiert eine service-orientierte Integrationsschicht die angeschlossenen Applikationen zu Diensten, die von anderen angebundenen Komponenten eingesetzt werden können. Hinter dem Begriff SOA verbirgt sich also keine bestimmte Integrations-Technologie wie WebServices, REST, XML, MessageQueueing oder FileTransfer mehr, sondern vielmehr ein übergreifendes Architektur-Paradigma: SOA liefert ein Muster für die Gestaltung besserer Integrationslösungen und damit für die Bewertung der Qualität von Integrationsarchitekturen im Allgemeinen, unabhängig von den Technologien für einzelne Schnittstellen.
Es lohnt sich daher, die Qualitätskriterien einer Serviceorientierten Integrationsarchitektur einmal näher zu betrachten. Wichtigstes Merkmal ist die vollständige Abstraktion: Alle systemspezifischen Parameter einer abzubildenden Verbindung (A-B) werden in die Integrationsschicht (I) gezogen, so dass aus A-B voneinander unabhängige Verbindungen A-I und I-B entstehen. Diese zeichnen sich nun durch ihre lose Kopplung aus: Die Verbindung von A-I und I-B zu A-I-B ist innerhalb von I also nicht hart verdrahtet, sondern entsteht im Falle einer auszuführenden Nachrichtenübertragung durch eine dynamische Bindung zur Laufzeit. Das Routing von A-I zu I-B innerhalb von I wird allein anhand der Nachricht zum Zeitpunkt der Übertragung ermittelt. Die Integrationsplattform ist selbst in der Lage, der Nachricht zu entnehmen, wo sie hin muss, sie muss es nicht vom Sender mitgeteilt bekommen.
Der Vorteil liegt auf der Hand: Ändert sich an der Schnittstelle A-I etwas, muss nur diese angepasst werden und nicht die n Schnittstellen (wie z.B. I-B), welche auf die Daten von A zugreifen wollen, weil jene dies nicht direkt, sondern über die Integrationsschicht I tun. Auch die Auslagerung wiederkehrender Aufgaben im Rahmen der Integration (z.B. Logging, Laststeuerung, Sequenzierung, Monitoring) in zentrale Dienste, welche die Integrationsschicht für alle eingebundenen Systeme und Austauschprozesse bereitstellt, kann in einer solchen Integrationsarchitektur effizient gewährleistet werden. Auch das spart signifikant Kosten. Letztes wichtiges Kriterium ist der Grad der Standardisierung: Geschäftsprozesse können in einer solchen Architektur einfach und effizient standardisiert werden, da die einzelnen Schritte als Dienste gekapselt zur Verfügung stehen und sich einzeln bei Bedarf in übergreifende Abläufe einbinden lassen.
Eine entsprechende Ausgestaltung der Integrationslösung unter der Leitidee einer Abstraktionsschicht im Sinne einer SOA bietet also entscheidende Vorteile vor allem in puncto Flexibilität: Sie ermöglicht ein flexibles Einbinden und Ausgliedern angebundener Komponenten (Anwendungen, Dienstleister usw.), da diese von einander durch die Integrationsschicht abstrahiert werden. Auch die Wiederverwendbarkeit zentraler Komponenten ist ein wichtiger Pluspunkt: Dadurch kann der Aufwand bei Anpassungen und Erweiterungen deutlich verringert werden, weil jene nur noch einmal an zentraler Stelle vorgenommen werden müssen und nicht mehr in den Einzelverbindungen. Des Weiteren steigen die Managebarkeit und die Zuverlässigkeit – letzteres insofern, als die Erfüllung von Anforderungen an die Performanz und Verfügbarkeit zentral gewährleistet werden. Und nicht zuletzt bringt eine Server-orientierte Architektur neue Monitoring-Möglichkeiten mit sich. Bewegungsdaten und die zugehörigen Prozesse können im Sinne einer professionellen Process Intelligence zentral ausgewertet werden.
Hybride Lösungen sichern Mehrwert in unterschiedlichen Szenarien
Diese Vorteile müssen jedoch im Einzelfall abgewogen werden gegen die damit verbundenen Nachteile. Es ist nicht von der Hand zu weisen, dass der Aufbau der zentralen Komponenten mit einem deutlichen Mehraufwand verbunden ist. Ebenfalls kritisch zu betrachten ist der Overhead bei der Nachrichtenaufbereitung (zum Beispiel im Zuge der Trennung von Nachrichten und Metainformationen für das Routing), aber auch der erhöhte Ressourcenverbrauch in der Schicht, denn die Latenzzeiten vergrößern sich bei hohen Performanzansprüchen spürbar.
Erst auf der Grundlage einer sorgfältigen Abwägung von Vor- und Nachteilen kann im Einzelfall die richtige Entscheidung für das eine und gegen das andere Architekturmuster getroffen werden. Die QUIBIQ GmbH mit Sitz in Stuttgart, die über die Best Practices aus über 400 Integrationsprojekten verfügt, empfiehlt in der Regel den Einsatz von hybriden Architekturen, die für die unterschiedlichen Bedarfsfälle auch die passenden Varianten anbieten und sich in der Praxis besonders bewährt haben. Der Großteil der Verbindungen kann effizient im Standard über die Abstraktionsschicht abgewickelt werden – hier gilt die 80/20-Regel –, während für Spezialfälle weiterhin dedizierte Verbindungen über den zentralen EAI-Hub möglich sind.