Data Contracts formalisieren die Beziehung zwischen Produzenten und Konsumenten eines Data Products. Sie sind der Unterschied zwischen einer Absprache, die bei Personalwechsel verloren geht, und einer dokumentierten Vereinbarung, die Teamgrenzen überdauert.
Wann werden Data Contracts wirklich gebraucht?
Zwei-Team-Szenario: Ein Produzent, ein Konsument. Absprache reicht. Data Contract ist Overkill.
Multi-Team-Szenario: Ein Produzent, 3+ Konsumenten. Jede Schema-Änderung wird zum Drama, wenn sie nicht koordiniert ist. Data Contract wird Pflicht.
Cross-Domain-Szenario: Produzenten und Konsumenten aus verschiedenen Fachdomänen. Ohne Contract driften die Erwartungen, niemand kennt mehr die tatsächliche Nutzung.
Externe Konsumenten: Wenn Daten nach außen gehen (Partner, Kunden, Aufsichtsbehörden) — Contract wird rechtlich relevant.
Die Pflichtgrenze liegt bei etwa 3 Konsumenten pro Data Product. Darunter lohnt sich oft nicht der Pflegeaufwand.
Anatomie eines Data Contracts
1. Header.
- Name des Data Products
- Version
- Owner + Kontakt
- Status (draft / stable / deprecated)
2. Schema.
- Felder mit Typen (INT, STRING, TIMESTAMP, ...)
- Nullable oder nicht
- Enum-Werte
- Referenz zu anderen Data Products (Foreign Keys)
- Beispiel-Werte
3. Semantic Descriptions.
- Was bedeutet jedes Feld fachlich?
- Einheit (Euro, Stunden, Prozent)
- Wertebereich, Grenzen
4. SLA.
- Update-Frequenz (Realtime, hourly, daily)
- Latenz (End-to-End-Zeit vom Event bis zur Verfügbarkeit)
- Verfügbarkeit (Uptime-%)
- Max. Ausfallzeit
- Recovery-Time
5. Qualitätsgarantien.
- Welche Quality-Checks laufen?
- Schwellwerte (z. B. „Dublettenquote < 0,5 Prozent")
- Was passiert bei Qualitäts-Verletzung?
6. Change-Management.
- Ankündigungsfrist für Breaking Changes (typisch 30–90 Tage)
- Deprecation-Prozess für Felder
- Versionierungs-Policy
7. Access-Control.
- Wer darf welche Felder lesen?
- Consent-Propagation-Logik
- PII-Handling
8. Support.
- Kontakt-Kanäle (Slack, E-Mail, Ticket-System)
- Response-Zeiten (Business-Hours, 24/7?)
- Eskalations-Pfade
Ein Beispiel-Contract (YAML)
```yaml name: customer-profile-v2 version: 2.1.0 owner: marketing-data-team status: stable
schema: fields:
- name: customer_id
type: STRING nullable: false description: "Unified Customer ID from Identity Resolution"
- name: email_hash
type: STRING nullable: false description: "SHA-256 hash der E-Mail, lowercase vor Hash"
- name: clv_predicted
type: DECIMAL(10,2) nullable: true description: "Predicted CLV in EUR, updated weekly" unit: EUR
- name: segment
type: STRING enum: [A, B, C] description: "ABC-Segment basierend auf 12M Umsatz"
sla: update_frequency: daily latency_p95: 6h availability: 99.5%
quality: checks:
- "dublikate_quote < 0.5%"
- "clv_predicted > 0 for 95%+ of profiles"
- "segment must be A, B, or C"
change_management: breaking_change_notice: 60d deprecation_policy: "Fields marked @deprecated stay for 90d before removal" ```
Dieses Format ist maschinenlesbar und kann für Contract-Enforcement automatisiert werden.
Contract Enforcement
Ein Contract ohne Enforcement ist ein Dokument. Operational wird er erst durch Automation.
Schema-Validation: Jede Pipeline-Ausführung prüft, ob der produzierte Output dem Contract entspricht. Abweichungen blockieren den Release.
Quality-Checks: Automatische Validierung der Qualitätsgarantien. Bei Verletzung: Alert an Owner.
Breaking-Change-Detection: Bei jedem Schema-Diff wird geprüft, ob es ein Breaking Change ist. Falls ja, Review-Prozess.
Consumer-Notifications: Automatische Benachrichtigung der Konsumenten bei Änderungen.
Tools wie PactFlow (für APIs), Monte Carlo (Data Quality), oder selbstgebaute Validator können das umsetzen.
Breaking-Change-Management
Der kritischste Teil jedes Contracts.
Was ist ein Breaking Change?
- Feld entfernt
- Feldname geändert
- Typ-Änderung, die Downstream brechen kann (STRING → INT)
- Enum-Wert entfernt
- Nullable-Änderung (false → true)
Was ist kein Breaking Change?
- Neues Feld hinzugefügt (abwärtskompatibel)
- Neuer Enum-Wert (abwärtskompatibel, wenn nicht exhaustive matching)
- SLA-Verbesserung
Prozess bei Breaking Changes:
- Ankündigung mit Lead-Time (z. B. 60 Tage)
- Neue Version parallel betreiben
- Konsumenten haben Zeit zu migrieren
- Alte Version stilllegen
Data Contracts und Data Mesh
In einem Data-Mesh sind Data Contracts die formalisierte Schnittstelle zwischen Data Products und ihren Konsumenten. Sie ersetzen:
- Informelle Absprachen
- „Wir wissen was wir brauchen"-Annahmen
- Reverse-Engineering durch Konsumenten
In einem zentralen Data Warehouse existieren Contracts implizit (die zentrale Governance überwacht), in einem Mesh müssen sie explizit gemacht werden, weil die Ownership verteilt ist.
Häufige Fehler
Fehler 1 — Contract als einmaliges Dokument. Einmal geschrieben, nie aktualisiert. In 6 Monaten stimmt er nicht mehr.
Fehler 2 — Kein Enforcement. Contract existiert, aber Schema-Änderungen passieren ohne Contract-Update.
Fehler 3 — Zu strict. Jede Änderung ist Breaking Change. Führt zu Stillstand in der Weiterentwicklung.
Fehler 4 — Zu lax. Alles ist kompatibel. Führt zu kaputten Downstream-Pipelines ohne Warnung.
Fehler 5 — Nur Schema, kein SLA. Contract ohne Performance-Zusage ist halber Contract.
Verbindungen: Data Products als zentrales Artefakt. Einführung für die Mesh-Prinzipien.