Integrationsarchitektur

Woran erkennt ein versierter IT-Architekt, ob die Anwendungslandschaft in einem Unternehmen flexibel und zukunftsfähig aufgebaut ist oder eine sanierungsbedürftige Altlast darstellt? Und woran erkennt er, ob er es mit einem  digitalen Ökosystem oder nur mit  vernetzten Systemen zu tun hat? Er erkennt es an der Integrationsarchitektur! Es gibt verschiedene Arten von Integrationsarchitekturen, die unterschiedliche  Integrationsmuster umsetzen können. Hier zeige ich die wichtigsten Integrationsarchitekturen und ihre Unterscheidungsmerkmale. Denn für eine gute Unternehmensarchitektur ist es wichtig zu wissen, was integriert werden soll. Ein weiterer Artikel mit  Integrationsmustern zeigt dann das Wie. Die Integration von Anwendungen und IT-Systemen ist ein konkreter, realer Ausdruck der Pläne und Richtlinien, für die ein Unternehmensarchitekt verantwortlich ist. Daher ist Integration eines der wichtigsten Themen, mit denen sich Architekten beschäftigen müssen, damit eine Enterprise Architektur kein Papiertiger im Elfenbeinturm bleibt.

Integration ist komplex und kein rein technisches Thema. Für jede Art der Integration gibt es geeignete und ungeeignete Protokolle und Datenformate. Vor allem aber muss jede Art der Integration anders organisiert werden. Dieser Artikel gibt einen Überblick und zeigt die Unterschiede zwischen den in der obigen Abbildung dargestellten Integrationsarchitekturen auf: Intra-Application-Integration: Wenn man sich eine Anwendung wie ein Haus vorstellen kann, dann ist Intra-Application-Integration die Treppe, die die verschiedenen Stockwerke miteinander verbindet.

• Inter-Application-Integration: Verbindet verschiedene Häuser über direkte Wege: einfache Straßen, Feldwege, Trampelpfade.
• Enterprise-Integration: Schafft explizite innerstädtische Straßen und deren Zufahrten
• Ecosystem-Integration: Stellt Bundesstraßen, Autobahnen oder auch Schienenwege dar, die große Stadtteile oder ganze Städte miteinander verbinden.

In den meisten Fällen macht es wenig Sinn, zwei Häuser mit einer Treppe zu verbinden. Genauso wenig macht es Sinn, die Stockwerke eines Hauses mit einer Autobahn zu verbinden. In IT-Landschaften von Unternehmen habe ich beides schon gesehen. Deshalb ist es wichtig, über die verschiedenen Integrationsarchitekturen nachzudenken und die Unterschiede zu respektieren.

Intra-Application-Integration

Die Intra-Application-Integration beschreibt die Integration von Komponenten innerhalb einer Anwendung. Hier geht es um das Zusammenspiel der Komponenten, die eine Anwendung zum Funktionieren benötigt. Im Vergleich zu allen anderen Integrationsarchitekturen weist diese die stärkste Kopplung auf. Denn innerhalb einer Anwendung können Komponenten wie Middleware oder Datenbank stark voneinander abhängig sein. Welche Technologien, Protokolle, Datenformate und Integrationsmuster verwendet werden, hängt ganz von der individuellen Anwendung ab. Organisatorisch kann eine Intra-Application-Integration innerhalb des Teams, das die Anwendung entwickelt, geregelt werden.

Inter-Application-Integration

Die Inter-Application-Integration verbindet zwei oder mehr Anwendungen direkt miteinander. In den meisten Fällen ist dies die Bereitstellung einer Schnittstelle von einer Anwendung zu einer anderen Anwendung. Die Kopplung ist loser als bei der zuvor genannten Intra-Application-Integration. Die Datenformate und Protokolle müssen zwischen den Anwendungen abgestimmt werden. Formal kann dafür ein individuell gestalteter Schnittstellenvertrag verwendet werden. Organisatorisch kann diese Art der Integration innerhalb einer Projekt- oder Produktorganisation geregelt werden.

Die Integration zwischen Anwendungen kann konzeptionell in 3 verschiedenen Schichten stattfinden:

• Präsentationsschicht: Hier findet die Integration im Frontend statt. Das heißt, eine Anwendung zeigt das Frontend einer anderen an. Für die Integration von Daten ist diese Schicht weniger geeignet. Sie ist gut geeignet, wenn ein Webportal mehrere unabhängige Anwendungen integrieren soll. Auf dieser Ebene gibt es verschiedene Stufen - von der Einbettung eines Frames über Single Sign-On bis hin zu Session- oder Cookie-Sharing.
• Logische Schicht: Auf dieser Ebene findet die eigentliche Integration verschiedener Anwendungen statt. Schnittstellen, die eine Anwendung zum Datenaustausch mit anderen Anwendungen anbietet oder nutzt, befinden sich auf dem Logical Layer. Je nach Größe der Anwendung kann hier eine Schnittstellenschicht als Teilschicht ausgeprägt sein.
• Persistenzschicht: Früher war es nicht unüblich, heute gilt es als Anti-Pattern, eine Anwendungsintegration auf der Persistenzschicht zu implementieren (siehe auch:  Shared Database). Der direkte Zugriff einer Anwendung auf die Datenbank einer anderen Anwendung kann - obwohl oft schnell und einfach - ungeahnte Folgen haben. Moderne Anwendungen speichern nicht nur “dumme” Daten. Eine Anwendung arbeitet mit Business-Objekten. Diese Objekte können auch Methoden enthalten, die dann in einer logischen Schicht implementiert werden. Greift man direkt auf die Persistenzschicht zu, ohne die Logikschicht zu durchlaufen, fehlt die Ausführung dieser Methoden und es werden falsche, inkonsistente oder schlicht falsche Daten gelesen oder geschrieben.

Enterprise-Integration

Die Enterprise-Integration wird wichtig, wenn ein Unternehmen mehr als eine Handvoll Anwendungen in seiner IT-Landschaft hat, die Daten austauschen müssen. Bei wenigen Anwendungen ist die Enterprise-Integration von untergeordneter Bedeutung. Handelt es sich jedoch um mehrere hundert Anwendungen, wird Enterprise-Integration zu einem strategischen Faktor, der über Erfolg oder Misserfolg der gesamten Anwendungslandschaft entscheiden kann.

Eine Enterprise-Integration erfordert technische und organisatorische Veränderungen im Unternehmen: Die Integration muss gemanagt und umgesetzt werden. Während einzelne Schnittstellen zwischen Anwendungen in Projekten nebenbei realisiert werden können, muss eine Enterprise-Integration durch eigene Teams und Verantwortlichkeiten realisiert werden. Es braucht eine dedizierte Verantwortung für die Steuerung der Datenflüsse und Teams, die die entsprechende Middleware implementieren.

Technisch kommt hier erstmals ein Integration Layer, also eine Integrationsschicht zum Einsatz. Diese Schicht ist kein einzelnes System, sondern kann aus mehreren Systemen bestehen. Je nachdem welche  Integrationsmuster benötigt werden, kann so eine Schicht beispielsweise aus einem API-Gateway, einer Message-Oriented-Middleware und einem S3-Server zum Filetransfer bestehen. Was genau in diese Schicht muss, hängt individuell vom Unternehmen ab.

Ecosystem-Integration

Setzt ein Unternehmen auf  Digitalisierung oder sollen mehrere Unternehmen integriert werden, muss die Integrationsarchitektur dem Rechnung tragen. Im Kern geht es darum, die Integrationsschicht in zwei Schichten aufzuteilen:

• Die innere Integrationsschicht (Inner Integration Layer)
• Die äußere Integrationsschicht (Outer Integration Layer)

Die innere Integrationsschicht wird sich im Laufe der Entwicklung eines digitalen Ökosystems aus der Integrationsschicht der Enterprise-Integration entwickeln und dient vor allem der schnellen und flexiblen Integration der Anwendungen untereinander. Die äußere Integrationsschicht wird dagegen neu entwickelt. Die Trennung von Inner Integration Layer und Outer Integration Layer ermöglicht einerseits eine höhere Skalierbarkeit der Architektur und hilft andererseits, den Widerspruch zwischen schneller und einfacher und nachhaltiger und robuster Integration zu überwinden. Die Technologien und die  Integrationsmuster können in beiden Schichten die gleichen sein. Dennoch unterscheidet sich die äußere Integrationsschicht in wichtigen Punkten von der inneren:

• Sie muss stärker abgesichert sein, da Daten außerhalb eines bestimmten Bereichs übertragen werden
• Sie muss stärker reguliert sein, da sie persistente Schnittstellen nach außen bieten soll
• Sie dient als eine Fassade, die die darin gekapselten Anwendungen von außen gesehen wie eine einzige aussehen lassen soll

Was genau in diesem Sinne innen und außen ist, unterscheidet sich je nach Szenario. Am einfachsten kann innen innerhalb eines Unternehmensnetzwerks sein und außen außerhalb davon. Komplizierter wird es bei Zero-Trust-Architekturen - hier kann innen jede Anwendung sein, die per unternehmensweitem SSO authentifiziert wird und außen jede andere. Noch interessanter wird es, wenn  Enterprise Architektur Schnittkanten verwendet werden. In diesem Fall verbinden die äußere Integrationsschichten die Bereiche der Anwendungslandschaft.

Die Schnittstellen des Inner Integration Layer müssen wie bei der Enterprise-Integration organisatorisch und technisch unterstützt werden. Die Schnittstellen des Outer Mediation Layer sollten dagegen nicht nur betreut, sondern als eigenes Produkt betrachtet und verwaltet werden - mit entsprechenden Verantwortlichen und Budgets. Die Consumer des Outer Integration Layer sollten als Kunden betrachtet werden und es müssen klare Strategien bezüglich Versionierung, Releases, Features und Sicherheit der Integration existieren und umgesetzt werden.

Fazit

Bei den dargestellten Integrationsarchitekturen unterscheiden sich die Technologien, Datenformate und Protokolle. Nicht jedes Protokoll, das für eine Intra-Application-Integration geeignet ist, kann auch für eine Enterprise-Integration verwendet werden. Auf diese Details geht der Artikel  Integrationsmuster näher ein. Aber das ist nicht das Entscheidende! Integrationsarchitekturen unterscheiden sich im Wesentlichen darin, wer für die Integrationen verantwortlich ist und wie die Schnittstellen gehandhabt werden (siehe folgende Tabelle). Werden diese Dinge außer Acht gelassen und Integration nur als technisches Problem betrachtet, ist das Chaos in der Anwendungslandschaft vorprogrammiert. Spätestens ab der Stufe Enterprise-Integration ist Integration ein IT-Management-Thema.