Consumer-Driven Contracts für Daten

Umsatz heute

48.230 € ▲ 12 %

Bestellungen

1.284 ▲ 8 %

Ø Warenkorb

37,55 € ▲ 3 %

Umsatz heute

— keine Daten

Bestellungen

— keine Daten

Ø Warenkorb

— keine Daten

Team Checkout

besitzt Service & Datenbank

order_total → total_amount

✅ Eigene Tests grün · deployed

Testdaten

Daten für Tests

• Generieren, anonymisieren, verwalten
• Eigene Disziplin mit ISTQB/GTB-Lehrplan
• Sichert die Qualität der Software

→ Heute nicht unser Thema

Service mit API

Zweck

Geschäftsprozesse ausführen

Schnittstelle

Schmale API – definierte Operationen

Typischer Zugriff

Ein Datensatz, aktueller Zustand

Die Tabelle ist …

Implementierungsdetail – gekapselt

Konsumenten

Andere Services & Frontends

Datenprodukt

Zweck

Fragen beantworten – auch die von morgen

Schnittstelle

Query-Interface – SQL, Topics, Files

Typischer Zugriff

Millionen Zeilen, Historie, Joins

Die Tabelle ist …

Die Schnittstelle selbst – bewusst veröffentlicht

Konsumenten

Analysten, Dashboards, ML, KI-Agenten

Das Schema ist die API des Datenprodukts – und jede Schnittstelle braucht einen Vertrag.

✓

Leistungs­fähigkeit

✓

Schutz­maßnahmen

✓

Benutzer­freundlichkeit

◆

Daten

01

Schema-Stabilität

Spalten & Typen – bricht wie eine API

◆

02

Aktualität

Wann kam die letzte Lieferung?

◆

03

Vollständigkeit

Alle Zeilen da? Wie viel null ist okay?

◆

04

Validität

Wertebereiche, Formate, Plausibilität

◆

05

Konsistenz

Passen die Zahlen zusammen – auch produktübergreifend?

◆

06

Semantik

Netto oder brutto? Bedeutung ist Teil der Qualität

◆

Genau diese Karten schreibt der Data Contract fest – maschinenlesbar und testbar.

Build & Unit-Tests

wie immer

Contract-Test

gegen einen Mock des Providers

Vertrag publizieren

an den Pact Broker

can-i-deploy ✓

dann Deploy

Pact Broker

verwahrt alle Verträge

Build & Unit-Tests

wie immer

Verträge verifizieren

gegen alle Konsumenten-Verträge

Ergebnis melden

zurück an den Broker

can-i-deploy ✓

dann Deploy

Build & Tests

wie immer

datacontract test ✓

prüft die gelieferten Daten

Ergebnis melden

zurück an die Registry

Deploy ✓

nur bei grünem Contract

Vorab · gemeinsam

Contract vereinbaren

Producer & Consumer, contract-first

Contract-Registry

verwahrt alle Contracts

Build & Transform

z. B. dbt run – wie immer

datacontract test ✓

Schema & Qualität aller Contracts

Ergebnis melden

zurück an die Registry

Deploy ✓

nur bei grünen Contracts

SLAs

Frische, Verfügbarkeit, Qualitätsregeln – zugesichert und testbar

ODCS: slaProperties

Sorgsamer Umgang

Klassifizierte Daten schützen, nicht weitergeben, im eigenen Output anonymisieren

heute meist nur Policy-Prosa

Terms of Use

Nutzungszweck, Grenzen und Pflichten der Verwendung

ODCS: terms

Consumer-Driven Contract

Der Ausschnitt, den der Konsument wirklich braucht – Spalten, Typen, Frische

Idee: ODCS am Input Port

Ein Format trägt alle vier Felder: ODCS – an Output- wie an Input-Ports.

Prävention

in der Pipeline · vor dem Deployment

Fängt die Known Knowns: Schema-Brüche, verletzte Qualitätsregeln – alles, was eine Änderung kaputt macht.

Unser order_total-Rename stirbt hier – im Code-Review, nicht im Dashboard.

CI/CD: datacontract test ✓

Reaktion

im Betrieb · kontinuierlich

Fängt die Known Unknowns: die kaputte Nachtlieferung, ausbleibende Daten, schleichenden Drift – ganz ohne Deployment.

Der Contract wird zum Monitor: SLAs laufend prüfen, verletzte Datensätze ausschleusen, Alarm an Producer und Konsumenten.

⚠ freshness: 26h > 24h → alert

Ein Contract, zwei Prüfpunkte: Die Pipeline schützt vor Änderungen, der Monitor vor der Wirklichkeit.

01

Kein Aufrufer, den du kontrollierst

Ein Service kennt seine Aufrufer – bei Pact meldet sich jeder Consumer mit seinem Vertrag an.

Daten werden abgefragt: Jeder mit Leserechten kann konsumieren – und niemand merkt es.

→ Konsumenten sichtbar machen ist Teil des Problems: Registry statt stiller SELECTs.

02

Kein Rollback für die Vergangenheit

Ein kaputtes Deployment rollst du zurück – der nächste Request ist wieder korrekt.

Drei Wochen falsche Daten stecken in jedem Downstream-System, Report und trainierten Modell.

→ Prävention schlägt Heilung: Der Test vor dem Deployment ist alles.

03

„Korrekt“ ist Semantik, nicht Typ

Bei einer API prüft der Compiler den Typ – total: Number ist entweder da oder nicht.

total = 47.11 ist ein valider Float – aber netto oder brutto? Mit oder ohne Storno?

→ Bedeutung gehört in den Contract: Definitionen, Semantik, Geschäftsbegriffe.

Schon heute fragen LLMs und Agenten eure Datenprodukte ab – per MCP, direkt in SQL.

Ein Mensch stutzt, wenn die Zahlen seltsam aussehen, und fragt im Chat nach.
Ein Agent stutzt nicht. Er nimmt, was da ist – und antwortet selbstbewusst.

Der Data Contract wird damit zur einzigen Verteidigungslinie: Er sagt der Maschine, was die Daten bedeuten, wie frisch sie sind – und ob sie ihnen trauen darf.

🤖  „Wie lief der Umsatz letzte Woche?“

Ohne Contract

„48.230 €.“ – aus einer Tabelle, die seit 21 Tagen steht. Kein Zweifel, keine Warnung.

Mit Contract

„Achtung: Die Daten verletzen die zugesicherte Frische von 24 h – letzter Stand vor 21 Tagen.“

Der maschinenlesbare Vertrag über Bedeutung und Qualität wird vom Nice-to-have zur Voraussetzung.

Drei Wochen früher, in der Pipeline von Team Checkout

✗ datacontract test – breaking change: order_total

Der Rename fliegt auf, bevor er deployed wird. Team Checkout sieht in der Registry, wen er getroffen hätte – und spricht vorher mit den Konsumenten.

Und auf dem Dashboard des Fachbereichs

48.230 € ▲ 12 %

● Zuletzt aktualisiert: vor 2 Minuten

1

Schreibt den Vertrag auf, den es implizit schon hat – als ODCS-YAML

2

datacontract test in die Pipeline – Producer wie Consumer

3

Macht eure Konsumenten sichtbar – ein Contract, ein Ort, alle wissen Bescheid