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, in drei Sätzen. Simon beginnt mit einem Teaser auf die Zukunft: Er startet einen Coding-Agenten, der eigenständig ein Datenprodukt baut, und lässt ihn dann im Hintergrund laufen. Die Mitte des Talks widmet er dem Stack offener Standards, der das möglich macht (ODCS für Data Contracts, ODPS für Datenprodukte, OSI für Semantik), und dem Open-Source-Tooling drumherum. Am Ende ist der Agent fertig, und die Zukunft stellt sich als bereits angekommen heraus. 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, was auf kein englisches Original zutrifft.
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.
Und was ist ein Standard?
Das obligatorische xkcd bringt es auf den Punkt. Wir brauchen Standards, um uns auf etwas zu einigen und Komplexität zu reduzieren: Das eine richtige Datumsformat ist das ISO-Format, und alles andere ist falsch. Genauso beim Countdown vor dem Start, „3, 2, 1, los", damit niemand unsicher ist, ob es bei „eins" losgeht oder erst danach.
Und das obligatorische Risiko: Es gibt 14 Standards, ein großer Player will mitmischen, und jetzt sind es 15. Das passiert überall, auch in der Datenwelt. Nützlich, wenn es Komplexität reduziert, schmerzhaft, wenn nur ein weiterer Kandidat dazukommt.
Was einen guten Standard ausmacht
Simon spannt vier Dimensionen auf, und er will jeweils die linke Seite:
- De facto vs. de jure (Nutzung): Wenn ihn einfach alle nutzen, ist er in der Praxis ein Standard, auch wenn kein Gremium das je erklärt hat.
- Initiative vs. Vendor (Eigentümer): besser, wenn eine Initiative dahintersteht, damit die Macht nicht bei einem einzigen Unternehmen liegt, das ihn vollständig kontrollieren kann.
- Viele vs. einer (Steuerung): Ist die Macht auf viele Contributors verteilt oder liegt sie bei einer einzelnen Partei?
- Offen vs. Paywall (Kosten): Kann ihn jeder lesen und adoptieren, oder zahlst du einem Gremium dafür, die Spec überhaupt lesen zu dürfen?
Die Standards, auf die es sich zu setzen lohnt, liegen auf allen vier Dimensionen links: in der Praxis genutzt, community-gesteuert, breit verankert und offen.
Eine Karte der offenen Standards
Standards stecken überall in einem Datenprodukt: in seiner Beschreibung, im Lesen anderer Produkte, in Processing, Storage, Scheduling, Monitoring, Observability. Um das gesamte Feld auf einen Blick zu sehen, pflegt Simon data-landscape.com, eine meinungsstarke, interaktive Karte der Metadaten- und Datenstandards, die er als adopt, situational, assess oder caution einstuft.
Für diesen Talk konzentriert er sich auf drei, die ihm persönlich nahe sind und zu denen er ehrlich etwas sagen kann: ODCS, ODPS und OSI. Die anderen kennt er nur von außen.
Was ist ein Data Contract?
Ein Data Contract existiert, um Vertrauen aufzubauen. Ein Data Producer bietet Daten an, ein Data Consumer will sie nutzen, und der Contract dazwischen trägt die Zusagen und Garantien des Producers zu diesem Datensatz (der aus mehreren Tabellen bestehen kann). Er deckt Struktur, Semantik, Ownership, Qualität und Nutzungsbedingungen ab.
Der Bedarf an Data Contracts ist vor ein paar Jahren in vielen Unternehmen parallel entstanden. Jeder hat sein eigenes Format gebaut, in YAML, JSON, Excel, Word oder Confluence, aber das zugrunde liegende Problem war immer dasselbe: festhalten, welche Garantien ein Provider für ein Datenangebot gibt. (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.
Im Inneren des Open Data Contract Standard
ODCS v3 trägt Schema-Informationen, Data Quality, Pricing (im Standard enthalten, auch wenn Simon noch nie jemanden gesehen hat, der es nutzt, eine unterhaltsame akademische Diskussion), Ownership und Team, Security, Service Level Agreements, Infrastruktur und mehr. Nachlesen kannst du das alles auf datacontract.com.
Der interessante Teil ist das Schema: Es speichert Dinge wie Datenklassifizierung und PII-Flags, Beispielwerte und inline definierte Data-Quality-Checks. Ein Check kann eine Menge gültiger Werte erzwingen, ein anderer kann rohes SQL sein, das als standardkonformer Quality-Check läuft. Du kannst außerdem festhalten, wem das Produkt gehört und wie man die Verantwortlichen erreicht, die Nutzungsbedingungen (was du mit den Daten tun darfst und was nicht, plus Links auf eine Datenschutzerklärung oder eine Lizenz bei eingekauften Daten) und SLAs wie Aufbewahrung und Aktualität.
Und es steht darin, wo die Daten liegen. Im Beispiel ist das Postgres auf Supabase, und ab ODCS 3.2 gibt es auch eine Hana-Location. (Hintergrund: Open Data Contract Standard.)
Was jetzt? Alles automatisieren
Warum hat sich der Standard gelohnt? Weil du das Format nicht erfinden musst und Logik daran hängen kannst. Das sind die besten Metadaten, die du über einen Datensatz haben kannst, argumentiert Simon, und besser wird es nicht, erst recht nicht, sobald du sie zusätzlich an eine Ontologie bindest. Sobald ein Contract maschinenlesbar ist, treibt er alles Weitere an:
- Code-Generierung: Java, Pydantic, dbt-Modelle, SQL DDL
- Testing: die Daten auf Hana oder jedem anderen System gegen den Contract prüfen, an jedem Punkt im Lebenszyklus, plus Erkennung von Breaking Changes und Monitoring
- Metadaten-Distribution: in Metastores, Datenkataloge und Datenmarktplätze pushen
- Infrastructure Provisioning: Output Ports, Input Ports, Anonymisierung, Access Control
- Collaboration und Governance: Namenskonventionen, Schema-Evolution, Nutzungsvereinbarungen, Genehmigungsworkflows
Menschen können ihn nutzen, deterministische Systeme können ihn nutzen, und Agenten auch, genau das, was der Agent im Hintergrund gerade tut.
Offene Standards bekommen offenes Tooling
Ein offener Standard lässt dich offenes Tooling bauen, das Hand in Hand mit ihm arbeitet, sodass du die Automatisierung fast geschenkt bekommst, wenn du den Standard adoptierst. Die Open-Source-Data Contract CLI (rund 900 GitHub-Sterne) liest das YAML, verbindet sich mit allen üblichen Datenanbietern, führt die Checks aus und gibt dir einen Testreport zurück, den du überall mit hinnehmen kannst. Sie importiert und exportiert außerdem, sodass du schnell zu einem Contract kommst und von dort aus weiterarbeitest.
Standard und Tooling sind eng gekoppelt. Die Star-History-Kurve zeigt beide gemeinsam auf 1.000 Sterne zuklettern: Die CLI lag lange vorn, unterstützt von einem Rewrite von Go nach Python (die Datenwelt lebt in Python), während der Standard am Ende einen Hockeystick zeigt. Ein Standard ohne Tooling ist anfangs wertlos, weil du alles selbst bauen musst; gib den Leuten die Automatisierung kostenlos, und der Standard setzt sich durch.
Ein Editor und das obligatorische Excel
Weil nicht jeder fließend YAML spricht, gibt es außerdem einen Open-Source-Data Contract Editor mit einer Formularansicht, einer YAML-Ansicht mit Live-Preview und einer Diagrammansicht, die wie ein Datenmodellierungs-Tool funktioniert.
Und das obligatorische Excel. Simon hatte gehofft, darum herumzukommen, aber die Realität zeigte immer wieder Unternehmen, die ihre eigenen Spreadsheets bauten, um ODCS-Contracts zu erfassen, also hat das Team eines gebaut, mit automatischer Konvertierung von Excel nach YAML. Es wurde sehr beliebt. Setz auf den Standard, und du bekommst den Editor, das Excel-Template und die CLI-Automatisierung als Paket. Wenn du willst, dass offene Standards gewinnen, hilf beim Tooling mit, denn das treibt die Adoption, und die Adoption bringt auch Anbieter dazu, sie zu unterstützen.
Der Open Data Product Standard
Data Contracts sprechen nicht über Datenprodukte; ein Contract ist eigentlich das Interface, der Datensatz, den du teilst. Ein Datenprodukt kann aus Simons Sicht mehrere Contracts auf mehreren Plattformen gleichzeitig anbieten, und dafür gibt es einen Standard, der gut passt: ODPS.
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, denn 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, bekommst du Lineage auf Produktebene: Ein Order Service speist das Orders-Produkt, das wiederum weitere Consumers speist. (Siehe Was ist ein Datenprodukt?)
Was in Bitol kommt
Kurze Handzeichen-Umfrage: Rund 10 % im Saal nutzen ODCS bereits. ODCS 3.2 landet bald, ODPS 1.1 kommt, und die Working Group entwirft weitere Standards rund um Observability, Data Domains, Access Agreements und Orchestrierung.
Das dauert seine Zeit, merkt Simon an. Das Komitee trifft sich nicht oft, und alle machen das neben der Arbeit, die tatsächlich die Rechnungen bezahlt.
Achtung: zwei Dinge heißen ODPS
Pass auf die Verwechslung auf: Es gibt zwei Standards namens ODPS, beide bei der Linux Foundation. Einer gehört zur Bitol-Familie, arbeitet über Input Ports gut mit ODCS zusammen und kann mehrere Contracts referenzieren. Der andere steht für sich, kennt kein Konzept von Input Ports und bildet nur auf einen einzigen ODCS ab.
Dahinter stecken wirklich unterschiedliche Vorstellungen davon, was ein Datenprodukt ist. Der aus der Bitol-Familie ist schwächer bei Pricing und Internationalisierung; der andere ist stark bei Preisplänen und i18n. Der eine heißt Standard, der andere Specification. Das tue ihm wirklich leid, gibt Simon zu.
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.)
Standards lernen voneinander
ODCS und OSI sind sich tatsächlich ziemlich ähnlich. Der Vergleich zeigt, wo jeder vorn liegt: OSI führt bei Metriken, dynamischen Feldern und KI-Kontext, während ODCS Terms of Use sowie Quality und SLAs abdeckt.
Die Lücken schließen sich über die Komitees. KI-Kontext kommt in ODCS 3.2, zusammen mit dynamischen Feldern und Metriken wie dem full_name-Beispiel. Die Standards wachsen zusammen und lernen voneinander, und das ist schön zu beobachten.
Ontologien und die Umbenennung in Apache Ossie
OSI hat viele Working Groups, und eine besonders aktive zu Ontologien, die Simon sehr gefällt. Das alles ist noch sehr früh (Version 0.2.0.dev), aber Snowflake steht mit Nachdruck dahinter. Du kannst eine Ontologie aus Konzepten und Beziehungen modellieren, mit Internationalisierung, und eine Contract-Spalte mit einem Konzept verknüpfen.
Ein Augenzwinkern an die Informatik-Fraktion: Seine Initiative "OSI" zu nennen, wenn es schon ein berühmtes Netzwerkmodell dieses Namens gibt, ist mutig. Sie scheinen das ähnlich zu sehen, denn erst gestern haben sie die Initiative an die Apache Foundation übergeben und in Apache Ossie umbenannt. Viele Anbieter stehen dahinter, Entropy Data eingeschlossen, das Format kommt also.
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, und das ist ziemlich schön.