Was ist Data Mesh?

Data Mesh ist eine dezentrale Datenarchitektur und ein Organisationsmodell, in dem Domänenteams ihre eigenen Data Products besitzen, bauen und bereitstellen, während ein zentrales Plattformteam die Self-Service-Infrastruktur liefert und ein Modell föderierter Governance die gemeinsamen Standards festlegt. Zhamak Dehghani hat den Ansatz 2019 vorgestellt und 2022 in ihrem Buch Data Mesh: Delivering Data-Driven Value at Scale vollständig ausgearbeitet.

Der Kerngedanke: Was große Datenarchitekturen ausbremst, sind organisatorische und keine technischen Probleme. Langsame Lieferung, Qualitätsmängel, gegenläufige Anreize, ein überlastetes zentrales Datenteam. Mehr Rechenleistung oder noch eine Plattform heilt kein Modell, in dem ein einziges Team Daten aus Hunderten Domänen verstehen und ausliefern soll, in denen es selbst nicht arbeitet. Data Mesh verteilt diese Verantwortung an die Menschen, die die Daten kennen: an die Teams, die sie erzeugen und nutzen.

Data Mesh, definiert

Data Mesh ruht auf einer einfachen, aber weitreichenden Annahme: Die Teams, die Daten erzeugen und Softwareprodukte darum herum bauen, können diese Daten am besten verstehen, pflegen und anderen bereitstellen. Statt alle Daten durch ein zentrales Plattformteam zu leiten, verteilt Data Mesh sowohl die Verantwortung als auch die Infrastruktur auf die Domänenteams.

Das heißt nicht, dass jede Domäne ihre eigene Dateninfrastruktur baut. Ein zentrales Plattformteam stellt das Gemeinsame bereit: die Datenebene (Speicher, Compute, Katalog, Governance) und die Erfahrungsebene (Self-Service-Werkzeuge, Vorlagen, APIs). Erst das macht es praktikabel, dass Domänenteams Data Products bauen und betreiben, ohne selbst zu Data Engineers zu werden. Den Domänen gehören die fachliche Logik und die Produkte, die Plattform liefert die Fähigkeiten, die das in großem Maßstab tragbar machen.

Die vier Prinzipien

Dehghanis Data Mesh ruht auf vier Prinzipien, die sich gegenseitig stützen. Alle vier sind nötig: Teilweise Umsetzungen, die Domain Ownership ohne Self-Service-Infrastruktur einführen oder umgekehrt, scheitern in aller Regel.

Prinzip 1: Domain Ownership

Statt eines zentralen Data-Engineering-Teams, dem alle Daten gehören, verantwortet jede Geschäftsdomäne ihre Daten von Anfang bis Ende: Erfassung, Transformation, Qualität, Bereitstellung. Die Teams, die Geschäftsereignisse erzeugen (Bestellungen, Lieferungen, Kundenkontakte), besitzen auch die Data Products, die daraus entstehen. Das bringt Verantwortung und Wissen zusammen: Domänenteams verstehen ihre Daten weit besser, als ein zentrales Team es je könnte.

Prinzip 2: Data as a Product

Domänenteams behandeln ihre Datenausgaben als Produkte für Konsumenten, nicht als interne Nebenprodukte. Ein Data Product hat eine klare Schnittstelle (Schema, API), ist in einem gemeinsamen Katalog auffindbar, trägt Qualitäts-SLAs, ist versioniert und getestet und hat einen benannten Owner, der für seine Verlässlichkeit geradesteht. Das Denkmodell „Produkt“ erzeugt genau die Ausrichtung auf den Konsumenten, die Daten über Domänengrenzen hinweg wirklich nutzbar macht.

Prinzip 3: Self-Service-Infrastruktur

Ein zentrales Plattformteam stellt die Technik bereit, die domänenorientierte Data Products praktikabel macht: Abstraktionen für Speicher und Compute, Orchestrierung von Pipelines, Katalog und Discovery, Zugriffskontrolle und Sicherheit, CI/CD für Data Products sowie Monitoring. Ohne diese Plattform müsste jedes Domänenteam die Infrastruktur neu erfinden, was die Dezentralisierung ad absurdum führt.

Prinzip 4: Föderierte computational Governance

Globale Standards (Schema-Kompatibilität, SLA-Anforderungen, Sicherheitsklassifizierung, Schwellenwerte für Datenqualität) werden zentral festgelegt und als Code umgesetzt, der in der automatisierten Pipeline jedes Data Products mitläuft. Domänenteams behalten lokale Autonomie für fachliche Entscheidungen, während die Governance-Vorgaben dafür sorgen, dass Data Products aus verschiedenen Domänen interoperabel und vertrauenswürdig bleiben. Das entscheidende Wort ist „computational“: Regeln, die sich nicht in großem Maßstab automatisieren lassen, bleiben unverbindliche Absichtserklärungen.

Data Mesh und das zentrale Data Warehouse

Die klassische zentrale Architektur, ein einziges Data Warehouse oder ein Data Lake, in das ein Plattformteam Daten aus allen Quellsystemen einspeist, funktioniert im kleinen Maßstab gut. Ihre Grenzen zeigen sich mit dem Wachstum:

• Das zentrale Team als Engpass: Jede Datenänderung läuft über ein Team, das keine einzelne Geschäftsdomäne wirklich durchdringt. Je größer das Portfolio, desto langsamer die Lieferung.
• Verlust von Kontext: Wandern Daten aus den Quellsystemen ins Warehouse, bleibt der fachliche Kontext zurück. Das zentrale Team kann Daten kopieren, aber nicht die Fachkenntnis, die zu ihrer korrekten Modellierung nötig wäre.
• Unklare Verantwortung für Qualität: Sinkt die Datenqualität im Warehouse, verweist das Quellteam auf das Warehouse-Team und dieses zurück auf die Quelle. Niemand verantwortet Qualität durchgängig.

Data Mesh setzt an allen drei Punkten an und gibt Lieferung, Kontext und Qualität an die Domänenteams zurück. Der Preis dafür ist erheblich: organisatorische Veränderung und höhere Anforderungen an die Engineering-Fähigkeiten der Domänen.

Föderierte Governance in der Praxis

Föderierte Governance ist das Prinzip, das Data Mesh von Datenchaos trennt. Ohne sie entstehen aus dezentralen Daten Data Products, die je für sich hochwertig, untereinander aber unvereinbar sind: andere Schemata, andere Definitionen, andere Qualitätssignale, die Konsumenten weder vergleichen noch verbinden können.

Föderierte Governance arbeitet mit einem kleinen Satz globaler Standards, die alle Domänenteams umsetzen müssen und die automatisch statt über Freigabeprozesse durchgesetzt werden:

• Interoperabilitätsstandards: verbindliche Schema-Konventionen, gemeinsame Identifikatoren für Objekte, die in mehreren Domänen vorkommen (Kunden-ID, Artikelnummer), und einheitliche Formate für Zeit, Währung und Geografie.
• Verträge über Datenqualität: Jedes Data Product macht Qualitätskennzahlen sichtbar, also Schwellen für Vollständigkeit, Aktualität und Genauigkeit, laufend überwacht. Die Governance-Schicht meldet, wenn ein SLA verletzt wird.
• Sicherheit und Datenschutz: Die Einstufung nach Schutzbedarf (personenbezogene Daten, vertraulich, öffentlich) erfolgt in allen Domänen nach denselben Regeln. Nachgelagerte Systeme können dieselben Zugriffsrichtlinien durchsetzen, gleich aus welcher Domäne die Daten stammen.

Ein Datenkatalog und ein Business Glossary (Fachglossar) sind die wichtigsten Werkzeuge, um föderierte Governance in den Betrieb zu bringen: Der Katalog liefert Discovery und Metadaten, das Business Glossary sorgt dafür, dass „Kunde“ im Produkt der Vertriebsdomäne dasselbe bedeutet wie im Produkt der Supportdomäne.

Was die Umsetzung wirklich verlangt

Data Mesh gilt als eine der ehrgeizigsten Transformationen im Unternehmensdatenbereich. Die technischen Bausteine sind gut verstanden: Katalog, Governance-Werkzeuge, Self-Service-Infrastruktur für Pipelines. Die organisatorische Veränderung ist das Schwierige.

Voraussetzungen für den Erfolg: Rückhalt in der Geschäftsführung, Domänenteams mit Engineering-Fähigkeiten (oder der Bereitschaft, sie aufzubauen), ein Plattformteam, das befähigen statt kontrollieren will, und die ernst gemeinte Absicht, Daten als Produkt zu behandeln und nicht als Infrastruktur. Organisationen, auf die das zutrifft, gewinnen spürbar an Liefergeschwindigkeit und Datenqualität. Alle anderen fahren zunächst besser mit dem bescheideneren Schritt zu einer Data Fabric.

Data Mesh und KI

Data Mesh schafft günstige Bedingungen für KI: Data Products in der Hand der Domänen, mit Qualitäts-SLAs, klarer Herkunft und geregeltem Zugriff, sind genau die Eingaben, die KI-Systeme verlässlich machen. Teams, die Modelle bauen, bekommen gut dokumentierte, belastbare Data Products von den Domänen-Ownern, statt sich Zugang zu einem zentralen Data Warehouse mit unklarer Lineage zu verschaffen.

Die Schwierigkeit: KI-Systeme, die Daten aus mehreren domäneneigenen Produkten verbinden müssen, brauchen genau die Interoperabilität, die föderierte Governance herstellt. Ein Modell, das Kundendaten aus drei Domänen zusammenführt, braucht einheitliche Kundenidentifikatoren, kompatible Schemata und vergleichbare Qualitätsstandards, sonst sind die Ergebnisse nicht schlüssig. Das macht föderierte Governance zur Grundlage jeder domänenübergreifenden KI.

Fazit

Data Mesh denkt neu, wie große Organisationen mit Daten umgehen sollten: verteilte Verantwortung, produktorientierte Lieferung, gemeinsame Infrastruktur und föderierte Governance. Es passt dort, wo zentrale Datenarchitekturen nachweislich an ihre Grenzen gestoßen sind, wo also das zentrale Team zum Engpass geworden ist, fachlicher Kontext verloren geht und die Verantwortung für Datenqualität wirklich ungeklärt ist. Für diese Organisationen führt Data Mesh zu besseren Daten im großen Maßstab. Für kleinere Häuser und für alle, die ihre Datengrundlagen erst aufbauen, bleibt eine gut geführte zentrale Architektur der praktischere Weg.