Open Standards for Data Products

Der Referent

Simon Harrer beschreibt sich selbst als Software Engineer, der in Daten eingetaucht ist: Er baut Tools, die dazu beitragen, dass Daten, Menschen und Agenten zusammenarbeiten können. Er ist Co-Autor von "Java by Comparison", hat Zhamak Dehghanis "Data Mesh" ins Deutsche übersetzt und die Website Data Mesh Architecture verfasst.

Er maintained die Open-Source-Data Contract CLI und data-landscape.com, sitzt im Technical Steering Committee der Bitol-Standards (ODCS & ODPS) und trägt zum Open Semantic Interchange (OSI) bei.

Sein Hauptjob ist Entropy Data – ein Datenprodukt-Datenmarktplatz, der auf Data Contracts und Semantik aufbaut und hochwertige Daten für Agenten und Menschen gleichermaßen verfügbar macht. ISO 27001 zertifiziert, sechs Produkt-Engineers, Kunden in den USA, der EU, der Schweiz und Australien. Kein VC, und profitabel – trotz der Tokens.

Der Plan

Drei Bewegungen. Erst in die Zukunft blicken – einem Coding-Agenten zuschauen, der ein Datenprodukt aus nichts weiterem als einem Contract baut. Dann die Standards lernen, die das möglich machen: die wenig glamouröse Infrastruktur, die einen Demo-Moment in etwas verwandelt, das du in der Produktion betreiben kannst.

Und schließlich Geschichte schreiben – denn diese Standards werden noch geschrieben, und die Anwesenden können mitentscheiden, ob sie Bestand haben.

Ein Blick in die Zukunft

Die Ausgangsfrage: Was wäre, wenn wir bereits offene Standards für Datenprodukte nutzen würden? Simons Antwort: er baut live eins – mit einem Coding-Agenten, ohne eine einzige Zeile händisch zu schreiben.

Das Rezept besteht aus vier Zutaten rund um einen Coding-Agenten (Claude Code, Codex, Copilot). Das Was kommt aus maschinenlesbaren Spezifikationen – einem Data Contract in ODCS-YAML, einem Datenprodukt in ODPS-YAML und einem Prompt. Das Wie kommt aus Skills, die deine Konventionen kodieren. Das Womit kommt aus Tools, die den Agenten mit deinen Systemen verbinden.

Am Ende steht ein echtes Datenprodukt – ein Dataset, ein dbt-Projekt, ein Databricks Asset Bundle. Der Rest des Talks ist den Standards hinter jedem dieser Bausteine gewidmet.

Woher Datenprodukte kommen

Eine kurze Einordnung: Das Datenprodukt ist das zweite der vier Data Mesh-Prinzipien – Domain Ownership, Data as a Product, die Self-Serve Data Platform und Federated Governance.

„Data as a Product" bedeutet, Produktdenken auf Daten anzuwenden: klare Ownership, ein Consumer Mindset und interoperable Interfaces. Genau dieses letzte Wort – interoperabel – ist der Bereich, in dem sich offene Standards wirklich bezahlt machen.

Was ein Datenprodukt wirklich ist

Bevor man etwas standardisiert, braucht man ein gemeinsames Bild der Sache. Das kostenlose Data Product Canvas hält den Purpose, die Output Ports, den Data Contract und die Consumers fest – das Gespräch, das du führst, bevor du Code schreibst.

Architektonisch ist ein Datenprodukt eine eigenständige Einheit mit Input Ports, Output Ports und einem Discovery Port für Metadaten, die Transformationscode, Storage, Tests, Policies, CI/CD und Observability nach innen kapselt. Jede dieser Schnittstellen und Komponenten ist ein Kandidat für einen Standard.

Was ist ein Standard – und warum lohnt es sich?

Ein Standard ist letztlich eine Vereinbarung darüber, wie etwas gemacht wird, damit verschiedene Menschen und Tools interoperieren können, ohne jedes Mal neu verhandeln zu müssen. ISO-8601-Datumsangaben (2013-02-27) sind das Paradebeispiel – ein Format, das alle parsen können.

Und das klassische Risiko ist das obligatorische xkcd: Jemand sieht 14 konkurrierende Standards, beschließt, sie zu vereinheitlichen, und am Ende gibt es 15. Genau dieses Ergebnis zu vermeiden ist das eigentliche Spiel im Bereich Datenprodukte gerade.

Vier Dimensionen zur Bewertung eines Standards

• De facto vs. de jure – ist er Standard, weil ihn Menschen tatsächlich nutzen, oder weil ein Gremium es so festgelegt hat? (Nutzung)
• Initiative vs. Vendor – wird er von einer neutralen Community verwaltet oder gehört er einem einzigen Unternehmen? (Eigentümer)
• Viele vs. einer – ist die Kontrolle auf viele Contributors verteilt oder liegt sie bei einer einzelnen Partei? (Steuerung)
• Offen vs. Paywall – kann ihn jeder kostenlos lesen und adoptieren, oder kostet das etwas? ($$$)

Die Standards, auf die es sich zu setzen lohnt, liegen auf allen vier Dimensionen auf der linken Seite: in der Praxis genutzt, community-gesteuert, breit verankert und offen. Behalte diese Scorecard für alles im Folgenden im Kopf.

Eine Karte der offenen Standards

Um das gesamte Feld auf einen Blick zu sehen, pflegt Simon data-landscape.com – eine meinungsstarke, interaktive Karte der offenen Standards, die eine moderne Datenarchitektur antreiben, geordnet danach, was sie beschreiben: Contracts, Datenprodukte, Schema und Semantik.

Inspiriert vom CNCF Landscape und dem ThoughtWorks Tech Radar wird jeder Standard als adopt / situational / assess / caution bewertet. Der Rest des Talks geht durch die drei Spalten, die für Datenprodukte am wichtigsten sind: Contracts, Products und Semantics.

Was ist ein Data Contract?

Ein Data Contract ist ein Dokument, das Ownership, Struktur, Semantik, Qualität und Nutzungsbedingungen für den Datenaustausch zwischen einem Data Producer und seinen Consumers definiert. Stell dir eine API vor – aber für Daten.

Der Producer besitzt den Contract und liefert die Daten; der Consumer vertraut dem Contract und greift auf die Daten zu. Alles, worauf der Consumer sich verlassen kann, ist schriftlich festgehalten – und entscheidend: maschinenlesbar. (Mehr dazu in Was ist ein Data Contract?)

Die große Format-Zusammenführung

Es war einmal so, dass jedes Unternehmen sein eigenes Data-Contract-Format bastelte – die klassische xkcd-Falle. Dann entstanden zwei Linien: die Data Contract Specification (dank der Data Contract CLI weit verbreitet) und ODCS (von PayPal als Vorlage gespendet).

Statt daraus 15 Standards zu machen, fusionierten die beiden Lager. ODCS fand eine neutrale Heimat bei Bitol in der Linux Foundation, Simon trat dem TSC bei, und die Data Contract CLI unterstützt ODCS nun vollständig. Ein Standard für alle – de facto und de jure.

Der Open Data Contract Standard

ODCS v3 ist der Baustein. Eine einzige YAML-Datei trägt die Fundamentals (Version, Name, Status), das Schema (Tabellen, Spalten, Semantik), Data-Quality-Regeln, Team und Ownership, Terms of Use, SLAs, Server und beliebige Custom Properties.

Jeder Abschnitt besteht aus nur wenigen Zeilen lesbarem YAML – zuerst Fundamentals, dann Schema, dann Quality-Regeln, die automatisch ausgeführt werden können. Das reicht für einen Menschen, um die Daten zu verstehen, und für eine Maschine, um darauf zu handeln. (Hintergrund: Open Data Contract Standard.)

Was jetzt? Alles automatisieren

Eine YAML-Datei lohnt sich nur zu schreiben, wenn etwas sie auch liest. Sobald ein Contract maschinenlesbar ist, wird er zur einzigen Quelle, die alles Weitere antreibt:

• Code-Generierung: Java, Pydantic, dbt-Modelle, SQL DDL
• Testing: Contract gegen echte Daten prüfen, Breaking Changes in PRs erkennen, kontinuierlich monitoren
• Metadaten-Distribution: in Metastores, Kataloge (Collibra) und Datenmarktplätze (Entropy Data) pushen
• Infrastructure Provisioning: Output Ports, Input Ports, Anonymisierung, Access Control
• Collaboration & Governance: Namenskonventionen, Schema-Evolution, Nutzungsvereinbarungen, Genehmigungsworkflows

Eine Datei rein – eine ganze Toolchain raus.

Open-Source-Tooling: die CLI

Das Arbeitstier ist die Open-Source-Data Contract CLI. Sie importiert Contracts aus bestehenden Quellen (SQL DDL, JSON Schema, Iceberg, dbt, BigQuery), exportiert in ein Dutzend Ziele (SQL, HTML, dbt, Pydantic) und testet einen Contract gegen echte Daten in S3, BigQuery, Azure, Databricks, Snowflake oder Kafka.

Die Star-History-Kurve erzählt die Adoptionsgeschichte: Sowohl die CLI als auch das ODCS-Repo klettern steil auf 1.000 GitHub-Sterne zu – genau die de-facto-Traktion, die einen Standard am Leben hält.

Schreib es, wie du möchtest

Niemand sollte YAML von Hand bearbeiten müssen, wenn er das nicht will. Der Open-Source Data Contract Editor bietet eine standardkonforme Authoring-Erfahrung mit Live-Preview und Validierung.

Und für die Spreadsheet-Fraktion gibt es das ODCS-Excel-Template – auf vielfachen Wunsch entstanden – das das Schema in Excel erfasst und später nach YAML konvertiert. Der Standard, der Editor, die CLI und das Template: vier kostenlose Tools, ein Format.

Der Open Data Product Standard

Beschreibt ODCS ein einzelnes Interface, so beschreibt ODPS – der Open Data Product Standard – das Produkt, das sie exponiert. Es ist die primäre Konfiguration und Dokumentation für ein Datenprodukt, und es baut auf ODCS auf: seine Input und Output Ports referenzieren Data Contracts per ID.

Ein ODPS-YAML kann mehrere versionierte Output Ports deklarieren – etwa einen orders_pii-Port und einen orders_npii-Port – jeder mit eigenem Contract, plus die Input Ports, die es konsumiert.

Weil Ports auf Contracts zeigen, erhältst du Lineage gratis: Applikationen speisen Datenprodukte, die wiederum andere Datenprodukte und Consumers speisen – als Graph, den du tatsächlich nachverfolgen kannst. (Siehe Was ist ein Datenprodukt?)

Was in Bitol kommt

Die Bitol-Familie wächst. Neben ODCS (3.1 jetzt, 3.2 in Vorbereitung) und ODPS (1.0 jetzt, 1.1 in Vorbereitung) gibt es OORS für Observability-Ergebnisse, die in die Quality- und SLA-Prüfungen eines Contracts zurückfließen.

Weiter in der Pipeline liegen Entwürfe für Data Domains (ODDS), Data Mesh (ODMS), Access Agreements (OAAS) und Orchestrierung & Steuerung (OOCS) – ein koordiniertes Set statt 15 konkurrierender Einzellösungen.

Achtung: Namenskonflikt

Ein echtes Praxisproblem, mit einem Grinsen vorgetragen: „ODPS" bezeichnet zwei verschiedene Dinge. Es gibt den Open Data Product Standard (Teil der Bitol-Familie, verknüpft mit ODCS über Input und Output Ports, einfaches Pricing, kein i18n) und die Open Data Product Specification (eigenständig, eingeschränkte Output-Port-Unterstützung, stark bei Preisplänen und i18n).

Beide kürzen sich als ODPS ab, beide sitzen unter LF AI & Data. Wenn du also einem Coding-Agenten sagst, er soll „ODPS nutzen", achte darauf, welches du meinst – die unordentliche Realität von Standards, die noch im Werden sind.

Open Semantic Interchange

Die dritte Säule ist Bedeutung. Open Semantic Interchange (OSI, noch v0.2.0.dev) definiert ein gemeinsames Semantikmodell – Datasets, Beziehungen und Metriken – das sowohl KI-Agenten als auch BI-Tools (Tableau, Qlik, MicroStrategy) von einem einzigen Ort konsumieren können.

Es ist die Schicht, die einem Tool sagt, was eine „Order" oder ein „Average Order Value" eigentlich ist, anstatt jeden Consumer raten zu lassen. Data Contracts und Datenprodukte verweisen darauf. (Mehr: Semantik.)

Contract vs. Semantikmodell

ODCS und OSI überlappen, ziehen aber in unterschiedliche Richtungen. Beide decken Schema, Beziehungen und Custom Properties ab. OSI fügt erstklassige Metriken, dynamische Felder und KI-Kontext hinzu; ODCS fügt Terms of Use sowie Quality & SLAs hinzu.

Die beiden ergänzen sich – der Contract regelt den Austausch, das Semantikmodell trägt die Bedeutung – und die Lücken auf jeder Seite (Metriken für ODCS, Governance für OSI) sind genau das, woran die Working Groups gerade arbeiten.

Starke Unterstützung dahinter

OSI hat ernsthaften Rückenwind – Working Groups zu fortgeschrittenen Metriken und einer Ausdruckssprache, Composability, Katalog-Integration, Ontologie-Repräsentation (bereits in 0.2.0.dev gelandet) und Model-Convertern.

Die Schlagzeile: OSI wurde in den Apache Incubator aufgenommen – unter dem neuen Namen Apache Ossie – und zieht in ein vendor-neutrales Zuhause um, damit es weiter als gemeinsame Business-Context-Schicht wachsen kann, die KI-Agenten und BI-Tools gleichermaßen brauchen.

Die Zukunft ist jetzt

Zurück zur Ausgangsfrage – was wäre, wenn wir bereits offene Standards für Datenprodukte nutzen würden? – und die Antwort liegt auf der Hand: wir tun es. Simon öffnet ein frisches Projekt und schickt Claude Code einen einzigen Prompt: „Implement the data product shelf-warmer-clearance-optimizer. Don't ask me anything. Request access yourself."

Von da an läuft er eigenständig – er liest den Contract, fragt Zugriff auf die drei vorgelagerten Datenprodukte an, die er braucht, erhält die Genehmigungen, schreibt ein dbt-Projekt, materialisiert die Tabelle auf Snowflake (13.987 Zeilen, OpenLineage-Events versendet), besteht dbt test und datacontract test und veröffentlicht das fertige Produkt zurück in den Marktplatz.

Der Contract sagt das Was, ODPS verdrahtet die Ports, OSI liefert die Bedeutung, Skills tragen das Wie, und Tools ermöglichen den Zugriff. Jeder Baustein aus dem ersten Slide ist jetzt ein echter, offener Standard – und der Agent übernimmt das Tippen.

Hilf ODCS, Geschichte zu schreiben

So kannst du das nächste Kapitel mitschreiben: ODCS braucht 1.000 GitHub-Sterne, um innerhalb der Linux Foundation zu graduieren. Die Graduation ist ein Signal für Adoption – genau die de-facto-Traktion, die einen de-jure-Standard am Leben hält.

Wenn dir die Standards in diesem Talk nützlich sind, gib dem ODCS-Repo einen Stern. Es kostet einen Klick und hilft einem offenen Standard, offen zu bleiben.