Foto: Bevan von Weichardt - shutterstock.com
Es ist noch gar nicht so lange her, da galten Data Lakes als der Schlüssel zur Nutzung riesiger Datenmengen. Allerdings zeigte sich schnell ein wachsendes Problem: Daten aus vielen Quellen und Formaten, gesammelt ohne ordnendes Prinzip, entziehen sich mit zunehmender Größe und Komplexität des Datensees ihrer Nutzung. Mit Data Mesh wird es möglich, die Datenfülle praxisnah zu strukturieren und besser nutzbar zu machen.
Data Mesh - Definition
Die Idee des Data-Mesh-Ansatzes liegt darin, Ordnung zu schaffen und dadurch die Komplexität zu verringern. Das Grundprinzip entspricht dem der agilen Softwareentwicklung oder Ansätzen wie DevOps oder Microservices: Man teile das große Ganze in überschaubare Einheiten und bearbeite diese in Sprints. Wobei jede Einheit und jeder Sprint in sich schlüssig sein sollte und als Produkt zu behandeln ist, das bereits einen praktischen Nutzen in sich zu tragen hat.
Statt also einen Sumpf an unstrukturierten Daten entstehen zu lassen, soll es der potenzielle Nutzer mit Datenprodukten zu tun haben, über die jeweils ein Product Owner wacht. Er sorgt dafür, dass sein Produkt "funktioniert". Der Data Product Owner vertreibt und erläutert seine Produkte. Er entwickelt neue Produktideen, hält engen, am Nutzen orientierten Kontakt zu seinen Abnehmern und greift deren Verbesserungsvorschläge auf. Er prüft die Marktrelevanz seiner Produkte, ob sie "Gewinn" abwerfen beziehungsweise genutzt werden - und er begleitet jedes seiner Produkte über den ganzen Lebenszyklus hinweg.
Data Mesh Architecture - Projektablauf
Innerhalb eines Data-Mesh-Projekts klärt der Product Owner mit den Nutzern seines Datenprodukts deren Bedarf ab. Kurz: Er entwickelt und pflegt sein Datenprodukt wie ein reales Produkt. Die dazu benötigten Daten erhält er von den Lieferanten der Daten:
Entwicklungsteams,
Data Engineers oder
Um wirklich optimalen Nutzen zu entfalten, sollte ein Datenprodukt nicht nur aus den Nutzdaten an sich bestehen, sondern auch aus einer Beschreibung, was die Daten genau aussagen. Außerdem sind weiteren Metadaten sinnvoll, etwa wie viele Datensätze es gibt, wie aktuell sie sind und wie oft sie genutzt werden. Während des Projekts erweitert der Product Owner die eigentlichen Nutzdaten daher um Metadaten, die zum Beispiel die Abrufhäufigkeit der Nutzdaten und weitere oben genannte Parameter tracken.
Je nach Größe des Data-Mesh-Projekts beziehungsweise der Menge an theoretisch nutzbaren Daten kann es hilfreich sein, ein spezielles Team abzustellen, das sich um eine gute Data User Experience kümmert. Zu den Aufgaben dieses Teams gehört es, für alle Datenprodukte geltende Standards zu definieren und deren Umsetzung zu unterstützen. Damit lässt sich die Anzahl der Datenprodukte leichter skalieren als mit einem zentralen Data Lake, bei dem das Betreiber-Team im Prinzip alle aus "seinen" Daten entstehenden Produkte betreuen soll. Denn das funktioniert in der Praxis kaum. Die Bandbreite der Möglichkeiten ist im Grunde so groß wie das Potenzial, das in den gesammelten Daten steckt. Der Data-Mesh-Ansatz kann einfache Datenprodukte hervorbringen, die sehr nah an den Quelldaten sind. Aber auch komplexe Produkte, die aus Quelldaten mehrerer Quellen oder sogar anderen Datenprodukten zusammengesetzt sind.
Liegen nur die nackten Nutzdaten vor, braucht der User eine Anleitung, wie sie zu nutzen sind. Hier kann man zum Beispiel einen Data Catalogue einsetzen, in dem beschreiben ist, was die Daten konkret beinhalten, beziehungsweise wie sie zu interpretieren sind. Kann der Nutzer nicht selbstständig mit den Daten arbeiten, wirkt sich das negativ auf seine User Experience aus. Im Umkehrschluss gilt: Seine Erlebnisqualität steigt, wenn die Daten in einem gemeinsamen Standard vorliegen und ein standardisierter Zugriff möglich ist.
Die Datenprodukte selbst werden idealerweise auf einer gemeinsamen Data Mesh Platform bereitgestellt. Dort sind Standards definiert und die einfache Herstellung und Nutzung der Datenprodukte gewährleistet. Die in der Plattform befindlichen Daten müssen dazu nicht im Detail bekannt sein - dieses Wissen liegt bei den Daten-Produkt-Teams. Natürlich löst auch der Data-Mesh-Ansatz nicht alle Probleme moderner, vernetzter IT-Systeme. Aber er kann dem Data Lake eine Struktur geben, die eine gezielte Nutzung des ansonsten intransparenten Datensumpfs möglich machen.
Data-Mesh-Ansatz - Fachabteilungen einbeziehen
Ein Product Owner, der ein gutes, wertschöpfendes Produkt entwickelt hat, kann sich schnell mit Begehrlichkeiten im eigenen Unternehmen konfrontiert sehen. Denn sobald sich herumspricht, dass ein Bereich oder eine Abteilung aus den im Data Lake schlummernden Daten eine nutzbringende Anwendung gezaubert hat, steigt die Bereitschaft, sich mit diesen Möglichkeiten auseinanderzusetzen, um sie für die eigenen Zwecke zu nutzen.
Der nächste logische Schritt ist, die Fachabteilungen in die Lage zu versetzen, selbst Datenprodukte zu definieren, die ihnen weiterhelfen. Und diese dann - in der Regel mit anfänglicher Unterstützung eines bereits an anderer Stelle aktiven Data Product Owners - selbst zu entwickeln und zu pflegen. Auch diese klare Konzentration auf Datenprodukte ist nur dann erfolgreich, wenn alle Parteien dabei in Einklang sind. Dazu ist eine systematische Kommunikation zwischen Datenanbietern und Datennutzern erforderlich, um einerseits Bedürfnisse und Vorhaben und andererseits potenziell dafür nutzbare Daten miteinander abzustimmen.
Lesetipp: So bringen Sie IT und Fachabteilung unter einen Hut
Auf diese Weise lässt sich die Nutzung bislang unstrukturierter Daten systematisieren, das Unternehmen beginnt, kreativ mit den eigenen Daten umzugehen. Das Ergebnis können neue digitale Services und neue Wertschöpfungsmodelle sein. Sei es, dass sie "nur" einen internen Nutzen bringen - etwa in Form größerer Transparenz oder höherer Effizienz. Sei es, dass sie sich direkt im Zusammenspiel mit externen Kunden monetarisieren lassen. (bw)