Data Mesh
Einleitung
Data Mesh ist ein Organisations- und Architekturansatz für Datenplattformen.
Er entstand aus einem wiederkehrenden Problem:
Zentrale Data-Teams und Data Lakes skalieren technisch –
aber nicht organisatorisch.
Data Mesh verschiebt die Verantwortung für Daten:
Weg von einem zentralen Data-Team
hin zu domänenorientierten Datenprodukten.
Es ist kein Tool-Pattern, sondern ein sozio-technisches Modell.
Einordnung
Data Mesh ist:
- kein Datenbank-Pattern
- kein reines Architekturdiagramm
- kein Ersatz für Data Governance
Es ist ein Betriebs- und Verantwortungsmodell für Datenlandschaften.
Es kombiniert:
- Domänenorientierung (DDD-Denke)
- Plattform-Engineering
- Produktdenken
- Governance
Ursprung
Der Begriff wurde von Zhamak Dehghani geprägt.
Data Mesh entstand als Reaktion auf:
- Monolithische Data Lakes
- Zentrale ETL-Teams
- Lange Wartezeiten für Datenänderungen
- Fehlende Ownership für Datenqualität
Zielsetzung
Data Mesh adressiert:
- Skalierung von Datenverantwortung
- Reduktion zentraler Bottlenecks
- Verbesserung von Datenqualität
- Verkürzung von Lead Time für Datenprodukte
Der zentrale Gedanke:
Daten sind Produkte – nicht Nebenprodukte.
Die vier Kernprinzipien
1️⃣ Domänenorientierung
Daten gehören der Domäne,
nicht einem zentralen Plattform-Team.
Jede Domäne:
- erzeugt
- pflegt
- dokumentiert
- betreibt
ihre eigenen Datenprodukte.
2️⃣ Daten als Produkt
Ein Datenprodukt hat:
- klar definierte Schnittstellen
- dokumentierte Semantik
- SLOs
- Versionierung
- Monitoring
Datenprodukte sind konsumierbar wie APIs.
3️⃣ Self-Serve-Datenplattform
Ein zentrales Plattform-Team stellt bereit:
- Infrastruktur
- Templates
- CI/CD
- Monitoring
- Security-Standards
Aber nicht:
- fachliche Ownership
4️⃣ Federated Governance
Governance ist:
- global definiert
- lokal umgesetzt
Beispiele:
- Naming-Standards
- Zugriffskontrolle
- Datenschutz
- Interoperabilität
Prinzipdarstellung
Kernaussage:
- Plattform liefert Infrastruktur
- Domänen liefern Datenprodukte
- Ownership ist dezentral
Vorteile
- Skalierung in großen Organisationen
- Reduzierung zentraler Engpässe
- Höhere Datenqualität durch Ownership
- Schnellere Weiterentwicklung
Typische Missverständnisse
- „Jede Domäne baut ihre eigene Plattform“
- „Keine Governance mehr“
- „Data Mesh ersetzt Data Engineering“
- „Data Mesh = viele Data Lakes“
Data Mesh ohne Plattform und Governance zerfällt.
Risiken / Fallstricke
- Hoher kultureller Reifegrad erforderlich
- Gefahr inkonsistenter Datenprodukte
- Hoher Initialaufwand für Plattform
- Widerstand gegen Ownership-Verlagerung
Data Mesh scheitert häufiger organisatorisch als technisch.
Eignung 2026
Geeignet bei:
- Großen Organisationen mit vielen Domänen
- Hohem Datenvolumen
- Zentralem Data-Team als Bottleneck
- Reifer Plattform-Infrastruktur
Weniger geeignet bei:
- Kleinen Teams
- Geringer Datenkomplexität
- Fehlender Plattform-Engineering-Kultur
- Geringem Governance-Reifegrad
Praxis-Check
Szenario 1: Großkonzern
Mehrere Business-Domänen liefern eigenständige Datenprodukte mit klarer Dokumentation und SLOs. Plattform-Team stellt Self-Service-Infrastruktur bereit.
Data Mesh kann hier skalieren.
Szenario 2: Mittelständische Firma
Ein zentrales Data-Team kann effizienter arbeiten als ein organisatorisch aufwendiges Mesh-Modell.
Data Mesh wäre hier Overhead.
Fazit
Data Mesh ist kein Technologie-Upgrade.
Es ist ein Organisationsmodell für skalierende Datenlandschaften.
Es funktioniert nur, wenn:
- Plattform-Reife vorhanden ist
- Governance klar definiert ist
- Domänenteams Ownership übernehmen
Ohne diese Voraussetzungen entsteht kein Mesh – sondern verteilte Daten-Inkonsistenz.