Data Mesh: Definition, vier Prinzipien und Abgrenzung

Data Mesh ist ein Organisations- und Architekturmodell für Auswertungs-Datenplattformen. Die Fachbereiche (Vertrieb, Logistik, Finance, HR) verantworten ihre analytischen Daten selbst; ein zentrales Datenteam bündelt diese Aufgabe nicht länger. Der Ansatz ruht auf vier Grundsätzen: Domain Ownership (Verantwortung im Fachbereich), Data-as-a-Product (Daten wie ein Produkt behandeln), Self-Service-Plattform (gemeinsame technische Grundlage) und Federated Computational Governance (zentrale Regeln, dezentral umgesetzt).

Was ist Data Mesh?

Data Mesh ist ein Zielbild für die Datenauswertung in großen Organisationen. Statt einem zentralen Datenteam, das alle Auswertungen für Vertrieb, Logistik, Finance und weitere Bereiche baut, verantwortet jeder Fachbereich seine analytischen Daten selbst. Analytische Daten sind dabei die Daten, die für Auswertungen, Reports und KI-Modelle aufbereitet werden. Der Begriff wurde 2019 von Zhamak Dehghani (Beraterin bei ThoughtWorks) in dem Aufsatz [„Vom monolithischen Data Lake zum Data Mesh"](https://martinfowler.com/articles/data-monolith-to-mesh.html) auf martinfowler.com geprägt und 2020 mit den [„Data Mesh Principles"](https://martinfowler.com/articles/data-mesh-principles.html) als Prinzipien-Katalog formalisiert. Das 2022 im O'Reilly-Verlag erschienene Buch [„Data Mesh: Delivering Data-Driven Value at Scale"](https://www.oreilly.com/library/view/data-mesh/9781492092384/) fasst den Ansatz zu einem umfassenden Rahmenwerk zusammen.

Ausgangspunkt der Diskussion ist die Beobachtung, dass zentrale, monolithische Analytics-Plattformen mit wachsender Domänen-Vielfalt und Team-Zahl an strukturelle Grenzen stoßen: ein zentrales Datenteam wird zum Nadelöhr für alle Fachbereiche, die Kenntnis über die Datenherkunft und den fachlichen Kontext bleibt in den Quell-Systemen und Fachbereichen, und die Adaptions-Geschwindigkeit an fachliche Änderungen bleibt niedrig. Data Mesh reagiert darauf mit einer organisatorischen Verschiebung: die Fachdomäne, die die Daten kennt, verantwortet auch ihre analytische Bereitstellung.

Der Ansatz ruht auf vier Prinzipien. Domain Ownership verlagert die Verantwortung für analytische Datenprodukte in die Fachdomänen (Vertrieb, Logistik, Finance, Produkt). Data-as-a-Product versteht analytische Daten wie ein Produkt mit Owner, Schema, Service-Level-Objectives, Dokumentation, Auffindbarkeit, Interoperabilität und Adressierbarkeit. Eine Self-Service-Datenplattform stellt eine domänen-agnostische Grundinfrastruktur bereit (Speicher, Compute, Katalog, Observability, Policy-Durchsetzung), auf der die Domänen ihre Produkte eigenständig bauen und betreiben. Federated Computational Governance definiert gemeinsame Regeln (Sicherheit, Interoperabilität, Metadaten-Pflichten, Klassifizierung) zentral und setzt sie automatisiert in der Plattform durch, während die konkrete Umsetzung dezentral erfolgt.

Data Mesh ist kein Produkt und keine Referenz-Architektur. Der Ansatz beschreibt ein Zielbild, das sich mit verschiedenen technologischen Bausteinen umsetzen lässt: Objekt-Speicher mit offenen Tabellenformaten (Delta Lake, Apache Iceberg, Apache Hudi), katalog-native Governance-Schichten (Unity Catalog, Microsoft Purview, SAP Datasphere), Zero-Copy-Datenteilung (Delta Sharing, Snowflake Secure Data Sharing) sowie Data-Contract-Werkzeuge für die Schnittstellen zwischen Datenprodukten.

Abgrenzung zu Data Fabric, Data Lakehouse und Data Warehouse

Data Mesh wird häufig mit benachbarten Konzepten aus der Datenarchitektur-Diskussion verwechselt. Die folgende Tabelle sortiert die Begriffe entlang ihrer primären Achse.

Begriff	Achse	Kernunterschied
Data Fabric	Metadaten-Layer	Metadaten-zentriertes Architekturmuster (Gartner, ab 2019) mit aktiven Metadaten, Knowledge Graph und KI-gestützter Integration. Fabric ist technologie-first: ein Metadaten-Layer verbindet vorhandene Systeme. Mesh ist organisations-first: Domänen bauen Datenprodukte. Beide Muster können koexistieren.
Data Lakehouse	Speicher-Muster	Technisches Muster aus Objekt-Speicher, offenem Tabellenformat und Katalog. Das Lakehouse liefert die Plattform-Grundlage, auf der ein Mesh betrieben werden kann. Über Ownership und Organisation trifft das Lakehouse keine Aussage.
Data Warehouse	Zentralisierungs-Grad	Zentrales relationales Analyse-Datenbank-Muster (Inmon, Kimball) mit vorgegebenem Schema. Warehouse ist zentral, Mesh dezentral. Ein Warehouse kann als Datenprodukt innerhalb eines Mesh auftreten.
Data Lake	Zentralisierungs-Grad	Rohdatenspeicher, oft monolithisch und zentral betrieben. Dehghanis Ausgangs-Kritik richtet sich gegen den zentralen Data Lake als Skalierungs-Engpass des Analytics-Betriebs.
Data Product	Manifestation	Konkrete Ausprägung des Prinzips Data-as-a-Product: eine Tabelle, ein Feature-Set oder eine API mit benanntem Owner, versioniertem Schema und SLO. Data-as-a-Product ist das Prinzip, Data Product das Objekt.

Zwei Trennlinien sind für die Einordnung entscheidend. Erstens die Abgrenzung zu Data Fabric: beide Ansätze reagieren auf die Skalierungs-Grenzen zentraler Plattformen, aber mit unterschiedlicher Stoßrichtung. Fabric setzt auf einen intelligenten Metadaten-Layer, der bestehende Systeme verbindet und über aktive Metadaten und Automatisierung Integrations-Aufwand reduziert. Mesh setzt auf eine organisatorische Neuverteilung von Verantwortung. In größeren Organisationen ergänzen sich beide Ansätze: der Fabric-Layer als Metadaten-Fundament, das Mesh als Betriebs-Modell darauf.

Zweitens die Abgrenzung zu Lakehouse und Warehouse: Data Mesh macht keine technischen Vorgaben zur Speicher-Schicht. Die Prinzipien lassen sich auf einem Lakehouse, einem Cloud-Warehouse, einem klassischen Warehouse oder einer heterogenen Landschaft umsetzen. Umgekehrt zwingt der Wechsel zu einem Lakehouse noch nicht zu einem Mesh. Wer ein Mesh einführt, entscheidet über Organisation und Verantwortung; wer ein Lakehouse einführt, entscheidet über Speicherformat und Compute-Architektur. Diese beiden Entscheidungen laufen parallel.

Beispiel: Data Mesh in einem Handelskonzern mit sieben Domänen

Ein DACH-Handelskonzern betreibt eine zentrale Analytics-Plattform aus Enterprise-Data-Warehouse und Data Lake für sieben eigenständige Geschäftsbereiche (Retail, Großhandel, Logistik, Finance, HR, Marketing, Digitalgeschäft). Im Steering wiederholen sich seit Monaten die gleichen Diagnosen: Wartezeiten von acht bis zwölf Wochen für neue Datenprodukte im zentralen Team, Schatten-Analysen in Excel und eigenen Snowflake-Instanzen der Fachbereiche, drei konkurrierende Definitionen des Konzern-Umsatzes.

Das Zielbild „Data Mesh" wird über eine mehrstufige Umsetzung angesteuert. Auf der Governance-Ebene wird [Unity Catalog](/insights/databricks/unity-catalog/) als katalog-native Kontrollschicht etabliert; jede Domäne erhält einen eigenen Catalog mit klar benanntem Data-Owner-Team, verpflichtenden Metadaten-Feldern (Klassifizierung, Retention, Owner, SLO) und Lineage-Erfassung ab Bronze-Layer. Auf der Interoperabilitäts-Ebene definiert ein Governance-Board Data Contracts als verbindliche Schnittstellen zwischen Domänen: Schema-Versionierung, Deprecation-Fenster, Test-Suiten, Break-Change-Freigaben. Auf der Plattform-Ebene liefert das zentrale Plattform-Team Terraform-Module, CI/CD-Templates und Policy-as-Code, damit Domänen neue Datenprodukte in Tagen statt Wochen produktionsreif ausrollen. Cross-Domain-Konsum läuft über Delta Sharing ohne physische Datenkopien.

Der Reifegrad wird an konkreten Kennzahlen gemessen: Anzahl der als Data Product ausgewiesenen Datenobjekte pro Domäne, Time-to-Data neuer Konsumenten (Antragstellung bis produktiver Zugriff), Cross-Domain-Konsum (Anteil externer Konsumenten je Datenprodukt), Governance-Automatisierungs-Grad (Anteil maschinell durchgesetzter Policies). Das Beispiel zeigt die typische Umsetzungs-Charakteristik: Data Mesh ist ein Organisations-Programm mit technischer Rückendeckung, kein Plattform-Rollout mit organisatorischer Rückendeckung.