Dieser Leitfaden ist für dich, wenn du in einem größeren Mittelständler oder Konzern arbeitest, in dem das zentrale Data-Team zum Bottleneck geworden ist — und wo in Meetings schon das Wort „Data Mesh" gefallen ist, aber keiner so richtig sagen kann, was darunter operativ zu verstehen wäre. Ich komprimiere, was ich aus der Data-Mesh-Implementierung bei Siemens Energy (Folge #316 mit Jonas Kell) und aus rund 30 weiteren Gesprächen mit Data-Mesh-Praktikern gelernt habe.
Was Data Mesh ist
Data Mesh ist ein 2019 von Zhamak Dehghani geprägtes Organisationsmodell für Daten-Arbeit in großen Unternehmen. Statt alle Daten in ein zentrales Data Warehouse oder einen Data Lake zu kippen und ein zentrales Data-Team über alles wachen zu lassen, verteilt Data Mesh die Verantwortung auf die Fachdomänen — und baut darunter eine Self-Serve-Infrastruktur plus eine federierte Governance.
Die vier Prinzipien sind:
- Domain Ownership — Jede Fachdomäne (Sales, Marketing, Logistik, Produkt) ist für ihre eigenen Daten verantwortlich.
- Data as a Product — Daten werden mit Produkt-Disziplin behandelt: mit Owner, SLA, Dokumentation, Feedback-Loops.
- Self-Serve Data Platform — Eine zentrale Plattform stellt Werkzeuge bereit, die es Domains ermöglichen, ihre Daten ohne Platform-Team-Ticket zu veröffentlichen und zu nutzen.
- Federated Computational Governance — Regeln werden zentral beschlossen, aber dezentral umgesetzt. Ein globales Gremium legt Standards fest, Domains implementieren.
Was Data Mesh nicht ist
Die häufigsten Missverständnisse.
- Data Mesh ist kein Ersatz für Data Warehouse oder Data Lake. Es ist ein Governance-Modell, das auf Daten-Infrastruktur aufsetzt — oft auf einem zentralen Data Lake.
- Data Mesh ist keine Tool-Kategorie. Es gibt keine „Data-Mesh-Plattform" im engeren Sinn. Was verkauft wird (Data Catalog, Data Product Registries, Data Contract Tools), sind Bausteine.
- Data Mesh ist nicht gleich Dezentralisierung. Es ist „Federated" — zentrale Regeln, dezentrale Umsetzung. Wer nur dezentralisiert, baut Chaos, nicht Mesh.
- Data Mesh ist keine Mittelstand-Standardantwort. In Organisationen unter 500 Mitarbeitern ist ein gut geführtes zentrales Data-Team meist effizienter.
Den tiefen Vergleich mache ich im Cluster Data Mesh vs. Data Warehouse.
Wann Data Mesh Sinn ergibt
Drei Bedingungen, die ich in der Praxis als Schwellwerte erlebe.
Bedingung 1 — Mehr als 5 unabhängige Daten-Domains. Wenn dein Unternehmen fünf oder mehr Fachbereiche hat, die jeweils eigene Daten-Produzenten und -Konsumenten sind (Sales, Service, Marketing, Produkt, Finance, HR), skaliert das zentrale Modell nicht mehr. Darunter ist die Abstimmung mit einem zentralen Team machbar.
Bedingung 2 — Zentrales Data-Team ist Bottleneck. Wenn Daten-Anfragen aus Fachbereichen Wochen dauern, Priorisierungskonflikte in Steuergruppen landen und das Data-Team schneller wächst als die Organisation, ist das ein Mesh-Signal. Nicht immer — manchmal braucht das zentrale Team einfach mehr Köpfe oder bessere Prozesse.
Bedingung 3 — Reifegrade-Voraussetzung. Data Mesh funktioniert erst ab Reifegrad 3 im klassischen Data-Maturity-Modell. Wer auf Stufe 2 ist und Mesh einführt, baut dezentrales Chaos. Erst wer definierte Prozesse und Governance hat, kann die Dezentralisierung stemmen.
Die Cluster in diesem Pillar
- Einführung — konzeptioneller Überblick mit mehr Detail als dieser Pillar erlaubt.
- Data Products — das zentrale Artefakt in einem Mesh. Owner, SLA, Schema, Discoverability.
- Data Contracts — die formale Vereinbarung zwischen Daten-Produzent und -Konsument.
- Data Citizens — das soziale Gegenstück zur technischen Architektur.
- Data Mesh vs. Data Warehouse — die Abgrenzung in Klartext.
- Organisationsmodell — wie du das Team-Setup strukturierst und welche Rollen neu entstehen.
Rolle der Plattform
In einem Data Mesh bleibt ein zentrales Platform-Team bestehen — nur mit anderer Aufgabe. Statt Daten für Fachbereiche zu produzieren, baut und betreibt es die Self-Serve-Infrastruktur, auf der Fachbereiche ihre eigenen Daten-Produkte bauen. Das heißt: Kein Ingest-Team, das für Domain X den Ingest baut, sondern Domain X baut den Ingest selbst — mit Werkzeugen vom Platform-Team.
Die Kompetenzverteilung verschiebt sich damit deutlich. Fachbereiche brauchen Data-Engineering-Kompetenz (zumindest anteilig), das Platform-Team wird kleiner und technisch tiefer. Für die meisten mittelgroßen Unternehmen ist genau das die Stelle, an der Data Mesh scheitert — die Kompetenz in den Domains fehlt, der Aufbau dauert länger als erwartet.
Data Products im Detail
Data Products sind das zentrale Artefakt. Jedes Produkt ist durch folgendes definiert:
- Owner — eine benannte Person (oder Team) mit Verantwortung für Existenz, Qualität und Roadmap
- SLA — Latenz, Verfügbarkeit, Freshness dokumentiert und einhaltbar
- Schema und Semantik — mit Versions-Management und Breaking-Change-Policy
- Discoverability — im Data Catalog auffindbar, mit Dokumentation und Beispielen
- Feedback-Loop — Konsumenten können Issues melden, Owner reagiert in definierten Zeiträumen
Das klingt nach Produkt-Management für Daten — und das ist es. Wer diese Disziplin nicht aufbaut, hat keine Data Products, sondern Daten-Tabellen mit Selbstbedienung.
Data Contracts
Data Contracts formalisieren die Beziehung zwischen Data-Produkt-Ownern und -Konsumenten. Ein Contract enthält mindestens:
- Schema mit Typ-Definitionen
- SLA (Frequenz, Latenz, Verfügbarkeit)
- Qualitäts-Checks mit Schwellwerten
- Change-Management-Prozess (wie werden Breaking Changes angekündigt)
- Support-Kanäle und Response-Zeiten
Contracts sind erst dann sinnvoll, wenn mehr als zwei Teams auf dieselben Daten zugreifen. Darunter reicht bilateral Absprache. Über zwei Teams hinweg skaliert Absprache nicht, dann braucht es Formalisierung.
Häufige Fehler in Data-Mesh-Projekten
Fehler 1 — Zu früh dezentralisieren. Ohne etablierte Governance wird Mesh zu Chaos. Reifegrad 3 ist Voraussetzung, nicht Ziel.
Fehler 2 — Platform ohne Produkt-Disziplin. Das zentrale Platform-Team baut Werkzeuge, die niemand nutzt, weil niemand sie kennt oder zu komplex sind. Self-Serve heißt: Ein Domain-Engineer muss in 2 Tagen produktiv sein.
Fehler 3 — Fehlende Kompetenz in den Domains. Wenn Marketing keine Data-Engineers hat, kann Marketing keine Daten-Produkte bauen. Die Frage „Wer baut die Data Products in Domain X?" muss vor jeder Mesh-Initiative beantwortet sein.
Fehler 4 — Mesh als Reorganisations-Vehikel. Manche CDOs nutzen Data Mesh, um interne Machtverschiebungen zu legitimieren. Das funktioniert eine Weile — bis die Realität die Reorganisations-Folien überholt.
Häufig gestellte Fragen
Ist Data Mesh eine Technologie oder ein Organisationsmodell?
Organisationsmodell, mit technologischen Implikationen. Die vier Prinzipien (Domain Ownership, Data as Product, Self-Serve Platform, Federated Governance) sind alle organisatorischer Natur. Die Tools setzen das um, sie definieren es nicht.
Lohnt Data Mesh sich im Mittelstand?
Selten in Reinform. Die vier Prinzipien lohnen sich ab einer Organisationsgröße, in der zentrale Data-Teams zum Bottleneck werden — typisch ab 500–1.000 Mitarbeitern. Darunter lohnt oft eine „Data-Mesh-light"-Herangehensweise: Domain-Ownership ohne komplette Dezentralisierung.
Wie unterscheidet sich Data Mesh von einem Data Lake?
Der Data Lake ist eine Speicher-Architektur (roh, zentral, schemalos). Data Mesh ist ein Governance- und Ownership-Modell. Viele Data-Mesh-Implementierungen nutzen Data Lakes als Substrat — sie ordnen es anders an, ersetzen es nicht.
Was sind Data Contracts und wann braucht man sie?
Data Contracts sind formale Vereinbarungen zwischen Daten-Produzent und -Konsument über Schema, Latenz, Qualität und Support. Sie werden relevant, wenn mehr als zwei Teams auf dieselben Daten angewiesen sind — davor reicht Absprache.
Wer ist in einem Data Mesh für Governance verantwortlich?
Federated — ein globales Governance-Gremium setzt die Regeln, die Domains setzen sie um. Das ist der Unterschied zu klassischer zentraler Governance (Regel und Umsetzung an einer Stelle) und zu totaler Dezentralisierung (jede Domain macht ihr eigenes Ding).
Was ist der typische Zeitrahmen für eine Data-Mesh-Transformation?
Drei bis fünf Jahre bei einem mittelgroßen Konzern. Wenn dir jemand 12 Monate verspricht, verkauft er dir eine Organisations-Neusortierung mit Mesh-Label, keine echte Transformation.
Der richtige Einstieg ist meist der Einführungs-Cluster für die Prinzipien-Vertiefung, dann Data Products für das operative Kern-Artefakt. Wer zweifelt, ob Mesh das Richtige ist, sollte zuerst Data Mesh vs. Data Warehouse lesen.