Was ist Integration?

Unter IT- oder Systemintegration versteht man die Verknüpfung von Daten, Anwendungen, APIs und Geräten im gesamten Unternehmen zur Steigerung von Effizienz, Produktivität und Agilität. Integration ist beim Thema geschäftliche Transformation (fundamentale Änderungen an Geschäftsprozessen zur Anpassung an Marktverschiebungen) enorm wichtig, da sie dafür sorgt, dass alle IT-Komponenten zusammenpassen. Sie verbindet nicht nur, sondern schafft auch Mehrwert durch neue Funktionalitäten, die durch die Verknüpfung von unterschiedlichen Systemfunktionen entstehen. So ist Apache Kafka beispielsweise eine Open Source-Plattform, mit der Sie Daten-Streams in Ihre Anwendungen integrieren und so Daten in Echtzeit verarbeiten können.

Man darf IT-Integration aber nicht mit Continuous Integration (CI) verwechseln, einer Entwicklungspraktik, bei der funktionierende Code-Kopien mehrmals am Tag in einem gemeinsames zentrales Repository zusammengeführt werden. Ziel der CI ist die Automatisierung von Builds und Prüfungen, damit Probleme frühzeitig erkannt werden können und so die Entwicklung beschleunigt wird.

Mit der Zeit wuchsen und entwickelten sich die IT-Systeme. Dabei entfernten sie sich immer mehr voneinander. Die Lösungen eines Anbieters konnten nicht mehr mit denen eines anderen kommunizieren. Dies führte unweigerlich dazu, dass der gesamte IT-Stack nur eine einzige Sache gemein hatte, nämlich den Eigentümer. Es wurde also eine Strategie zur Organisation dieser verschiedenen Technologiestränge benötigt, um doppelte Prozesse zu eliminieren, vor allem bei der Implementierung von Geschäftslogik.

*Hinweis: Folgende Begrifflichkeiten werden unterschiedlich verwendet: physische Topologien versus logische Topologien, Konzepte versus Architekturen versus Technologien. Die unten angeführten Erläuterungen dienen als allgemeiner Überblick.

Integration von Unternehmensanwendungen

Eine Lösung für diesen unkontrollierbaren Wildwuchs war EAI (Enterprise Application Integration, Unternehmensanwendungsintegration), also Technologien, Tools und ein Framework für die nachrichtenbasierte Echtzeitintegration zwischen Apps. Diese Nachrichten werden von Änderungen oder Parametern ausgelöst, die in die einzelnen Apps eingebaut sind. EAI konnte dabei auf zwei mögliche Wege erreicht werden: als Point-to-Point- oder als Hub-and-Spoke-Modell.

Beim Point-to-Point-Modell muss jede Anwendung ganz genau auf die Kommunikation mit anderen Anwendungen und Komponenten Ihrer IT zugeschnitten werden. Das betrifft alle IT-Komponenten und alle weiteren Elemente, mit denen sie verbunden sind. Der ganze Vorgang ist extrem mühsam und verständlicherweise höchst fehleranfällig. Und was alles noch schlimmer macht, ist die Tatsache, dass die Wartung dieses Modells immer komplexer wird, je häufiger die Infrastruktur und die Apps im Lauf der Zeit aktualisiert werden.

Um dies zu vermeiden, wurde das Hub-and-Spoke-Modell entwickelt, bei dem die Verbindungen zwischen Apps und Services über einen zentralen Broker, den Hub, verwaltet werden. Die „Speichen", die die „Nabe" mit den Apps und Services verbinden, können individuell gewartet werden. Da alle Integrationen gehandhabt werden, können die Apps selbst viel zielgerichteter sein. Der große Nachteil dieser Variante ist die Zentralisierung des Hubs. Denn der Hub wird zum Single Point of Failure für das System und Ihre Infrastrukturkommunikation. Alle Integrationen in das EAI Hub-and-Spoke-Modell sind designtechnisch von der Verbindung zwischen Hub und Funktion abhängig.

ESB (Enterprise Service Bus)

Auf das EAI Hub-and-Spoke-Modell folgte der ESB (Enterprise Service Bus), ein Tool mit nachrichtenbasierter Abstraktion, das die Services zwischen den Anwendungen modularisiert.

Ein ESB fungiert auch als zentraler Hub, in dem alle modularisierten Services geteilt, umgeleitet und organisiert werden, um Ihre Apps und Daten untereinander zu verbinden. Diese Lösung ist dem EAI Hub-and-Spoke-Modell vorzuziehen, ist aber nicht die ultimative Lösung für Unternehmen, die kontinuierlich wachsen, Komponenten hinzufügen und immer mehr Geschwindigkeit zwischen all ihren Standorten und Software-Ressourcen benötigen.

Sie vermuten sicher schon, dass ein ESB einem Hub-and-Spoke-Modell sehr ähnelt. Und Sie liegen richtig. Allerdings unterscheidet sich ein ESB auch in einigen besonderen Funktionen deutlich.

• ESBs sind Services, die offene Standards verwenden. Dadurch entfällt die Notwendigkeit, individuelle Schnittstellen für jede einzelne Anwendung schreiben zu müssen.
• Integrationsservices können mit minimalem Änderungsaufwand für Anwendungen bereitgestellt werden.
• ESBs basieren auf branchenüblichen offenen Protokollen und Schnittstellen, die neue Deployments vereinfachen.

Allerdings führen typische ESB-Deployments (aus den im Zusammenhang mit dem Hub-and-Spoke-Modell erwähnten Gründen) meist zu zentralen Architekturen, genauer gesagt, zu einem zentralen Ort für das Hosting und Management aller Integrationsservices. Zentrale ESB-Deployments und -Architekturen wiederum enthalten eine starre zentrale Governance, die eine Bereitstellung schnellerer und anpassungsfähigerer Lösungen behindert, die die Grundlage aller Digitalisierungsinitiativen bilden. Auch werden die ESBs am Ende nicht selten selbst zu monolithischen Anwendungen.

Agile Integration

Bis dato haben wir über die reine Integration gesprochen, also die Technologien, mit denen alle Komponenten zusammen funktionieren sollen. Was ist dann also agile Integration? Einfach gesagt, geht es hier darum, wie Red Hat die Zukunft verbundener Systeme sieht und wie diese den kontinuierlichen Erfolg der eigentlichen Arbeit Ihrer IT-Teams unterstützen, besonders wenn Änderungen mit höherer Frequenz auftreten.

Red Hat ist der Überzeugung, dass der herkömmliche Integrationsansatz, bei dem ein zentrales Team die monolithische Technologie steuert, die Entwicklung und langfristig den Nutzen verteilter Anwendungen einschränken kann. Traditionelle Lösungen wie ESBs haben ihre Vorteile, da beispielsweise der Sicherheits- und Datenintegrität Priorität eingeräumt wird. Sie hängen aber auch von einem einzelnen Team ab, wenn Integrationen für das gesamte Unternehmen definiert werden müssen.

Die mithilfe von agilen und DevOps-Methoden erstellten, lose gekoppelten, cloudnativen Anwendungsarchitekturen von heute benötigen eine gleichermaßen agile wie skalierbare Integrationsstrategie. So interpretiert auch Red Hat agile Integration, nämlich als Konzept zur Verbindung von Ressourcen, das Integrationstechnologien, agile Bereitstellungstechniken und cloudnative Plattformen kombiniert, um die Softwarebereitstellung zu beschleunigen und sicherer zu machen. Insbesondere umfasst eine agile Integration den Einsatz von Integrationstechnologien (wie APIs in Linux-Containern) und die Ausweitung von Integrationsrollen auf funktionsübergreifende Teams. Eine agile Integrationsarchitektur kann in drei Schlüsselfunktionen aufgeteilt werden: verteilte Integration, Container und APIs.