Schnittstellen zwischen zwei Systemen – warum ist der Datenaustausch in der Praxis so aufwendig?

Sehr schöne Frage, weil sie genau den Punkt trifft, an dem Lehrbuch und Praxis auseinandergehen. Für die Klausur sortiere ich Integration immer nach der Ebene, auf der zwei Systeme gekoppelt werden – das ist die gängige Systematik:

• Datenintegration (Dateiaustausch / Batch): System A exportiert nachts eine CSV, System B liest sie ein. Billig, robust, funktioniert auch mit uralten Systemen. Nachteil: Die Daten sind immer nur so aktuell wie der letzte Lauf, und keiner merkt sofort, wenn ein Lauf ausfällt.
• Direkte Datenbankkopplung: System B liest direkt in die Tabellen von System A. Schnell gebaut – und auf lange Sicht die schlechteste Idee. Man umgeht die Logik von A, und beim nächsten Update ändert der Hersteller sein Datenmodell und alles bricht.
• Funktions-/Anwendungsintegration (API, z. B. REST oder SOAP): B ruft eine definierte Funktion von A auf. A behält die Kontrolle über seine Regeln, die Schnittstelle ist dokumentiert und versioniert. Das ist heute der Normalfall.
• Nachrichtenorientierte Integration (Middleware, Message Broker / Bus): A schickt ein Ereignis („Wareneingang gebucht“) in eine Warteschlange, alle interessierten Systeme hören mit. Das entkoppelt die Systeme zeitlich – wenn B kurz weg ist, bleibt die Nachricht liegen und wird später verarbeitet.
• Prozessintegration: Ein übergeordneter Workflow steuert die Reihenfolge über mehrere Systeme hinweg.

Die zweite Achse, die in Klausuren gern vergessen wird, ist synchron vs. asynchron. Synchron heißt: A wartet auf die Antwort von B (nötig z. B. bei einer Bonitäts- oder Verfügbarkeitsprüfung). Asynchron heißt: A gibt ab und macht weiter. Asynchron ist deutlich stabiler, weil ein langsames oder ausgefallenes B nicht den ganzen Prozess in A blockiert.

Und noch eine Regel, die die Auswahl in den meisten Fällen erklärt: Punkt-zu-Punkt-Verbindungen skalieren nicht. Bei n Systemen brauchst du im schlimmsten Fall n·(n−1)/2 Verbindungen – bei 10 Systemen also 45 statt 10 Anbindungen an eine zentrale Middleware. Genau das ist das Argument für einen Integrationsbus, und genau das ist auch die typische Musterlösung, wenn nach dem Nutzen von Middleware gefragt wird.

Tobis Systematik ist die Antwort auf „welche Arten“. Zu deiner zweiten Frage – technisch oder organisatorisch – aus der Projektpraxis ganz klar: Der technische Transport ist der einfache Teil. Die Monate gehen für die Semantik drauf.

Die typischen Stolpersteine, in der Reihenfolge, in der sie einen einholen:

• Unterschiedliche Bedeutung gleicher Felder. „Kunde“ ist im ERP der Rechnungsempfänger, im Lagersystem die Warenempfangsstelle. Beides heißt Kunde, beides ist eine Nummer – und beim ersten Abgleich passt nichts zusammen. Dafür braucht es ein Mapping, und dafür braucht es jemanden aus der Fachabteilung, nicht aus der IT.
• Schlüssel und Stammdaten. Welches System ist die führende Quelle für einen Artikel? Wenn beide Seiten Artikel anlegen dürfen, hast du früher oder später Dubletten. „Ein führendes System je Datenobjekt“ ist die Regel, an der man sich festhalten sollte.
• Formate und Einheiten. Datumsformate, Dezimaltrenner, Mengeneinheiten (Stück vs. Karton), Zeitzonen, Zeichensatz. Klingt banal, kostet reale Wochen.
• Wiederholbarkeit (Idempotenz). Was passiert, wenn dieselbe Nachricht zweimal ankommt, weil die Leitung wackelte? Wenn dann zweimal eingebucht wird, ist der Bestand falsch. Deshalb bekommt jede Nachricht eine eindeutige ID und der Empfänger ignoriert Wiederholungen.
• Fehlerbehandlung und Monitoring. Die Frage ist nie, ob ein Datensatz mal durchfällt, sondern wer es merkt. Ohne Protokoll, Alarm und definierten Wiederanlauf fällt der Fehler erst bei der Inventur auf.
• Versionierung. Die Schnittstelle muss sich ändern dürfen, ohne dass die Gegenseite am selben Tag mitziehen muss.

Für die Klausur würde ich es so zuspitzen: Eine Schnittstelle ist kein Kabel, sondern ein Vertrag – über Inhalt, Format, Zeitpunkt, Verantwortung und Fehlerfall. Der technische Teil ist nur die Umsetzung dieses Vertrags. Wenn ein Integrationsprojekt hängt, fehlt fast immer der Vertrag, nicht die Technik.