Stackable

Das Potenzial von Data Mesh [Whitepaper]

stackable-blog-header-blau-laptop

Welche Möglichkeiten bietet Data Mesh? Was hole ich mir damit überhaupt ins Haus und wie kann ein Data-Mesh-Projekt konkret ablaufen? Als Gegenentwurf zum klassischen DWH oder Data Lake ist Data Mesh bereits in aller Munde. Gemeinsam mit dem Bitkom e. V. durfte ich als einer der Autoren des Whitepapers „Data Mesh – Datenpotenziale finden und nutzen“ diese und viele weitere Fragen rund um das Thema betrachten. Meine Ausführungen zum Thema Architektur findest Du hier; den gesamten Leitfaden kannst Du Dir beim Bitkom e. V. kostenfrei herunterladen. 

Architektur

[…] Nachdem wir gelernt haben woher das Konzept des Data Mesh kommt, wollen wir nun in die konkrete Architektur einsteigen. Der wichtigste Punkt hierbei ist, dass es sich bei dem Data Mesh um ein »soziotechnologisches Paradigma« handelt. Hinter diesem sperrigen Wort verbirgt sich der Fakt, dass es bei einem Data Mesh nicht um eine rein technische Lösung, sondern um eine Kombination von Datenstrategie, Enterprise Architektur und Unternehmensorganisation geht. Technik spielt eine unterstützende, aber untergeordnete Rolle. Wir haben gelernt, dass das Data Mesh eine Lösung darstellt, um Bottlenecks zu umgehen und die Geschwindigkeit der Innovation innerhalb von Teams und Organisationen zu erhöhen bzw. wieder herzustellen. Ein zentraler Baustein dieser Architektur ist daher die konsequente Identifizierung und Entfernung dieser Bottlenecks indem möglichst viel Verantwortung in verteilte Teams gegeben wird, die trotzdem anhand von zentral definierten »Leitplanken« agieren. Dieser Gedanke mündet in einer logischen Architektur, welche auf vier Prinzipien aufbaut. 

Domain-oriented ownership

Die Verantwortung für Daten liegt nicht bei einem zentralen Team, sondern wird in die Hände der Teams gegeben, die am »nächsten« an den Daten arbeiten. Dies sind häufig – aber nicht immer – die Teams, die auch die Daten generieren. Damit unterscheidet sich ein Data Mesh grundlegend von vielen Data Lake oder Data-Warehouse-Projekten, in denen es Teams gibt, die sämtliche Daten entgegennehmen, säubern, strukturieren und speichern, aber selbst keine Experten der jeweiligen Domänen sind, aus welchen die Daten kommen. Diese Teams generieren daher häufig qualitativ nicht optimale Datensätze und tragen zur Trägheit des Systems bei. Das Team, welches die Daten bereitstellt, kümmert sich also um den gesamten Lebenszyklus. Nutzer sehen nur das Ergebnis – das Datenprodukt. Dies bringt uns zum nächsten Prinzip. 

Data as a Product

Wenn »Zeit Geld ist«, dann ist Datenanalyse heute eine Katastrophe. In der Literatur dokumentierten Übersichten zufolge werden heute mehr als 80% des Zeitbudgets eines Datenanalyseprojekts für die Datenaufbereitung aufgewendet – nicht etwa für die Entwicklung von Algorithmen. Dies würde das 80/20 Pareto-Prinzip, einen Eckpfeiler der Geschäftseffizienz, auf den Kopf stellen. Die Lösung: Daten wie Produkte behandeln und bewährte Ansätze, wie das Produktmanagement auf Daten anwenden. Es geht darum, die Daten als eigenständiges Produkt zu verstehen und nicht als Nebenprodukt einer anderen Tätigkeit. Zu einem Produkt gehört alles was nötig ist dieses bereit zu stellen: Daten, Metadaten, Code, Policies und ggf. Infrastruktur. Das Produkt muss autonom und damit eigenständig nutzbar sowie vom Anbieter mit einem Service Level versehen sein, welches eine verlässliche Nutzung garantiert. In anderen Bereichen der Softwareentwicklung findet immer häufiger ein Prinzip namens »Shift-Left« Anwendung. Damit ist gemeint, dass Aufgaben und Verantwortung näher an die Quelle rücken. Die wohl prominenteste Vertreterin dieses Prinzips ist die Art und Weise wie Softwareprodukte heute erstellt werden: DevOps erhöht die Geschwindigkeit, Stabilität sowie verbessert die Abstimmungsprozesse in der Softwareentwicklung. Dies geschieht durch eine Kombination der Entwicklung (»Development«) und dem Betrieb (»Operations«) in einem einzigen Team. Eine vergleichbare Entwicklung findet sich unter dem Begriff DataOps für Prozesse rund um das Datenmanagement und Maschinelles Lernen (MLOps) sowie der Security (DevSecOps) und auch beim Testen von Software.

Früher war es üblich, dass Entwicklungsabteilungen Produkte entwickelt und dann an Betriebsabteilungen übergeben haben. DevOps löst diese starre Verteilung auf. Das Data Mesh Prinzip dehnt diese Verschiebung der Verantwortlichkeiten nun auch auf die generierten Daten aus, welche Stand heute noch sehr häufig von zentralen Teams verwaltet werden. Die Daten und deren Nutzbarkeit als eigenständiges Produkt werden zurückgeholt zu den Teams, die die Daten produzieren und es liegt in deren Verantwortung, ein vernünftiges Datenprodukt zu bauen. Um dies in der Organisation zu verankern, sind neue Rollen hilfreich: »Domain Data Product Owner« und »Data Product Developer«, welche die Verantwortung für ein Datenprodukt tragen. Dieses Prinzip ist eng verwandt mit dem vorherigen – Domain Ownership. Während es dort um die Zuständigkeiten und deren Dezentralisierung ging, geht es hier darum Daten als echtes Produkt zu sehen, wie z. B. Softwareartefakte zuvor. Dies führt häufig zu einem Mehraufwand in den jeweiligen Teams welches weitere Fragen aufwirft. Zum Beispiel wer für die dafür entstehenden Kosten aufkommt. Ein Produkt sollte diese Anforderungen erfüllen: Es muss auffindbar (»discoverable«), verständlich (»understandable«), adressierbar (»addressable«), sicher (»secure«), interoperabel (»interoperable & composable«), vertrauenswürdig (»trustworthy«), einfach und nativ abrufbar (»natively accessible«) und eigenständig nutzbar (»valuable on its own«) sein. Viele dieser Anforderungen können durch Technologie erreicht oder unterstützt werden, womit wir zum dritten Prinzip kommen.

Self Service Data

Platform und Data Factories Beim Lesen der vorherigen Punkte mögen Bedenken vor einer Vervielfachung von Wissen, Infrastruktur und Daten aufkommen. Auch gibt es Sorgen über den Fachkräftemangel, denn es klingt als bräuchte jedes Team genügend Fachleute, um den gesamten Lebenszyklus eines Datenproduktes abzudecken. Das ist allerdings nicht der Fall: Ein zentrales Infrastrukturteam sollte die nötigen Tools und Standards in Form einer Plattform bereitstellen, um es nicht spezialisierten Mitarbeitenden zu ermöglichen, die notwendigen Pipelines und Verarbeitungsschritte selbst auszuführen. Dazu gehören auch Querschnittsfunktionalitäten wie Monitoring und Logging, genauso wie gemeinsame API Standards und Protokolle. Dieser »as-a-Service« Gedanke sollte unbedingt in Kombination mit einem »as Code« Ansatz verbunden werden: Die Möglichkeit, Infrastruktur als Programmcode bereitzustellen, oft innerhalb weniger Minuten, ermöglicht eine neue Flexibilität bei der Herstellung von Datenprodukten.
Es handelt sich hier aber tatsächlich ausschließlich um die Zurverfügungstellung der Plattform sowie von Wissen. Nicht aber um eine konkrete Umsetzung – diese liegt, wie erwähnt, bei den Fachteams selbst.

Durch diese Trennung der Aufgaben ist es nicht nötig, toolspezifische Experten in jedem Team zu haben, es reichen stattdessen geschulte Anwender dieser Tools. Ziel sollte es sein, über typische SaaS/IaaS/PaaS-Angebote hinweg Data Mesh spezifische Produkte anzubieten. Hierbei kann es sich um Möglichkeiten handeln, Datenprodukte in einem zentralen Katalog zu registrieren oder die Überwachung von Datenqualität zu automatisieren. Dadurch, dass Data Mesh noch relativ neu ist, gibt es hier noch einige Lücken in den verfügbaren Angeboten. Einige technische und nicht-technische Themen hingegen, lassen sich aufgrund Ihrer Art nicht komplett in die einzelnen Teams auslagern, womit wir zum vierten und
letzten Prinzip kommen. Ein eleganter Lösungsansatz für die Organisation der Erstellung von Datenprodukten ist der Wechsel von Handarbeit hin zu industrialisierten Verfahren, so wie auch bei anderen Produkten und Konsumgütern – den sogenannten Data Factories (Schlueter Langdon und Sikora 2020). Im Kern geht es um die Zergliederung des Konversionsprozesses von Rohdaten zu Datenprodukten in Kernverfahrensschritte und deren Automatisierung.

Federated Computational Governance

Es gibt einige Aufgaben, die immer zentral gesteuert werden sollten. Ein Beispiel hierfür sind die typischen Vorgaben der Rechtsabteilungen zum Thema Datenschutz oder sensiblen Daten im Allgemeinen. Auch die (Daten-)Sicherheit sowie automatisierte Tests und Monitoring gehören häufig dazu. Dafür bietet es sich an ein föderiertes Team aufzubauen, welches aus Mitgliedern aller Abteilungen besteht (Domänen-/Fachabteilungen, Rechtsabteilung, Sicherheit usw.). Dieses Team ist dafür zuständig, zentrale Regeln zu definieren und ggf. Vorgaben für Automatismen zu machen. Die einzelnen Produktteams hingegen sind für ihre lokale Governance verantwortlich, welches z.B. auch Autorisierungsregeln auf die Datenprodukte beinhaltet. Um diese beiden Komponenten – die lokale und globale Governance – zu verzahnen, bietet es sich an, möglichst viel auf »as code« Ansätze zu bauen. In diesem Falle also »Policy as Code« oder »Security as Code«.

Zusammenfassung

Diese vier Prinzipien sind dafür gedacht, zusammen genutzt zu werden – einzeln umgesetzt sind sie nicht ausreichend, um die Ziele zu erfüllen. Jedoch komplementieren sie sich. Zusammengenommen sind diese vier Prinzipien hingegen hinreichend. Eine umfassende Landschaft zur Verarbeitung von analytischen Daten umfasst mehrere Komponenten, welche von unterschiedlichen Rollen in der Organisation wahrgenommen werden. Die logische Architektur eines Data Mesh stellt sich beispielhaft wie unten abgebildet dar:

Logische Architektur (Quelle: Nach Microsoft via Ralph Kemperdick)

Zusammen umgesetzt, erlauben diese vier Prinzipien eine dezentrale Verarbeitung und Zurverfügungstellung von Daten, was es erlaubt, schneller auf Änderungen oder neue Anforderungen zu reagieren. Ein Data Mesh umzusetzen, bedeutet Änderungen in der Organisation zu erlauben und zu implementieren. Es kann zur Auflösung vorhandener Teams kommen, zu neuen Aufgaben in vorhandenen Teams, Budgetfragen müssen geklärt werden und vieles mehr. Auch darf nicht vergessen werden, dass Data Meshes noch sehr neu sind (2018) und es noch einige ungeklärte Fragen und technische Lücken gibt.
In der Tat werden mit der Erzeugung von Datenprodukten und deren Bereitstellung sowie Katalogisierung zum schnellen Auffinden/Verstehen Datensilos verhindert. Nichtsdestotrotz sind auch Datenprodukte ihrerseits domain-spezifisch und lassen häufig keine Verbindung mit anderen Datenprodukten zu. Dennoch hebt erst die Kombination von mehreren Datenprodukten das eigentliche Potential, dass in den
Daten liegt. Das Datenprodukte ihrerseits Silos darstellen können liegt daran, dass die Datenprodukt-Owner oft keine domain-spezifischen Kenntnisse über die anderen Datenprodukte besitzen. Folglich muss es ein zentrales (Cross-)Team geben, dass nunmehr Kenntnis von mehreren Datenprodukte besitzt und Verbindungen/Überführungen durch das Erzeugen von neuen Kombi-Datenprodukten herstellt. Eine andere Option wäre es, dass man ein übergeordnetes Domain-Model zwischen den Data Products schafft, das eine Überführung/Austausch von Daten aus unterschiedlichen Domänen schafft, wozu wieder ein zentrales Cross-Team erforderlich ist. Die Dezentralisierung des Data Mesh hat also seine Grenzen, wenn es um die Definition übergeordneter Gemeinsamkeiten/Mapping der Datenprodukte geht, welche bei der Implementierung eines Data Mesh bedacht werden müssen.


Du möchtest mehr zum Thema erfahren? Dann lade Dir hier den gesamten Bitkom-Leitfaden kostenfrei herunter:

© Bitkom e. V. sowie die Autoren des Leitfadens:
Sebastian Baumann | DATAbility
Stephan Bautz, Ronny Garz, Goran Loncar | PwC
Ralf Böhme | MT AG
Lukas Feuerstein, Martin Günther | Deloitte Consulting
Lars Francke | Stackable
Carsten Fritsch | Deutsche Bahn
Rüdiger Karl | SAP
Ralph Kemperdick | Microsoft
Niklas Lümmen | Eucon Group
Vaibhavi Rege | Allianz Direct
Dr. Nora Reich | KfW
Dr. Gerald Ristow | Software AG
Prof. Dr. Christoph Schlueter Langdon | Deutsche Telekom
Dominik Schneider | Merck Group
David Schönwerth | Bitkom
Dr. Thomas Vollmer | Philips
Dr. Sebastian Werner | Dataiku

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Copy link
Powered by Social Snap