Abschluss

Rückblick auf das Gebaute und wie es weitergeht.

~10 Min.0 von 2 Schritten erledigt

Geschafft! Schau auf das Gebaute zurück und überleg, wie es zu deinen eigenen Daten passt.

Was du gebaut hast

Ein Quell-Datenprodukt mit Kontrakten. Du hast die orders-Tabellen unter einen ODCS-Kontrakt gestellt, ihn testbar gemacht und um Semantik, Qualitätsregeln, Ownership und Service Levels ergänzt.
Sichere Evolution. Du hast einen Breaking Change als neue Major-Version (orders_v2) veröffentlicht und den Migrationszyklus durchlaufen.
Datenprodukte. Du hast Orders und SKU Sales mit ODPS beschrieben, inklusive Input- und Output-Ports.
Contract-first-Entwicklung. Du hast SKU Sales vor dem SQL entworfen und die fehlschlagenden Tests als Spezifikation genutzt, für dich oder einen KI-Agenten.
Consumer-driven Contracts. Du hast explizit gemacht, von welchen Feldern du abhängst.
Automatisierung. GitHub Actions testet jede Änderung und stoppt Breaking Changes im Pull Request.
Wenn du Teil D gemacht hast: eine Plattform, auf der andere Teams deine Datenprodukte finden, und Semantik, die deine Fachsprache einmal definiert.

Reflektieren

Auf deine eigenen Daten übertragen

Nimm dir fünf Minuten und schreib kurze Antworten auf. Sie sind ein guter erster Entwurf für einen Vorschlag an dein Team.

Welcher Datensatz in deinem Unternehmen würde zuerst von einem Kontrakt profitieren? Denk an Daten, die viele Teams nutzen, die oft kaputtgehen oder in kritische Reports einfließen.
Wer wäre Owner des Kontrakts? Wer beantwortet Fragen zu den Daten, und wer entscheidet über Änderungen?
Wer sind die Konsumenten? Kennen die Owner sie heute?
Wo würden die Kontrakttests laufen? In der Pipeline des Producers, in der CI bei jeder Änderung, zeitgesteuert?
Welche Qualitätsregel würdest du als Erstes schreiben? Was ist kürzlich schiefgegangen, das ein Test erkannt hätte?

So fängst du in deiner Organisation an

Klein anfangen. Stell einen wichtigen Datensatz unter Vertrag, so wie Orders. Ein täglich getesteter Kontrakt überzeugt mehr als ein großer Rollout-Plan.
Neue Datenprodukte contract-first bauen. Stimm die Schnittstelle mit deinen Konsumenten ab, bevor du baust. Das kostet wenig und spart Nacharbeit.
Kontrakte in Git ablegen und in der CI testen. Ein ungetesteter Kontrakt veraltet wie jede andere Dokumentation.
Breaking Changes sichtbar machen. Nutze datacontract breaking in Pull Requests und veröffentliche Breaking Changes als neue Major-Versionen mit Übergangszeit.
Konsumenten zu Wort kommen lassen. Consumer-driven Contracts zeigen Producern, was wirklich wichtig ist.

Weiterlernen

Open Data Contract Standard (ODCS) und Open Data Product Standard (ODPS): die vollständigen Spezifikationen
Data Contract CLI: alle Befehle, Importer und Exporter (GitHub)
Data Product CLI: ODPS-Datenprodukte prüfen und veröffentlichen
Data Contract Editor: der visuelle Editor im Browser, ohne Installation
Entropy Data Docs: die Datenproduktplattform aus Teil D

Feedback geben

Hat etwas nicht funktioniert? War ein Schritt unklar? Eine Idee für eine Übung? Leg ein Issue auf GitHub an. Jedes Feedback verbessert das Tutorial.

Danke, dass du das Tutorial durchgearbeitet hast, und viel Erfolg mit deinem ersten Datenkontrakt in Produktion!

Was du gebaut hast

Ein Quell-Datenprodukt mit Kontrakten. Du hast die orders-Tabellen unter einen ODCS-Kontrakt gestellt, ihn testbar gemacht und um Semantik, Qualitätsregeln, Ownership und Service Levels ergänzt.

Sichere Evolution. Du hast einen Breaking Change als neue Major-Version (orders_v2) veröffentlicht und den Migrationszyklus durchlaufen.

Datenprodukte. Du hast Orders und SKU Sales mit ODPS beschrieben, inklusive Input- und Output-Ports.

Contract-first-Entwicklung. Du hast SKU Sales vor dem SQL entworfen und die fehlschlagenden Tests als Spezifikation genutzt, für dich oder einen KI-Agenten.

Consumer-driven Contracts. Du hast explizit gemacht, von welchen Feldern du abhängst.

Automatisierung. GitHub Actions testet jede Änderung und stoppt Breaking Changes im Pull Request.

Wenn du Teil D gemacht hast: eine Plattform, auf der andere Teams deine Datenprodukte finden, und Semantik, die deine Fachsprache einmal definiert.

Reflektieren

Auf deine eigenen Daten übertragen

Nimm dir fünf Minuten und schreib kurze Antworten auf. Sie sind ein guter erster Entwurf für einen Vorschlag an dein Team.

Welcher Datensatz in deinem Unternehmen würde zuerst von einem Kontrakt profitieren? Denk an Daten, die viele Teams nutzen, die oft kaputtgehen oder in kritische Reports einfließen.
Wer wäre Owner des Kontrakts? Wer beantwortet Fragen zu den Daten, und wer entscheidet über Änderungen?
Wer sind die Konsumenten? Kennen die Owner sie heute?
Wo würden die Kontrakttests laufen? In der Pipeline des Producers, in der CI bei jeder Änderung, zeitgesteuert?
Welche Qualitätsregel würdest du als Erstes schreiben? Was ist kürzlich schiefgegangen, das ein Test erkannt hätte?

So fängst du in deiner Organisation an

Klein anfangen. Stell einen wichtigen Datensatz unter Vertrag, so wie Orders. Ein täglich getesteter Kontrakt überzeugt mehr als ein großer Rollout-Plan.

Neue Datenprodukte contract-first bauen. Stimm die Schnittstelle mit deinen Konsumenten ab, bevor du baust. Das kostet wenig und spart Nacharbeit.

Kontrakte in Git ablegen und in der CI testen. Ein ungetesteter Kontrakt veraltet wie jede andere Dokumentation.

Breaking Changes sichtbar machen. Nutze datacontract breaking in Pull Requests und veröffentliche Breaking Changes als neue Major-Versionen mit Übergangszeit.

Konsumenten zu Wort kommen lassen. Consumer-driven Contracts zeigen Producern, was wirklich wichtig ist.

Weiterlernen

Open Data Contract Standard (ODCS) und Open Data Product Standard (ODPS): die vollständigen Spezifikationen

Data Contract CLI: alle Befehle, Importer und Exporter (GitHub)

Data Product CLI: ODPS-Datenprodukte prüfen und veröffentlichen

Data Contract Editor: der visuelle Editor im Browser, ohne Installation

Entropy Data Docs: die Datenproduktplattform aus Teil D

Feedback geben

Hat etwas nicht funktioniert? War ein Schritt unklar? Eine Idee für eine Übung? Leg ein Issue auf GitHub an. Jedes Feedback verbessert das Tutorial.

Danke, dass du das Tutorial durchgearbeitet hast, und viel Erfolg mit deinem ersten Datenkontrakt in Produktion!