Systeme verbinden: Welche Integration sich lohnt und welche Sie sich sparen können

„Unsere Systeme sprechen nicht miteinander.” Hinter diesem Satz stecken sehr unterschiedliche Probleme.

Manchmal ist es eine Datei, die jeden Montag jemand exportiert und woanders hochlädt. Manchmal ist es eine Kundenadresse, die in vier Programmen gepflegt wird und in dreien veraltet ist. Manchmal ist es ein Auftragsstatus, den niemand beantworten kann, ohne vorher zwei Kollegen zu fragen.

Diese drei Fälle sehen ähnlich aus, brauchen aber unterschiedliche Antworten. Der erste ist eine Fleißaufgabe. Der zweite ist ein Datenproblem. Der dritte ist ein Prozessproblem. Nur einer davon wird durch eine Schnittstelle wirklich gelöst.

Nicht jede Trennung zwischen zwei Programmen ist ein Integrationsproblem

Bevor über Schnittstellen gesprochen wird, lohnt sich eine nüchterne Prüfung der einzelnen Übergabe. Vier Fragen reichen meist aus:

• Wie oft passiert es? Ein Vorgang pro Quartal rechtfertigt keine dauerhafte Verbindung. Zwanzig Vorgänge pro Tag rechtfertigen fast immer eine.
• Wie groß ist der Schaden, wenn es schiefgeht? Eine falsch übertragene Telefonnummer kostet einen Rückruf. Eine falsch übertragene Bankverbindung oder Menge kostet deutlich mehr.
• Wie schnell muss die Information drüben sein? Wenn eine Verzögerung von Stunden fachlich niemanden stört, brauchen Sie keine Verbindung in Echtzeit.
• Was passiert heute, wenn die zuständige Person im Urlaub ist? Wenn die Antwort „dann bleibt es liegen” lautet, ist der manuelle Weg bereits ein Risiko und nicht nur eine Unbequemlichkeit.

Genauso wichtig sind die Fälle, in denen eine Integration die falsche Antwort ist:

• Ein Feld wird doppelt gepflegt, weil zwei Abteilungen sich nicht auf eine Zuständigkeit einigen konnten. Eine Schnittstelle zementiert diesen Konflikt, sie löst ihn nicht.
• Ein Bericht wird aus drei Quellen zusammengesetzt, weil niemand geprüft hat, ob zwei davon dasselbe aussagen.
• Ein Schritt existiert nur, weil er früher notwendig war. Der günstigste Weg, ihn zu automatisieren, ist ihn zu streichen.
• Die vorhandene Software kann den Fall bereits, aber die Funktion wurde nie eingerichtet.

Deshalb steht am Anfang die Aufnahme des tatsächlichen Ablaufs, nicht die Auswahl eines Werkzeugs. Wie das geht, beschreibt der Beitrag Prozesse richtig automatisieren im Detail. Für die Integration gilt derselbe Grundsatz: Erst verstehen, dann vereinfachen, danach verbinden.

Zuerst wird entschieden, welches System welches Feld besitzt

Die Frage, die vor jeder Technikentscheidung beantwortet werden muss, ist keine technische. Sie lautet: Wenn zwei Systeme unterschiedliche Angaben zu derselben Sache enthalten – welche gilt?

Das System, dessen Angabe im Zweifel gilt, ist für dieses Feld das führende System. Im Englischen heißt das system of record. Der Begriff wird oft so verwendet, als gäbe es pro Unternehmen ein einziges Leitsystem. In der Praxis wird die Frage nicht pro System entschieden, sondern pro Feld:

• Die Rechnungsanschrift führt meist die Buchhaltung, weil sie dort rechtlich verbindlich verwendet wird.
• Die Lieferanschrift führt oft die Auftragsbearbeitung, weil sie dort zuletzt mit dem Kunden abgestimmt wurde.
• Den Bearbeitungsstatus führt das System, in dem tatsächlich gearbeitet wird – nicht das, in dem der Vertrieb ihn gern sehen möchte.
• Die Einwilligung für Werbe-E-Mails führt das System, in dem sie erteilt und protokolliert wurde.

Wird das nicht entschieden, entstehen zwei typische Muster. Entweder überschreiben sich zwei Systeme gegenseitig im Wechsel, bis niemand mehr weiß, welcher Stand aktuell ist. Oder es gewinnt schlicht der letzte Schreibvorgang – was bedeutet, dass die Datenqualität davon abhängt, wer zufällig zuletzt gespeichert hat.

Ein brauchbares Ergebnis dieser Vorarbeit ist eine schlichte Tabelle: Feld, führendes System, Richtung der Übertragung, was passiert bei Widerspruch. Sie passt für die meisten kleinen Integrationen auf eine Seite und erspart später Wochen an Diskussion.

Zwei Ergänzungen gehören dazu:

• Ein Feld darf genau eine führende Quelle haben. Zwei sind keine Absicherung, sondern ein Konflikt mit Ansage.
• Es muss einen eindeutigen Schlüssel geben, an dem beide Seiten denselben Kunden, denselben Auftrag, denselben Artikel erkennen. Existiert er nicht, ist er die erste Aufgabe – vor jeder Übertragung. Zuordnung über den Namen funktioniert genau so lange, bis es zwei Firmen mit ähnlicher Schreibweise gibt.

Fünf Wege, zwei Systeme zu verbinden – vom geringsten Aufwand aufwärts

Die folgende Reihenfolge ist eine Faustregel für Einführungs- und Betriebsaufwand, keine Preisliste. Im Einzelfall kann eine saubere Schnittstellenanbindung günstiger sein als ein Jahr Handarbeit. Diese Einordnung ist eine Einschätzung aus der Sache heraus, keine belegte Marktzahl.

1. Export und Import von Hand

Daten werden im Quellsystem exportiert und im Zielsystem eingelesen, meist als CSV- oder Excel-Datei.

Das genügt, wenn die Übergabe selten stattfindet, die Menge überschaubar ist, nur eine Richtung betroffen ist und eine Verzögerung von Tagen niemanden stört. Für eine jährliche Preisliste ist das der richtige Weg.

Die Kosten sind unsichtbar, aber real: Arbeitszeit pro Durchlauf, Formatfehler, Abhängigkeit von einer einzelnen Person, keine Nachvollziehbarkeit darüber, was wann übertragen wurde. Solange niemand diese Zeit misst, wirkt der Weg kostenlos.

Die Grenze ist erreicht, sobald das Vergessen des Exports jemandem auffällt.

2. Zeitgesteuerter Abgleich

Ein Skript oder ein Standardwerkzeug liest in festem Takt – stündlich, nachts – und schreibt die Änderungen in das Zielsystem.

Sinnvoll, wenn eine Verzögerung von Minuten bis Stunden fachlich unerheblich ist: Stammdaten, Preise, Auswertungen, nächtliche Übernahmen.

Der Aufwand steckt in Details, die im ersten Entwurf gern fehlen: Woran erkennt der Lauf, was sich seit dem letzten Mal geändert hat? Was passiert mit Datensätzen, die im Quellsystem gelöscht wurden? Was passiert, wenn ein Lauf ausfällt – wird er nachgeholt oder übersprungen? Und wer merkt, dass er ausgefallen ist?

Ein häufiger Fehler ist der vollständige Abgleich über eine wachsende Datenmenge. Er funktioniert im ersten Jahr gut und reicht im dritten in den Arbeitstag hinein.

3. Direkte Anbindung über die Schnittstelle des Systems

Das eine System ruft die dokumentierte Programmierschnittstelle (API) des anderen auf, im Moment des Ereignisses.

Voraussetzungen, die vor der Zusage geprüft gehören: Gibt es überhaupt eine Schnittstelle? Ist sie dokumentiert? Deckt sie die benötigten Felder ab – auch die eigenen Zusatzfelder? Gibt es Beschränkungen bei der Anzahl der Aufrufe? Und bekommen Sie die Zugangsdaten ohne zusätzliches Lizenzpaket?

Eine Schnittstelle ist ein Vertrag zwischen zwei Systemen. Ob dieser Vertrag geschrieben wird, ist eine Entscheidung – vorhanden ist er ohnehin. Für HTTP-Schnittstellen gibt es dafür ein etabliertes Beschreibungsformat, die OpenAPI-Spezifikation, die eine Schnittstelle so beschreibt, dass Menschen und Programme sie ohne Zugriff auf den Quelltext verstehen können. Eine solche Beschreibung ist bei jeder Integration die günstigste Versicherung gegen die Frage „Wie war das noch mal gedacht?” zwei Jahre später.

Bewusst zu bewerten ist der Fall, in dem es keine Schnittstelle gibt und stattdessen die Bedienoberfläche automatisiert wird. Das kann als Übergangslösung vertretbar sein. Es bricht aber bei jeder Oberflächenänderung des Anbieters, und es sollte im Projekt auch so benannt werden – als Notlösung mit begrenzter Haltbarkeit, nicht als Integration.

4. Integrationsplattform oder Middleware

Ein zusätzliches System in der Mitte übernimmt Verbindungen, Feldzuordnungen, Wiederholungen und Protokolle. Fertige Konnektoren für verbreitete Anwendungen sind meist enthalten.

Das lohnt sich, wenn mehr als eine Handvoll Verbindungen existiert, mehrere Fachbereiche beteiligt sind und Änderungen ohne Entwicklungsprojekt möglich sein sollen.

Der Preis ist nicht nur die laufende Nutzung. Die Plattform wird selbst zu einem kritischen System: mit eigenen Zugängen, eigenem Berechtigungskonzept, eigener Datensicherung und einem eigenen Ausfallszenario. Wenn sie steht, stehen alle Verbindungen gleichzeitig. Bei zwei Verbindungen ist dieser Weg in aller Regel Überbau.

5. Ereignisgesteuerte Verbindung

Das Quellsystem meldet jede Änderung aktiv – über Rückrufe (Webhooks) oder eine Nachrichtenwarteschlange. Empfänger reagieren darauf, ohne dass jemand fragen muss.

Geeignet bei vielen Ereignissen, mehreren Empfängern und kurzer erwarteter Reaktionszeit, und überall dort, wo Systeme sich nicht gegenseitig ausbremsen sollen.

Dieser Weg stellt die höchsten Anforderungen an die Fehlerbehandlung. Doppelte Zustellung derselben Nachricht ist hier der Normalfall und nicht der Sonderfall, und die Reihenfolge der Ereignisse ist nicht garantiert. Wer das nicht einplant, erhält Systeme, die schnell und zuverlässig falsche Daten verteilen.

Eine Integration ist erst fertig, wenn der Fehlerfall geregelt ist

Vorführungen zeigen den Idealfall. Der Betrieb besteht aus abgelaufenen Zugangstoken, überschrittenen Aufruflimits, unvollständigen Datensätzen und Systemen, die gerade gewartet werden.

Wiederholungen und Idempotenz gehören zusammen

Wenn ein Aufruf fehlschlägt, soll er wiederholt werden – meist mehrfach, mit wachsendem Abstand, damit ein überlastetes Zielsystem nicht zusätzlich belastet wird.

Wiederholungen sind aber nur dann harmlos, wenn der Vorgang idempotent ist. Idempotent heißt: Dieselbe Anweisung mehrfach ausgeführt hat dasselbe Ergebnis wie einmal ausgeführt. Die HTTP-Spezifikation formuliert es so, dass eine Methode als idempotent gilt, wenn die beabsichtigte Wirkung mehrerer identischer Anfragen dieselbe ist wie die einer einzigen solchen Anfrage (RFC 9110, Abschnitt 9.2.2).

Für eine Integration bedeutet das konkret: Wenn dieselbe Bestellung zweimal ankommt, weil die Antwort auf den ersten Versuch verloren ging und nicht, weil zweimal bestellt wurde, darf im Zielsystem trotzdem nur ein Auftrag entstehen.

Das erreicht man nicht durch Hoffnung, sondern durch einen eindeutigen Schlüssel, der zum Vorgang gehört – eine Bestellnummer, eine Vorgangs-ID oder ein vom Sender vergebener Schlüssel. Das Zielsystem merkt sich verarbeitete Schlüssel und antwortet beim zweiten Mal mit demselben Ergebnis, statt einen zweiten Datensatz anzulegen.

Ohne Idempotenz sind Wiederholungen gefährlich. Ohne Wiederholungen ist eine Integration nicht betriebsfähig. Beides muss zusammen entschieden werden, nicht nacheinander.

Was passiert, wenn eine Seite nicht erreichbar ist

Diese Frage sollte beantwortet sein, bevor die erste Verbindung produktiv geht:

• Werden eingehende Vorgänge zwischengespeichert, oder gehen sie verloren?
• Wie viele Wiederholungen sind vorgesehen, in welchem Abstand, und wann wird aufgegeben?
• Wohin kommen endgültig fehlgeschlagene Vorgänge, und kann man sie später gezielt nachfahren?
• Was passiert mit einem Vorgang, der nur zur Hälfte übertragen wurde – Auftrag angelegt, Positionen fehlen?
• Wie lange darf ein Rückstau anwachsen, bevor jemand eingreifen muss?

Wer erfährt davon

Die gefährlichste Fehlerbehandlung ist die stille. Ein Fehler, der nur im Protokoll steht, ist kein gemeldeter Fehler.

Legen Sie deshalb eine benannte Person fest, nicht ein Sammelpostfach. Unterscheiden Sie zwischen „ein Vorgang ist fehlgeschlagen” und „die Verbindung steht seit zwei Stunden” – das sind unterschiedliche Dringlichkeiten, und sie sollten unterschiedliche Wege nehmen. Und stellen Sie sicher, dass es eine Meldung gibt, wenn nichts mehr passiert. Eine Verbindung, die aufgehört hat zu arbeiten, meldet von sich aus nämlich gar nichts.

Sinnvoll ist zusätzlich ein Weg, einen Vorgang manuell abzuschließen. Es wird Fälle geben, die die Automatik nicht bewältigt, und dann darf der Vorgang nicht im System feststecken.

Punkt-zu-Punkt-Verbindungen wachsen schneller, als es sich anfühlt

Jede einzelne Verbindung wirkt für sich genommen überschaubar. Das Wachstum der Gesamtzahl ist es nicht.

Bei drei Systemen gibt es höchstens drei Paare. Bei sechs Systemen sind es fünfzehn Paare – und wenn Daten in beide Richtungen fließen, dreißig Wege, die jeweils eigene Zuordnungen, Zugangsdaten und Fehlerfälle haben. Das ist reine Kombinatorik und keine Erhebung; es beschreibt nur die Obergrenze, wenn man jedes System mit jedem verbindet.

Praktisch bedeutet das: Der Aufwand steckt nicht in der einzelnen Verbindung, sondern in ihrer Anzahl. Was hilft:

• Nur die Paare verbinden, die fachlich gebraucht werden. Die Obergrenze ist kein Ziel.
• Eine Drehscheibe statt eines Netzes. Wenn ein System ohnehin die meisten Stammdaten führt, ist es der natürliche Mittelpunkt. Alle anderen holen dort ab und liefern dort ab.
• Begriffe einmal klären. Was genau ist ein „Kunde”, was ein „Auftrag”, was ein „abgeschlossener Vorgang”? Wenn drei Systeme drei Definitionen haben, übersetzt jede Verbindung zwischen ihnen – und jede Übersetzung ist eine Fehlerquelle.
• Verbindungen inventarisieren. Eine Liste aller produktiven Verbindungen mit Zweck, Verantwortlichkeit und Stand ist die Voraussetzung dafür, später überhaupt etwas abschalten zu können.
• Vor jeder neuen Verbindung fragen, welche dafür entfällt. Wenn nie eine entfällt, wächst das Netz unbegrenzt weiter.

Was dokumentiert sein muss, bevor die erste Verbindung produktiv geht

Für jede Verbindung gehört Folgendes auf eine Seite:

• welche Systeme beteiligt sind und in welche Richtung Daten fließen
• welche Felder übertragen werden, mit welcher Zuordnung und welcher Umrechnung – Einheiten, Datumsformate, Steuersätze, Sprachkennzeichen
• welches System bei welchem Feld führt
• was die Übertragung auslöst und in welchem Takt sie läuft
• welches technische Konto verwendet wird, mit welchen Rechten, und wo die Zugangsdaten liegen
• was bei Fehlern passiert und wer benachrichtigt wird
• was protokolliert wird und wie lange die Protokolle aufbewahrt werden
• wer die Verbindung fachlich verantwortet

Für die Protokollierung gibt das IT-Grundschutz-Kompendium des BSI einen brauchbaren Maßstab. Der Baustein OPS.1.1.5 verlangt eine Richtlinie, in der geregelt ist, „wie, wo und was zu protokollieren ist”; Art und Umfang sollen sich am Schutzbedarf der Informationen orientieren. Für den Austausch mit Partnern außerhalb des eigenen Verbunds ist der Baustein CON.9 Informationsaustausch einschlägig. Und für die Anbindung von Hintergrundsystemen an eine Webanwendung fordert APP.3.1, dass der Zugriff „ausschließlich über definierte Schnittstellen und von definierten IT-Systemen aus” möglich sein soll und dass der Datenverkehr über Netz- und Standortgrenzen hinweg authentisiert und verschlüsselt wird.

Zwei Punkte zum Datenschutz, die bei Integrationen regelmäßig übersehen werden:

• Eine Verbindung sieht mehr als ein einzelner Mitarbeiter. Der Grundsatz der Datenminimierung nach Art. 5 Abs. 1 lit. c DSGVO gilt auch hier. Das Standard-Datenschutzmodell der deutschen Datenschutzaufsichtsbehörden nennt dazu unter anderem die „Reduzierung von erfassten Attributen der betroffenen Personen” als Maßnahme. Übertragen Sie die Felder, die das Zielsystem braucht – nicht den ganzen Datensatz, weil die Schnittstelle ihn ohnehin liefert.
• Protokolle sind selbst eine Datenverarbeitung. Wer zur Fehlersuche vollständige Nachrichteninhalte speichert, legt eine zweite Kopie personenbezogener Daten an, oft ohne Löschfrist und mit anderen Zugriffsrechten als das Fachsystem.

Welche Punkte wir bei einer Systemintegration berücksichtigen, beschreibt die Leistungsseite zu Automatisierung und Systemintegration.

Ein realistischer Zuschnitt für das erste Integrationsprojekt

1. Eine Verbindung, ein Auslöser, eine Richtung. Nicht drei Systeme gleichzeitig.
2. Feldliste und führendes System schriftlich – vor der ersten Zeile Code, nicht danach.
3. Fehlerfälle vorher benennen, mit der gewünschten Reaktion je Fall.
4. Parallelbetrieb auf Zeit. Die Automatik läuft, der alte Weg läuft eine begrenzte Zeit daneben, die Ergebnisse werden verglichen. Das kostet ein paar Wochen und findet die Abweichungen, die in keiner Anforderung standen.
5. Ein Abschaltkriterium für den alten Weg festlegen, sonst läuft er dauerhaft mit.
6. Übergabe klären: wer betreibt die Verbindung, wer wird alarmiert, wo liegt die Dokumentation, wer darf die Zugangsdaten erneuern.

Erst danach lohnt es sich, über die zweite und dritte Verbindung zu sprechen. Was Sie beim ersten Projekt über Ihre eigene Datenqualität lernen, verändert den Zuschnitt der folgenden meist erheblich.

Die teuerste Integration ist die, die niemand gebraucht hätte

Eine gute Integration erkennt man nicht daran, wie viele Systeme sie verbindet, sondern daran, dass niemand mehr über sie spricht. Sie läuft, sie meldet sich, wenn sie nicht läuft, und es ist klar, wer dann etwas tut.

Der Weg dorthin führt nicht über die Auswahl eines Werkzeugs. Er führt über die Entscheidung, welche Übergaben es überhaupt geben soll, welches System bei welchem Feld recht hat und was im Fehlerfall passieren soll. Wer diese drei Fragen beantwortet hat, kann die Technik danach in Ruhe wählen. Wer sie überspringt, baut die Unklarheit in Software nach – nur schneller und in mehreren Systemen gleichzeitig.

Handlungsaufruf

Welche Daten pflegt Ihr Team heute an mehr als einer Stelle? TakFlow nimmt den betroffenen Ablauf auf, klärt die führende Datenquelle je Feld und schlägt einen Integrationsweg vor, der zum tatsächlichen Bedarf passt – auch dann, wenn das Ergebnis lautet, dass eine Schnittstelle sich nicht lohnt.

Integrationsbedarf prüfen lassen

Weiterführend: Automatisierung, KI und Systemintegration · Prozesse richtig automatisieren · Standardsoftware, Open Source oder individuelles Tool

Quellenhinweise

• RFC 9110 „HTTP Semantics”, Abschnitt 9.2.2 „Idempotent Methods” (IETF, Juni 2022) – Definition der Idempotenz
• BSI: IT-Grundschutz-Bausteine, Edition 2023 – Bausteine OPS.1.1.5 Protokollierung, CON.9 Informationsaustausch, APP.3.1 Webanwendungen und Webservices
• Datenschutzkonferenz: Das Standard-Datenschutzmodell (SDM), Version 3.1, beschlossen am 14. Mai 2024 – Gewährleistungsziel Datenminimierung
• OpenAPI Specification, OpenAPI Initiative – Beschreibungsformat für HTTP-Schnittstellen
• Verordnung (EU) 2016/679 (Datenschutz-Grundverordnung), EUR-Lex – Art. 5 Abs. 1 lit. c