Talk · TDWI München 2026
Open Standards for Data Products
Dr. Simon Harrer (CEO & Co-Founder, Entropy Data) · 23. Juni 2026
Ein Solo-Talk auf der TDWI München 2026. Simon beginnt mit einem Blick in die Zukunft – ein Coding-Agent, der eigenständig ein Datenprodukt baut – und zeigt dann, dass die Zukunft bereits da ist, gebaut auf einem Stack offener Standards: ODCS für Data Contracts, ODPS für Datenprodukte und OSI für Semantik, alles eingebettet in Open-Source-Tooling. Die abschließende Bitte: hilf dabei, Geschichte zu schreiben, indem du diese Standards zur Ziellinie bringst.
Live auf der TDWI München 2026. Die Annotation unten ist eine redigierte Zusammenfassung der Slides.
Der Referent
Simon Harrer beschreibt sich selbst als Software Engineer im Herzen, der vor rund fünf Jahren in die Datenwelt gewechselt ist. Er ist Co-Autor von "Java by Comparison" (mittlerweile Teil der Trainingsdaten mehrerer großer Sprachmodelle, wie er grinsend anmerkt) und hat Zhamak Dehghanis "Data Mesh" ins Deutsche übersetzt. Die deutsche Druckausgabe ist komplett in Farbe – bei keinem englischen Original der Fall.
Heute ist er Co-Founder und CEO von Entropy Data, einem kleinen Startup, das einen Datenprodukt-Marktplatz und eine Metadaten-Schicht baut, mit Kunden weltweit, sechs Menschen und vielen Agenten, die die Arbeit erledigen. Er sitzt im Technical Steering Committee von Bitol bei der Linux Foundation, trägt zum Open Semantic Interchange bei (der Standardisierungsinitiative, die Snowflake gestartet hat), und baut Open-Source-Tooling rund um all das.
Außerdem maintained er data-landscape.com, eine offene Übersicht der offenen Standards in der Datenwelt. Ein Blick lohnt sich, sagt er: alles offen und kostenlos.
Der Plan
Drei Dinge. Erst ein Blick in die Zukunft, als Motivation: Wie könnte das aussehen? Dann die Standards lernen, die offene Art: warum es sie gibt und was sie können.
Und zuletzt gemeinsam Geschichte schreiben. Handys bereithalten und bei GitHub einloggen, sagt Simon dem Saal, denn das brauchen wir noch vor Ende des Talks.
Ein Blick in die Zukunft (nur ein Teaser)
Die Ausgangsfrage: Was wäre, wenn wir bereits offene Standards für Datenprodukte nutzen würden – und sie wirklich leben würden? Um sie zu beantworten, führt Simon eine Live-Demo vor (mit einer Aufzeichnung als Backup, nur für den Fall). In einem Verzeichnis liegen zwei Dateien: ein standardkonformer Data Contract, der die Daten beschreibt, die er anbieten will, und eine ODPS-Datenprodukt-Datei, die die Box im Architekturdiagramm beschreibt – mit Purpose, Domain, Output Ports und Verweisen in die semantische Schicht.
Dann startet er den Coding-Agenten: claude --dangerously-skip-permissions, „mach dieses Datenprodukt Wirklichkeit". Er hat nur aufgeschrieben, was er will. Den Rest findet der Agent selbst heraus, der Build dauert etwa 15 Minuten.
Also lässt er ihn im Hintergrund weiterlaufen, während die Tokens für uns arbeiten, und wendet sich dem eigentlichen Thema des Talks zu. Dieses Bild im Kopf behalten – die Auflösung kommt am Ende.
Erstens, was ist ein Datenprodukt?
Das Publikum auf einer Datenkonferenz kennt das schon, also macht Simon es kurz. Ein Datenprodukt ist Produktdenken, angewendet auf Daten: du optimierst für deine Consumers, übernimmst Ownership, hast ein Team, das dahintersteht, und baust Interfaces, für die du verantwortlich bist. Es ist das zweite der vier Data-Mesh-Prinzipien.
Das kostenlose, quelloffene Data Product Canvas ist der Ort, an dem du eins auf dem Reißbrett entwirfst, in einem Workshop mit Menschen, ausgehend vom Use Case. Simon nennt das fertige Canvas eine „Geburtsurkunde" für das Produkt.
Als Software-Architekt im Herzen sieht er ein Datenprodukt auch als architektonische Einheit: Es nimmt Dinge über Input Ports auf, tut viel im Inneren und stellt Ergebnisse über Output Ports bereit. In der Eingangsdemo hat er nur den Output Port und die Box festgelegt und den Coding-Agenten dann machen lassen.
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
Hier die Geschichte dazu. PayPal hat sein Data-Contract-Format als Version 2.2 quelloffen gemacht und an die Linux Foundation gespendet. Auch Simons eigene Firma hatte ein konkurrierendes Format, wie viele andere auch. Er trat der Standardisierungsinitiative bei, und die Gruppe hat PayPals Version (zugeschnitten auf eine Datenplattform, denn nicht jeder ist PayPal und fährt nur BigQuery) so überarbeitet, dass sie zu jedem Unternehmen passt.
Mit Version 3.1 wurden die beiden Linien zusammengeführt und die eigenen Formate aufgegeben, weil ein starker Standard besser ist als zwei konkurrierende. ODCS 3.2 steht kurz bevor. Die Lehre daraus: Statt daraus 15 Standards zu machen, haben sich die Lager zu einem zusammengeschlossen, verwaltet bei Bitol.
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 Datenprodukt verweist für jeden Output Port (was es teilt) und jeden Input Port (worauf es angewiesen ist) auf einen Contract. Im Beispiel hat ein Orders-Produkt vier Output Ports: Orders in Version 1 und Version 2, plus Non-PII-Varianten – Daten ohne personenbezogene Informationen lassen sich deutlich leichter beziehen, während die sensiblen Ports hinter einem manuellen Freigabeprozess liegen, der Wochen dauern kann. Ein Input Port referenziert ein Kafka-Topic, aus dem eine Pipeline das Angebot baut.
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
Datenprodukte landen in einem Datenmarktplatz, und dort fragen Agenten nach, was es gibt – also braucht auch diese Schicht Standards, sonst landet man wieder bei proprietären Metadatenformaten. Der dritte Standard ist Semantik: Was bedeuten die Daten? Open Semantic Interchange (OSI), stark vorangetrieben von Snowflake, startete mit dem klassischen Semantikmodell: Datasets, Beziehungen und, wichtig, Metriken. Du hast deine Daten schon in Snowflake, Databricks, Oracle oder SAP, und legst eine semantische Schicht darüber.
Auffällig ist, wie KI-first das Format ist. Es trägt Instructions, Synonyme und Beispiele, sodass das Ausfüllen davon Agenten deutlich besser arbeiten lässt: gib deinen Metadaten Instructions, und die Agenten machen mehr daraus. Ansonsten sieht es wie ein Contract aus: Du beschreibst Datasets, Beziehungen und jetzt auch Metriken, zum Beispiel total_revenue als Summe der Bestellbeträge, oder full_name als Vorname plus Leerzeichen plus Nachname.
Und, wie überall, gibt es Open-Source-Tooling, inklusive eines Editors zum Modellieren. (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.
Live während des Talks: Das Open Data Contract Standard Repository erreicht 1.000 Sterne.
Schreiben wir Geschichte
Hier ist der Teil, den der Saal gemeinsam machen kann. Kurz vor dem Talk stand der Open Data Contract Standard bei 978 GitHub-Sternen. Bei 1.000 erreicht er die nächste Stufe und kann innerhalb der Linux Foundation graduieren. Also deine Chance: 22 Sterne – das schaffen wir doch.
Und der Saal tat es. Smartphones kamen raus, der Zähler tickte live nach oben, 998, dann über die Ziellinie.
Wir haben es tatsächlich geschafft. In weniger als fünf Minuten hat die Bitol-Community den Open Data Contract Standard von 978 auf über 1.000 GitHub-Sterne gebracht – live im Saal. Das erfüllt die Voraussetzung für die Graduation von ODCS innerhalb der Linux Foundation. Danke an alle, die den QR-Code gescannt und einen Stern vergeben haben. Zusammen können wir Berge versetzen.
Wenn dir die Standards in diesem Talk nützlich sind, gib dem ODCS-Repo einen Stern und hilf dabei, ihn weiter wachsen zu lassen.
Danke
Das ist die These: Datenprodukte, gebaut auf einem Stack offener Standards – ODCS für Contracts, ODPS für Produkte, OSI für Semantik – lassen Agenten und Menschen Daten auf dieselbe Weise bauen und konsumieren. Die Zukunft kommt nicht erst noch; sie ist ein git clone entfernt.
Probier den Contract-basierten Datenprodukt-Marktplatz selbst aus auf demo.entropy-data.com, erreich Simon unter simon.harrer@entropy-data.com oder auf LinkedIn, und gib der datacontract-cli einen Stern auf GitHub, wenn sie dir geholfen hat.
Q&A
Ausgewählte Fragen aus dem Publikum nach dem Talk.
F: Stehen Data Mesh und Datenprodukte im KI-Zeitalter endlich vor dem Durchbruch, jetzt wo Metadatenqualität der eigentliche Hebel ist?
Das ist die These. Data Mesh blieb oft an der Politik hängen, am Pendel zwischen Zentralisierung und Dezentralisierung, und im BI-Kontext hat es häufig nicht abgehoben. Was sich geändert hat: Metadatenqualität hat früher niemanden interessiert; Governance konnte Zuckerbrot und Peitsche schwingen, wie sie wollte, es hat niemanden gekümmert. Jetzt sagst du einem Agenten „los", und bei schlechten Metadaten produziert er selbstbewusst Müll, während er bei guten, durch Standards getriebenen Metadaten etwas wirklich Brauchbares liefert. Das erzeugt eine echte Feedback-Schleife, die sich um Metadatenqualität kümmert. Standards sind keine Wunderwaffe und kein Feuerwehrschlauch, der alles löst, aber sie schubsen dich in die richtige Richtung und helfen, mittelmäßige Agenten zu guten zu machen. Selbst so etwas Kleines wie die Instructions, Synonyme und Beispiele in OSI verbessern die Agenten-Ergebnisse spürbar.
F: Sind Metadaten nicht ein Konkurrenzprodukt für die großen Plattformen – und eine neue Form von Lock-in?
Ja, und genau deshalb solltest du auf offene Standards setzen. Der Erfolg von Agenten entscheidet sich an Metadaten, also will jeder große Anbieter, dass deine Metadaten bei ihm leben. Gerade entsteht ein riesiges Metadaten-Lock-in, und es ist noch stärker, wenn deine Metadaten in einem proprietären Format vorliegen. Als Kunde brauchst du eine gewisse Verhandlungsmacht bei Preisen; wenn der Anbieter sagen kann „aber all deine Metadaten sind schon hier", sitzt du fest. Also kontrolliere deine Metadaten, behalte sie im eigenen Haus, vielleicht sogar privat. Metadaten selbst sind nicht teuer und nicht groß; der teure Teil ist Compute und Inference.
F: ODPS wirkt dünn bei dem, was zwischen Input und Output Ports passiert. Wird die Logik standardisiert, oder nutze ich Custom Properties?
Da wird noch etwas passieren, aber gerade liegt der Fokus nicht darauf, sondern auf ODCS. Es gibt bereits einen Teil im Bill-of-Materials-Stil, die Idee aus der Fertigung, woraus ein Produkt besteht, und du kannst heute schon einiges davon so modellieren, auch wenn ich das noch nicht oft in Gebrauch gesehen habe. Der größere Punkt ist: Mit ODCS und ODPS hast du eine Art Spec für deinen Coding-Agenten, und die Skills sorgen dafür, dass er konforme Produkte baut. „Anonymisiere diese Spalte" im Contract zu kodieren, und wie die Anonymisierung in den Skills passiert, setzt der Agent zusammen. Wie viel du wirklich beschreiben musst, ist eine offene Frage – vielleicht weniger, als wir denken. Beschreibe das Ziel und die Qualität, die du willst, nicht jeden einzelnen Schritt.
F: Wie vermeide ich teure Metadatenpflege, wenn das Fachwissen bei Domain Experts liegt, die niemals YAML schreiben werden?
Eine Antwort ist eine Domain-Ontologie, erarbeitet mit dem Business in Workshops, genauso wie du ein Data Product Canvas ausfüllst. Die technischen und physischen Details sind Sache der Engineers, aber du kannst das Business trotzdem in die Diskussion einbeziehen. Es gibt kein Wundermittel. Was ich beobachte: Mit KI schmerzt Bürokratie weniger – KI automatisiert die bürokratischen Teile, sodass du den Nutzen bekommst, ohne dass es dich als Mensch aufreibt. Der alte Einwand „Data Contracts sind zu viel Aufwand" ist dramatisch geschrumpft. Eine kleine Anekdote: Du kannst den Input-Contract mit KI entwerfen, indem du ihr deine Guidelines für einen guten Contract fütterst, plus zum Beispiel das Transkript eines Meetings, das eine Stunde vorher stattfand. Wichtig bleibt, dass das Artefakt als Source of Truth existiert.
F: Wird das schon in der Praxis eingesetzt, wo der Agent das meiste baut und du reviewst und verfeinerst?
Ja. Wir haben US-Kunden, die das beeindruckend einsetzen, Contract-first: Sie nutzen KI, um den Contract zu entwerfen, er wird reviewt, und dann baut ein anderer Agent die Pipeline. Das entscheidende Artefakt ist der Contract. Dort einigt man sich, dort sitzt die Review-Schleife, dort steigt der Mensch ein. Stell dir den Contract wie eine Kommode vor: Du legst deine Qualitätsanforderungen in eine Schublade, deine Anonymisierungs- oder Pseudonymisierungsstrategie in eine andere, deine Schutzklasse in eine weitere. Menschen füllen die Schubladen, der Agent baut, und es bleibt Platz für Menschen im Prozess – das ist ziemlich schön.