Systemintegration für geschäftskritische Systeme: Muster, die in Produktion bestehen

Systemintegration entscheidet darüber, ob ein geschäftskritischer Prozess unter Last trägt oder bricht. In den meisten gewachsenen Unternehmen ist sie über Jahre als Folge von Einzelentscheidungen entstanden, nicht als Architektur. Das Ergebnis ist eine Landschaft, die niemand mehr vollständig versteht und an der jede Änderung teuer wird. Dieser Artikel ordnet die gängigen Integrationsmuster ein, zeigt, wann welches unter realer Transaktionslast trägt, und beschreibt den realistischen Weg aus dem Spaghetti-Zustand.

Warum Punkt-zu-Punkt am Ende immer scheitert

Am Anfang ist Punkt-zu-Punkt-Integration die naheliegende Lösung. Zwei Systeme müssen Daten austauschen, also baut ein Team eine direkte Verbindung. Schnell, billig, funktioniert.

Das Problem ist nicht die einzelne Verbindung. Es ist die Summe. Mit jedem neuen System wächst die Zahl möglicher Verbindungen nicht linear, sondern quadratisch. Bei fünf Systemen sind bis zu zehn Verbindungen denkbar, bei zwanzig sind es bis zu 190. Jede davon hat ein eigenes Format, ein eigenes Fehlerverhalten, einen eigenen Eigentümer, der das Unternehmen vielleicht längst verlassen hat.

In einer typischen gewachsenen DACH-Landschaft sieht das so aus: ein Kernsystem aus den 90ern, drei Generationen CRM, ein halbes Dutzend Fachanwendungen, mehrere Datenbanken, die direkt aufeinander zugreifen, und ein Geflecht an nächtlichen Batch-Jobs, die niemand anzufassen wagt.

Die Kosten dieser Landschaft sind real, auch wenn sie selten direkt sichtbar werden:

• Änderungskosten: Eine Schemaänderung in einem System zwingt zu Anpassungen in jedem direkt angebundenen System. Niemand kennt die vollständige Liste der Abhängigkeiten.
• Ausfallrisiko: Eine fehlerhafte Verbindung kann eine Kaskade auslösen, deren Pfad im Vorhinein niemand absehen konnte.
• Wissensverlust: Punkt-zu-Punkt-Logik liegt verstreut in Skripten, Triggern und Konfigurationen. Es gibt keine zentrale Stelle, an der man die Integrationslandschaft ablesen kann.

Punkt-zu-Punkt ist kein Fehler, solange die Zahl der Systeme klein und stabil bleibt. Es wird zum Problem genau in dem Moment, in dem das Geschäft wächst, also genau dann, wenn man es am wenigsten gebrauchen kann.

Hub-and-Spoke und der ESB: Zentralisierung mit Tücken

Die historische Antwort auf den Spaghetti-Zustand war der Enterprise Service Bus. Statt dass jedes System mit jedem spricht, kommuniziert jedes System nur noch mit einem zentralen Bus, der Nachrichten transformiert, routet und an die Empfänger verteilt. Aus einem Netz von Punkt-zu-Punkt-Verbindungen wird ein Hub-and-Spoke-Modell.

Der Gewinn ist konkret: Die Zahl der Verbindungen wächst wieder linear statt quadratisch. Transformation und Routing leben an einer definierten Stelle. Protokollbrüche zwischen Alt und Neu (etwa SOAP gegen REST, oder eine proprietäre Schnittstelle gegen ein modernes Format) werden zentral aufgelöst.

Der ESB hat aber seinen Ruf nicht ohne Grund. Die wiederkehrenden Probleme:

• Der Bus wird zum Engpass. Wenn jede Nachricht durch eine zentrale Komponente läuft, ist diese Komponente der einzige Punkt, an dem unter Last alles bricht. Skalierung muss von Anfang an mitgedacht werden.
• Geschäftslogik wandert in den Bus. Was als reine Vermittlungsschicht beginnt, sammelt mit der Zeit Transformationen, Validierungen und Sonderregeln an. Der Bus wird selbst zum schwer wartbaren Monolithen.
• Ein Team wird zum Flaschenhals. Wenn jede Integration durch das ESB-Team muss, wird dieses Team zum Engpass jedes Projekts im Unternehmen.

Ein ESB ist kein Auslaufmodell. In Landschaften mit vielen heterogenen Altsystemen, die schwergewichtige Transformation und garantierte Zustellung brauchen, ist er nach wie vor eine valide Wahl. Er scheitert dort, wo er als Universallösung für alles missverstanden wird, statt als ein Werkzeug unter mehreren.

API-led: Integration als Produkt

Das API-led-Modell verschiebt den Schwerpunkt. Statt einer schweren zentralen Vermittlungsschicht stellt jedes System seine Fähigkeiten über klar definierte, versionierte APIs bereit. Integration wird zur Komposition dieser APIs, gesteuert über ein API-Management-Layer für Authentifizierung, Drosselung, Versionierung und Monitoring.

Ein bewährtes Ordnungsprinzip unterscheidet drei Ebenen:

• System-APIs kapseln den direkten Zugriff auf ein Quellsystem. Sie verbergen dessen Eigenheiten und bleiben auch dann stabil, wenn das System dahinter ausgetauscht wird.
• Prozess-APIs orchestrieren mehrere System-APIs zu einem fachlichen Ablauf, etwa der Anlage eines Kunden über mehrere Systeme hinweg.
• Experience-APIs liefern Daten so, wie ein konkreter Kanal (Web, App, Partnerportal) sie braucht.

Der Vorteil dieser Schichtung: Eine Änderung am Quellsystem bleibt hinter der System-API verborgen. Die darüberliegenden Schichten merken nichts davon. Das ist genau die Entkopplung, die in einer Punkt-zu-Punkt-Landschaft fehlt.

API-led trägt gut bei synchronen Abfragen und Orchestrierungen, bei denen der Aufrufer auf eine Antwort wartet. Es trägt schlecht, wenn es als alleiniges Muster auf alles angewendet wird. Wer hochfrequente Ereignisse oder lang laufende Geschäftsprozesse über synchrone Request-Response-Ketten abbildet, baut sich Latenz und enge zeitliche Kopplung ein, die unter Last zum Problem werden. Eine Kette synchroner Aufrufe ist nur so verfügbar wie ihr schwächstes Glied.

Ereignisgetrieben: für Last und Entkopplung gebaut

Bei der ereignisgetriebenen Integration kommunizieren Systeme nicht durch direkten Aufruf, sondern über Ereignisse. Ein System veröffentlicht ein Ereignis (etwa "Vertrag abgeschlossen"), eine Plattform wie Apache Kafka transportiert es, und beliebig viele andere Systeme reagieren darauf, ohne dass der Sender sie kennen muss.

Das löst genau die Probleme, an denen synchrone Muster unter Last brechen:

• Zeitliche Entkopplung: Der Sender wartet nicht. Ist ein Empfänger kurz nicht erreichbar, bleibt das Ereignis im Log liegen und wird verarbeitet, sobald der Empfänger zurück ist.
• Lastpufferung: Lastspitzen werden im Log abgefangen, statt sie direkt auf nachgelagerte Systeme durchschlagen zu lassen. Genau das brauchen Plattformen mit hohem Transaktionsdurchsatz, etwa im Tolling oder Billing, wo Ereignisse schubweise und in großer Zahl anfallen.
• Erweiterbarkeit: Ein neuer Konsument kann einen bestehenden Ereignisstrom abonnieren, ohne dass die produzierende Seite angefasst werden muss.

Der Preis dafür ist eine andere Art von Komplexität. Eventual Consistency bedeutet, dass der Systemzustand für kurze Zeit auseinanderlaufen kann, was fachlich verstanden und akzeptiert sein muss. Die Reihenfolge von Ereignissen und der Umgang mit doppelter Zustellung (Idempotenz) müssen sauber gelöst werden. Und die Fehlersuche über eine asynchrone Kette hinweg ist ohne durchgängiges Tracing erheblich schwieriger als ein einzelner synchroner Aufruf.

Ereignisgetrieben ist das stärkste Muster für Durchsatz und lose Kopplung. Es ist nicht das einfachste, und es ist nicht für jeden Anwendungsfall die richtige Wahl. Eine reife Systemintegration kombiniert die Muster: synchrone APIs dort, wo eine sofortige Antwort gebraucht wird, Ereignisse dort, wo Entkopplung und Last im Vordergrund stehen.

Der Anti-Corruption-Layer: Modernisieren ohne Big-Bang

Das größte Hindernis bei der Sanierung einer Integrationslandschaft ist selten die neue Technologie. Es ist das Datenmodell der Altsysteme. Ein dreißig Jahre altes Kernsystem trägt fachliche Annahmen, kryptische Feldnamen und historische Sonderfälle in sich, die man unter keinen Umständen in eine neue Architektur durchsickern lassen will.

Hier setzt der Anti-Corruption-Layer an, ein Muster aus dem Domain-Driven Design. Es ist eine Übersetzungsschicht, die das Modell des Altsystems sauber in das Modell des neuen Systems überführt und umgekehrt. Das neue System spricht ausschließlich seine eigene, saubere Sprache. Der gesamte Schmutz der Alt-Schnittstelle bleibt im Layer eingekapselt.

Das ist die praktische Voraussetzung für eine schrittweise Ablösung. Statt ein geschäftskritisches System in einem riskanten Big-Bang zu ersetzen, kann man neue Funktionalität daneben aufbauen, sie über den Anti-Corruption-Layer an die Altlast anbinden und das alte System Stück für Stück hinter dieser Fassade abschmelzen. Das Risiko bleibt zu jedem Zeitpunkt beherrschbar.

Im DACH-Kontext kommt ein Punkt hinzu, der von Anfang an in die Architektur gehört: Datenresidenz. Wenn personenbezogene oder regulatorisch geschützte Daten über eine Integrationsschicht laufen, muss klar sein, in welcher Region sie verarbeitet und zwischengespeichert werden. Eine Integrationsplattform, die Nachrichten unbemerkt durch eine außereuropäische Region routet, ist im regulierten Umfeld ein Problem, das man nicht nachträglich repariert.

Der inkrementelle Weg aus dem Spaghetti-Zustand

Es gibt keinen Knopf, der eine gewachsene Landschaft über Nacht in einen sauberen Integrations-Backbone verwandelt. Der Versuch eines großen Umbaus auf einen Schlag ist der zuverlässigste Weg, ein laufendes Geschäft zu gefährden. Der tragfähige Weg ist schrittweise.

Eine bewährte Reihenfolge:

1. Bestand aufnehmen. Welche Integrationen existieren, welche Daten fließen, welche sind geschäftskritisch. Ohne diese Karte ist jede Sanierung Blindflug.
2. Nach Wert priorisieren, nicht nach Alter. Die teuersten und brüchigsten Verbindungen zuerst, nicht die ältesten. Eine alte, stabile Verbindung, die niemanden stört, hat Zeit.
3. Den Backbone aufsetzen, bevor man umhängt. Erst die Zielplattform (ESB, API-Management, Event-Backbone oder eine Kombination) bereitstellen, dann die priorisierten Verbindungen darauf umhängen.
4. Mit Fassaden entkoppeln. Jede umgehängte Verbindung bekommt ihren Anti-Corruption-Layer, damit das Altsystem die neue Architektur nicht infiziert.
5. Governance von Tag eins. Ein Verzeichnis der Schnittstellen, Eigentümer pro Integration, Versionierungs- und Monitoring-Standards. Ohne das entsteht hinter der neuen Architektur exakt dasselbe Spaghetti wie vorher, nur mit moderneren Werkzeugen.

Der entscheidende Punkt ist der letzte. Technologie allein saniert keine Integrationslandschaft. Ein ESB ohne Governance wird zum zentralen Spaghetti-Knoten, eine API-Landschaft ohne Eigentümer und Versionierung zum unübersichtlichen API-Zoo. Was eine Landschaft tragfähig macht, ist nicht das Werkzeug, sondern die Disziplin, mit der es betrieben wird.

Systemintegration mit DNA Solutions angehen

DNA Solutions begleitet Unternehmen im DACH-Raum bei der Systemintegration geschäftskritischer Systeme, von der Bestandsaufnahme einer gewachsenen Landschaft bis zum tragfähigen Integrations-Backbone. Wir wählen das Muster nach dem realen Anwendungsfall und der tatsächlichen Last, nicht nach Mode, und gehen den Umbau inkrementell an, ohne das laufende Geschäft zu gefährden. Wenn Sie vor der Ablösung einer Punkt-zu-Punkt-Landschaft stehen oder eine Integrationsplattform aufbauen, die unter realer Transaktionslast trägt: Sprechen Sie uns an.