Software Architektur: Data Mesh
10. September 2026
Was das ist, wofür du es brauchst — und was am 12. September in Kraft getreten sein wird.
Ticket
Jemand braucht eine Zahl. Umsatz je Vertriebsregion, letzte zwölf Monate. Ticket ans zentrale Datenteam.
Sechs Wochen später kommt eine Tabelle. Die Zahl ist falsch. „Region” bedeutet im Vertrieb etwas anderes als im Controlling, und im zentralen Datenteam wusste das keiner — dort sitzt niemand, der jemals eine Vertriebsregion zugeschnitten hat.
Neues Ticket.
Das ist der Normalfall in großen Häusern. Und es ist kein Kapazitätsproblem. Du kannst dem zentralen Team fünf Leute dazustellen. Dann wird das Ticket schneller falsch beantwortet.
Der Engpass war nie der Speicher. Der Engpass ist die Zuständigkeit.
Idee
2019 schreibt Zhamak Dehghani bei Thoughtworks auf, warum das passiert. Der zentrale Data Lake ist ein Monolith, und wie jeder Monolith skaliert er an genau einer Stelle nicht: bei der Zahl der Menschen, die gleichzeitig etwas daran ändern wollen.
Die Fachdomäne kennt die Bedeutung der Daten. Das zentrale Team kennt die Pipelines. Dazwischen liegt ein Übersetzungsvorgang, den keiner bezahlt und keiner verantwortet. Genau dort verschwindet der Kontext.
Data Mesh dreht die Richtung um. Die Daten bleiben, wo sie entstehen. Wer sie erzeugt, veröffentlicht sie — als Produkt, mit Zusage, mit Namen dran.
Wer Microservices gemacht hat, kennt den Schnitt. Bounded Context, eigenes Deployment, klare Schnittstelle, ein Team haftet. Data Mesh ist derselbe Schnitt, eine Etage tiefer.
Vier
Vier Prinzipien tragen das Ganze. Seit 2019 unverändert. Keines davon ist Technik.
Domain Ownership. Die Fachdomäne verantwortet ihre Daten. Vertrieb besitzt Vertriebsdaten. Nicht den Betrieb der Datenbank — die Bedeutung, die Qualität, die Zusage.
Data as a Product. Ein Datensatz wird behandelt wie eine API: auffindbar, adressierbar, dokumentiert, versioniert, mit Owner und Support. Der Konsument ist Kunde und darf unzufrieden sein.
Self-Serve Data Platform. Ohne gemeinsame Plattform baut jede Domäne ihr eigenes ETL, ihren eigenen Katalog, ihr eigenes Rechtekonzept. Acht Domänen, achtmal dasselbe Problem, achtmal anders gelöst.
Federated Computational Governance. Regeln werden gemeinsam vereinbart, als Code geschrieben und von der Plattform automatisch durchgesetzt. Kein Gremium, das freitags Freigaben erteilt.
Vertrag
Das Herzstück ist der Data Contract. Eine YAML-Datei, versioniert, im Repository neben dem Code. Drin steht: Schema, Semantik je Feld, Qualitätsregeln, Service Level, Eigentümer, Nutzungsbedingungen.
Dafür gibt es einen offenen Standard. ODCS, gepflegt vom Bitol-Projekt unter der Linux Foundation, hervorgegangen aus einer internen Vorlage von PayPal, aktuell in Version 3.2.0. Daneben ODPS für das Datenprodukt selbst — Input-Ports, Output-Ports, jeder Port an einen Contract gebunden.
Wenn alle Domänen das schreiben, fällt der Abhängigkeitsgraph des Unternehmens als Nebenprodukt aus YAML heraus. Ohne Workshop.
Ein Datenprodukt ohne Contract ist ein Ordner voller Parquet-Dateien und guter Absichten.
Agenten
Data Mesh ist sieben Jahre alt. Die Frage, warum plötzlich wieder alle davon reden, ist berechtigt. Es sind zwei Dinge, und beide sind neu.
Das erste sind die Agenten.
Ein Mensch, der auf eine schlecht dokumentierte Spalte stößt, fragt nach. Er kennt jemanden, oder er kennt jemanden, der jemanden kennt. Ein Agent hat keinen Flurfunk. Er nimmt die Spalte und rechnet.
Damit wird Semantik zur Laufzeitanforderung. Thoughtworks nennt das im Feldbericht vom Januar 2026 Dual-use Data Products: Datenprodukte mit Output-Ports für Menschen und für Agenten — SQL, API, und MCP. Der ODCS-Standard trägt inzwischen einen context-Block mit instructions, verifiedStatements und constraints. Felder, die es ohne Agenten nicht gäbe.
Der Business Case für Data Mesh war jahrelang Analytics. Er heißt jetzt: verlässliche KI in Produktion.
Frist
Das zweite ist Regulierung, und die hat ein Datum.
Der EU Data Act, Verordnung (EU) 2023/2854, ist seit dem 12. September 2025 anwendbar. In Deutschland ist am 30. Mai 2026 das Durchführungsgesetz in Kraft getreten, das DADG. Zuständig ist die Bundesnetzagentur, mit Beschwerdeverfahren und Bußgeldrahmen.
Und dann steht da Artikel 3 Absatz 1: Vernetzte Produkte, die nach dem 12. September 2026 in Verkehr gebracht werden, müssen so gestaltet sein, dass die erzeugten Daten für den Nutzer standardmäßig, einfach und sicher zugänglich sind.
Das ist übermorgen.
„Zugriff by Design” ist die juristische Formulierung. Technisch steht dort: ein abgegrenzter Datenbestand, dokumentiertes Schema, definierter Zugriffsweg, benannter Verantwortlicher, Regeln für die Weitergabe an Dritte.
Das ist ein Datenprodukt mit Contract. Ob du es so nennst, ist der Bundesnetzagentur egal.
Haken
Gartner hat Data Mesh 2022 im Hype Cycle im Innovation Trigger geführt, mit der Prognose, es könne veralten, bevor es Reife erreicht. Marktdurchdringung damals: ein bis fünf Prozent. Eine zweite Zahl wird seither herumgereicht — achtzehn Prozent der Organisationen haben die Governance-Reife, die Data Mesh voraussetzt.
Thoughtworks, sieben Jahre Feldarbeit, formuliert es ohne Umweg: Data Mesh ist eine organisatorische Transformation. Die größten Hindernisse sind Verhaltensweisen, keine Architekturen.
Das häufigste Anti-Pattern ist ein Namensschild. Die IT benennt ihre bestehenden Teams um: aus dem SAP-Team wird die „SAP-Domäne”, aus dem Salesforce-Team die „Salesforce-Domäne”. Kein Mandat, keine fachliche Verantwortung, keine Entscheidungsbefugnis. Kann man machen. Ist halt Zuständigkeitskosmetik.
Die andere Art zu scheitern ist Dezentralisierung ohne Plattform. Das zentrale Team wird aufgelöst, es kommt nichts nach, und nach zwölf Monaten hat jede Domäne ihr eigenes Werkzeug. Zwei Datenprodukte zu joinen ist dann ein Projekt. Verwandt damit: „föderiert” wird als „freiwillig” gelesen. Standards ohne Durchsetzung sind Empfehlungen, und Empfehlungen verlieren gegen Termindruck. Immer.
Das Ende ist jedes Mal dasselbe. Nach achtzehn Monaten wird re-zentralisiert, und der Begriff ist im Haus verbrannt.
Anfangen
Wenn du es trotzdem willst — und es gibt gute Gründe dafür:
Such nicht die perfekten Domänengrenzen. Ein Jahr Analysis Paralysis ist kein Fundament, sondern ein Jahr. Grenzen verschieben sich, weil das Geschäft sich verschiebt.
Nimm ein Datenprodukt. Das, an dem gerade etwas weh tut — das mit dem sechs Wochen alten Ticket. Schreib den Contract dazu, versioniert, im Repo, neben dem Code.
Bau die Plattform erst, wenn das dritte Team dasselbe braucht. Vorher ist es Spekulation mit Budget.
Und codifiziere die erste Regel, egal wie klein sie ist. Eine durchgesetzte Regel schlägt einen Katalog aus dreißig empfohlenen.
Das zentrale Datenteam wird dabei nicht abgeschafft. Es hört auf, Torwächter zu sein, und fängt an, zu befähigen: Templates, Onboarding, Plattform. Es besitzt nicht mehr die Daten. Es besitzt die Praxis.
Rest
Data Mesh ist teuer und politisch. Es dauert Jahre, es braucht Rückendeckung von ganz oben, und es macht sichtbar, wer im Haus eigentlich nichts entscheiden darf.
Die Alternative ist ein Ticket, das seit sechs Wochen offen ist. Und ein Agent, der die falsche Spalte summiert, ohne zu fragen.
Quellen
- Thoughtworks: The state of data mesh in 2026 — From hype to hard-won maturity, 16. Januar 2026
- Bitol / Linux Foundation AI & Data: Open Data Contract Standard und Open Data Product Standard
- Bundesnetzagentur: Data Act — Zuständigkeit nach DADG seit 30. Mai 2026
- Taylor Wessing: Fristen und Pflichten des EU Data Act, u. a. Art. 3 Abs. 1
- Atlan: Zusammenfassung der Gartner-Einordnung zu Data Mesh