Schnittstellen zwischen zwei Systemen: Was vor der Beauftragung geklärt werden muss
Eine Schnittstelle ist schnell beauftragt. Eine belastbare Systemintegration ist es nicht.
Ob Shop, ERP, CRM, PIM, Warenwirtschaft, Logistikplattform oder individuell entwickelte Anwendung: Sobald zwei Systeme dauerhaft Daten austauschen sollen, reicht die Frage nach einer vorhandenen API nicht aus. Entscheidend ist, welche Daten in welcher Richtung, zu welchem Zeitpunkt und nach welchen Regeln übertragen werden – und was passiert, wenn dieser Prozess nicht wie vorgesehen funktioniert.
Genau diese Punkte sollten vor Projektbeginn geklärt sein. Sie bestimmen den Entwicklungsaufwand ebenso wie Stabilität, Wartbarkeit und Betriebskosten der späteren Integration.
Zwei Angebote für vermeintlich dieselbe Schnittstelle können deshalb erheblich voneinander abweichen. Während ein Anbieter einen einfachen zeitgesteuerten Import kalkuliert, berücksichtigt ein anderer bereits Validierung, Retry-Mechanismen, Logging, Monitoring und eine saubere Behandlung von Fehlerfällen.
Beides kann technisch korrekt kalkuliert sein. Es handelt sich jedoch nicht um dieselbe Leistung.
Vier Faktoren bestimmen den technischen Aufwand
Datenfluss, Aktualität, Fehlerbehandlung und Betrieb
Vier Faktoren bestimmen einen großen Teil des technischen Aufwands
- Datenfluss. Welche Inhalte wandern zwischen den Systemen? Von welchem System zu welchem? Wer stößt die Übertragung an?
- Aktualität. Wie schnell müssen Änderungen im Zielsystem verfügbar sein? Benötigt jeder Datentyp dieselbe Aktualisierungsfrequenz?
- Fehlerbehandlung. Was geschieht bei Timeouts, ungültigen Daten oder nicht erreichbaren Systemen? Wie werden Wiederholungen und doppelte Übertragungen behandelt?
- Betrieb. Wie wird die Integration überwacht? Wer erhält Fehlermeldungen? Wer ist für die Behebung verantwortlich?
Diese Fragen wirken zunächst organisatorisch. Tatsächlich definieren sie wesentliche Teile der technischen Architektur.
Eine Schnittstelle definiert einen Prozess
Eine API oder ein anderer technischer Übergabepunkt stellt zunächst lediglich die Möglichkeit bereit, Daten zwischen Systemen auszutauschen.
Eine produktive Integration entsteht erst durch die Regeln darum herum.
Beide Systeme müssen beispielsweise eindeutig wissen:
- welchen Inhalt eine Übertragung trägt,
- in welchem Format das Zielsystem ihn erwartet,
- welche Felder ohne Ausnahme gefüllt sein müssen,
- welches System eine Information verbindlich führt,
- woran ein Datensatz wiedererkannt wird,
- auf welchem Weg eine Änderung verarbeitet wird,
- und was geschieht, wenn eine Übertragung scheitert.
Der wirtschaftliche Nutzen entsteht vor allem dort, wo manuelle Mehrfachpflege entfällt.
Wird ein Artikel heute in mehreren Systemen separat gepflegt oder werden Bestellungen aus einem Shop manuell in eine Warenwirtschaft übertragen, entstehen nicht nur Personalkosten. Es entstehen zwangsläufig auch Abweichungen.
Eine gut konzipierte Integration reduziert genau diese Medienbrüche.
Eine schlecht konzipierte Integration verschiebt sie dagegen lediglich in den Hintergrund. Fehler werden dann nicht mehr beim Abtippen produziert, sondern automatisiert verteilt – über Tausende Datensätze hinweg.
Deshalb beginnt ein Integrationsprojekt sinnvollerweise nicht mit Programmierung, sondern mit einer Bestandsaufnahme:
Welche Information entsteht wo, welches System benötigt sie und welches System ist dafür fachlich verantwortlich? Wie sich daraus eine belastbare Aufteilung ergibt, zeigt der Beitrag zu Shop, Warenwirtschaft und Auftragsmanagement als Gesamtsystem.
Datenfluss und Trigger bestimmen die Architektur
Grundsätzlich kann ein Datenaustausch auf unterschiedliche Weise organisiert werden.
Beim Pull-Verfahren fragt das empfangende System Daten beim Quellsystem ab. Beim Push-Verfahren sendet das Quellsystem Änderungen aktiv an ein anderes System.
Hinzu kommt der Trigger.
Daten werden beispielsweise alle fünf, 15 oder 60 Minuten verarbeitet. Das Verfahren eignet sich insbesondere für Informationen, bei denen eine geringe zeitliche Verzögerung akzeptabel ist.
Eine Änderung löst unmittelbar einen Prozess aus. Eine neu eingegangene Bestellung kann beispielsweise sofort an das ERP oder Auftragsmanagement übergeben werden.
Eine Information wird genau in dem Moment abgefragt, in dem sie benötigt wird. Ein typisches Beispiel ist eine Bestands- oder Verfügbarkeitsprüfung unmittelbar vor Abschluss einer Bestellung.
In professionellen Systemlandschaften werden diese Verfahren häufig kombiniert.
Produktinformationen können regelmäßig synchronisiert werden, Bestellungen ereignisgesteuert übertragen werden und besonders kritische Bestände zusätzlich unmittelbar vor dem Checkout validiert werden.
Welche Architektur sinnvoll ist, hängt daher nicht allein an den eingesetzten Systemen. Entscheidend sind Geschäftsprozess, Datenvolumen, Aktualitätsanforderungen und die Folgen eines veralteten Datenstands.
Jedes Datenobjekt braucht ein führendes System
Einer der wichtigsten Punkte einer Integration ist die Datenhoheit.
Sobald mehrere Systeme dieselbe Information vorhalten können, ist festzulegen, welches von ihnen sie fachlich führt – häufig als System of Record oder Single Source of Truth bezeichnet. Wie sich eine solche Aufteilung auf die Datenkonsistenz auswirkt, behandelt der zugehörige Wissensbeitrag.
Diese Entscheidung sollte nicht pauschal für ein komplettes System getroffen werden.
Ein Onlineshop kann beispielsweise die ursprüngliche Bestellung erzeugen, während das ERP anschließend den Auftragsstatus führt. Preise und Lagerbestände können aus der Warenwirtschaft stammen, Produkttexte aus einem PIM und Kundendaten wiederum aus dem CRM.
Entscheidend ist deshalb die Zuordnung auf Daten- oder Objektebene.
Fehlt diese Festlegung, entstehen typische Konflikte:
Ein Wert wird in System A geändert. Kurz darauf überschreibt System B ihn mit einem älteren Stand. Mitarbeiter korrigieren den Datensatz erneut – und beim nächsten Synchronisationslauf beginnt derselbe Vorgang von vorn.
Das ist kein Programmierfehler. Es ist ein Architekturfehler.
Erstellen Sie vor Projektbeginn eine Datenmatrix. Für jedes relevante Objekt oder Feld sollte dokumentiert sein, welches System die Information erzeugt, welches sie verändern darf und welche Systeme sie ausschließlich konsumieren. Diese einfache Festlegung verhindert später einen erheblichen Teil unnötiger Sonderlogik.
Nicht jede Information benötigt Echtzeit
„Echtzeit“ klingt bei Integrationsprojekten zunächst nach der technisch besten Lösung. Häufig wäre sie jedoch unnötig aufwendig.
Die entscheidende Frage lautet nicht: Wie schnell können wir synchronisieren? Sondern: Wie alt darf diese Information maximal sein, bevor daraus ein geschäftliches Problem entsteht?
Bei einem redaktionellen Beschreibungstext können 30 oder 60 Minuten Verzögerung irrelevant sein.
Bei Lagerbestand, Preis, Zahlungsstatus oder Auftragsinformationen kann dieselbe Verzögerung dagegen unmittelbar wirtschaftliche Folgen haben.
Deshalb sollte die Aktualitätsanforderung je Datenart definiert werden.
Kritische Daten werden zu selten aktualisiert, oder unkritische Daten werden unnötig häufig verarbeitet und erzeugen zusätzliche Systemlast. Gerade bei größeren Produktbeständen oder hohen Transaktionszahlen kann dieser Unterschied erheblich sein.
Eine robuste Architektur behandelt Aktualität deshalb nicht als globale Einstellung der Schnittstelle, sondern als fachliche Anforderung des jeweiligen Datenprozesses.
Fehlerbehandlung ist Bestandteil der Schnittstelle
Eine Integration muss nicht nur für den Normalfall entwickelt werden.
APIs sind zeitweise nicht erreichbar. Authentifizierungen laufen ab. Systeme reagieren zu langsam. Daten entsprechen nicht dem erwarteten Format. Ein Zielsystem weist einzelne Datensätze zurück.
Die entscheidende Qualitätsfrage lautet daher nicht, ob Fehler auftreten, sondern wie kontrolliert das Gesamtsystem damit umgeht.
Dazu gehören mindestens drei Mechanismen.
Temporäre Fehler sollten nicht zwangsläufig einen manuellen Eingriff erfordern. Für geeignete Fehlerklassen werden fehlgeschlagene Übertragungen nach definierten Regeln erneut versucht. Anzahl und zeitlicher Abstand der Wiederholungen sollten festgelegt sein.
Ein erneuter Übertragungsversuch darf nicht versehentlich einen zweiten Geschäftsvorgang erzeugen. Wenn nach einem Timeout beispielsweise unklar ist, ob eine Bestellung im Zielsystem bereits angelegt wurde, muss die Integration denselben Vorgang eindeutig wiedererkennen können.
Ein einzelner ungültiger Datensatz sollte nicht zwangsläufig einen kompletten Import blockieren. Robuste Prozesse isolieren den Fehler, protokollieren ihn und verarbeiten – sofern fachlich möglich – die übrigen Datensätze weiter.
Genau hier spielt Idempotenz eine zentrale Rolle. Ohne diese Mechanismen kann aus einer kleinen Datenabweichung schnell ein vollständiger Synchronisationsstopp entstehen.
Stabile Synchronisation benötigt stabile Identitäten
Zwei Systeme müssen zweifelsfrei erkennen können, dass sie über denselben Datensatz sprechen.
Dafür wird ein dauerhaft eindeutiger Identifier benötigt. Das kann beispielsweise eine Artikelnummer, Kunden-ID, Auftrags-ID oder eine eigens für die Integration definierte technische ID sein.
Entscheidend sind zwei Eigenschaften: Der Identifier muss eindeutig und dauerhaft stabil sein.
Bezeichnungen, Namen oder Beschreibungstexte sind dafür ungeeignet.
Wird beispielsweise ein Produktname korrigiert und gleichzeitig zur Identifikation verwendet, kann das Zielsystem den Datensatz nicht mehr zuordnen und legt einen neuen an. Die Folge sind Dubletten und inkonsistente Datenbestände.
Zur Datenzuordnung gehört außerdem ein sauber definiertes Field Mapping. Vor Beginn der Entwicklung sollte feststehen:
- welche Felder den Weg zwischen den Systemen nehmen,
- welchen Datentyp das Zielsystem je Feld annimmt,
- welche Felder gefüllt sein müssen und welche leer bleiben dürfen,
- an welcher Stelle ein Wert umgerechnet oder umbenannt wird,
- und welche Werte im Zielsystem niemals überschrieben werden.
Gerade bei gewachsenen Systemen liegt ein erheblicher Teil des Integrationsaufwands nicht im eigentlichen API-Aufruf, sondern in genau dieser fachlichen Zuordnung.
Eine Schnittstelle benötigt Observability
Eine der unangenehmsten Eigenschaften fehlerhafter Integrationen ist, dass sie häufig unbemerkt ausfallen.
Der Onlineshop funktioniert weiterhin. Das ERP funktioniert ebenfalls. Auch das CRM ist erreichbar. Nur die Daten bewegen sich nicht mehr.
Mögliche Ursachen reichen von abgelaufenen Zugangsdaten über API-Änderungen bis zu Speicherproblemen, Rate Limits oder Änderungen an Datenstrukturen.
Deshalb benötigt eine produktive Integration mehr als ein Logfile. Sie benötigt Überwachung. Sinnvolle Kennzahlen können beispielsweise sein:
Wie viele Vorgänge konnten innerhalb eines definierten Zeitraums nicht verarbeitet werden?
Wie lange wartet der älteste noch nicht erfolgreich verarbeitete Datensatz?
Stimmen relevante Datenbestände nach einem regelmäßigen Reconciliation-Prozess noch überein?
Monitoring ist allerdings nur sinnvoll, wenn aus einer technischen Abweichung auch eine organisatorische Reaktion entsteht.
Ein Alarm, den niemand liest, ist kein Monitoringkonzept.
Deshalb muss definiert sein, wer informiert wird, wer für die erste Analyse verantwortlich ist und wann Entwickler oder Systemanbieter hinzugezogen werden.
Genauso zählen Tests nach jedem größeren Update der beteiligten Systeme. Änderungen an APIs, Authentifizierungsverfahren oder Datenstrukturen können eine bis dahin stabile Integration beeinträchtigen, obwohl beide Anwendungen für sich weiterhin fehlerfrei erscheinen.
Diese acht Angaben gehören in eine Schnittstellenanfrage
Je genauer die Anforderungen vor der Angebotsphase beschrieben werden, desto belastbarer lassen sich Angebote vergleichen. Für eine erste technische Bewertung sollten mindestens folgende Angaben vorhanden sein:
- Beteiligte Systeme. Produkt, Version, Betriebsmodell und vorhandene Schnittstellen. Wichtig ist insbesondere, ob dokumentierte APIs bereits existieren oder auf einer Seite zunächst ein eigener Zugriff entwickelt werden muss.
- Datenrichtung. Welche Informationen fließen von welchem System in welches andere System? Bei bidirektionalen Prozessen sollten beide Richtungen getrennt beschrieben werden.
- Trigger. Erfolgt die Übertragung zeitgesteuert, ereignisgesteuert oder synchron auf Anfrage?
- Führendes System. Welches System besitzt für welches Datenobjekt beziehungsweise Feld die Datenhoheit?
- Datenumfang. Welche Objekte und Felder werden übertragen? Welche Werte werden transformiert? Welche Informationen dürfen im Zielsystem nicht verändert werden?
- Identifikationsmerkmal. Über welchen stabilen Identifier werden vorhandene Datensätze systemübergreifend zugeordnet?
- Aktualitätsanforderung. Welche maximale Verzögerung ist je Datenart fachlich vertretbar? Gibt es Informationen, die unmittelbar vor einem Geschäftsvorgang zusätzlich validiert werden müssen?
- Fehlerstrategie. Wie reagiert die Integration auf einen vorübergehenden Fehler? Nach welchen Regeln läuft ein Wiederholungsversuch? Woran erkennt das Zielsystem eine bereits zugestellte Übertragung? Auf welchem Weg wird ein endgültig gescheiterter Vorgang sichtbar?
Drei weitere Fragen entscheiden über die Qualität im späteren Betrieb
Eine technisch funktionierende Schnittstelle ist noch keine nachhaltig betriebene Integration. Deshalb sollten Unternehmen zusätzlich klären:
Es sollte nachvollziehbar sein, welche technischen und fachlichen Zustände überwacht werden und wann eine Warnung ausgelöst wird.
Datenflüsse, Mapping, Authentifizierung, Fehlerbehandlung, Abhängigkeiten und Betriebsprozesse sollten so dokumentiert sein, dass nicht ausschließlich der ursprüngliche Entwickler das System verstehen kann.
Diese Frage wird häufig erst relevant, wenn ein Dienstleister gewechselt werden soll. Dann ist es zu spät.
Was dabei auf dem Spiel steht, behandelt der Wissensbeitrag zur Anbieterbindung.
Häufig gestellte Fragen
Acht Angaben: die beteiligten Systeme mit Produkt, Version und vorhandenen Schnittstellen, die Datenrichtung, der Trigger, das führende System je Datenobjekt, der Datenumfang mit Feldern und Transformationen, das Identifikationsmerkmal, die Aktualitätsanforderung je Datenart und die Fehlerstrategie. Liegen diese Angaben vor, beschreiben mehrere Angebote dieselbe Leistung und lassen sich sachlich vergleichen.
Weil die Anbieter unterschiedliche Annahmen kalkulieren. Ein zeitgesteuerter Import ohne Validierung, Retry und Monitoring ist eine andere technische Leistung als eine Integration mit Fehlerbehandlung, Wiederholungslogik, Protokollierung und Überwachung. Beide Kalkulationen können korrekt sein. Erst eine ausformulierte Anforderung macht sichtbar, worin sie sich unterscheiden.
Datenhoheit legt fest, welches System für eine Information fachlich führend ist, häufig als System of Record bezeichnet. Die Zuordnung erfolgt auf Daten- oder Objektebene und nicht pauschal je System: Ein Shop kann die Bestellung erzeugen, während das ERP den Auftragsstatus führt. Fehlt die Festlegung, überschreiben sich zwei Systeme wechselseitig, und dieselbe Korrektur wiederholt sich bei jedem Synchronisationslauf.
Nach einem Timeout ist häufig unklar, ob das Zielsystem einen Vorgang bereits angelegt hat. Ein Wiederholungsversuch darf deshalb keinen zweiten Geschäftsvorgang erzeugen. Idempotenz sorgt dafür, dass die Integration denselben Vorgang wiedererkennt und die erneute Zustellung ohne zusätzliche Wirkung bleibt. Ohne diese Eigenschaft entstehen Doppelaufträge, die anschließend manuell storniert werden.
Die Anforderung wird je Datenart bestimmt. Maßgeblich ist, wie alt eine Information höchstens sein darf, bevor daraus ein geschäftliches Problem entsteht. Bei redaktionellen Texten sind längere Intervalle unkritisch, bei Lagerbestand, Preis oder Zahlungsstatus wirken sich dieselben Intervalle unmittelbar aus. Eine globale Einstellung für alle Datenarten führt entweder zu veralteten kritischen Werten oder zu unnötiger Systemlast.
Eine namentlich benannte Rolle, unterstützt durch technische Kennzahlen. Überwacht werden die Zahl fehlgeschlagener Übertragungen, das Alter des ältesten offenen Vorgangs und Abweichungen aus einem regelmäßigen Abgleich beider Systeme. Zusätzlich ist festzulegen, wer die erste Analyse übernimmt und wann Entwicklung oder Systemanbieter hinzugezogen werden. Eine Warnung ohne zuständige Person bleibt wirkungslos.
Eine dokumentierte Integration lässt sich von einem anderen Dienstleister übernehmen
Eine sauber entwickelte Integration sollte nicht nur heute funktionieren. Sie sollte auch nach einem Systemupdate nachvollziehbar bleiben, überwacht werden können und bei Bedarf durch einen anderen qualifizierten Dienstleister übernommen werden können.
Genau darin unterscheidet sich eine kurzfristig programmierte Datenübertragung von einer professionell geplanten Systemintegration. Wer eine gewachsene Ablage in Tabellendateien ablöst, findet den passenden Einstieg im Beitrag zu wichtigen Abläufen in einer Tabellendatei.
Wir gehen mit Ihnen in 1 Werktag die acht Angaben durch, die Ihre Integration beschreibbar machen.
KI für Entscheider, sachlich aufbereitet.
Wöchentlich ein vollständiger Fachbeitrag über Künstliche Intelligenz im Mittelstand. Jederzeit abbestellbar.
Zu den KI-News