Zielsetzung - Worum geht es?
Welche Probleme sollen mit Data Mesh adressiert werden?
Die klassische Struktur eines Unternehmens sieht ein zentrales Datenmanagement-Team vor, welches für sämtliche Daten-Pipelines, die Datenaufbereitung und die Datenanalyse verantwortlich ist. Dementsprechend weit verbreitet sind zentrale Datenarchitekturen wie beispielweise Data Lakes und Data Warehouses. Für kleinere Unternehmen ist das ein guter Ansatz, da so die Integrität und Konsistenz der Daten auf einfachem Wege gesichert wird. Bei einem wachsenden Unternehmen, mit starker Datenorientierung, d.h. insbesondere bei steigendem Datenvolumen, steigender Anzahl an Datenquellen und datengetriebenen Use-Cases, die alle vom zentralen Datenteam bedient werden möchten und verschiedene Datenstrukturen verwenden, kann dies zu einem Bottleneck führen.
Das zentrale Daten-Team kann auf Dauer die analytischen Fragen in Bezug auf Daten nicht schnell genug bearbeiten. Neben der Instandhaltung der Daten-Pipelines muss das Daten-Team sich mit den Themen der einzelnen Domains befassen, um sämtliche Fragen kompetent beantworten zu können. Die Wettbewerbsfähigkeit wird hierdurch gefährdet.
Sofern nicht anders erklärt, sind mit Daten immer analytische Daten gemeint.
Wie löst Data Mesh diese Probleme?
Ein wesentliches Augenmerk beim Data Mesh liegt auf der Dezentralisierung der Datenverwaltung. Das Data Mesh Prinzip bringt die Verantwortung für das Datenmanagement weg vom zentralen Daten-Team und hin zu den Domain-Teams, also näher an die Quelle der Daten. Die Domain-Teams verwalten ihre Daten autonom, befolgen jedoch gewisse Grundsätze und Richtlinien, um die Kooperation zwischen den Domain-Teams zu verbessern und zu erhöhen. Unterstützt werden sie dabei durch eine zentrale Plattform, die die notwendigen Werkzeuge dafür bereitstellt. Dadurch werden einige Schwierigkeiten adressiert, die durch eine Dezentralisierung der Datenverwaltung auftreten können, etwa Mehraufwand, duplizierte Daten oder Inkompatibilität.
Der Ursprung von Data Mesh
Der Begriff Data Mesh wurde im Wesentlichen von Zhamak Dehghani geprägt. Dieser und die folgenden Artikel orientieren sich an dem Artikel “Data Mesh Principles and Logical Architecture” sowie dem Buch “Data Mesh” von Zhamak Dehghani.
Was ist Data Mesh?
Data Mesh ist ein Prinzip, das in erster Linie eine Struktur auf organisatorischer Ebene beschreibt. Die konkrete, technische Umsetzung ist nicht festgeschrieben, sondern erlaubt einen gewissen Spielraum. Data Mesh baut auf vier Grundsäulen auf.
- Domain Ownership – Domain Teams sind verantwortlich für ihre analytischen Daten, neben den operationalen Daten
- Data as a Product – Daten werden wie Produkte behandelt
- Self-serve Data Platform – Bereitstellung einer Werkzeug-Plattform für die Domain-Teams
- Federated Computational Governance – Übergreifende Richtlinien
Die Domain Ownership beschreibt den Kern des Data Mesh Konzepts: Eine Dezentralisierung und Verteilung der Verantwortung für die Daten an diejenigen, die am nächsten an der Quelle sind. Hierdurch werden kontinuierliche Veränderung und Skalierbarkeit gewährleistet. Softwareorganisationen in Unternehmen sind bereits oftmals nach den Unternehmensdomänen strukturiert und demgemäß die Entwicklungsverantwortung für deren Microservices verteilt. Diese Teams sollen nun auch die Verantwortung für ihre eigenen analytischen Daten übernehmen.
Die Self-serve Data Platform wird zentral bereitgestellt, um den Domain-Teams den Aufbau einer Data Product Infrastruktur zu erleichtern, bzw. zu ermöglichen. Die Anforderungen an die Domain-Teams in Bezug auf das technische Know-How sollen damit gesenkt werden. Die Self-serve Data Platform liefert Werkzeuge, mit denen ein Workflow im Hinblick auf den Lebenszyklus von Data Products ohne spezielle Kenntnisse vorgegeben und ermöglicht werden soll.
Mit der Federated Computational Governance ist das Erstellen, Ausführen und Überwachen von globalen sowie lokalen Richtlinien gemeint, die einen Standard in Bezug auf die Data Products und die Nutzung der Self-serve Data Platform bilden sollen. Dies ist grundlegend und wichtig für die Zusammenarbeit der Domain-Teams. Nur so kann gewährleistet werden, dass die Data Products untereinander kompatibel sind, von mehreren Domain-Teams genutzt werden können und für Mehrwert schaffende Analysen/Datenverarbeitungen zugänglich sind. Hierbei muss darauf geachtet werden, dass das Gleichgewicht zwischen dezentralen Domain-Teams und zentralen/globalen Richtlinien eingehalten wird.
So entsteht letztendlich ein Datennetz, deshalb Data Mesh, wobei die Data Products die Knoten sind und die Kanten die Beziehungen, Verknüpfungen und Verwendungen der Daten darstellen.
Es sei erwähnt, dass die vier Grundprinzipien an sich bereits länger existieren und praktiziert werden. Das Zusammenführen zu einem Ganzen, einem gut funktionierenden System ist das, was Data Mesh letztendlich ausmacht: Die Dezentralisierung des Datenmanagements über die Domain Ownership, das saubere Arbeiten mit Daten mittels Data Products, die technische Unterstützung der Domains durch die Self-serve Data Platform und die Federated Computational Governance als Monitoring- und Richtlinien-Komponente, um Kompatibilität zu gewährleisten und das Data Mesh als Ganzes zu realisieren.
Ausblick
Wie bereits angesprochen ist die Bottleneck-Problematik ein zentraler Gesichtspunkt im Datenmanagement heutiger Unternehmen. Die Domain-Teams bieten hier den idealen Anknüpfungspunkt, um die Problematik anzugehen. Klar ist jedoch auch, dass ein Data Mesh nicht auf Knopfdruck implementiert werden kann. Dementsprechend muss abgewogen werden, ob und in welcher Form sich ein (fließender) Übergang zu einer Data Mesh Infrastruktur realisieren lässt. Data Contracts sind hierbei erwähnenswert. Der Fokus liegt wie schon erwähnt eher auf größeren Unternehmen.
Da Data Mesh ein recht neues Konzept ist, gibt es keine Standardlösung für die konkrete Implementierung, allerdings gibt es bereits einige Unternehmen, die Data Mesh umgesetzt haben und als Erfolg bewerten, beispielsweise PayPal.
In den folgenden Artikeln werden die vier Grundprinzipien von Data Mesh und der Übergang zu einer Data Mesh-Architektur noch ausführlicher behandelt. Anschließend sollen auch praktische Implementierungsmöglichkeiten thematisiert werden. Apache Kafka stellt hier eine gute Möglichkeit dar. Ebenso könnte SBC ein hilfreiches Tool bei einer Realisierung von Data Mesh sein.