Die meisten Integrationsprobleme in gewachsenen Systemlandschaften sind keine Netzwerk- oder Verfügbarkeitsprobleme. Sie sind Formatprobleme: Ein Feld, das plötzlich leer sein kann. Ein Statuswert, der um eine Ausprägung erweitert wurde. Ein Datum, das gestern als Zeitstempel kam und heute als Datum ohne Uhrzeit. Die Schnittstelle antwortet weiterhin mit Status 200 — und trotzdem ist die Auswertung dahinter falsch.
Warum Dokumentation allein nicht reicht
Eine Schnittstellendokumentation beschreibt den Aufruf. Sie sagt, welche Felder existieren und welchen Typ sie haben. Was sie fast nie sagt: welche Werte tatsächlich vorkommen, ob ein Feld leer sein darf, wie aktuell die Daten sind, und was passiert, wenn sich das ändert.
Genau diese Zusagen sind der Kern eines Data Contracts. Er ist eine Vereinbarung zwischen dem System, das Daten liefert, und den Systemen, die sie verarbeiten — mit demselben Verbindlichkeitsanspruch wie ein API-Vertrag, nur auf die Inhalte bezogen.
Was in einen Data Contract gehört
- Schema: Felder, Typen, Pflicht oder optional, erlaubte Wertebereiche und Aufzählungen.
- Qualitätszusagen: maximale Anteile fehlender Werte, Eindeutigkeit von Schlüsseln, referenzielle Bedingungen.
- Aktualität: in welchem Rhythmus geliefert wird und wie alt die Daten im schlechtesten Fall sein dürfen.
- Semantik: was ein Feld bedeutet. Ein Feld „Status" ohne definierte Bedeutung der Werte ist unbrauchbar, egal wie sauber der Typ ist.
- Zuständigkeit: wer den Vertrag verantwortet und wer bei Abweichungen erreichbar ist.
- Änderungsregeln: was rückwärtskompatibel geändert werden darf und was eine neue Version erzwingt.
Der wichtigste Satz eines Data Contracts ist der über Änderungen. Felder hinzufügen ist unkritisch. Ein Feld entfernen, umbenennen, seinen Typ oder seine Bedeutung ändern ist es nicht — das ist ein Bruch und braucht eine neue Version mit Übergangszeit.
Rückwärtskompatibel oder nicht: die einzige Frage, die zählt
In der Praxis lässt sich fast jede Änderung in zwei Kategorien einsortieren. Additiv sind neue optionale Felder und neue Werte in Aufzählungen, sofern Empfänger unbekannte Werte tolerieren. Brechend sind entfernte Felder, verengte Wertebereiche, geänderte Einheiten und geänderte Bedeutungen bei gleichem Namen.
Die letzte Kategorie ist die gefährlichste, weil sie technisch unsichtbar ist: Ein Betrag, der von Brutto auf Netto umgestellt wird, verletzt kein Schema. Er verfälscht nur jede Auswertung dahinter. Genau deshalb gehört die Semantik in den Vertrag und nicht nur der Typ. Wie Versionierung praktisch umgesetzt wird, steht im Beitrag API-Versionierung.
Prüfen statt hoffen
Ein Vertrag, der nur in einem Dokument steht, hält bis zur ersten dringenden Änderung. Wirksam wird er erst, wenn die Zusagen maschinenlesbar sind und automatisch geprüft werden — beim Bauen der liefernden Anwendung und beim Eingang jeder Lieferung.
Sinnvoll ist eine zweistufige Reaktion. Verletzt eine Lieferung das Schema, wird sie abgewiesen und gemeldet, statt fehlerhafte Daten in nachgelagerte Systeme zu lassen. Verletzt sie nur eine Qualitätszusage, etwa einen Schwellenwert für fehlende Felder, wird sie verarbeitet, aber markiert. So bleibt der Betrieb handlungsfähig und die Abweichung trotzdem sichtbar.
Wo anfangen
Nicht bei allen Schnittstellen gleichzeitig. Sinnvoll ist der Datenfluss, der die meisten Störungen verursacht hat — er ist der, bei dem der Nutzen sofort messbar wird. Für diesen einen Fluss wird der Vertrag geschrieben, hinterlegt und geprüft. Danach dient er als Vorlage.
Der Vertrag gehört dabei in die Versionsverwaltung neben den Code, nicht in ein Wiki. Nur dort ist nachvollziehbar, wer wann was geändert hat — und nur dort lässt sich eine Änderung mit derselben Sorgfalt prüfen wie jede andere Codeänderung.
Der stille Fall: Daten, die formal stimmen
Die unangenehmsten Fehler verletzen kein Schema. Eine Quelle liefert plötzlich nur noch die Hälfte der Datensätze, weil ein Filter im Vorsystem geändert wurde. Jeder einzelne Datensatz ist korrekt, das Format stimmt, die Prüfung läuft grün — und die Auswertung dahinter ist trotzdem falsch.
Gegen diese Klasse von Fehlern hilft nur eine Zusage über Mengen und Verläufe: eine erwartete Größenordnung je Lieferung, ein zulässiger Korridor gegenüber dem Vortag, eine Mindestzahl an Datensätzen. Diese Zusagen sind unbequem, weil sie gelegentlich falsch anschlagen. Sie sind aber die einzigen, die einen stillen Datenverlust überhaupt sichtbar machen.
Was sich dadurch verändert
Der spürbarste Effekt ist nicht weniger Fehler, sondern früher erkannte Fehler. Eine Abweichung fällt beim Bauen auf statt drei Wochen später in einem Bericht. Und die Diskussion darüber, wer schuld ist, entfällt: Es steht geschrieben, was zugesagt war.