vorheriger Artikel
Data Mesh ist das aktuelle technische, organisatorische Konzept, um in großen Data-&-Analytics-Organisationen mehr Business-Nähe und mehr Skalierung zu ermöglichen. Eine konsequente Umsetzung ist revolutionär und erfordert Change-Management.
Die Nutzung von Daten
Die Nutzung von Daten gewinnt in allen Branchen zunehmend an Bedeutung, deshalb sind vielerorts die entsprechenden Organisationen gewachsen. Was vor 20 Jahren nur mit Hilfe von Spezialist:innen verwendet werden konnte, wird mittlerweile von vielen Personen in unterschiedlichen fachlichen Funktionen genutzt. Die klassischen, zentralen Organisationen sehen sich dadurch mit zahlreichen Herausforderungen konfrontiert. In einer LinkedIn-Umfrage (ohne Anspruch auf Repräsentativität) habe ich meine Follower befragt, was ihrer Meinung nach die größte Herausforderung in großen Data-&-Analytics-Organisationen ist. So war die vorherrschende Meinung, dass die Nähe zum Business als größte Herausforderung angesehen wird und es bedeutend ist, nahe an den geschäftskritischen Fragestellungen zu sein. Dieses Ergebnis bestätigt meine persönliche Einschätzung und zeigt, wie wichtig die Anwendung der Erkenntnisse aus Data & Analytics in den geschäftsrelevanten Prozessen ist.
Die Idee von Data Mesh
Data Mesh beruht auf der Idee, dass die Daten eines Unternehmens nicht länger von einer zentralen Datenabteilung verwaltet werden, sondern von dezentralen Teams, welche die Daten produzieren und nutzen. Damit das funktionieren kann, wurden vier Prinzipien etabliert:
- Domain Ownership – dezentralisierte und verteilte Verantwortung:
Jedes dezentrale, fachliche Team hat das Recht und die Verantwortung, seine eigenen Daten zu definieren, zu sammeln, zu speichern, zu pflegen und zu veröffentlichen. Das bedeutet, dass jedes Team dazu in der Lage sein sollte, seine Datenprodukte unabhängig zu verwalten und entscheiden zu können, wie sie von anderen Teams innerhalb des Unternehmens genutzt werden können.
- Data as a Product – Product Thinking für Daten:
Für Marty Cagan müssen Produkte wertvoll, nutzbar und machbar sein. Dies gilt auch für Datenprodukte. Darüber hinaus sollen sie wie Softwareprodukte entwickelt, getestet, dokumentiert, bereitgestellt und gewartet werden.
- SelfService-Dateninfrastruktur als Plattform:
Um die dezentralen Teams bei der inhaltlichen Arbeit mit Daten zu unterstützen, wird von einem zentralen Team eine Plattform zur Verfügung gestellt, die technische Aspekte wie DatenDiscovery, Datenintegration, API-Management, Datenqualitätskontrollen und Monitoring übernimmt.
- Verteilte, automatisierte Governance:
Wegen der grundsätzlich dezentralisierten Verantwortung für die Datenprodukte muss auch die Verantwortung für die Governance dezentral wahrgenommen werden. Um sich nicht ausschließlich auf organisatorische Anweisungen zu verlassen, werden verschiedene Aspekte automatisiert. Security und Datenschutz sind dafür die ersten Kandidaten.
Data Mesh adressiert genau diese Nähe zum Business durch Dezentralisierung und anwendungsspezifische Datenprodukte. Dabei gibt es nicht nur Citizen-Data-Analysten, die dezentral Auswertungen durchführen, sondern auch IT-affine Business-Analysten für dezentrales Data Engineering. Überdies wurde der Holy Grail «Single Source of Truth» mit zentralem integrierten Datenmodell und zentraler Governance angestrebt. Beide Komponenten fallen weg. Verlieren wir damit die «Single Source of Truth»? Sind wir uns dessen bewusst? Sind wir dafür bereit? Meiner Einschätzung nach streben wir einen höheren Grad an «Truth» an. Eine businessnahe Wahrheit, welche für die Geschäftsprozesse unmittelbar genutzt werden kann.
Aktualität von Data Mesh
Aktuell sehe ich Data Mesh besonders für größere Organisationen als relevant an. Kleinere Unternehmen eignen sich im Moment für ein zentrales Modell sehr gut.
- Sie bündeln die kritischen Skills in einem Team.
- In einer kleinen Organisation kann bei einem zentralen Team die Nähe zum Business garantiert werden.
- Ein kleines zentrales Team hat noch nicht die Koordinationsprobleme bzw. den Overhead wie große zentrale Teams.
Je besser die technische Unterstützung wird, desto relevanter wird Data Mesh auch für kleinere Organisationen. Es ist eine Frage der Zeit.
Im März war ich als Moderator bei einem Google-Event zum Thema Data Mesh. Gemeinsam mit Dr. Anna Hannemann und Peter Kühni waren zwei interessante, erfahrene Referent:innen dabei und 30 Kund:innen diskutierten engagiert über ihre Erwartungen und Herausforderungen im täglichen Umgang mit Data Mesh. Ganz klar versprechen sich viele von Data Mesh, das Wachstum besser bewältigen und weiter an Relevanz gewinnen zu können. Die Herausforderung ist die Komplexität, die Data Mesh mit sich bringt, da Konsistenz über verschiedene Teams, mehr Kommunikation und mehr technische Unterstützung gefordert werden. Für die technische Unterstützung sind bereits erste Werkzeuge auf dem Markt erhältlich, die aber noch nicht etabliert sind und sich komplex präsentieren.
Data Mesh Methodology by b.telligent
Deshalb hat b.telligent den Ansatz von Zhamak Dehghani aufgenommen und mit dessen Hilfe bereits bei unterschiedlichen Kunden Umsetzungserfahrung sammeln können. Es hat sich eine Methodik entwickelt, die dem bewährten Change Management Approach folgt und sich wie folgt darstellt: «Awareness -> Desire -> Knowledge -> Ability -> Reinforcement». Sie wird genutzt, um nachhaltige Veränderungen zu ermöglichen. Entlang dieses Approachs gibt es verschiedene Unterstützungsmöglichkeiten, von initialen Workshops mit dem Management-Team bis hin zu technischen Umsetzungsunterstützungen. Dadurch können wir maßgeschneidert auf die unterschiedlichen Kundenbedürfnisse eingehen.
Dieser Blogbeitrag ist der erste Teil einer Reihe zum Thema Data Mesh. An dieser Stelle auch vielen Dank an meine Kollegen Sergej Kaiser, John Held und Peter Kühni für den Input und Review dieses Beitrags.
Melde Dich bei uns, wenn Du das Konzept von Data Mesh in Deinem Unternehmen gewinnbringend einsetzen möchtest.
