Data Mesh Architekturen – Wie viel Datenfreiheit darf es sein?

Data Mesh ist das neue Buzzword unter Datenprofis. Und plötzlich fragen sich alle: Brauche ich das jetzt auch? Tatsächlich gibt es darauf keine pauschale Antwort. Ob und in welchem Umfang der Einsatz der innovativen Datenarchitektur sinnvoll ist, hängt von der Ausgangssituation und den Zielen des jeweiligen Unternehmens ab. Das Data Mesh Paradigma in Reinform beispielweise, dürfte für die meisten IT Abteilungen derzeit kaum praktikabel sein. Hingegen kann ein Data Mesh Ansatz in „kleineren“ Ausbaustufen auch heute schon einen konkreten Mehrwert erzeugen.

So zeichnen sich in der Praxis gegenwärtig drei typische Data Mesh Architekturen ab:

1. Fully Governed Mesh
2. Fully Federated Mesh
3. Hybrid Mesh Federation

Die verschiedenen Ansätze unterscheiden sich vor allem im Grad der Dezentralisierung – das heißt: Die Verantwortung für Daten, Datenqualität und Datenprodukte wird mal mehr, mal weniger stark von den zentralen Data Engineers auf die Fachbereiche und interdisziplinäre Analyse-Teams verlagert. Wie sich die Data Mesh Architekturen im Einzelnen gestalten, wollen wir uns nun anschauen und dabei auch auf bevorzugte Einsatzgebiete eingehen.

1. Fully Governed Mesh

Das Fully Governed Mesh trägt die “Governance” nicht umsonst im Namen. Zwar arbeiten bei dieser Architektur bereits verschiedene Data Teams bzw. Domänen autark mit Daten. Allerdings existieren auch noch viele zentrale Komponenten, mit denen die Verteilung, Kompatibilität und Wiederverwendbarkeit der Arbeitsergebnisse – der Datenprodukte – gewährleistet wird.

Kern des Ansatzes bildet eine zentrale Cloud Datenplattform, wie Sie heutzutage in vielen Unternehmen bereits vorhanden ist. Sie bietet den Mesh-Teilnehmern domänenübergreifende Sicherheitsmaßnahmen sowie allgemein verfügbare Ressourcen, wie Speicher und Rechenleistung. Meist kommt ein „Multiple Workspaces Shared Lake“-Design zum Einsatz – das heißt: Jede Domäne besitzt ihren eigenen Workspace inklusive lokalem Storage für die Datenverarbeitung und Datennutzung. Gleichzeitig können die Teams aber auch auf den gemeinsamen Speicher der Datenplattform zugreifen, um sich mit den anderen Datenproduzenten auszutauschen.

Als Kontrollinstanz fungiert bei diesem Konzept ein zentrales Betriebsteam, das die Mesh Architektur gestaltet und weiterentwickelt. Es stellt den einzelnen Domänen eine vordefinierte Self Service Infrastruktur für die Erstellung ihrer Data Products bereit, die alle relevanten Standards etwa zur Konnektivität und häufig verwendeten Ressourcen beinhaltet. Das fertige Datenprodukt wird schließlich in die zentrale Plattform integriert und für alle Domänen und Datenkonsumenten zugänglich gemacht

Dieses hohe Maß an Kontrolle hat allerdings auch seinen Preis: Gerade einer der wichtigsten Benefits des Data Mesh Prinzips – nämlich die Beschleunigung der Time-to-Market – leidet darunter. Insbesondere, wenn die zentralen Instanzen nicht über ausreichend Kapazitäten verfügen, um Datenprodukte zu integrieren und zu aktualisieren. So kommt der Fully Governed Mesh vor allem bei Unternehmen zur Anwendung, deren Fokus auf Kontrolle, anstatt auf Agilität liegt, wie etwa dem Versicherungs- und Finanzsektor.

2. Fully Federated Mesh

Das Fully Federated Mesh ist vom Prinzip her das genaue Gegenteil des vorherigen Datenarchitekturansatzes – und damit am nächsten am „perfekten“ Data Mesh der Erfinderin Zhamak Dehghani. Agilität, Self Service und der direkte Austausch zwischen den Domain Teams sind hier das Maß aller Dinge. Mit großen Auswirkungen auf die zentralen Instanzen: Sie verwalten und verteilen nur noch Metadaten, die die grundlegenden Informationen zu Data Ownership und Data Products sowie Data Contracts und Sharing Agreements mit anderen Teams enthalten.

Hingegen liegt die Verantwortung für die Daten und Datenprodukte allein bei den Domains – und mit ihr alle erforderlichen Technologien zur Selektion, Transformation, Aufbereitung und Bereitstellung. Daher wird ein Datenprodukt insbesondere beim Fully Federated Mesh oftmals als „Architectural Quantum“ bezeichnet. Auch Schnittstellen für die Datensuche und das Monitoring werden über die domaineigene Self Service Dateninfrastruktur realisiert. Standards gibt es bei dieser Architektur nur in Hinsicht auf die Kompatibilität zu anderen Domains. Deshalb muss ein dezentralisiertes Team nicht nur über einen kompetenten Data Engineer verfügen. Ebenso werden Experten für die Datenarchitektur und Dateninfrastruktur benötigt.

Womit wir schon zu den besonderen Herausforderungen der „unverfälschten“ Data Mesh Denkweise gelangen: Unternehmen müssen eine technologische Expertise aufbauen, die am Arbeitsmarkt rar gesät ist. Und nicht nur das: In einer stark dezentralisierten Infrastruktur sind auch allgemeine Richtlinien für die Sicherheit, Kompatibilität und Entwicklung wesentlich schwerer zu verfolgen. Zudem erleben Fragen zur Datenredundanz und Zugriffsberechtigung mit den altbekannten Begleiterscheinungen ein unerwartetes Comeback.

So sind bei einem Fully Federated Mesh im Regelfall spürbare Kostensteigerungen bzw. Investitionen zu erwarten. Im Gegenzug wird man mit einem hohen Maß an Agilität in der Entwicklung sowie kurzen Einführungszeiten belohnt. Ob sich das für ein Unternehmen auszahlt, muss die zugrundeliegende Datenstrategie zeigen. Grundsätzlich ist der Ansatz aber eher für stark autonom arbeitende Fachbereiche und lose Firmenverbünde geeignet.

3. Hybrid Mesh Federation

Unter Hybrid Mesh Federation werden schließlich verschiedene Mischformen zusammengefasst, wobei die Data Mesh Prinzipien je nach Ausgangslage und Zielvorstellung unterschiedlich stark ausgeprägt sind. Gemeinsam ist allen Ansätzen, dass manche Lösungskomponenten zentralisiert sind, während andere dezentral agieren.

Beispielsweise kann die Anbindung neuer Quellen von Domänen vorgenommen werden, die sich auf einen spezifischen Use Case konzentrieren und somit vorwiegend als Produzenten agieren. Die Teams sind nach Ouellsystemen oder Fachlichkeit ausgerichtet und entwickeln eigene „Source System Aligned Data Products“. Auf diese quellnahen Datenprodukte können Datenkonsumenten dann über eine zentrale Plattform zugreifen und mit ihren eigenen Entwicklungen darauf aufsetzen. Die Ergebnisse machen die Konsumenten wiederum zu Produzenten für andere Domains, wodurch ein engmaschiges „Federated Mesh“ entsteht.

Wie gesagt: Dies ist nur eine von vielen Möglichkeiten, um ein Hybrid Federated Mesh zu realisieren. Abhängig von der Datenstrategie einer Organisation kann auch eine andere Verteilung der zentralen und dezentralen Elemente sinnvoll sein. Dabei werden Standards generell streng verfolgt, während die Domain Teams für Daten und Datenprodukte verantwortlich sind. Über zentral integrierte Metadaten können die Teams dann Data Contracts mit anderen Domänen schließen.

Damit eignet sich dieser Architekturansatz auch sehr gut zur Einführung in Unternehmen ganz unterschiedlicher Größen und Branchen. Er bietet den Verantwortlichen die Möglichkeit, die für das Thema notwendigen Best Practices zu sammeln und schrittweise zu definieren, welche Prinzipien in welcher Ausprägung verfolgt werden sollen – und welche Bereiche letztendlich zu dezentralisieren sind. Dieser Weg bringt natürlich neue Herausforderungen mit sich, wie die unterschiedliche Handhabung von Richtlinien in zentralisierten und dezentralisierten Bestandteilen.

Wollen auch Sie mit Data Mesh schneller die besten Lösungen für Ihr Geschäft, Ihre Kunden und Ihre Mitarbeiter entwickeln? Dann schauen Sie doch mal im Bereich Datenstrategie vorbei oder informieren Sie sich über unser Data Strategy Assessment.