Wie initiiert man ein Data Mesh? – Teil 3 – Ihre ersten Datenprodukte herstellen 

Die Literatur zum Data Mesh ist zwar umfangreich, beschreibt aber oft einen Endzustand und selten, wie man diesen in der Praxis erreicht. Es stellt sich also die Frage:

Welche Vorgehensweise sollten Sie wählen, um das Datenmanagement zu transformieren und ein Data Mesh einzurichten?

In dieser Artikelreihe finden Sie Auszüge aus unserem Praxisleitfaden Data Mesh, in dem wir ein iteratives Vorgehen für die Einführung eines Data Mesh in Ihrer Organisation vorschlagen. Dieser Ansatz basiert auf seinen vier Schlüsselprinzipien (Domain-oriented Decentralized Data Ownership and Architecture, Data as a Product, Self-serve Data Infrastructure as a Platform und Federated Computational Governance) und stützt sich auf die vorhandenen personellen und technologischen Ressourcen.

• Teil 1: Den Umfang Ihres Pilotprojekts definieren
• Teil 2: Das Entwicklungsteam und die Datenplattform für das Pilotprojekt zusammenstellen
• Teil 3: Ihre ersten Data Products herstellen
• Teil 4: Zu einem Federated-Governance-Modell übergehen

Im Laufe dieser Artikelreihe und zur Veranschaulichung dieses iterativen Vorgehens bei der Einrichtung eines Data Mesh werden wir ein Fallbeispiel verwenden: das fiktive Unternehmen Premium Offices – eine Gesellschaft für Gewerbeimmobilien, die Immobilien erwirbt und an Unternehmen vermietet.

–

In den ersten Artikeln der Reihe haben wir die Domänen identifiziert, einen ersten Use Case definiert und das Team zusammengestellt, das für die Entwicklung verantwortlich sein wird. Mit der Entwicklung der ersten Datenprodukte ist es an der Zeit, zum zweiten Prinzip des Data Mesh, Data as a Product, überzugehen.

Der produktorientierte Ansatz des Data Mesh

Im Laufe des letzten Jahrzehnts haben die Domänen sehr häufig bereits eine produktorientierte Kultur rund um ihre operativen Fähigkeiten entwickelt. Sie bieten sie dem Rest der Organisation in Form von APIs an, die konsumiert und zusammengestellt werden können, um neue Dienste und Anwendungen zu entwickeln. In manchen Organisationen sind die Teams darauf bedacht, den Entwicklern, die APIs in ihrem Bereich nutzen, die bestmögliche Erfahrung zu bieten: Suche in einem globalen Katalog, umfassende Dokumentation, Codebeispiele, Sandbox, garantierte und überwachte Service Levels und vieles mehr.

Diese APIs werden dann wie Produkte verwaltet, die entstehen, sich weiterentwickeln (ohne Kompatibilitätsbruch), erweitert werden und dann abgeschrieben werden, wobei sie in der Regel durch eine neue, modernere, leistungsfähigere und umfangreichere Version ersetzt werden.

Das Data Mesh schlägt vor, denselben produktbasierten Ansatz (Product-Thinking) auf Daten anzuwenden, die von den Domänen geteilt werden.

Die Eigenschaften eines Datenprodukts

In einigen Organisationen ist diese Produktkultur bereits fest verankert. In anderen muss sie weiterentwickelt oder sogar erst eingeführt werden. Aber lassen wir uns nicht täuschen:

Ein Datenprodukt ist kein neues digitales Gebilde, das neue technische Fähigkeiten erfordert (ähnlich wie ein API-Produkt). Es ist lediglich das Ergebnis einer bestimmten Art des Managements von Daten, die von einer Domäne für den Rest der Organisation zur Verfügung gestellt werden.

APIs wie ein Produkt zu verwalten, erforderte keinen technologischen Bruch: Die vorhandene Middleware erfüllte den Zweck sehr gut. Ebenso können Data Products problemlos auf bereits vorhandenen Dateninfrastrukturen jeglicher Art eingeführt werden.

Technisch gesehen kann ein Datenprodukt eine einfache Datei in einem Data Lake mit einer SQL-Schnittstelle sein; ein kleines Sternschema, das um einige Ansichten ergänzt ist, welche die Abfrage erleichtern, und in einer relationalen Datenbank instanziiert ist; oder eine API, eine Kafka-Streams-Bibliothek, eine Excel-Datei usw.

Ein Data Product wird also nicht dadurch definiert, wie es sich darstellt, sondern durch die Art und Weise, wie es konzipiert, verwaltet und gesteuert wird; und durch eine Reihe von Merkmalen, die seine breite Nutzung in der Organisation ermöglichen.

Diese Merkmale werden oft in dem Akronym DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure) zusammengefasst.

Um ein DATSIS-Datenprodukt zu erreichen, sind ebenfalls keine großen Investitionen erforderlich. Es geht darum, eine Reihe globaler Konventionen festzulegen, an die sich die Domänen halten müssen (Benennung, unterstützte Protokolle, Zugriffs- und Berechtigungsverwaltung, Qualitätskontrollen, Metadaten usw.). Die operative Umsetzung dieser Konventionen erfordert in den allermeisten Fällen keine neuen technologischen Fähigkeiten – die vorhandenen Lösungen reichen in der Regel aus, um loszulegen.

Eine Ausnahme ist jedoch der Katalog. Er spielt eine zentrale Rolle bei der Einführung des Data Mesh, da er es den Domänen ermöglicht, Informationen über ihre Data Products zu veröffentlichen, und den Konsumenten, diese Datenprodukte zu finden, zu durchsuchen, zu verstehen und zu nutzen.

Best Practices für die Gestaltung eines Datenprodukts

Die Gestaltung eines Datenprodukts ist natürlich keine exakte Wissenschaft – man kann ein einziges Produkt herstellen, aber auch drei oder vier. Als Leitfaden bei dieser Entscheidung ist es wiederum hilfreich, einige Best Practices aus verteilten Architekturen zu nutzen – ein Datenprodukt muss:

Erfahrung bei der Entwicklung von Datenprodukten

Die Entwicklererfahrung ist ebenfalls ein grundlegender Aspekt des Data Mesh, mit dem Ziel, die Entwicklung von Datenprodukten und die Entwicklung von Dienstleistungen oder Softwarekomponenten zusammenzuführen. Es geht nicht nur darum, freundlich zu den Engineers zu sein, sondern auch darum, eine gewisse wirtschaftliche Rationalität zu erfüllen:

Die Dezentralisierung des Datenmanagements bedeutet, dass die Domänen über eigene Ressourcen zur Entwicklung von Datenprodukten verfügen. In vielen Organisationen ist das zentrale Datenteam nicht groß genug, um verteilte Teams zu versorgen. Für den Erfolg des Data Mesh ist es daher unerlässlich, auf den oftmals größeren Pool an Softwareingenieuren zurückgreifen zu können.

Der Stand der Technik in der Softwareentwicklung beruht auf einem sehr hohen Automatisierungsgrad: deklarative Zuweisung von Infrastrukturressourcen, automatisierte Unit- und Integrationstests, orchestrierter Aufbau und Einsatz über CI/CD-Tools, Git-Workflows zur Verwaltung von Quellen und Versionen, automatische Veröffentlichung der Dokumentation usw.

Die Entwicklung von Datenprodukten muss auf diesen Stand der Technik zusteuern – und je nach Reifegrad der Organisation, der Reife ihrer Teams und ihres Technologie-Stacks wird diese Konvergenz mehr oder weniger lange dauern. Der richtige Ansatz besteht darin, so viel wie möglich zu automatisieren und dafür bereits vorhandene und bekannte Tools zu nutzen, und dann zu ermitteln, welche Vorgänge noch nicht automatisiert sind, um nach und nach zusätzliche Tools zu integrieren.

In der Praxis besteht ein Datenprodukt aus folgenden Elementen:

1. Zunächst einmal dem Code – für die Pipelines, die das Datenprodukt mit Daten aus verschiedenen Quellen oder anderen Datenprodukten versorgen; für mögliche APIs zur Nutzung des Datenprodukts; zum Testen der Pipelines und zur Überwachung der Datenqualität usw.

2. Aus Daten, natürlich – aber meistens sind die Daten in den Systemen vorhanden und werden nur von den Pipelines extrahiert und umgewandelt. Sie sind daher nicht im Quellcode vorhanden (außer in Ausnahmefällen).

3. Aus Metadaten – von denen einige dazu dienen, das Datenprodukt zu dokumentieren: Schema, Semantik, Syntax, Qualität, Lineage usw. Andere sollen die Governance des Produkts auf Mesh-Ebene sicherstellen – Verträge, Verantwortlichkeiten, Zugriffsrichtlinien, Nutzungsbeschränkungen usw.

  FALLBEISPIEL PREMIUM OFFICES

Um einen vorläufigen Rahmen für die Governance seines Data Mesh festzulegen, hat Premium Offices die folgenden Regeln aufgestellt:

✅ Ein Datenprodukt wird in BigQuery durch ein dediziertes Projekt dargestellt – dadurch ist es möglich, Zugriffsregeln auf Projektebene oder bei Bedarf auch feiner festzulegen. Diese Projekte werden in einem Repository namens „Data Products“ und einem Unterverzeichnis mit dem Namen der Domäne, zu der sie gehören (in unserem Beispiel „Brokerage“), abgelegt.

✅ Datenprodukte müssen Ansichten für den Zugriff auf die Daten anbieten – diese Ansichten ermöglichen es, eine stabile Schnittstelle für die Nutzung anzubieten und das interne Modell des Produkts potenziell weiterzuentwickeln, ohne seine Konsumenten zu beeinträchtigen.

✅ Alle Datenprodukte müssen die Daten mithilfe gemeinsamer Referenzen für gemeinsame Daten (Kunden, Produkte, Lieferanten, Mitarbeiter usw.) identifizieren – dies soll die Verknüpfung von Daten aus verschiedenen Datenprodukten (LEI, Produktcode, UPC, EAN, E-Mail-Adresse usw.) vereinfachen.

✅ Der Zugriff auf Datenprodukte erfordert eine starke Authentifizierung, die auf den IAM-Fähigkeiten von GCP beruht – die Verwendung eines Service-Kontos ist möglich, aber jeder Nutzer eines Datenprodukts muss dann über ein eigenes Service-Konto verfügen. Wenn die Zugriffsrichtlinien vom jeweiligen Benutzer abhängen, muss die Identität des Endbenutzers über eine OAuth2-Authentifizierung bestätigt werden.

✅ Standardmäßig wird nur der Zugriff auf die Ansichten gewährt – und nicht auf das interne Modell.

✅ Zugriffsanfragen werden vom Data Product Owner mithilfe von Workflows bearbeitet, die in Service Now eingerichtet wurden.

✅ DBT ist das bevorzugte ETL zur Implementierung von Pipelines – jedes Data Product hat ein dediziertes Repository für seine Pipeline.

✅ Ein Datenprodukt muss seinen Vertrag festlegen – Häufigkeit der Datenaktualisierung, Qualitätsstufen, Klassifizierung der Informationen, Zugriffsrichtlinien, Nutzungseinschränkungen.

✅ Ein Datenprodukt kann entweder über das JDBC-Protokoll oder über die BigQuery-APIs (schreibgeschützt) konsumiert werden.

✅ Das Datenprodukt muss seine Metadaten und seine Dokumentation auf einem Marktplatz veröffentlichen – mangels eines bestehenden Systems beschließt Premium Offices, seine ersten Data Products in einem speziellen Bereich seines Unternehmenswikis zu dokumentieren.

Dieser erste Satz von Regeln wird natürlich weiterentwickelt werden müssen, aber er definiert einen ersten pragmatischen Rahmen, um die DATSIS-Merkmale von Datenprodukten zu gewährleisten und nutzt dazu ausschließlich bereits vorhandene Technologien und Kompetenzen. Für sein Pilotprojekt entschied sich Premium Offices dafür, die Architektur auf zwei Datenprodukte aufzuteilen:

• Tenancy analytics dieses erste Datenprodukt bietet Analysefunktionen für Mietverträge – Einheit, Muttergesellschaft, Standort der Immobilie, Beginn des Mietvertrags, Ende des Mietvertrags, Art des Mietvertrags, Höhe der Miete usw. Es wird in Form eines kleinen Sterndiagramms modelliert, das die Analyse nach zwei Dimensionen ermöglicht: Zeit und Mieter – das sind die Analysedimensionen, die für den Aufbau der ersten Version des Dashboards benötigt werden. Es umfasst auch eine oder zwei Ansichten, die das Sternschema nutzen, um voraggregierte Daten bereitzustellen – diese Ansichten bilden die öffentliche Schnittstelle des Data Products. Schließlich enthält es noch eine Ansicht, mit der die aktuelle Liste der Mieter abgerufen werden kann.

• Entity ratings – dieses zweite Datenprodukt liefert temporale Bewertungen der Einheiten in Form eines einfachen Datensatzes und einer gespiegelten Ansicht, die als Schnittstelle dient und den gemeinsamen Regeln entspricht. Das Rating wird von einem spezialisierten Anbieter bezogen, der es über APIs zur Verfügung stellt. Um diese API aufzurufen, muss eine Liste von Einheiten bereitgestellt werden, die über die entsprechende Schnittstelle des Datenprodukts Tenancy Analytics erzeugt wird.

In unserem letzten Artikel dieser Reihe werden wir uns mit dem vierten und letzten Prinzip des Data Mesh beschäftigen: Federated Computational Governance.

Praxisleitfaden Data Mesh: Ein unternehmensweites Data Mesh einrichten und überwachen

Dieser Leitfaden von Guillaume Bodet, Mitbegründer und CPTO von Zeenea, vermittelt Ihnen einen praktischen Ansatz zur Implementierung eines Data Mesh in Ihrer Organisation und hilft Ihnen:

✅ Ihren Data-Mesh-Ansatz mit einem fokussierten Pilotprojekt zu starten,

✅ effektive Methoden kennenzulernen, um Ihr Data Mesh zu skalieren,

✅ die entscheidende Rolle eines internen Data Marketplaces zu verstehen, um die Nutzung von Datenprodukten zu erleichtern

✅ zu verstehen, was Zeenea als robustes, unternehmensweites Data-Mesh-Monitoring-System auszeichnet.