Data Mesh oder Data Fabric

Beide Architekturen lösen dasselbe Problem, nämlich den Zugang zu Daten im ganzen Unternehmen zu skalieren, aber von entgegengesetzten Seiten. Data Mesh verteilt die Verantwortung an Domänenteams und behandelt jeden Datenbestand als Produkt mit eigenem Team, eigenem SLA und eigenem Lebenszyklus. Data Fabric zentralisiert die Anbindung über eine Technikschicht, die Integration, Metadatenmanagement und Governance über alle Datenquellen der Organisation hinweg abstrahiert.

Welcher Weg richtig ist, hängt davon ab, wo der Engpass sitzt. Steckt das Fachwissen in einem zentralen Datenteam fest, das den Anfragen nicht hinterherkommt, verteilt Mesh die Arbeit neu. Besteht das Problem darin, dass Dutzende Systeme schlicht nicht miteinander sprechen, liefert Fabric die Verkabelung.

Was Data Mesh löst

Data Mesh, vorgestellt von Zhamak Dehghani, ruht auf vier Prinzipien. Jedes beantwortet eine typische Schwäche zentraler Datenplattformen.

Domain Ownership. Man denke an eine Bank, in der das Kreditteam die Daten aus der Kreditvergabe besser kennt als alle anderen: die Risikostufen, die Ausnahmen in der Bonitätsprüfung, die saisonalen Muster. Im zentralen Modell stellt dieses Team ein Ticket und bittet die Datenplattform um eine Pipeline. Das Plattformteam, das die Domäne nicht kennt, baut etwas, das richtig aussieht und die Sonderfälle verfehlt. Im Mesh besitzt das Kreditteam sein Data Product selbst, vom Schema bis zur Qualitätsüberwachung.

Data as a Product. Jede Domäne behandelt ihre Daten mit derselben Sorgfalt wie ein Produkt für Kunden: mit fester Schnittstelle, Dokumentation, einem SLA für Aktualität und Vollständigkeit und einem benannten Owner. Konsumenten finden diese Produkte über einen gemeinsamen Datenkatalog, statt Kollegen in Slack zu fragen.

Self-Service-Plattform. Domänenteams sollen nicht jedes für sich Speicher, Rechenleistung und Überwachung aufbauen. Ein zentrales Plattformteam stellt einheitliche Infrastruktur bereit, also Speicher, Pipelines und Observability, die die Domänen über Self-Service-APIs nutzen. Das Plattformteam baut die Straße, die Domänen fahren darauf.

Föderierte Governance. Globale Regeln, etwa Namenskonventionen, Zugriffsrechte und Qualitätsschwellen, werden zentral festgelegt und über die Plattform automatisch durchgesetzt. Die Domänen behalten ihre Autonomie in fachlichen Fragen, während im Unternehmen einheitliche Standards für alle Data Products gelten.

Was Data Fabric löst

Data Fabric geht von der Technik aus. Man denke an einen mittelgroßen Händler mit 15 SaaS-Werkzeugen, drei Cloud-Anbietern und einem ERP im eigenen Rechenzentrum. Das Marketing braucht Kundendaten aus Salesforce, Kaufhistorie aus dem ERP und Web-Analyse aus einem Cloud Data Warehouse, verbunden, dedupliziert und nahezu in Echtzeit verfügbar. Die Frage ist hier nicht, wem die Daten gehören, sondern dass die Systeme buchstäblich nicht miteinander sprechen können.

Data Fabric löst das mit fünf Bausteinen, die zusammenwirken. Die Integrationsschicht verbindet unterschiedliche Quellen über fertige Konnektoren, ETL- und ELT-Pipelines und API-Adapter. Das Metadatenmanagement katalogisiert jedes Objekt, verfolgt Lineage und klassifiziert Daten automatisch mit Machine Learning. Die Datenvirtualisierung lässt Konsumenten verteilte Daten abfragen, ohne sie zu bewegen: Eine einzige SQL-Abfrage kann eine Postgres-Tabelle mit einem Salesforce-Objekt verbinden. Die Orchestrierung plant Pipelines, löst Abhängigkeiten auf und fängt Fehler ab. Und die zentrale Governance setzt Zugriffsregeln, Maskierung und Aufbewahrungsfristen über alle angebundenen Quellen hinweg einheitlich durch.

Wie sich die Architekturen unterscheiden

Die Unterschiede zwischen Mesh und Fabric sind nicht nur technischer Art. Sie bestimmen, wer entscheidet, wie schnell Teams vorankommen und welche Abstriche eine Organisation in Kauf nimmt.

Die Tabelle zeigt die strukturellen Unterschiede, der wichtigste ist jedoch grundsätzlicher Natur. Mesh sagt: Wer den Daten am nächsten steht, soll sie verantworten. Fabric sagt: Die Technik soll die Frage der Verantwortung unsichtbar machen. Keine der beiden Aussagen ist falsch, sie beantworten verschiedene Fragen.

Wann welcher Weg passt

Data Mesh passt, wenn eine Organisation klar getrennte Geschäftsdomänen mit tiefem Fachwissen hat, eine produktorientierte Engineering-Kultur pflegt und mehr als einige hundert Menschen mit Daten arbeiten. Das zentrale Datenteam ist zum Engpass geworden, jeder neue Bericht, jede Pipeline, jedes Modell läuft durch denselben Rückstau. Mesh gibt die Arbeit an die Teams zurück, die die Daten ohnehin kennen.

Data Fabric passt, wenn der Schmerz vor allem aus der Integration kommt, also aus vielen ungleichen Systemen, aus Multi-Cloud oder hybriden Umgebungen und aus dem Bedarf nach schnellem, einheitlichem Zugriff. Die Organisation arbeitet zentral geführt und muss Quellen verbinden, bevor die Frage der Verantwortung überhaupt ansteht. Fabric liefert schneller Nutzen, weil sie eine Technikeinführung ist und kein Umbau der Organisation.

Beides passt, wenn keiner der reinen Wege trägt. Eine europäische Bank hat Fabric genutzt, um regulatorische Datenquellen aus drei Ländern zu verbinden, weil in der Compliance Tempo und Einheitlichkeit schwerer wogen als die Autonomie der Domänen. Gleichzeitig hat dieselbe Bank für die Produktanalyse Mesh-Prinzipien eingeführt und jeder Produktlinie die Verantwortung für ihre Data Products gegeben. Beides bestand nebeneinander, verbunden über einen gemeinsamen Datenkatalog.

Die hybride Wirklichkeit

In der Praxis landen die meisten großen Unternehmen bei einer Mischform. Reines Mesh verlangt eine organisatorische Reife, die Jahre braucht. Reines Fabric riskiert, den Engpass des zentralen Teams von der Organisation in die Technik zu verlegen. Der pragmatische Weg verbindet Elemente aus beidem.

Von Fabric zu Mesh. Mit Fabric beginnen und schnelle Erfolge in der Integration holen: Systeme verbinden, Objekte katalogisieren, Zugriff vereinheitlichen. Wächst die organisatorische Reife, wandert die Verantwortung für einzelne Domänen zu den Teams, die sie am besten kennen. Die Fabric-Schicht bleibt als gemeinsame Infrastruktur, die Mesh-Prinzipien regeln, wer wofür geradesteht.

Fabric mit Mesh-Verantwortung. Die Domänen besitzen ihre Data Products und legen ihre Qualitätsstandards fest. Die Fabric liefert die Anbindung, also Verknüpfungen über Domänen hinweg, Lineage und einheitliche Zugriffsregeln. Dieses Muster trägt, wenn Domänen Autonomie brauchen und Konsumenten einen einzigen Zugangspunkt.

Gezielter Einsatz. Mesh für Analyse und Berichtswesen, wo Fachwissen die Datenqualität unmittelbar hebt. Fabric für die operative Integration, wo Tempo und Einheitlichkeit schwerer wiegen als tiefer fachlicher Kontext. Eine Domäne Lieferkette kann ihre Analyseprodukte selbst besitzen (Mesh), während die Anbindung vom ERP ans Warehouse über die Fabric läuft.

Governance in beiden Modellen

Im Mesh ist Governance föderiert. Jedes Domänenteam legt die Regeln für seine eigenen Data Products fest, also Zugriffsrechte, Aufbewahrungsfristen und Qualitätsschwellen, innerhalb von Leitplanken, die ein zentrales Gremium setzt. Die Automatisierung setzt diese Regeln auf der Plattform durch: Ein Domänenteam kann kein Data Product veröffentlichen, dem die Schemadefinition oder ein benannter Owner fehlt.

In der Fabric ist Governance zentral. Die Fabric-Schicht wendet dieselben Regeln auf jede angebundene Quelle an: Maskierung, Zugriffsrechte, Lineage und Prüfprotokolle laufen durch einen einzigen Punkt. Das ist einfacher umzusetzen und schwerer an fachliche Sonderfälle anzupassen.

Gemeinsam ist beiden, dass sie drei Dinge brauchen: einen Datenkatalog für die Discovery, ein Business Glossary (Fachglossar) für gemeinsame Definitionen und Data Lineage, um zu verstehen, wie Daten fließen. Ohne das finden die Domänen im Mesh die Produkte der anderen nicht, und die Fabric kann nicht erklären, woher Daten kommen und wie sie umgeformt wurden. Genau hier wird eine Governance-Plattform unverzichtbar, gleich für welche Architektur sich eine Organisation entscheidet.

Wo Dawiso hineinpasst

Dawiso liefert die Metadatenschicht, die beide Architekturen brauchen. Im Data Mesh können Domänenteams ihre Data Products über einen gemeinsamen Katalog veröffentlichen, auffindbar machen und dokumentieren, was genau die Anforderungen an Auffindbarkeit und Verständlichkeit erfüllt, die zu Data as a Product gehören. Die Teams melden ihre Produkte mit Schemadefinition, Verantwortlichkeit, SLAs und Qualitätskennzahlen an. Konsumenten aus anderen Domänen suchen im Katalog, was es gibt, und prüfen, ob es zu ihrem Bedarf passt.

In der Data Fabric übernimmt Dawiso das zentrale Metadatenmanagement: Es katalogisiert Daten über alle Quellen, verfolgt Lineage von Anfang bis Ende und hält über das Business Glossary einheitliche Definitionen. Führt die Virtualisierungsschicht der Fabric eine Abfrage über mehrere Quellen aus, liefert Dawiso den fachlichen Kontext dazu, also welche Tabelle die maßgebliche Kennzahl „Umsatz“ hält, welche Regeln einen „aktiven Kunden“ definieren und wie die Daten von der Quelle bis zum Dashboard fließen.

Über das Model Context Protocol (MCP) können KI-Agenten den Katalog von Dawiso programmatisch nutzen, also Definitionen nachschlagen, die Aktualität prüfen und Lineage abrufen, gleich ob die Organisation nach Mesh, nach Fabric oder gemischt arbeitet.

Fazit

Die Frage Mesh oder Fabric ist keine Frage danach, welche Architektur besser ist. Sie ist eine Frage danach, welche organisatorischen und technischen Zwänge am schwersten wiegen. Mesh löst den Engpass beim Fachwissen über verteilte Verantwortung. Fabric löst den Engpass bei der Integration über eine einheitliche Technik. Beide brauchen ein belastbares Metadatenmanagement als Fundament, und die meisten Unternehmen werden mit wachsender Reife Elemente aus beidem verbinden.