So verbinden Sie fragmentierte Systeme: ein Leitfaden für Integrations- und API-Strategie

Fragmentierte Systeme zu verbinden beginnt mit Eigentümerschaft, Grenzen und Informationsfluss – nicht mit der Wahl eines Integrationstools. Bevor Technologie ausgewählt wird, sollte der Betrieb sagen können, welches System für welche Daten verantwortlich ist, wo diese Daten die Grenzen jedes Systems überqueren und was geschehen muss, wenn eine Übergabe scheitert. Eine Integration auf unklarer Eigentümerschaft und verschwommenen Grenzen bewegt Daten zwischen Systemen, die sich trotzdem nicht wie ein System verhalten. Was ein kohärentes Business-System ist, behandelt der Leitfaden zu Business-Systemen (/resources/was-geschaeftssysteme-umfassen); dieser Leitfaden ist die Implementierungstiefe: wie die Grenzen und der Informationsfluss zwischen den bereits bestehenden Systemen gestaltet werden.

Beginnen Sie mit dem operativen Fluss, wie er heute läuft: die beteiligten Systeme, die Personen, die sie bedienen, die Daten, die die Grenzen jedes Systems überqueren, die Zustandsübergänge, die ein Datensatz durchläuft, die menschlichen Genehmigungen, die zum Ablauf gehören, und die externen Abhängigkeiten, die der Fluss berührt. Zeichnen Sie die Karte in operativen Begriffen, bevor Sie eine Integrationsform wählen. Der Zweck ist keine Selbstzweck-Dokumentation – die Karte ist die einzige verlässliche Grundlage dafür, zu entscheiden, welche Daten sich bewegen müssen, wer für sie verantwortlich ist und was geschieht, wenn ein Schritt scheitert.

Jeder Kern-Datenbestand sollte ein System of Record haben – das System, das für diese Daten massgeblich ist. Kunde, Auftrag, Rechnung, Buchung, Ticket und Lagerartikel sind typische Beispiele: Jeder gehört in genau ein System als Quelle der Wahrheit, während andere Systeme nur eine Referenz darauf halten dürfen. Diese Kategorien sind illustrativ und keine Vorgabe, welches Produkt was besitzen muss. Es geht um Verantwortlichkeit: Wenn zwei Systeme bei einem Auftrag unterschiedlicher Meinung sind, muss jemand sagen können, welche Version gewinnt.

Eine Systemgrenze benennt, was ein System besitzt und was nicht. Ein System, das Aufträge besitzt, dupliziert nicht den Kundenstamm, und ein System, das Rechnungen führt, hält keine eigene private Kopie des Auftrags. Unklare Grenzen erzeugen Synchronisationsprobleme, weil jede duplizierte Tatsache für immer in Übereinstimmung gehalten werden muss – per Integration, Batch oder von Hand – und jeder Abstimmungsmechanismus irgendwann scheitert. Eine Grenze ist keine Mauer; sie ist eine benannte Verantwortung, und die Daten, die sie überqueren, bewegen sich auf definierte Weise.

Es gibt keine universelle Integrationsform. Direkte Punkt-zu-Punkt-Verbindungen funktionieren für wenige stabile Verknüpfungen. Eine gemeinsame Integrations- oder Serviceschicht bündelt die Verträge, wenn mehrere Systeme Daten über dieselben Regeln austauschen. Die ereignisgesteuerte Übergabe lässt ein System Änderungen veröffentlichen, auf die andere asynchron reagieren. Die geplante Batch-Synchronisation passt zu Daten, die eine periodische Angleichung vertragen. Eine kontrollierte manuelle Grenze ist eine legitime Wahl, wenn eine Übergabe selten ist, von Urteil abhängt oder zu folgenreich für die Automatisierung. Die richtige Form folgt dem Fluss, den Daten, den Timing-Anforderungen und den Folgen eines Ausfalls – nicht der Mode.

Eine API ist ein Vertrag zwischen begrenzten Systemen: explizite Eingaben, explizite Ausgaben, stabile Semantik und ein definierter Weg, Fehler zu signalisieren. Verträge sollten über die Zeit stabil bleiben, Änderungen über eine bewusste Versions- oder Änderungsgrenze laufen und ihre eigene Fehlersemantik beschreiben, statt den Ausfall dem Zufall zu überlassen. Authentifizierung und Autorisierung gehören konzeptionell zum Vertrag – wer was aufrufen darf – aber der strategische Punkt ist, dass der Vertrag existiert, dokumentiert ist und einen Eigentümer hat. Dies ist ein Strategieleitfaden, kein API-Tutorial: Die Entscheidungen, die zählen, sind, den Vertrag zu benennen, stabil zu halten und seine Ausfälle sichtbar zu machen.

Jede Integration bewegt Daten in eine Richtung, und die Richtung muss explizit sein: Welches System ist die Quelle der Wahrheit für jedes Feld, wie wird die Synchronisation ausgelöst, und was geschieht, wenn derselbe Datensatz an zwei Orten geschrieben wird? Doppelte Schreibvorgänge und gelegentliche Inkonsistenz sind in realen Systemen normal; entscheidend ist, dass sie geplant und nicht entdeckt werden. Wiederholungen und Idempotenz machen erneute Versuche sicher – ein Schritt, der wiederholt werden kann, muss gefahrlos mehrfach laufen können. Der Abgleich (Reconciliation) – der Vergleich dessen, was die Systeme tatsächlich halten – macht stille Abweichung sichtbar.

Verteilte Abläufe scheitern teilweise: Das erste System hat die Änderung angenommen, das zweite nicht. Die Strategie muss entscheiden, was in diesem Moment geschieht – bevor er eintritt. Wiederholung mit begrenzter Anzahl, sichtbare Fehler für die Personen, die handeln können, und die Weiterleitung nicht abschliessbarer Arbeit an einen Ort, an dem eine Person sie löst – eine Dead-Letter- oder manuelle Auflösungs-Queue ist das Konzept, kein bestimmtes Produkt. Kein stiller Ausfall ist akzeptabel: Eine Übergabe, die lautlos scheitert, verdirbt das Bild der Wahrheit in beiden Systemen. Was versucht wurde, was scheiterte und wie es gelöst wurde, sollte nachvollziehbar sein.

Integration bedeutet, dass Systeme Informationen und Zustand austauschen; Automatisierung bedeutet, dass Ablaufschritte mit reduziertem manuellen Eingriff ausgelöst und ausgeführt werden. Es sind unterschiedliche Anliegen, die oft vermischt werden. Ein Ablauf kann Integration ohne jede Automatisierung brauchen – Systeme tauschen Daten sauber aus, während Menschen die nächsten Schritte entscheiden und ausführen. Und ein Ablauf kann ohne viel Integration automatisiert sein, wenn er innerhalb eines Systems läuft. Beides zu unterscheiden hält die Diskussion ehrlich: Die Frage, wie diese Systeme Daten austauschen, wird beantwortet, bevor die Frage gestellt wird, welche Schritte automatisch laufen können – diese behandelt der Leitfaden zur Workflow-Automatisierung (/resources/was-als-erstes-automatisieren) ausführlich.

Eine individuelle Integrationsentwicklung wird nötig, wenn die vorhandenen APIs, Konnektoren und Konfigurationen der genutzten Produkte den geforderten Vertrag nicht liefern können – die Datenbewegung, die Transformation, die Fehlerbehandlung oder das Timing. Die Antwort ist eine begrenzte individuelle Integration: eine kleine, selbst betriebene Schicht, die genau den fehlenden Vertrag implementiert und nichts weiter – kein Ersatzsystem. Ob ein Build überhaupt gerechtfertigt ist, entscheidet der Entscheidungsrahmen für Individualsoftware (/resources/wann-individualsoftware-sinnvoll-ist); die Integrationsstrategie bestimmt nur die Grenze des individuellen Teils.

Unkontrollierte Punkt-zu-Punkt-Verbindungen, die ohne Design wachsen.

Geschäftslogik, die in mehreren Konnektoren dupliziert ist, sodass eine Regeländerung an jeder Stelle gemacht werden muss.

Zirkuläre Abhängigkeiten, in denen System A auf B wartet, B auf C und C auf A.

Unklares Dateneigentum, sodass jedes System glaubt, denselben Datensatz zu besitzen.

Versteckte Transformationen, in denen Daten still zwischen Systemen umgeformt werden und niemand mehr weiss, wo.

Fragile synchrone Ketten, in denen ein langsamer oder fehlschlagender Schritt den ganzen Fluss blockiert.

Die Antwort ist nicht automatisch Microservices oder ereignisgesteuerte Architektur. Die Antwort ist Design: benannte Grenzen, Verträge mit klarem Eigentümer und explizite Fehlerbehandlung – ob das ein Konnektor oder zwanzig sind.

Mehrdeutige Ausnahmen, die keine Regel im Voraus beschreiben kann.

Irreversible oder folgenreiche Aktionen wie die Freigabe von Zahlungen, externe Kommunikation oder das Löschen von Datensätzen.

Widersprüchliche Datensätze, in denen zwei Systeme verschiedene Versionen derselben Tatsache halten und eine Person entscheiden muss, welche korrekt ist.

Fehlgeschlagener Abgleich, wenn der automatische Vergleich eine Abweichung findet, die nicht automatisch gelöst werden kann.

Die Schwelle ist die Folge, nicht das Volumen: Menschliche Kontrollpunkte gehören dorthin, wo ein Fehler teuer ist – nicht dorthin, wo das System beschäftigt ist.

Welches System ist für jeden Datenbestand, der sich bewegt, das System of Record?

Was braucht das empfangende System wirklich, und was ist die minimale Datenmenge, die es erfüllt?

Wann darf der Austausch gelegentlich inkonsistent sein, und wann muss er exakt sein?

Was geschieht, wenn eine Übergabe scheitert – wer sieht es, und wer löst es?

Kann jeder Schritt sicher wiederholt werden, und ist eine wiederholte Lieferung folgenlos?

Wer besitzt den Vertrag auf jeder Seite, und wie werden Änderungen daran geprüft?

Welche Teile des Ablaufs bleiben menschlich kontrolliert, und warum?

Wie wird die Integration überwacht, und wie werden Abweichungen erkannt und abgeglichen?

Integrationsarchitektur ist erfolgreich, wenn sie die operative Fragmentierung reduziert: wenn die Systeme die richtigen Informationen in der richtigen Richtung austauschen, wenn Ausfälle sichtbar und lösbar sind und wenn eine Person benennen kann, wem was gehört. Werkzeuge ohne diese Struktur zu verbinden macht die Fragmentierung nur effizienter – dieselben duplizierten Daten, dieselbe unklare Eigentümerschaft, nur schneller bewegt. Der Test einer guten Integrationsstrategie ist nicht, wie viele Systeme verbunden sind. Er ist, ob sich der Betrieb danach eher wie ein System verhält.