- Ein Data Contract ist eine verbindliche Vereinbarung zwischen Datenproduzenten und Datennutzern. Er definiert, welche Daten bereitgestellt werden und welche Anforderungen dafür gelten.
- Ein Data Contract kann unter anderem Struktur, Datentypen, fachliche Bedeutung, Qualitätsregeln, Aktualität und Verantwortlichkeiten festlegen.
- Data Contracts schaffen klare Erwartungen an Daten und helfen dabei, Änderungen kontrolliert und nachvollziehbar umzusetzen.
- Für BI und Analytics reduzieren sie das Risiko, dass veränderte oder qualitativ unzureichende Daten unbemerkt in nachgelagerte Anwendungen gelangen.
- Für KI werden Data Contracts besonders relevant. KI-Anwendungen benötigen nicht nur Zugriff auf Daten, sondern eine kontrollierte Grundlage, auf der Daten eindeutig eingeordnet und zuverlässig genutzt werden können.
- Data Contracts ersetzen weder Datenmodellierung noch Data Governance, Data Quality oder einen Semantic Layer. Sie ergänzen diese Bausteine durch verbindliche Vereinbarungen zwischen Datenproduzenten und Datennutzern.
- Data Contracts machen Erwartungen an Daten explizit, überprüfbar und damit besser steuerbar.
Ein Data Contract, auf Deutsch Datenvertrag, beschreibt verbindliche Erwartungen zwischen denjenigen, die Daten bereitstellen, und denjenigen, die sie weiterverwenden.
Datenproduzenten können beispielsweise operative Systeme, Fachbereiche oder Data-Engineering-Teams sein. Auf der anderen Seite stehen Datennutzer wie Data Warehouses, BI-Lösungen, Planungsanwendungen, Machine-Learning-Modelle oder Data Agents.
Ein Data Contract beantwortet beispielsweise folgende Fragen:
Ein einfaches Beispiel:
Ein ERP-System stellt Rechnungsdaten für eine zentrale Datenplattform bereit. Im Data Contract kann festgelegt sein, welche Felder geliefert werden, welche Datentypen gelten, welche Felder verpflichtend sind, wie aktuell die Daten sein müssen und wer bei Änderungen oder Qualitätsproblemen verantwortlich ist.
Damit wird aus einer technisch verfügbaren Datenquelle eine definierte Schnittstelle mit klaren Erwartungen.
Der Umfang eines Data Contracts hängt vom Datenprodukt und vom jeweiligen Anwendungsfall ab. Einige Bestandteile sind jedoch besonders relevant.
Struktur und Schema
Der Data Contract beschreibt, welche Tabellen, Felder oder Datenobjekte bereitgestellt werden. Auch Datentypen, Pflichtfelder und Schlüssel können definiert werden.
Beispielsweise kann festgelegt sein, dass eine Kunden-ID eindeutig sein muss, ein Rechnungsdatum immer als Datum geliefert wird und bestimmte Felder nicht leer sein dürfen.
Damit besteht eine direkte Verbindung zur Datenmodellierung. Während die Datenmodellierung die strukturelle Grundlage einer Datenlandschaft schafft, legt der Data Contract fest, welche Teile dieser Struktur für einen bestimmten Datenkonsumenten verbindlich bereitgestellt werden.
Fachliche Bedeutung und Semantik
Eine technische Bezeichnung allein reicht häufig nicht aus.
Ein Feld mit dem Namen „Revenue“ sagt beispielsweise noch nicht eindeutig, ob Bruttoumsatz, Nettoumsatz, fakturierter Umsatz oder gebuchter Umsatz gemeint ist.
Ein Data Contract kann deshalb fachliche Beschreibungen und Definitionen enthalten. Er schafft damit Klarheit darüber, wie bereitgestellte Daten zu verstehen sind.
Für zentrale Kennzahlen, Dimensionen und Business-Logik reicht ein Data Contract allein jedoch nicht aus. Hier übernimmt der Semantic Layer eine weiterführende Aufgabe.
Datenqualität
Ein Data Contract kann definieren, welche Qualitätsanforderungen für bestimmte Daten gelten.
Dazu können beispielsweise gehören:
Welche Kriterien relevant sind, hängt vom jeweiligen Anwendungsfall ab. Mehr zu den unterschiedlichen Qualitätsdimensionen finden Sie in unserem Wiki zu Data Quality.
Aktualität und Verfügbarkeit
Korrekte Daten sind nicht automatisch geeignete Daten. Für viele Anwendungen ist entscheidend, wann und wie häufig sie bereitgestellt werden.
Ein Data Contract kann deshalb beispielsweise festlegen, dass Daten täglich bis zu einer bestimmten Verarbeitung bereitstehen oder innerhalb eines definierten Zeitraums aktualisiert werden müssen.
Für einen monatlichen Finanzreport gelten dabei andere Anforderungen als für eine operative Analyse mit kurzen Aktualisierungszyklen.
Verantwortlichkeiten
Ein Data Contract sollte klären, wer fachlich und technisch für die bereitgestellten Daten verantwortlich ist.
Dazu gehören Fragen wie:
Damit werden Zuständigkeiten nicht nur organisatorisch vorausgesetzt, sondern konkret mit den bereitgestellten Daten verbunden.
Änderungen und Versionierung
Datenstrukturen verändern sich. Felder werden ergänzt, umbenannt oder entfernt. Auch Datentypen oder fachliche Definitionen können sich ändern.
Ein Data Contract schafft einen definierten Rahmen für solche Veränderungen.
Entscheidend ist dabei nicht, Veränderungen zu verhindern. Entscheidend ist, dass relevante Änderungen nachvollziehbar sind und ihre Auswirkungen auf nachgelagerte Anwendungen berücksichtigt werden.
Moderne Datenplattformen stellen Daten häufig für viele Teams, Systeme und Anwendungen gleichzeitig bereit.
Dadurch entstehen Abhängigkeiten.
Eine scheinbar kleine Änderung in einem Quellsystem kann Auswirkungen auf Data Pipelines, Reports, Kennzahlen, Planungsanwendungen oder KI-Systeme haben.
Ein Beispiel:
Ein Quellsystem verändert den Datentyp oder die fachliche Bedeutung eines Feldes. Im Ursprungssystem funktioniert weiterhin alles. Eine nachgelagerte Pipeline, ein Bericht oder eine KI-Anwendung erwartet jedoch weiterhin die bisherige Struktur oder Interpretation.
Ohne klar definierte Vereinbarungen wird die Änderung möglicherweise erst sichtbar, wenn bereits Fehler entstanden sind.
Data Contracts setzen genau an dieser Schnittstelle an.
Sie machen Erwartungen zwischen Datenproduzenten und Datennutzern explizit. Dadurch können relevante Änderungen früher erkannt, abgestimmt und gegebenenfalls automatisiert überprüft werden.
Nicht erst der Datennutzer sollte feststellen, dass sich seine Datengrundlage verändert hat. Kritische Abweichungen sollten möglichst dort erkannt werden, wo sie entstehen.
Data Contracts unterstützen damit einen Wechsel von reaktiver Fehlerbehebung zu einer kontrollierteren Bereitstellung von Daten.
Für klassische BI-Anwendungen werden Datenmodelle, Berichte und Kennzahlen in der Regel gezielt aufgebaut. Auch hier können fehlerhafte Daten oder uneinheitliche Definitionen zu falschen Ergebnissen führen.
KI-gestützte Anwendungen verändern zusätzlich die Art, wie auf Daten zugegriffen wird.
Ein Data Agent kann beispielsweise eine fachliche Frage in natürlicher Sprache interpretieren, relevante Daten auswählen und daraus eine Abfrage erzeugen.
Eine Frage wie: „Wie hat sich unsere Marge bei Bestandskunden im letzten Quartal entwickelt?“ klingt eindeutig. Für eine belastbare Antwort muss jedoch geklärt sein:
Ein leistungsfähiges Sprachmodell allein löst diese Fragen nicht.
KI-Anwendungen benötigen eine kontrollierte Datenbasis, klare Definitionen, verlässliche Metadaten und ausreichende Datenqualität. Ein Data Catalog kann Daten und Metadaten auffindbar machen. Ein Semantic Layer stellt fachliche Begriffe, Kennzahlen und Beziehungen bereit. Data Contracts ergänzen diese Komponenten durch verbindliche Erwartungen an die bereitgestellten Daten.
Aus DATA MART Sicht ist deshalb entscheidend:
KI braucht nicht nur Zugriff auf Daten. Sie braucht verlässliche Regeln darüber, welche Daten verfügbar sind, was sie bedeuten und welcher Qualität sie entsprechen.
Data Contracts sind damit ein Baustein für verlässlichere BI- und KI-Anwendungen. Sie ersetzen jedoch weder ein sauberes Datenmodell noch Semantik, Governance, Berechtigungen oder laufende Qualitätssicherung.
Data Contract, Data Schema und API Contract verfolgen unterschiedliche Aufgaben. Die Begriffe sollten deshalb nicht gleichgesetzt werden.
Data Contract: Verbindliche Erwartungen an Daten
Der Data Contract definiert, welche Daten bereitgestellt werden und welche Anforderungen dabei gelten.
Neben technischen Strukturen kann er fachliche Definitionen, Qualitätsregeln, Aktualitätsanforderungen, Verantwortlichkeiten und Regeln für Änderungen enthalten.
Er betrachtet die Daten damit aus der Perspektive der Beziehung zwischen Produzent und Nutzer:
Was wird bereitgestellt und worauf darf sich der Datennutzer verlassen?
Data Schema: Technische Struktur der Daten
Ein Data Schema beschreibt vor allem den Aufbau der Daten und definiert beispielsweise:
Ein Data Schema kann damit Bestandteil eines Data Contracts sein. Der Data Contract geht jedoch darüber hinaus.
Ein Schema kann beispielsweise festlegen, dass das Feld net_revenue ein numerischer Wert ist. Der Data Contract kann zusätzlich festhalten, was unter net_revenue fachlich verstanden wird, welche Qualitätsanforderungen gelten und wie aktuell die Daten sein müssen.
API Contract: Vereinbarung für eine technische Schnittstelle
Ein API Contract definiert, wie unterschiedliche Anwendungen über eine Programmierschnittstelle miteinander kommunizieren.
Dabei geht es beispielsweise darum, welche Endpunkte vorhanden sind, welche Anfragen eine Anwendung senden kann, welche Parameter erwartet werden und welche Antworten zurückgegeben werden.
Der Schwerpunkt liegt damit auf der technischen Interaktion zwischen Systemen.
Ein Data Contract konzentriert sich dagegen auf die Eigenschaften und Verlässlichkeit der bereitgestellten Daten.
Beide Konzepte folgen dennoch einem ähnlichen Prinzip:
Erwartungen werden explizit vereinbart, statt nur implizit vorausgesetzt zu werden.
Data Contracts sind kein isoliertes Konzept. Sie entfalten ihren Nutzen im Zusammenspiel mit weiteren Bausteinen einer modernen Datenarchitektur.
Data Governance schafft den Rahmen
Data Governance definiert übergeordnete Regeln, Verantwortlichkeiten und Standards für den Umgang mit Daten.
Ein Data Contract überträgt Teile dieses Rahmens auf konkrete Datenprodukte und deren Nutzung.
Die Governance kann beispielsweise vorgeben, dass geschäftskritische Daten eindeutig verantwortet und nach definierten Qualitätsstandards bereitgestellt werden müssen. Der Data Contract konkretisiert anschließend, welche Anforderungen für einen bestimmten Datenbestand gelten.
Data Quality macht Anforderungen messbar
Data Quality beschreibt, ob Daten die Anforderungen ihres jeweiligen Einsatzzwecks erfüllen.
Ein Data Contract kann festlegen, welche Qualitätskriterien für konkrete Daten gelten. Die Qualitätssicherung prüft anschließend, ob diese Anforderungen tatsächlich eingehalten werden.
Vereinfacht gilt:
Data Governance definiert den Rahmen. Data Contracts konkretisieren Erwartungen. Data Quality überprüft deren Einhaltung.
Data Catalog schafft Transparenz
Ein Data Catalog macht Datenbestände und ihre Metadaten auffindbar und verständlich.
Data Contract und Data Catalog ergänzen sich deshalb gut. Der Data Catalog beantwortet insbesondere die Frage, welche Daten vorhanden sind und welche Informationen über sie bekannt sind. Der Data Contract beschreibt zusätzlich, welche verbindlichen Erwartungen für die Bereitstellung bestimmter Daten gelten.
Semantic Layer schafft fachliche Eindeutigkeit
Der Semantic Layer übersetzt technische Datenstrukturen in fachliche Begriffe, Kennzahlen und Beziehungen.
Data Contract und Semantic Layer haben dabei unterschiedliche Schwerpunkte:
Für verlässliche BI- und KI-Anwendungen werden beide Perspektiven benötigt. Eine belastbare Datenbasis braucht Struktur und Qualität. Eine belastbare fachliche Antwort braucht zusätzlich eindeutige Semantik.
Ein Data Contract kann zunächst als dokumentierte Vereinbarung entstehen.
Der größere Nutzen entsteht jedoch, wenn wichtige Regeln maschinenlesbar definiert und automatisiert geprüft werden können.
Technisch überprüfbar sind beispielsweise:
Solche Prüfungen können in Data Pipelines oder Entwicklungs- und Bereitstellungsprozesse integriert werden.
Dieser Ansatz wird häufig als Contract as Code bezeichnet.
Die Vereinbarung liegt dann nicht ausschließlich als Dokument vor. Sie wird Bestandteil der technischen Datenbereitstellung und kann versioniert, getestet und überwacht werden.
Damit können kritische Veränderungen früher erkannt werden, bevor sie nachgelagerte Reports, Anwendungen oder KI-Systeme beeinflussen.
Data Contracts sind technologieunabhängig. Sie sind kein spezifisches Feature einer einzelnen Datenplattform.
Moderne Plattformen stellen jedoch Funktionen bereit, mit denen sich verschiedene Anforderungen eines Data Contracts technisch umsetzen oder überwachen lassen.
Dabei geht es unter anderem um:
In Databricks übernehmen verschiedene Plattformkomponenten Teile dieser Aufgaben.
Data Contracts müssen nicht sofort für sämtliche Datenquellen eines Unternehmens eingeführt werden.
Ein sinnvoller Einstieg ist ein klar abgegrenztes Datenprodukt, das beispielsweise:
Für dieses Datenprodukt sollten Datenproduzenten und Datennutzer gemeinsam klären:
Auf dieser Grundlage können geeignete Regeln anschließend schrittweise automatisiert überprüft werden.
Wichtig ist: Data Contracts sind keine reine Data-Engineering-Aufgabe.
Die technische Umsetzung kann im Data Engineering erfolgen. Fachliche Definitionen, Qualitätsanforderungen und Nutzungsregeln müssen gemeinsam mit den verantwortlichen Fachbereichen festgelegt werden.