Data Contracts: Wann sie sich lohnen und wie du den ersten einführst
Was Data Contracts sind und wann sie sich lohnen: Bestandteile, Open Data Contract Standard (ODCS), Abgrenzung zu dbt und der Weg zum ersten Contract.
Die Kernaussagen auf einen Blick.
- Ein Data Contract ist eine Vereinbarung zwischen dem Team, das Daten liefert, und den Teams, die sie nutzen: Schema, Qualitätsregeln, Liefergarantien und Zuständigkeit in einer versionierten Datei.
- Er wirkt nur, wenn ein Produzent ihn verantwortet und ein automatischer Check ihn durchsetzt, sonst bleibt er Dokumentation.
- Der Open Data Contract Standard (ODCS) ist heute die Referenz, aktuell in Version 3.2.0, während die ältere Data Contract Specification Ende 2026 ausläuft.
- dbt Model Contracts, Schema Registry und Pipeline-Expectations decken jeweils nur einen Teil ab und ersetzen keinen Data Contract.
- Ein Contract lohnt sich zuerst dort, wo Daten eine Teamgrenze überqueren und ein Bruch viele Konsumenten trifft.
Inhaltsverzeichnis
Warum ein Schema allein Datenprobleme nicht verhindert
Ein Entwicklerteam benennt im Shop-Backend eine Spalte um. Der Deployment-Prozess läuft sauber durch, alle Tests sind grün. Zwei Tage später meldet der Vertrieb, dass der Umsatzbericht seit Montag leer ist. Die Pipeline hat die Spalte nicht mehr gefunden, und niemand hatte die Analytics-Seite auf dem Schirm.
Solche Brüche entstehen, weil Datenanwendungen direkt auf Datenbankschemata aufsetzen, die sich laufend ändern. Andrew Jones, der den Begriff Data Contract mitgeprägt hat, nennt genau das als ursprüngliche Motivation. Ein Autor des Herstellers Gable beschreibt das Datenbankschema als „a kind of non-consensual API“: eine Schnittstelle, der nie jemand zugestimmt hat.
Das Problem ist selten technisch. Es fehlt eine Absprache darüber, was der Produzent zusagt und wer reagiert, wenn etwas bricht. Diese Absprache macht ein Data Contract ausdrücklich und prüfbar. Wo Data Contracts in einer Datenstrategie hingehören, nämlich in die Frage nach Ownership und Operating Model, zeigen wir im Überblick zur Datenstrategie.
Was sind Data Contracts?
Ein Data Contract ist die Vereinbarung zwischen einem Datenproduzenten und seinen Konsumenten über einen Datensatz. Er legt fest, welche Struktur die Daten haben, welche Qualitätsregeln gelten, wie aktuell sie sein müssen, wer verantwortlich ist und wofür die Daten verwendet werden dürfen. Geschrieben wird er maschinenlesbar, meist in YAML, und liegt versioniert neben dem Code.
Ein juristischer Vertrag ist er nicht. Rechtliche Fragen wie Zweckbindung oder Datenschutz regelt eine separate Vereinbarung, auf die der Contract verweisen kann.
Andrew Jones beschreibt den Data Contract als „an API for data“. Der Unterschied zur klassischen API-Dokumentation liegt in der Schnittstelle: Die API-Dokumentation beschreibt einzelne HTTP-Aufrufe, ein Data Contract ganze Datensätze, etwa eine Tabelle im Warehouse oder einen Kafka-Stream. Jones sieht den Contract außerdem klar beim Produzenten: Der liefernde Teil schreibt und verantwortet ihn, im Austausch mit den Konsumenten.
Für uns ist ein Data Contract deshalb zuerst eine Zusage über Verantwortung und erst danach eine YAML-Datei. Chad Sanderson, der zweite Begriffsprägende, formuliert es schärfer: Setzt auf Produzentenseite nichts den Contract durch, gibt es keinen Contract, nur ein „handshake agreement“.
Zum Datenprodukt verhält sich der Contract wie ein Baustein zum Ganzen. Seit ODCS 3.1.0 beschreibt ein Contract genau einen Datensatz oder eine API. Ein Datenprodukt bündelt mehrere Contracts und weitere Metadaten und wird im Schwesterstandard ODPS beschrieben. Wie Domänen und Datenprodukte auf einer Plattform organisiert werden, klären wir in Data Mesh auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Was steht in einem Data Contract?
ODCS gliedert einen Contract in feste Abschnitte. Für die Einführung sind fünf davon wichtig:
| Abschnitt | Inhalt | Wozu |
|---|---|---|
| Fundamentals | ID, Version, Status, Domäne, Zweck und Grenzen der Daten | macht den Contract eindeutig und versionierbar |
| Schema | Tabellen, Spalten, Datentypen, fachliche Bedeutung | definiert die Form, auf die Konsumenten bauen |
| Data Quality | prüfbare Regeln, etwa keine leeren Pflichtfelder oder erlaubte Wertebereiche | definiert den Inhalt, nicht nur die Form |
| SLA | Aktualität, Lieferfrequenz, Verfügbarkeit | sagt, worauf sich Konsumenten zeitlich verlassen können |
| Team und Support | Owner, Rollen, Kontaktkanäle | klärt, wer reagiert, wenn eine Regel verletzt wird |
Dazu kommen Abschnitte für Preise, Infrastruktur und Server, Referenzen auf fachliche Definitionen, Tags und eigene Felder. In den Fundamentals sind nur vier Felder Pflicht: apiVersion, kind (immer DataContract), id und version. Die übrigen Abschnitte sind optional. Ein Contract kann also schlank starten und wachsen.
Ein vereinfachtes Beispiel für eine Bestelltabelle zeigt, wie das zusammenspielt. Der Kopf folgt dem offiziellen ODCS-Beispiel. Schema, Qualitätsregel und SLA sind gekürzt, die vollständigen Feldnamen stehen in der ODCS-Spezifikation:
Zeile für Zeile gelesen: Der Kopf macht den Contract auffindbar und versioniert. Das Schema sagt, welche Spalten verbindlich sind. Die Qualitätsregel prüft den Inhalt, den ein reines Schema nicht prüfen kann. Und der Kommentar an order_total zeigt, warum fachliche Bedeutung in den Contract gehört: Ob der Betrag brutto oder netto ist, verrät kein Datentyp, und genau solche Missverständnisse erzeugen widersprüchliche Umsatzzahlen. Das SLA verspricht eine tägliche Lieferung. Der Team-Eintrag schließlich beantwortet die Frage, die im Beispiel oben niemand beantworten konnte: wer zuständig ist.
Was ist der Standard für Data Contracts?
Als Standard hat sich der Open Data Contract Standard durchgesetzt. Gepflegt wird er vom Projekt Bitol, das im Juli 2026 den Status „Graduated“ bei der LF AI & Data Foundation der Linux Foundation erreicht hat. Über die Spezifikation entscheidet ein technisches Gremium mit zwölf stimmberechtigten Mitgliedern, höchstens zwei pro Unternehmen.
Die aktuelle Version 3.2.0 ist am 8. September 2026 erschienen. Neu ist unter anderem ein Abschnitt context, der KI-Systemen mitgibt, wie sie die Daten nutzen sollen, was verifiziert ist und was sie nie tun dürfen. Dazu kommen Synonyme, Kennzahlen und Dimensionen sowie neue Servertypen wie Iceberg und SAP HANA. Version 3.1.0 vom Dezember 2025 bleibt rückwärtskompatibel zu 3.0.
Die ältere Data Contract Specification ist zugunsten von ODCS abgekündigt. Laut ihrem Repository wird sie in der Data Contract CLI nur noch bis Ende 2026 unterstützt. Für neue Contracts kommt sie deshalb nicht mehr infrage.
Ein eigenes Format bleibt eine Option, wenn du nur Schema und Owner festhalten willst und kein Werkzeug den Contract auswerten soll. Sobald aber eine CLI prüfen, ein Katalog importieren oder ein KI-Agent den Contract lesen soll, spart der Standard Übersetzungsarbeit. Andrew Jones rät trotzdem davon ab, ODCS unverändert und vollständig zu übernehmen. Der Standard enthält alles, was man in einen Contract schreiben könnte. Nötig sind am Anfang vor allem Ownership, Schema und Servicezusagen.
Bei der Plattformunterstützung lohnt ein genauer Blick. DataHub bietet eine ODCS-Ingestion an, OpenMetadata dokumentiert Import und Export für ODCS 3.1.0. Bitol selbst nennt das Open-Source-Projekt Unity Catalog als Unterstützer. Für den verwalteten Unity Catalog in Databricks, für Snowflake, Collibra oder Atlan haben wir keine Herstellerquelle gefunden, die native ODCS-Unterstützung bestätigt. Prüf das vor einer Werkzeugentscheidung im konkreten Fall.
Was decken dbt, Schema Registry und Pipeline-Checks ab?
Viele Teams haben bereits Werkzeuge im Einsatz, die nach Data Contract klingen. Jedes davon deckt einen Ausschnitt ab, zu einem bestimmten Zeitpunkt:
| Werkzeug | Prüft | Prüft nicht | Wann |
|---|---|---|---|
| dbt Model Contract | Spaltennamen und Datentypen, auf vielen Plattformen nur not_null als Constraint | Qualität, Aktualität, Ownership | beim Build, das Modell wird bei Abweichung nicht gebaut |
| Schema Registry (z. B. Confluent) | Kompatibilität neuer Schemaversionen im Streaming, mit Zusatzregeln auch Feldwerte | Vollständigkeit, Aktualität, fachliche Bedeutung | beim Registrieren bzw. beim Schreiben durch den Produzenten |
| Pipeline-Expectations (z. B. Lakeflow) | Regeln pro Datensatz mit warn, drop oder fail | Schema-Zusagen an Konsumenten, Ownership | zur Laufzeit in der Pipeline |
| Data Observability | Auffälligkeiten bei Aktualität, Volumen, Verteilung | Zusagen und Verantwortung | nach dem Laden, erkennt statt verhindert |
| Data Contract | Schema, Qualität, SLA, Owner, Nutzung in einer Vereinbarung | nichts davon automatisch ohne Durchsetzung | in CI und je nach Einbindung zur Laufzeit |
Drei Details verändern dabei die Bewertung. dbt schließt Qualität und Zuverlässigkeit laut Dokumentation zu Model Contracts ausdrücklich aus dem Contract aus. Ein dbt-Contract sichert also nur die Form. Bei den Expectations in Lakeflow ist warn die Standardeinstellung: Ungültige Datensätze landen trotzdem in der Zieltabelle. Und bei fail stoppt das Update, für dieses Update werden dann aber keine Expectation-Metriken geschrieben. Dienen Expectations als Durchsetzung eines Contracts, müssen diese Einstellungen bewusst gewählt sein.
Die Werkzeuge bilden deshalb die Durchsetzungsschicht des Contracts. Der Contract legt fest, was gelten soll. dbt, Registry und Expectations prüfen es an der jeweiligen Stelle. Observability fängt ab, woran beim Schreiben der Regeln niemand gedacht hat.
Wann lohnt sich ein Data Contract?
Ein Data Contract lohnt sich, wenn Daten eine Teamgrenze überqueren, mehrere Konsumenten darauf bauen und ein Bruch teuer ist. Eine feste Schwelle, ab wie vielen Konsumenten sich ein Contract rechnet, hat niemand veröffentlicht. Die Kriterien in den Quellen sind aber konsistent. TDWI hält informelle Abstimmung für ausreichend, solange ein Team alle Daten und Pipelines selbst verantwortet. Bei Dutzenden Teams wirkt der Pflegeaufwand für Contracts dagegen billig im Vergleich zu den Kosten ohne sie. dbt empfiehlt Contracts für Modelle, auf die andere Teams, Projekte oder Dashboards bauen.
Daraus leiten wir eine einfache Prüfregel ab:
Data Contract, wenn
- Produzent und Konsument in verschiedenen Teams sitzen
- mehrere Konsumenten darauf aufbauen, etwa Reporting, Planung und ein ML-Modell
- sich die Quelle regelmäßig ändert
- ein unbemerkter Bruch spürbaren Schaden anrichtet, zum Beispiel falsche Steuerungszahlen oder ein KI-Agent, der auf kaputten Daten antwortet
dbt-Test oder Expectation reicht, wenn
- nur eines der vier Kriterien zutrifft
- ein Team alle Daten und Pipelines selbst verantwortet
- sich die Spalten des Modells gerade noch wöchentlich ändern
Treffen alle vier Kriterien zu, gehört der Datensatz zu den ersten Kandidaten. Für Modelle, deren Spalten sich gerade noch wöchentlich ändern, raten Praktiker ausdrücklich ab. Der Pflegeaufwand, den STX Next „YAML tax“ nennt, frisst dann den Nutzen.
Vier Reifestufen
Hilfreich ist es, den Contract nicht als Ja-Nein-Entscheidung zu sehen. Wir unterscheiden vier Stufen:
- Dokumentiert: Schema, Owner und Zweck sind aufgeschrieben, aber nicht maschinenlesbar.
- Maschinenlesbar: Der Contract liegt als ODCS-Datei versioniert im Repository.
- In CI geprüft: Jede Änderung am Contract oder an der Quelle läuft durch einen automatischen Check, Breaking Changes blockieren den Merge.
- Zur Laufzeit erzwungen: Qualitätsregeln und SLA werden im Betrieb geprüft, Verstöße stoppen die Verarbeitung oder lösen einen Alarm beim Owner aus.
Diese Einteilung ist unsere eigene Einordnung. Ein veröffentlichtes Praktiker-Modell mit fünf Stufen geht in eine ähnliche Richtung. Es empfiehlt eine mittlere Stufe mit Owner, Rollen und Servicezusagen für alles in Produktion und die höchste Stufe nur für die kritischsten Datensätze. Stufe 2 ohne Stufe 3 ist der häufigste Zwischenstand, der keinen Bruch verhindert.
Wie kommt man zu einem Data Contract?
Der Weg zum ersten Contract führt über fünf Schritte, von der Wahl der Schnittstelle bis zur Prüfung im laufenden Betrieb:
Schnittstelle wählen
Nimm die eine Übergabe, deren Bruch zuletzt am meisten gekostet hat. Bei GoCardless lief die Einführung bei neuen Datenströmen besser als bei der Umstellung laufender Services.
Owner festlegen
Das liefernde Team verantwortet den Contract, die Konsumenten melden ihre Anforderungen. Technisch umgesetzt wird er in der Praxis oft vom Datenteam, die Verantwortung bleibt trotzdem beim Produzenten. Deshalb läuft der Check schon in der Pipeline des liefernden Teams: Die umbenannte Spalte aus dem Einstiegsbeispiel wäre so im Pull Request des Shop-Backends aufgefallen statt erst im Umsatzbericht.
Vorschlag automatisch erzeugen
Adevinta Spanien leitet aus dem bestehenden Event-Schema automatisch einen Pull Request mit einem Contract-Vorschlag ab. Der Produzent ergänzt fehlende Angaben wie personenbezogene Felder und Servicezusagen. Das senkt die Einstiegshürde deutlich.
In CI prüfen
Ein automatischer Check läuft bei Push und Pull Request und zusätzlich zeitgesteuert. Ein Vergleich zweier Contract-Versionen stuft Änderungen ein, ein Breaking Change wie eine entfernte oder umbenannte Spalte, ein geänderter Datentyp oder eine verschärfte Pflichtangabe blockiert den Merge. Jede Änderung erzeugt eine neue Contract-Version, die alte bleibt als deprecated bestehen, bis alle Konsumenten umgestellt haben.
Zur Laufzeit absichern
Die Qualitätsregeln aus dem Contract landen als Tests in der Pipeline, etwa als Expectations mit fail für harte Regeln. So stoppt ein Verstoß die Verarbeitung, bevor kaputte Daten bei den Konsumenten ankommen.
Für Schritt 4 eignet sich die Open-Source-Data Contract CLI, die direkt in GitHub Actions läuft. Adevinta legt dabei jede Contract-Version unveränderlich ab, statt die alte zu überschreiben. Welche Berichte von einem Bruch betroffen wären, zeigt in Schritt 5 die Lineage im Unity Catalog.
Wie viel das bringt, zeigen zwei veröffentlichte Beispiele. Bei Adevinta Spanien dauerte es vor der Automatisierung rund fünf Tage vom Contract bis zu nutzbaren Daten, danach rund 30 Minuten, wie das Team in seinem Engineering-Blog beschreibt. GoCardless hatte nach sechs Monaten rund 30 Contracts, über die etwa 60 % der asynchronen Events zwischen Services liefen.
Wo stoßen Data Contracts an Grenzen?
Data Contracts lösen nicht jedes Datenproblem. Vier Grenzen zeigen sich in veröffentlichten Erfahrungsberichten immer wieder:
Ohne Verantwortung verwaisen Contracts
Ein Praktiker-Newsletter beschreibt Contracts, die nur oberflächlich ausgefüllt wurden oder ohne fachlich Verantwortliche zu toten Dokumenten werden. Laut Gable brauchte Convoy für die Einführung ein eigenes Team, als Nebenprojekt war sie nicht zu stemmen. Ohne Zeit und Mandat für die liefernden Teams entsteht vor allem Papier.
Alles abdecken führt zu Stillstand
STX Next berichtet, dass Contracts überall durchzusetzen meist in Stillstand der Entwicklung endet. Jede Änderung braucht dann einen Contract-Prozess, auch dort, wo kein Konsument betroffen ist.
Externe Systeme lassen sich nicht verpflichten
Ist der Produzent ein ERP oder eine SaaS-Anwendung, unterschreibt kein Team einen Contract. Dann sitzt er an der Übernahmestelle, prüft die Daten beim Laden, und das Fachteam des Quellsystems wird Owner. Ein Soda-Template zeigt das für Salesforce-Daten in Snowflake, einen Erfahrungsbericht für SAP als Produzent haben wir nicht gefunden.
Der Contract prüft nur, was drinsteht
Regelbasierte Checks finden nur die Fehler, für die jemand eine Regel geschrieben hat. Für unerwartete Muster bei Volumen oder Verteilung bleibt Observability nötig.
Fazit
Data Contracts lösen ein Organisationsproblem mit einem technischen Werkzeug. Sie lohnen sich dort, wo Daten eine Teamgrenze überqueren, viele Konsumenten daran hängen und ein Bruch teuer ist. Für ein einzelnes Team mit eigenen Pipelines sind sie Overhead.
Zum Einstieg wählst du eine kritische Schnittstelle, gibst dem liefernden Team die Verantwortung, schreibst den Contract nach ODCS 3.2 und prüfst ihn ab dem ersten Tag in CI. Ein Contract, der nur im Repository liegt, verhindert keinen einzigen Bruch.
Lasst uns über den nächsten Schritt sprechen
In einem Gespräch zur Data & AI Beratung klären wir, an welchen Schnittstellen deiner Plattform Data Contracts sich lohnen und wie Ownership und Durchsetzung dazu aussehen.
- welche zwei, drei Datensätze nach Teamgrenzen, Konsumenten und Schadensrisiko als erste einen Contract brauchen
- wer bei dir Produzent und Owner wird und wie das in Rollen und Prozesse passt
- wie Contract-Checks in deine bestehende CI und Pipelines kommen, etwa über dbt, Expectations oder die Data Contract CLI
FAQ
Data Contracts sind maschinenlesbare Vereinbarungen zwischen dem Team, das Daten liefert, und den Teams, die sie nutzen. Sie legen für einen Datensatz Schema, Qualitätsregeln, Liefergarantien und Zuständigkeit fest und liegen meist als YAML-Datei versioniert neben dem Code.
