Data Mesh: Entwicklungsteams heben Datenschätze

Inhaltsverzeichnis

In den Daten operativer IT-Systeme liegen wertvolle Informationen, die Aussagen zum Verhalten der Nutzerinnen und Nutzer zulassen und helfen können, das Softwaresystem genauer zu verstehen. Softwareentwicklerinnen und -entwickler verzichten aber oft auf Datenanalysen im Rahmen ihrer Projekte. Auch für viele Projektmanager und Product Owner spielen Daten bei der Bewertung von Features und User Stories eine untergeordnete Rolle, vor allem, weil diese kaum in analytisch aufbereiteter Form vorliegen.

Daten werden traditionell bereits im großen Stil von Daten-Teams in Data-Warehouse-Systemen und Data Lakes gesammelt und ausgewertet. Doch bei deren Auswertung sind meistens Unternehmenssteuerung und Marketing im Blick, eher selten jedoch die Teams, die neue Features entwickeln. Die Ergebnisse dieser Auswertungen sind zudem häufig enttäuschend. Ursachen dafür dürften meist die unzureichende Datenqualität der angeschlossenen Quellsysteme und mangelnde Fachkenntnisse zur Interpretation dieser Daten durch zentral organisierte Daten-Teams sein. Zudem skalieren solche zentralen Systeme und Teams nicht ausreichend schnell mit den stetig wachsenden Datenanalyseanforderungen.

Data Mesh ist ein relativ neuer, dezentraler Datenarchitekturansatz, der es Entwicklungsteams ermöglichen soll, selbstständig domänenübergreifende Datenanalysen durchzuführen und so das Verhalten ihrer Nutzerinnen und Nutzer und der Systeme besser zu verstehen. Mit dem Bereitstellen kuratierter Daten für andere Teams entsteht ein wertvolles dezentrales Datennetzwerk.

Modularisierung auch in der Datenarchitektur

In der Softwareentwicklung sind in den letzten Jahren maßgebliche Fortschritte zu verzeichnen: strategisches Domain-Driven Design (DDD) hilft, die fachliche Funktionalität in einem System zu organisieren und abzubilden. Es lassen sich klare Verantwortlichkeiten einzelner Domänen bestimmen und beispielsweise mittels Context Mapping die soziotechnischen Zusammenhänge und Schnittstellen erkennen und beschreiben.

Autonome Produktteams in der Aufbauorganisation übernehmen die Verantwortung für genau eine abgegrenzte Domäne und erhalten im Gegenzug ein hohes Maß an Freiheiten, von der Wahl der Programmiersprachen bis hin zum Team-Staffing. Diese Teams bauen folglich Softwaresysteme, die den fachlichen Scope ihres Bounded Context abbilden. Sie nutzen dazu modulare Softwarearchitekturansätze wie Microservices (in dem von Sam Newman bereits 2015 formulierten Sinne) oder Self-contained Systems, um monolithische Systeme zu vermeiden und Qualitätsziele, etwa nach Zuverlässigkeit und Wartbarkeit, bestmöglich umzusetzen. Das Zusammenspiel mit anderen Domänen erfolgt über klar definierte Schnittstellen, möglichst asynchron als Domain Events, beispielsweise über Apache Kafka oder HTTP-Feeds.

Das Aufsplitten monolithischer Strukturen in getrennte fachliche Domänen lässt sich nach dem Data-Mesh-Prinzip nun auch für Datenarchitekturen anwenden. Voraussetzung dafür ist eine Aufteilung der Teams anhand der fachlichen Grenzen. Anstelle eines zentralen Data Warehouse, das alle Daten zusammenführt und von einem Data Team verwaltet wird, führen Domänen-Teams analytische Auswertungen für ihre spezifische Domäne selbst durch und greifen auf Datensätze anderer Domänen über klar definierte Schnittstellen zu.

Die Prinzipien des Data Mesh

Den Begriff Data Mesh prägte 2019 erstmals Zhamak Dehghani in ihrem Beitrag "How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh". Die Definition umfasst typischerweise die folgenden vier Prinzipien:

• Domain Ownership
• Data-as-a-Product
• Self-serve Platform
• Federated Governance

Domain Ownership bedeutet, dass die für die operativen Systeme verantwortlichen Teams auch ihre analytischen Daten bereitstellen. Die Kernidee dahinter ist, dass Daten nur innerhalb ihres Bounded Context eine klar definierte Bedeutung haben und die jeweiligen Teams ihre eigenen Daten am besten kennen. Jedes Team entscheidet daher individuell, welche Daten von Bedeutung sind und wie diese für analytische Zwecke aufbereitet werden. Jedes Team übernimmt die volle Verantwortung für seine Daten.

Gemäß dem Prinzip Data-as-a-Product sollten analytisch relevante Daten so verwaltet und zugänglich sein, dass andere Teams einfach darauf zugreifen können. Die Daten unterliegen dabei dem üblichen Entwicklungsprozess innerhalb des Teams, von der Beschreibung einer User Story durch den Product Owner und einer verständlichen Dokumentation über den Datenzugriff und die Bedeutung der einzelnen Felder bis zur operativen Verantwortung, die beispielsweise das Monitoring einschließt. Das Team liefert mit seinen Daten dann einen Wertbeitrag für andere Teams.

Die Self-serve Data Platform beschreibt eine Datenplattform, die den Teams zum Bereitstellen analytischer Daten, Datenauswertungen und Visualisierungen sowie für den einfachen Zugriff auf Daten aus anderen Domänen dient. Dabei steht der Self-Service-Charakter im Vordergrund: Alle Aktivitäten sollen durchführbar sein, ohne dass ein anderes Team eingreifen muss.

Unter Federated Governance versteht man domänenübergreifende Vereinbarungen, die regeln, wie sich das Zusammenwirken effizient gestalten und die Qualität der Datenlandschaft langfristig gewährleisten lässt. Vertreter der Domänen definieren dazu gemeinsam die notwendigen Global Policies (vergleiche Makro-Architektur-Richtlinien), die für Interoperabilität und Sicherheit erforderlich sind. Auf einer höheren Ausbaustufe lässt sich das Einhalten dieser Regeln auch automatisiert durch die Plattform sicherstellen.

Diese Prinzipien sind geeignet, um die Verantwortung in dezentralen Datenarchitekturen zu beschreiben, aber was bedeuten sie für Softwareentwicklerinnen und -entwickler in den Domänen-Teams?