Data Mesh – ein Gamechanger?
Eine differenzierte Betrachtung des Hype-Themas

Wenn es um Architekturen und Infrastrukturen zur analytischen Nutzung von Daten geht, ist Data Mesh in aller Munde. Neben Tool-Herstellern haben natürlich auch Berater, ob Technologie- oder Strategie-, das Thema für sich entdeckt. Ein Versuch, hinter den Hype zu schauen.
Was soll ein Data Mesh überhaupt sein? Zunächst einmal gibt es nicht "das Mesh", das man im besten Fall einfach als Produkt installieren kann. Vielmehr ist es ein soziotechnisches Framework, welches Ideen von Domain-driven Design über Microservices bis hin zu Team Topologies auf die Welt der analytischen Daten überträgt. Adressiert werden soll damit nichts weniger, als die häufig unzureichende Verfügbarkeit und Nutzung ebendieser Daten in Unternehmen. Die Idee kommt von Zhamak Dehghani, die es 2019 unter dem Titel "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh" veröffentlichte [1]. Vom trägen, langsamen Monolithen-Data-Lake (oder oft auch Data Warehouse) zum schnellen, verteilten und flexiblen Mesh.
Vier Grundprinzipien
Die Idee des Data Mesh basiert auf vier Prinzipien, deren Zusammenspiel die Grundlage für das Data Mesh bilden. Die ersten beiden Prinzipien haben dabei einen erkennbaren organisatorischen Charakter. Die anderen beiden nehmen die Technologie mehr in den Fokus, beschränken sich aber ausdrücklich nicht auf diese.
Domain Ownership
Die Hoheit für analytische Daten liegt bei der Business Domain und nicht bei einem zentralen Data-Team. Die Business Domain kennt die Daten inhaltlich und kann darüber Auskunft geben. Dadurch, dass die Ownership für die analytischen Daten verteilt und dezentral bei den Business Domains liegt, ist das zentrale Team kein Flaschenhals mehr. Durch diese Dezentralisierung soll es gelingen, mehr Datenquellen bereitzustellen und mehr Nutzer für die Daten zu erreichen. Ebenso entfällt die "Stille Post" zwischen Nutzer und Bereitsteller über das Data-Team, beispielsweise wenn die Daten fehlerhaft oder erklärungsbedürftig sind. Stattdessen wendet sich der Nutzer direkt an die Bereitsteller der Daten.
Data as a Product
Damit die Daten nicht in den Silos der Domänen verbleiben, sollen sie als Produkt verstanden werden. Als etwas, das einen Mehrwert bietet, nicht nur innerhalb des eigenen Kontexts, sondern auch für andere Domänen. Insbesondere dann, wenn sie mit anderen Daten verknüpft werden. Damit Daten auch außerhalb der Domäne genutzt werden, müssen die Daten nicht nur als reines Asset gesehen werden, sondern als Produkt mit entsprechenden Merkmalen. So bemisst sich zum Beispiel der Erfolg eines Produkts am Kundennutzen.
"Etwas als Produkt sehen" findet man aktuell bei vielen IT-Themen (z. B. Platform Engineering, API as a Product). Der wesentliche Teil ist hier, den Kunden und Nutzer der Daten im Blick zu haben. Die Daten sind verlässlich, verständlich und auffindbar. Sie sind interoperabel und mit anderen Datenprodukten kombinierbar. Datenprodukte umfassen dabei nicht nur die Daten selbst, sondern auch Metadaten, Policies und der Code, der zum Beispiel für die Bereitstellung und Aufbereitung der Daten genutzt wird. Durch Contracts über Form, Inhalt und Bereitstellung der Produkte soll auch Stabilität erreicht werden. Und durch Metadaten und Beschreibungen kann die Nutzung der Daten vereinfacht werden.
Wie ein Datenprodukt technologisch umgesetzt wird, ist dabei nicht festgelegt. Es kann in Form von Tabellen, Queue und Dateien erfolgen – nicht aber als direkter Zugriff auf die produktive, operative Datenbank einer Anwendung. Metadaten können in einem Datenkatalog, einer zusätzlichen Datei oder einem Wiki gepflegt werden. Es gibt viele unterschiedliche Ansätze und ebenso viele Erfahrungsberichte. Wichtig ist vor allem die Grundidee des Produkts, weniger die technische Ausprägung.
Self-Service Data Platform
Die meisten operativen Teams haben wenig Know-how in der Bereitstellung analytischer Daten. Ebenso liegen die Prioritäten eher bei der Umsetzung von Features für die Anwendung. Um die Teams bei der Bereitstellung und Nutzung von Datenprodukten zu entlasten, soll eine Self-Service-Data-Platform geschaffen werden. Diese soll Teams ermächtigen, einfach Daten zu teilen und zu aktualisieren, und genauso Nutzern es ermöglichen, Daten zu entdecken, sie zu verstehen, auf sie zuzugreifen, sie zu nutzen und sie mit anderen Daten zusammenzubringen.
Ebenso soll damit verhindert werden, dass jedes Team eigene Werkzeuge für analytische Daten aufbaut und betreibt und somit eine dezentrale Infrastruktur entsteht. Durch diese Werkzeuge steigt sonst bei vielen Teams, die sich bereits mit Development, Operations, Security und weiteren Themen beschäftigen, die kognitive Komplexität noch weiter an. Aber auch nicht-technischen Teams soll mittels einer Plattform eine unkomplizierte Teilhabe an der Demokratisierung der Daten ermöglicht werden. Und zu guter Letzt sollen über die Plattform auch Security- und Compliance-Standards sichergestellt werden, womit wir zum letzten der vier Grundprinzipien kommen.
Federated Computational Governance
Die Ideen des Data Mesh führen dazu, dass Verantwortlichkeiten für Daten dezentralisiert werden. Ein Vorteil eines zentralen Data Warehouse war insbesondere die vergleichsweise einfache Möglichkeit, Qualitätsstandards sicherzustellen oder Vorgaben des Datenschutzes umzusetzen. Im Data Mesh übernimmt die Self-Service-Plattform diese Aufgabe. Sie soll dabei helfen, Governance-Vorgaben umzusetzen, die gemeinsam (federated) von den relevanten Gruppen (Security, Legal, Domänenexperten, Tech und weitere) erarbeitet und vorgegeben werden. Damit das dezentral mit potentiell vielen Nutzern der Plattform funktionieren kann, soll die Umsetzung möglichst automatisiert (computational) erfolgen, auch um die Akzeptanz bei den Nutzern zu erhöhen.
Dabei gilt es die Balance zwischen Autonomie und Agilität der Domänen auf der einen Seite und notwendiger Standardisierung für die globale Verwendung auf der anderen Seite zu wahren. Ziel ist es auch, Inkompatibilitäten zwischen Domänen zu verhindern und manuelle Abstimmungen zu reduzieren. Auch Themen wie Data Catalogs werden aus diesem Grund explizit im Bereich der Governance gesehen.
Die vier Prinzipien bauen erkennbar aufeinander auf und bedingen sich teilweise gegenseitig. Abb. 1 zeigt das Zusammenspiel der Prinzipien.
Datensilos aufbrechen
Die ersten beiden Prinzipien klingen für viele am einfachsten, insbesondere für Entwicklerteams, die bereits in einer "microservice-artigen" Architektur unterwegs sind. Für sie ist es normal, die Ownership für Daten, die in den eigenen Anwendungen erzeugt werden, zu haben. Das heißt nicht nur, dass sie diese für andere Anwendungen bereitstellen (zum Beispiel als Event über einen Message Broker oder abrufbar über eine REST-API). Sie übernehmen auch Verantwortung für die Qualität der Daten.
In solchen Microservice-Architekturen geschieht der Austausch der Daten häufig in Form von einzelnen Datensätze bei Anforderungen, beispielsweise wenn sich der Kunde in einem Online-Shop seine Bestellhistorie anzeigen lassen will oder unter einem Artikel die vorberechneten Produktempfehlungen angezeigt werden.
Für das Berechnen dieser Produktempfehlungen braucht man aber keine Einzelsätze mehr, ebenso für die Analyse der letzten Marketingkampagne oder die Erstellung der Geschäftszahlen. Hier müssen Massendaten geliefert werden. Hier besteht für viele Entwicklerteams eine Herausforderung bei der Forderung nach dem Data-as-a-Product: Um analytisch relevante Daten als Massendaten anbieten zu können, brauchen sie neben entsprechender Infrastruktur (s. Prinzip 3: die Plattform) auch entsprechendes Know-how. Daten werden auf einmal im parquet-Format geschrieben, die Verarbeitung auf der Plattform erfolgt z. B. mit Python oder PySpark und Tests für die Qualität der Daten (nicht nur Code muss getestet werden!) erfolgt mit Great Expectations [3]. Das sind Werkzeuge und Arbeitsweisen, die nicht in jedem Team bekannt sind. Neben DevSecOps (beliebig erweiterbar) sollen die Teams jetzt auch noch Data machen.
Analytische Daten als First-Class-Citizen
Nun werden einige sagen: Aber man kann das Ganze auch deutlich entwicklerfreundlicher gestalten. Das stimmt: Werkzeuge wie dbt erlauben es weiterhin, mit (bekanntem) SQL und Datenbanken zu arbeiten, ohne dabei Engineering-Best-Practices zu vernachlässigen. Die Pipelines, die Daten regelmäßig bereitstellen, müssen nicht zwingend mit Airflow oder Prefect gesteuert werden: Das klappt auch mit bekannten und vorhandenen CI-Tools sehr gut.
Der für mich allerdings hier wichtigere Teil ist: Entwickler beschäftigen sich mit Daten über das Erfüllen von operativen Aufgaben hinaus. Analytische Daten werden zu einem First-Class-Citizen in der Softwareentwicklung. Dadurch, dass ich die Datenhoheit an die Entwicklerteams übertrage, beschäftigen sie sich auch mit der Speicherung und Verwaltung dieser Daten. Und wenn die Daten dann eh schon bei ihnen liegen, können diese auch selbst genutzt werden. Beispielsweise um die Verwendung ihrer Anwendung besser zu verstehen, daraus sinnvolle Features oder Verbesserungen abzuleiten oder aber auch von außen gewünschte Features besser beurteilen zu können. Datengetriebene Produktentwicklung ohne für die Analyse auf andere (ggfs. zentrale, langsame DWH-)Teams angewiesen zu sein.
Wenn die Idee des Data Mesh nur bewirkt, dass die Barriere oder zum Teil auch die Unwissenheit für Entwickler in Richtung analytischer Daten verschwindet und selbst Mehrwerte entdeckt werden, ist das für mich bereits ein absolut positiver Effekt.
Plattform & Governance als Herausforderung
Die Self-Service-Plattform soll Teams befähigen, die Daten einfach bereitzustellen und Governance-Anforderungen zu erfüllen. Dafür gibt es Stand jetzt keine Lösung out-of-the-box, auch wenn einige Hersteller dies gerne behaupten. Was es gibt, sind einige wenige Erfahrungsberichte von Unternehmen, zum Beispiel Zalando, die solche Plattformen aufgebaut haben. Meist sind es Lösungen auf Basis vorhandener Komponenten und Werkzeugen, die zusammengesteckt werden.
Bislang ist das aber alles eher Stückwerk, das schnell sehr aufwändig werden kann und weiterhin viel manuellen Aufwand erfordert. Es ist schwierig, hier die Balance zu finden: groß genug zum helfen, aber nicht zu teuer soll es sein. Insbesondere für kleine Unternehmen lohnt sich der Aufbau einer selbst gebauten Plattform selten und es gilt hier passende Lösungen zu finden, die ausreichend Mehrwert liefern.
Die Automated Governance ist für mich Stand jetzt eine Vision. Die Konzepte und Ideen sind durchaus schlüssig, für die Umsetzung fehlt es aber noch an guten Werkzeugen. Die Anforderungen reichen da von Berechtigungen für den Datenzugriff über automatisierte Erhebung der Daten und der Qualität bis hin zur automatischen Sicherstellung regulatorischer oder organisatorischer Vorgaben. Auch hier gibt es noch viel Stückwerk und manuelle Lösungen.
Lösungsansätze für die Plattform
Interne IT-Plattformen sind natürlich kein data-mesh-spezifisches Thema. Bereits seit Jahren bauen viele Unternehmen mit mehr oder weniger Erfolg solche Plattformen, mal on-premises, mal in der Cloud. Hier haben in den letzten Monaten die Ideen des Plattform Engineering vermehrt Beachtung gefunden. Wie beim Data Mesh gibt es auch bei diesen Konzepten viele unterschiedliche Interpretationen und Ausprägungen. Für mich wesentlich ist aber das Übertragen von Product Thinking und Self-Service auf Plattformen, die für interne Entwickler gebaut werden. Eine zentrale Idee ist dabei der Golden Path. Der Standard-Weg, um bestimmte Probleme, zum Beispiel das Deployment von Anwendungen, zu lösen. Und die Nutzung dieses Standard-Wegs ist so einfach und gut gemacht, dass die Entwickler-Teams diesen selbstverständlich nutzen und die Plattform wirklich als Enabler anstatt als eine Einschränkung sehen.
Warum ist das für das Data Mesh interessant? Die kognitive Last für Entwicklerteams wird durch die zusätzliche Beschäftigung mit analytischen Daten noch größer. Gute Plattformen, die einfache Lösungen anbieten – ob fertig gekauft oder mittels vorhandener Werkzeuge selber entwickelt und betrieben – helfen hier. Ebenso wird das Thema Governance adressiert, auch hier in Form von Automatisierung. Die bislang vorhandenen Tools rund um das Plattform Engineering sind noch stark auf den Software-Entwicklungsprozess fokussiert. Aus meiner Sicht spricht wenig dagegen, diese auch für Aufgaben rund um analytische Daten anzupassen und zu verwenden.
Knackpunkt Kultur & Organisation
Neben aller Technik spielt natürlich auch die Kultur und die Organisation eine Rolle. Insbesondere wenn es darum geht, die Datennutzung domänen- und teamübergreifend zu verbessern. Schwierig ist es zum Beispiel, wenn Software vor allem in Projekten entwickelt wird und so keine Produktteams entstehen, die langfristig die Gesamtverantwortung für eine Anwendung oder ein System übernehmen. Eine Organisation in Form von eigenverantwortlichen Domänenteams in der Anwendungsentwicklung ist meiner Meinung nach zwingend notwendig.
Und auch wenn in der Idealform jedes Team für sich Analysen ausführen kann und dabei auch Daten anderer Domänen einfach nutzen kann, ist offen, wer Auswertungen über mehrere Domänen hinweg durchführen kann, beispielsweise für Marketing- oder Vetriebszwecke. Dies könnte beispielsweise ein ehemaliges, zentrales DWH- oder Data-Lake-Team übernehmen. Andere übergreifende Themen sind das Betreiben der Plattform sowie das Enablement der Domänenteams.
Bis zum datengetriebenen Unternehmen ist es auch mit dem Data Mesh für viele Firmen noch ein weiter Weg. Daten im Unternehmen müssen als Wert verstanden werden, der vor allem durch Austausch entsteht. Damit dies auch so gelebt wird, ist in vielen Unternehmen ein umfangreiches Umdenken notwendig, für das neben soziotechnischen Frameworks wie dem Data Mesh auch ein gezieltes Change-Management notwendig ist.
Für welche Unternehmen ist es interessant?
Data Mesh heißt für ein Unternehmen, in Analytics zu investieren. Die Frage für ein Unternehmen heißt also: Wieviel Mehrwert erwarte ich, wenn analytische Daten besser verwendet werden. Entsprechend kann abgeschätzt werden, wie viel Investition sinnvoll ist. Neben dieser Frage gibt es aber aus meiner Sicht einige Rahmenbedingungen, die teils hilfreich, teils sogar Voraussetzung für die Überlegungen sind:
- Ein eventuell bereits vorhandenes, zentrales Datenteam ist überlastet oder wird absehbar den steigenden Anforderungen nicht gerecht werden können.
- Die Teams in der Software-Entwicklung sind vertikal nach Domänen geschnitten und entsprechend aufgestellt. (s. Domain-driven Design).
- Die Teams sind cross-funktional und werden durch Plattform- und Enabling-Teams unterstützt (s. Team Topologies).
- Die Organisation entwickelt Software als Produkte und nicht in Form aneinandergereihter Projekte.
- Eine ausgeprägte Affinität zur Public Cloud, um die Fertigungstiefe drastisch zu reduzieren.
- Daten analytisch zu nutzen ist essentiell für den Erfolg des Produkts oder des Unternehmens.
Ausgehend von diesen Rahmenbedingungen ergibt sich auch, dass das Thema Data Mesh für Unternehmen mit nur wenig eigener Software-Entwicklung und starkem Einsatz von Standardsoftware potentiell weniger relevant ist. Aber auch hier gibt es gegebenenfalls Potentiale, beispielsweise bei einer großen Heterogenität der Software-Landschaft und daraus resultierend einem Bedarf an übergreifender Auswertung der Daten, über Software- und Anbietergrenzen hinaus. Bei eher kleineren Unternehmen besteht die Gefahr der "Premature Optimization". Andererseits lassen sich hier bereits frühzeitig Grundlagen schaffen, auf die dann im Laufe der Zeit bei Bedarf zurückgegriffen werden kann.
Ausblick & Fazit
Insgesamt umfasst "das Data Mesh" durchaus schlüssige und sinnvolle Konzepte. Allerdings gibt es bei der Umsetzung dieser in der Praxis noch einige Herausforderungen, sowohl beim Tooling als auch bei der Organisation. Die Bedeutung analytischer Daten im Unternehmen wird mit den Ideen gestärkt, insbesondere auch für die Entwicklerteams. Sie bekommen in diesem Modell allerdings auch mehr Aufgaben. Hier gilt es, mit der Plattform sinnvolle Unterstützungen bereitzustellen. Gerade beim Thema Plattform und Governance gibt es aus technischer Sicht noch die meisten Baustellen – und gleichzeitig in Verbindung mit dem Plattform-Engineering großes Potential.
Insgesamt ist das Data Mesh eine gute Diskussionsgrundlage zum Thema analytischer Daten im Unternehmen. Es fasst vorhandene Best Practices und Werkzeuge zu einem schlüssigen Konzept zusammen und entwickelt dabei auch eine mögliche Vision für zukünftige Lösungen. Für uns sind die Ideen vor allem ein gut strukturierter Werkzeugkasten. Manche passen sehr gut zu den Herausforderungen unserer Kunden, andere weniger. Aber das strikte Festhalten an einem ganzen Konzept nur um des Konzeptes Willen ist – wie so oft – nicht sinnvoll.