Was sind Data Contracts?

Ein Data Contract ist eine förmliche Vereinbarung zwischen einem Erzeuger von Daten und seinen Abnehmern, die Struktur, Bedeutung, Qualitätsstandards und erwartete Servicegüte für einen Datensatz oder ein Data Product festlegt. Er macht stillschweigende Annahmen ausdrücklich: welche Felder es gibt, welche Typen sie haben, wie frisch die Daten sind und wer einsteht, wenn etwas bricht.

Data Contracts sind aus einem praktischen Problem entstanden. Als Organisationen Data Mesh und verteilte Datenverantwortung einführten, zeigte sich, dass Dezentralisierung ohne Abstimmung ins Chaos führt. Eine Änderung an einer Pipeline in einer Domäne bricht still ein Dashboard in einer anderen. Data Contracts lösen das, indem sie zwischen Erzeuger und Abnehmer eine durchsetzbare Schnittstelle schaffen.

Was ist ein Data Contract?

Ein Data Contract ist kein Rechtsdokument. Er ist eine technische und organisatorische Spezifikation, die festhält, worauf sich beide Seiten eines Datenaustauschs verständigt haben. Der Erzeuger verpflichtet sich, Daten in einem festgelegten Format mit bestimmten Qualitätsgarantien zu liefern. Der Abnehmer verpflichtet sich, die Daten im vorgesehenen Rahmen zu verwenden.

Denken Sie an einen API-Vertrag für Daten. So wie eine REST API ein dokumentiertes Schema, eine Versionierungsregel und ein Verfügbarkeits-SLA hat, legt ein Data Contract dieselben Garantien für einen Datensatz, eine Tabelle oder ein Streaming-Topic fest. Der Unterschied: Data Contracts decken zusätzlich die fachliche Bedeutung ab (wofür die Felder im Geschäft stehen), Regeln zur Datenqualität (Vollständigkeit, Aktualität, Gültigkeit) und die Verantwortung (wen man anspricht, wenn der Contract verletzt wird).

Warum Data Contracts wichtig sind

Data Contracts adressieren drei systemische Probleme, die mit dem Umfang des Datenbetriebs schlimmer werden.

Brechende Änderungen pflanzen sich still fort

Wenn ein Quellsystem eine Spalte umbenennt, einen Datentyp ändert oder die Fachlogik anpasst, wirkt das durch jede nachgelagerte Pipeline, jeden Bericht und jedes Modell, das davon abhängt. Ohne Contract werden solche brechenden Änderungen erst nach dem Schaden entdeckt, in einem kaputten Dashboard, einer falschen Kennzahl oder einem neu trainierten Modell, das Unsinn liefert. Contracts legen fest, was als brechende Änderung gilt, und verlangen vorher eine Ankündigung oder eine neue Version.

Qualitätserwartungen bleiben stillschweigend

Ein Abnehmer nimmt an, dass das Feld email gültige Adressen enthält. Der Erzeuger nimmt an, dass Nullwerte im Feld phone in Ordnung sind. Keine der beiden Annahmen ist dokumentiert. Regeln zur Datenqualität in einem Contract machen diese Erwartungen ausdrücklich und prüfbar: Sie lassen sich in CI/CD-Pipelines automatisch validieren, bevor schlechte Daten in die Produktion gelangen.

Die Verantwortung ist unklar

Wenn Daten brechen, lautet die erste Frage immer „Wessen Problem ist das?“. Contracts weisen klare Verantwortung und Supportwege zu. Der Erzeuger steht dafür ein, den Contract einzuhalten. Der Abnehmer verantwortet, die Daten im festgelegten Rahmen zu nutzen. Eskalationswege und erwartete Reaktionszeiten sind Teil der Vereinbarung.

Was in einen Data Contract gehört

Die Umsetzungen unterscheiden sich, aber die meisten Data Contracts decken diese Kernbestandteile ab:

• Schemadefinition: Feldnamen, Datentypen, Nullwert-Bedingungen, Primärschlüssel. Das strukturelle Rückgrat des Contracts.
• Semantische Metadaten: fachliche Definitionen je Feld, verknüpft mit einem Business Glossary, damit Abnehmer verstehen, was die Daten bedeuten und nicht nur, wie sie aussehen.
• Qualitätsregeln: Schwellwerte für Vollständigkeit, Anforderungen an die Aktualität, gültige Wertebereiche, Eindeutigkeitsbedingungen. Prüfbare Zusicherungen, keine Absichtserklärungen.
• Service Level Agreements (SLAs): Lieferfrequenz, Zusagen zur Latenz, Verfügbarkeit. Legt fest, wann Abnehmer mit Daten rechnen können und wie schnell Störungen behoben werden.
• Verantwortung und Support: das Team oder die Person, die für die Daten einsteht, die Supportwege, die Eskalationsverfahren.
• Versionierung und Änderungsregeln: wie Schemaänderungen gehandhabt werden, Fristen für Abkündigungen, Zusagen zur Rückwärtskompatibilität.
• Sicherheit und Zugriff: Klassifizierungsstufe, Zugriffsbeschränkungen, Datenschutzanforderungen, Aufbewahrungsregeln.
• Preise und Nutzungsbedingungen: für Data Products im Marktplatzkontext das Kostenmodell und die Nutzungsbedingungen.

Die Landschaft der offenen Standards

Das Feld der Data Contracts ist seit 2023 schnell gereift. Was als interne Vorlage bei Technologieunternehmen begann, ist heute ein zusammenwachsendes Ökosystem offener Standards unter der Governance der Linux Foundation. Wer diese Landschaft kennt, kann fundierter entscheiden, welche Standards zu übernehmen sind.

Open Data Contract Standard (ODCS)

Der Open Data Contract Standard ist der maßgebliche offene Standard für Data Contracts. Aktuell in Version 3.1.0 (veröffentlicht im Dezember 2025), gepflegt von Bitol, einem Projekt der Linux Foundation AI & Data Foundation, lizenziert unter Apache 2.0.

ODCS ging aus dem internen Data Contract Template von PayPal hervor, das dort während der Einführung von Data Mesh entstand. PayPal stellte die Vorlage 2023 quelloffen, und daraus entwickelte sich der von der Community gepflegte Standard. Diese Herkunft zählt: Der Standard entstand aus der Praxis im Produktivbetrieb, nicht aus der Theorie.

Ein Data Contract in ODCS ist ein maschinenlesbares YAML-Dokument (Medientyp application/odcs+yaml) mit zehn Hauptabschnitten: Grunddaten, Schema, Datenqualität, SLAs, Preise, Team, Rollen, Infrastruktur, Verweise und eigene Eigenschaften. Für die Einbindung in VS Code und IntelliJ steht eine Validierung per JSON Schema bereit.

Data Contract Specification (DCS), abgekündigt

Die Data Contract Specification war ein alternativer Standard des Teams hinter datacontract.com. Mit der Veröffentlichung von ODCS v3.1 hat das DCS-Team seine Spezifikation abgekündigt, um die Branche auf einen einzigen Standard zu bündeln. Unterstützung beim Umstieg von DCS auf ODCS gibt es bis Ende 2026. Diese Bündelung ist ein gutes Zeichen für das Ökosystem: Konkurrierende Standards erzeugen Reibung bei der Einführung, Zusammenwachsen senkt sie.

Data Contract CLI

Die Data Contract CLI ist ein quelloffenes Kommandozeilenwerkzeug, das Data Contracts operativ macht. Sie kann Contracts prüfen und validieren, sich mit Datenquellen verbinden (Databricks, Snowflake, BigQuery, AWS), um Schema- und Qualitätstests auszuführen, brechende Änderungen in CI/CD-Pipelines erkennen und in verschiedene Formate exportieren. Die CLI unterstützt ODCS und DCS gleichermaßen und ist damit das zentrale Durchsetzungswerkzeug, unabhängig davon, mit welchem Standard eine Organisation angefangen hat.

Open Data Product Specification (ODPS)

Die Open Data Product Specification, ebenfalls bei der Linux Foundation beheimatet, blickt weiter. Aktuell in Version 4.1 (Oktober 2025), ist ODPS eine herstellerneutrale YAML-Spezifikation, um Data Products zu definieren, zu verwalten und zu vermarkten. Sie deckt über 120 Metadatenattribute ab, darunter Preismodelle, Lizenzbedingungen und Zugriffskontrolle, also Bereiche jenseits dessen, was ein Data Contract allein regelt.

ODPS unterstützt Data Contracts ausdrücklich innerhalb der Spezifikation. Contracts lassen sich per URL referenzieren oder direkt einbetten. Dieser geschichtete Ansatz erkennt an, dass ein Data Product mehr ist als sein Contract: Es umfasst fachlichen Kontext, Erlösmodelle und Lebenszyklusverwaltung, die über der Contract-Ebene liegen.

Data Product Descriptor Specification (DPDS)

Die Data Product Descriptor Specification der Open Data Mesh Initiative geht konzeptionell einen anderen Weg. Statt unmittelbar von Data Contracts zu sprechen, gliedert DPDS die Schnittstellen in Zusagen, Erwartungen und Pflichten, angelehnt an die Promises Theory. Eine Zusage beschreibt, was das Data Product zu liefern verspricht. Eine Erwartung beschreibt, wie Abnehmer es nutzen sollen. Eine Pflicht ist die bindende Vereinbarung, also das, was einem klassischen Data Contract am nächsten kommt. Dieses Rahmenwerk ist ausdrucksstärker als ein einfacher Contract und zugleich aufwendiger umzusetzen.

Wohin die Standards gehen

Die Richtung ist klar: Zusammenwachsen um ODCS als Standard auf Contract-Ebene, mit ODPS und DPDS auf der darüberliegenden Ebene des Data Product. Wer heute mit Data Contracts anfängt, sollte ODCS für die Contract-Definitionen nehmen und ODPS erwägen, wenn eine vollständige Spezifikation für Data Products gebraucht wird, samt kaufmännischen Bedingungen, Lizenzen und Marktplatzfähigkeiten. Die Governance beider Standards durch die Linux Foundation sorgt für langfristige Stabilität und Herstellerneutralität.

Data Contracts und Data Products

Data Contracts sind die Vertrauensinfrastruktur von Data Products. Ein Data Product ohne Contract ist ein Datensatz mit einem Etikett. Ein Data Product mit Contract ist ein verlässlicher Baustein, auf den sich andere Teams und KI-Systeme stützen können.

Der Zusammenhang ist unmittelbar: Die sechs Kerneigenschaften eines Data Product (auffindbar, adressierbar, selbstbeschreibend, vertrauenswürdig, interoperabel, unmittelbar nutzbar) verlangen alle vertragliche Zusagen, um überhaupt etwas zu bedeuten. Vertrauenswürdigkeit ohne SLA ist eine Absichtserklärung. Interoperabilität ohne Zusagen zum Schema ist Zufall. Selbstbeschreibung ohne dokumentierte Bedeutung ist unvollständig.

In einer Data-Mesh-Architektur spielen Contracts eine entscheidende Rolle für die föderierte Governance. Die zentrale Governance-Funktion legt Vorlagen und Mindeststandards fest. Die Domänenteams setzen innerhalb dieser Leitplanken Contracts für ihre Data Products um. Diese Balance wahrt die Eigenständigkeit der Domänen und sorgt zugleich dafür, dass Produkte verschiedener Teams sich verlässlich kombinieren lassen.

Für Abnehmer auf der KI-Seite liefern Data Contracts etwas Unverzichtbares: maschinenlesbare Vertrauenssignale. Ein KI-Agent, der prüft, ob ein Data Product für eine Aufgabe taugt, kann den Contract programmatisch auf Schemaverträglichkeit, Aktualitätszusagen und Qualitätswerte hin abfragen, also Entscheidungen treffen, die sonst menschliches Urteil und institutionelles Wissen verlangen.

Wie Dawiso Data Contracts angeht

Dawiso bindet Data Contracts als zentralen Governance-Mechanismus in sein Rahmenwerk für Data Products ein. In Dawiso sind Data Contracts keine eigenständigen Dokumente, die in einem Repository abgelegt werden, sondern lebende Governance-Artefakte, verbunden mit Katalog, Lineage und Qualitätsüberwachung.

Die Verantwortlichen für ein Data Product definieren Contracts, die Erwartungen an das Schema, Qualitätsregeln und Lieferzusagen festlegen. Diese Contracts sind mit den Begriffen des Business Glossary verknüpft, für semantische Einheitlichkeit, und mit der Data Lineage, für die Folgenabschätzung bei geplanten Änderungen. Abnehmer finden Data Products über den Katalog und können deren Contracts prüfen, bevor sie eine Abhängigkeit eingehen.

Über das Model Context Protocol (MCP) können KI-Agenten die Contract-Informationen programmatisch abrufen und prüfen, ob ein Data Product ihren Anforderungen an Qualität und Aktualität genügt, bevor sie es nutzen. Damit werden Data Contracts nicht nur zum Governance-Werkzeug für menschliche Teams, sondern zu einer Vertrauensschicht, die KI-Agenten eigenständig bewerten können.

Fazit

Data Contracts halten fest, was zwischen Erzeugern und Abnehmern von Daten bisher stillschweigend, mündlich überliefert oder gar nicht geregelt war. Das Ökosystem offener Standards, angeführt von ODCS für die Contract-Definitionen und ODPS für die Spezifikation von Data Products, ist so weit gereift, dass Organisationen maschinenlesbare, durchsetzbare Contracts übernehmen können, ohne Eigenbauten zu entwickeln. Für Organisationen, die Data Products betreiben, sind Contracts kein optionaler Governance-Aufwand. Sie sind der Mechanismus, der Data Products vertrauenswürdig genug macht, um sich auf sie zu stützen, für menschliche Analysten, nachgelagerte Pipelines und KI-Agenten gleichermaßen.