Data Mesh und Data Products im Vergleich

Data Mesh und Data Products sind keine konkurrierenden Alternativen, sie wirken auf verschiedenen Ebenen. Data Mesh ist die Architektur, Data Products sind die Bausteine darin. Beide zu vergleichen ist, als vergleiche man „eine Architektur aus Microservices“ mit „einem einzelnen Dienst“. Das eine ist das organisatorische und technische Leitbild, das andere die Einheit, in der Wert geliefert wird.

Diese Beziehung zu verstehen ist wichtig, weil viele Organisationen beides verwechseln. Teams wollen Data Mesh einführen, ohne vorher zu wissen, wie ein gutes Data Product aussieht. Andere bauen ausgezeichnete Data Products, richten aber nie die Plattform und die Governance ein, mit der diese Produkte im Unternehmen skalieren könnten. Ob sich die Investition auszahlt, hängt an der richtigen Reihenfolge.

Architektur und Baustein

Data Mesh ist ein Leitbild, das organisatorische Veränderung mit technischer Infrastruktur verbindet. Es sagt: Domänenteams sollen ihre Daten von Anfang bis Ende verantworten, gestützt auf eine Plattform zur Selbstbedienung und auf föderierte Governance. Data Products sind die kleinsten Einheiten, in denen dieses Leitbild Wert liefert.

Ein Data Product ist ein Datenbestand, der mit der Disziplin eines Softwareprodukts behandelt wird. Es hat eine Verantwortung, also ein benanntes Team oder eine benannte Person, die für Qualität und Weiterentwicklung geradesteht. Es hat ein SLA, also Zusagen zu Aktualität, Vollständigkeit und Verfügbarkeit. Es hat eine Dokumentation, also Definitionen des Schemas, fachlichen Zusammenhang und Beispiele für die Nutzung, eingetragen in einem Datenkatalog. Es hat Qualitätsmetriken, also selbsttätige Prüfungen, die fortlaufend ausgeführt werden und die Verantwortlichen alarmieren, sobald Schwellen gerissen werden. Und es hat definierte Abnehmer, also nachgelagerte Teams oder Systeme, die davon abhängen.

Data Mesh liefert das organisatorische Modell, also Verantwortung in der Domäne, eine Plattform zur Selbstbedienung und föderierte Governance, mit dem Data Products im Unternehmen skalieren. Ohne Mesh funktionieren einzelne Data Products gut, bleiben aber vereinzelte Verbesserungen. Ohne Data Products ist Mesh ein leeres Gerüst, eine Änderung am Organigramm ohne vorzeigbares Ergebnis.

Was ein Data Product ausmacht

Das Rahmenwerk von Zhamak Dehghani beschreibt die Merkmale, die ein Data Product von einem gewöhnlichen Datenbestand im Warehouse unterscheiden. Jedes Merkmal löst ein bestimmtes Problem, das Daten im großen Maßstab schwer nutzbar macht.

Auffindbar. Wer Daten zum Kundenwert über die gesamte Beziehung sucht, sollte das Produkt in einem Katalog finden, ohne jemanden fragen zu müssen. Gefunden wird über Suche, Schlagworte und Begriffe aus dem Business Glossary, nicht über mündlich weitergegebenes Wissen.

Adressierbar. Jedes Produkt hat einen stabilen, eindeutigen Bezeichner und einen Zugangspunkt. Abnehmer verbinden sich über eine dokumentierte API oder eine Schnittstelle für Abfragen, nicht über den Verweis auf eine bestimmte Datenbanktabelle, die sich verschieben kann.

Verständlich. Die Dokumentation des Produkts erklärt, was die Daten darstellen, wie sie berechnet werden, welche fachlichen Regeln gelten und welche Vorbehalte bestehen. Wer neu ins Unternehmen kommt, kann das Produkt ohne Einweisung durch das ursprüngliche Team nutzen.

Vertrauenswürdig. Selbsttätige Prüfungen der Qualität bestätigen bei jeder Aktualisierung Aktualität, Vollständigkeit und Genauigkeit. Das Produkt veröffentlicht seine Qualitätswerte, damit Abnehmer die Eignung für den eigenen Anwendungsfall einschätzen können, bevor sie eine Abhängigkeit aufbauen.

Interoperabel. Das Produkt folgt den Standards der Organisation für Benennung, Format und semantische Typen. „Customer ID“ nutzt in jedem Data Product der Organisation dasselbe Format des Bezeichners und erlaubt damit Verknüpfungen ohne manuelle Zuordnung.

Sicher. Der Zugriff wird durch Regeln bestimmt, die festlegen, wer lesen darf, welche Spalten maskiert werden und unter welchen Bedingungen. Diese Regeln werden selbsttätig durchgesetzt, nicht über einzeln per Ticket vergebene Berechtigungen.

Ein greifbares Beispiel: ein Data Product „Customer 360“, veröffentlicht vom Team für das CRM. Es ist mit der Dokumentation des Schemas im Datenkatalog eingetragen, mit einem Eintrag im Business Glossary für jedes Feld. Es stellt Daten über eine versionierte API bereit, mit einem Vertrag über 99,9 % Verfügbarkeit und Daten, die nicht älter als 15 Minuten sind. Sein Dashboard zur Qualität zeigt Vollständigkeit und Genauigkeit in Echtzeit. Und seine Zugriffsregeln erzwingen die Maskierung auf Spaltenebene für Felder mit PII, wenn die Freigabe nach der DSGVO fehlt.

Wie Data Products im Data Mesh arbeiten

Innerhalb eines Data Mesh wirken Data Products über drei Schichten, die sich gegenseitig verstärken.

Domänenteams bauen und verantworten die Produkte. Das Team, das den Daten am nächsten steht, also sie erzeugt oder ihren fachlichen Zusammenhang am besten kennt, übernimmt die volle Verantwortung. In einem Handelsunternehmen veröffentlicht das Domänenteam für den Bestand ein Data Product „Bestandsmengen“. Es legt das Schema fest, setzt das SLA für die Aktualität, nämlich alle 10 Minuten aus den Systemen der Lagerverwaltung aktualisiert, und überwacht die Qualität. Wenn die Domäne Lieferkette Bestandsdaten für die Bedarfsprognose braucht, nutzt sie das Produkt über dessen veröffentlichte Schnittstelle, statt eine eigene Strecke aus derselben Quelle zu bauen.

Eine Plattform zur Selbstbedienung stellt die Infrastruktur. Domänenteams sollen nicht jeweils eigene Rechencluster und Stapel zur Überwachung betreiben. Das Plattformteam stellt vereinheitlichte Infrastruktur bereit: Bereitstellung von Speicher, Orchestrierung von Strecken, Überwachung der Qualität und Eintrag in den Katalog, alles über APIs zur Selbstbedienung. Das Team für den Bestand setzt sein Produkt über die Plattform auf und betreibt keine Cluster mit Kubernetes.

Föderierte Governance setzt übergreifende Standards. Ein Gremium für die Governance, mit Vertretung aus jeder Domäne, legt Namenskonventionen, Mindestschwellen für die Qualität, Anforderungen an die Einstufung der Sicherheit und Vorlagen für SLAs fest. Diese Standards werden über die Plattform durchgesetzt: Ein Team kann kein Produkt veröffentlichen, dem die Verantwortung, eine Definition des Schemas oder eine Mindestzusage zur Aktualität fehlt. Domänenteams behalten die Freiheit über domänenspezifische Entscheidungen, also welche Felder aufgenommen und wie Sonderfälle behandelt werden, während die Organisation die Einheitlichkeit wahrt.

Data Products ohne Data Mesh

Sie können das Denken in Data Products übernehmen, ohne die gesamte Organisation umzubauen. Viele Teams beginnen damit, Grundsätze des Produktmanagements auf ihre meistgenutzten Datenbestände anzuwenden, also auf die, die in der Auswertung immer wieder neu gebaut, im Data Engineering immer wieder repariert und von den Beteiligten immer wieder beklagt werden.

Das Vorgehen ist geradlinig. Wählen Sie die fünf Datenbestände, die den meisten Ärger machen oder den größten fachlichen Wert tragen. Weisen Sie jedem eine Verantwortung zu. Beschreiben Sie Schema und fachlichen Zusammenhang in einem Datenkatalog. Legen Sie ein SLA für Aktualität und Vollständigkeit fest. Richten Sie selbsttätige Prüfungen der Qualität ein. Veröffentlichen Sie eine Schnittstelle für den Zugang, auf die sich Abnehmer verlassen können, ohne brechende Änderungen fürchten zu müssen.

Das ist kein Data Mesh. Es gibt keine Plattform zur Selbstbedienung, kein Gremium für föderierte Governance und keinen organisatorischen Umbau auf Ebene der Domänen. Aber es löst sofort echte Probleme: Wer Daten nutzt, weiß, wo verlässliche Daten zu finden sind, wer Daten erzeugt, kennt die Standards, an denen die Arbeit gemessen wird, und Probleme der Qualität werden gefunden, bevor sie in Dashboards ankommen.

Der Wert dieses Anfangs liegt darin, dass er organisatorischen Beleg schafft. Wenn ein Produktteam sieht, dass das Data Product „Customer 360“ seine Zeit für die Fehlersuche in Strecken um 60 % gesenkt hat, wird es zum Fürsprecher des Ansatzes. Wenn die Finanzleitung sieht, dass das Data Product „Revenue“ drei widersprüchliche Definitionen des Quartalsumsatzes beseitigt hat, schreibt sich die Begründung für den Ausbau von selbst. Dieser Beleg von unten rechtfertigt am Ende die größere Investition in die Infrastruktur für das Mesh.

Wo man anfängt

Beginnen Sie mit Data Products, wenn die Organisation bestimmte, benennbare Probleme mit der Datenqualität oder mit dem Zugriff hat. Das Team braucht keine Erlaubnis, das Organigramm umzubauen, es muss fünf Datenbestände verlässlich machen. Ressourcen sind begrenzt, und die Priorität liegt darauf, den Nutzen schnell zu zeigen und so Schwung für größere Veränderungen aufzubauen.

Entwickeln Sie sich zum Data Mesh, wenn das zentrale Datenteam zum Engpass geworden ist. Mehrere Domänen brauchen die Freiheit, im eigenen Takt voranzugehen. Die Organisation hat das Denken in Data Products bereits im Kleinen belegt und ist bereit für den kulturellen Wechsel zur Verantwortung in der Domäne. Mesh braucht Rückhalt in der Geschäftsleitung, weil es Teamstrukturen und Verantwortungslinien ändert.

Ein Vorgehen in Phasen senkt das Risiko. Phase eins: die fünf wichtigsten Datenbestände zum Produkt machen, also Verantwortung zuweisen, SLAs festlegen, im Katalog eintragen. Phase zwei: eine Plattform zur Selbstbedienung aufbauen, die Speicher, Strecken, Überwachung und den Eintrag in den Katalog über APIs bedient. Phase drei: die Verantwortung an die Domänenteams übergeben, ein Gremium für föderierte Governance einrichten und die Domänen innerhalb gemeinsamer Leitplanken unabhängig weiterentwickeln lassen.

Der Katalog als Grundlage

Sowohl Data Products als auch Data Mesh brauchen einen Datenkatalog als Schicht für das Finden. Data Products müssen auffindbar sein: Abnehmer durchsuchen den Katalog, um zu sehen, was es gibt, Schema und Qualität zu verstehen und Zugriff zu beantragen. Ohne Katalog fällt das Finden auf Nachfragen bei Leuten in Slack zurück, und das skaliert nicht.

Im Mesh führt der Katalog die Metadaten über die Domänen hinweg zusammen und hält dabei einheitliche Standards. Jede Domäne trägt ihre Produkte mit Definitionen des Schemas, mit der Verantwortung, mit Qualitätsmetriken und mit Lineage ein. Der Katalog liefert eine einzige Sicht auf die gesamte Datenlandschaft der Organisation, obwohl die Verantwortung verteilt ist.

Ein Business Glossary stellt sicher, dass „Umsatz“ in allen Data Products dasselbe bedeutet, gleich welche Domäne sie veröffentlicht. Ohne dieses gemeinsame Vokabular erzeugt die Freiheit der Domänen semantische Zersplitterung: Der „Umsatz“ der Domäne Finanzen enthält abgegrenzte Erlöse, der „Umsatz“ der Domäne Vertrieb zählt nur abgeschlossene Geschäfte, und nachgelagerte Abnehmer verknüpfen beides, ohne zu bemerken, dass die Definitionen auseinandergehen.

Wo Dawiso hineinpasst

Dawiso liefert die Infrastruktur für Metadaten, die Data Products erst arbeiten lässt. Sein Datenkatalog ermöglicht das Finden: Domänenteams veröffentlichen ihre Produkte mit Definitionen des Schemas, mit der Verantwortung, mit SLAs und mit Qualitätswerten. Abnehmer durchsuchen den Katalog, finden Produkte, bewerten die Eignung für den eigenen Anwendungsfall und verstehen Abhängigkeiten über die Verfolgung der Lineage.

Das Business Glossary liefert gemeinsame Definitionen über die Domänen hinweg. Wenn das Team Finanzen ein Data Product „Revenue“ veröffentlicht und das Team Vertrieb ein Data Product „Bookings“, klärt das Glossar die Beziehung zwischen beiden Begriffen und verhindert widersprüchliche Auslegungen weiter unten.

Über das Model Context Protocol (MCP) können KI-Agenten den Katalog abfragen, um verfügbare Data Products zu finden, ihre Qualitätswerte zu prüfen, Schemata zu verstehen und die Lineage zu verfolgen, und so Data Products ohne manuelles Nachschlagen selbsttätig nutzen.

Fazit

Data Mesh ist das Ziel, Data Products sind der Weg dorthin. Beginnen Sie damit, Ihre wichtigsten Datenbestände auffindbar, beschrieben und verlässlich zu machen, der Rest der Architektur folgt aus dieser Grundlage.