Wie initiiert man ein Data Mesh? – Teil 4 – Zu einem Federated-Governance-Modell übergehen

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, das Team zusammengestellt, das für die Entwicklung verantwortlich sein wird und unsere ersten Data Products erstellt. Jetzt ist es an der Zeit, zum letzten Prinzip des Data Mesh, der Federated Computational Governance, überzugehen.

Was ist Federated Computational Governance?

Federated Computational Governance verweist auf ein Governance-System, bei dem die Entscheidungsprozesse auf mehrere Einheiten oder Organisationen verteilt sind, wobei computergestützte Algorithmen und verteilte Technologien eingesetzt werden. In diesem System ist die Entscheidungsgewalt dezentralisiert, wobei jede teilnehmende Einheit ein gewisses Maß an Autonomie behält, während alle innerhalb eines größeren Rahmens zusammenarbeiten. Federated Governance beruht auf den folgenden Merkmalen:

• Dezentralisierung: Die Entscheidungsbefugnis wird auf mehrere Einheiten verteilt, anstatt sie in einer zentralen Stelle zu konzentrieren.

• Algorithmen: Algorithmen spielen eine bedeutende Rolle in Governance-Prozessen und helfen dabei, die Entscheidungsprozesse zu automatisieren, Regeln durchzusetzen und für Transparenz und Fairness zu sorgen.

• Ein kollaborativer Rahmen: Die Einheiten arbeiten innerhalb eines größeren Rahmens zusammen und teilen Ressourcen, Daten und Verantwortlichkeiten, um gemeinsame Ziele zu erreichen.

• Transparenz und Verantwortlichkeit: Die Verwendung von Algorithmen und verteilten Registrys kann die Transparenz erhöhen, indem sie eine klare Aufzeichnung der Prozesse bietet und die Verantwortlichkeit der teilnehmenden Einheiten sicherstellt.

• Anpassungsfähigkeit und Resilienz: Föderierte computergestützte Governance-Systeme sind so konzipiert, dass sie anpassungsfähig und belastbar sind, sich weiterentwickeln und auf Veränderungen in der Umgebung oder auf die Bedürfnisse der Teilnehmer reagieren können.

Die Herausforderungen einer Federated Governance im Data Mesh

Dieses letzte Prinzip des Data Mesh, die Federated Computational Governance, bedeutet, dass ein zentrales Organ die Regeln und Richtlinien festlegt, an die sich die Domänen halten müssen. Lokale Verantwortliche sind dafür zuständig, diese Regeln in ihrem Bereich umzusetzen und dem Zentralorgan die Compliance nachzuweisen – meist in Form von Berichten.

Obwohl das Modell im Prinzip einfach ist, scheitert seine Umsetzung oft an der internen Kultur. Dies ist insbesondere in stark regulierten Branchen der Fall, in denen zentralisierte Governance-Teams nur ungern alle oder einen Teil der Kontrollen delegieren, für die sie bisher verantwortlich waren.

Federated Governance trifft auch selten auf eine günstige Realität in der Praxis: Die Data Governance ist stark mit dem Risikomanagement und der Compliance verknüpft, zwei Bereichen, die bei den operativen Teams selten Begeisterung hervorrufen.

Daher ist es schwierig, die lokalen Verantwortlichen zu identifizieren oder bestimmte Aspekte der Governance auf die Data Product Owner zu übertragen – von denen die meisten bereits ein neues Aufgabenfeld erlernen müssen. Es ist daher wahrscheinlich, dass in den meisten großen Unternehmen die föderale Struktur vom Zentralorgan emuliert und dann allmählich und mit fortschreitender Reife in den Domänen eingeführt wird.

Um eine Kostenexplosion bei der Governance oder deren Fragmentierung zu vermeiden, prognostiziert Dehghani, dass die Datenplattform mit der Zeit ganze Bereiche der Governance automatisch übernehmen kann.

Automatisierbare Aspekte einer föderierten Governance

Wir bei Zeenea sind der festen Überzeugung, dass Automatisierung diese Herausforderung in mehrfacher Hinsicht bewältigen kann:

Der Weg ist natürlich lang, aber die Dezentralisierung erlaubt sehr iterative Fortschritte, Domäne für Domäne, Produkt für Produkt. Und rufen wir uns auch in Erinnerung, dass jeder Fortschritt bei der Automatisierung der Governance, egal in welcher Hinsicht, auf der Erzeugung und Verarbeitung von Metadaten beruht.

  FALLBEISPIEL PREMIUM OFFICES

Bei Premium Offices hat das Data Office eine sehr defensive Governance-Kultur – da das Unternehmen auf dem Kapitalmarkt tätig ist, unterliegt es einer Reihe von strengen gesetzlichen Vorschriften.

Im Rahmen des Pilotprojekts wurde beschlossen, das Governance-Framework unangetastet zu lassen. Qualität und Nachvollziehbarkeit bleiben in der Zuständigkeit des Data Office und werden im Nachhinein mit dessen Werkzeugen und Methoden bearbeitet. Auch die Zugriffskontrolle wird in dessen Verantwortung fallen – ein Prozess ist bereits in Form eines ServiceNow-Workflows eingerichtet (das Einrichten von Berechtigungen in BigQuery erfordert mehrere manuelle Arbeitsschritte sowie Überprüfungen). Als einziges Zugeständnis wird der Workflow so geändert, dass die Zugriffsanfragen vom Data Product Owner überprüft werden, bevor sie vom Data Office freigegeben und bearbeitet werden. Ein erster kleiner Schritt in Richtung Federated Governance.

Auf der Metadatenseite müssen die neuen Tabellen und Ansichten in BigQuery auf konzeptueller und physischer Ebene im zentralen Datenkatalog dokumentiert werden (der den Begriff Data Product nicht kennt). Es handelt sich um einen deklarativen Prozess, den das Pilotteam bereits kennt. Das Tagging der Spalten wird gegebenenfalls nach der Auswertung durch das Data Office durchgeführt.

Ansonsten wird die Benutzerdokumentation für die Datenprodukte in einem eigenen Bereich des internen Wikis veröffentlicht, das nach Domänen gegliedert ist, in dem man eine sehr umfangreiche und strukturierte Dokumentation schreiben kann und das über eine angemessene Suchmaschine verfügt.

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.