Einführung: Was ist ein Data Mesh?
Mit der Erkenntnis, dass Daten für ihr Geschäft von strategischer Bedeutung sind, haben Unternehmen versucht, sich neu zu organisieren, um das volle Potenzial ihres Datenbestands zu erschließen. Die Frage der Datenspeicherung hat nach und nach verschiedene Lösungen hervorgebracht, die versuchen, diese Frage zu beantworten: Datamarts, Data Warehouses und schließlich Data Lakes, die immer größere Datenmengen aufnehmen können und die Datenbestände möglichst vielen Menschen zentral zur Verfügung stellen, um die Silos im Unternehmen aufzubrechen.
Aber die Unternehmen haben nach wie vor Schwierigkeiten, den Bedürfnissen der verschiedenen Fachbereiche gerecht zu werden. Denn die Geschwindigkeit der Produktion, der Transformation und die zunehmende Komplexität der Daten (Art, Herkunft usw.) stellen die Skalierbarkeit einer solchen zentralisierten Organisation auf die Probe. Der zentrale Datenbrunnen neigt dazu, zu einem Nadelöhr zu werden, an dem Fachbereiche reagieren können und an dem nur einige wenige Expertenteams anzutreffen sind.
Dies gilt umso mehr in einem Umfeld, in dem Unternehmen aus Fusionen oder Übernahmen hervorgegangen oder in Tochtergesellschaften organisiert sind. Der Aufbau einer gemeinsamen Vision und Organisation aller Einheiten kann sich als komplex und mühsam erweisen.
Ausgehend von dieser Erkenntnis entwickelte Zhamak Dehghani das Konzept des „Data Mesh“ und schlug einen Paradigmenwechsel bei der Verwaltung analytischer Daten mit einem dezentralen Ansatz vor.
Das Data Mesh ist in der Tat keine technische Lösung, sondern vielmehr ein Ziel, ein Leitstern, wie Mick Lévy es nennt, dem man folgen muss, um die Herausforderungen zu meistern, denen die Unternehmen heute gegenüberstehen:
- Elegant auf die Komplexität, die Unbeständigkeit und die Unsicherheit des Geschäfts reagieren
- Trotz Wachstum seine Agilität bewahren
- Die Wertschöpfung proportional zu den Investitionen beschleunigen
Wie kann der Data Catalog die Einführung eines Data-Mesh-Ansatzes erleichtern?
Ein Data Catalog hat das Ziel, alle Daten eines Unternehmens zu katalogisieren und sie den technischen oder fachlichen Teams zur Verfügung zu stellen, die Nutzung der Daten zu erleichtern, die Zusammenarbeit rund um die Verwendung der Daten zu fördern und so die Wertschöpfung zu maximieren und zu beschleunigen.
In einer Organisation mit einem Data Mesh sind die Daten an verschiedenen Orten gesichert und werden von unterschiedlichen Teams verwaltet. Hier besteht die Aufgabe des Datenkatalogs darin, einen zentralen Zugriffspunkt auf die Datenressourcen für das gesamte Unternehmen zu gewährleisten.
Aber dafür muss der Data Catalog die folgenden vier Grundprinzipien des Data Mesh unterstützen:
- „Domain-driven ownership of data“
- „Data as a product“
- „Self-serve data platform“
- „Federated computational governance“
Domain Ownership
Das erste Prinzip des Data Mesh besteht darin, die Verantwortlichkeiten rund um Daten zu dezentralisieren. Das Unternehmen muss zunächst Fachbereiche definieren, und zwar mehr oder weniger granular, je nach Kontext und Anwendungsfall (z. B.: Produktion, Vertrieb, Logistik usw.).
Jeder Bereich erhält dann die Verantwortung für die von ihm erzeugten Daten. Die Bereiche gewinnen an Autonomie, um wachsende Datenmengen leichter zu verwalten und zu nutzen. Insbesondere wird dadurch die Datenqualität verbessert, da das Fachwissen direkt an der Quelle genutzt wird.
Dieser Ansatz stellt insbesondere die Zweckmäßigkeit eines zentralisierten Master Data Managements in Frage, das eine zentrale, umfassende Datenmodellierung vorschlägt, die jedoch für die Datenkonsumenten schwer zu verstehen und nur schwer über einen längeren Zeitraum aufrechtzuerhalten ist.
Dank des Data Catalogs müssen sich die Fachteams auf den Datenkatalog stützen und verlassen können, um ihre Daten zu inventarisieren und den Umfang ihres Bereichs mithilfe einer Modellierung zu beschreiben, die sich an der bereichsspezifischen Nutzung orientiert.
Diese Modellierung muss über ein mit dem Data Catalog verknüpftes Business Glossary zugänglich sein. Dieses Business Glossary muss die einzige Quelle der Wahrheit bleiben, jedoch gleichzeitig die verschiedenen Facetten der Daten entsprechend der Nutzung und den Bedürfnissen jedes Bereichs widerspiegeln.
Wenn z. B. das Konzept „Produkt“ für das gesamte Unternehmen gilt, sind seine Attribute für die Bereiche Logistik, Design oder Verkauf dennoch von unterschiedlichem Interesse.
Ein graphenbasiertes Business Glossary ist daher aufgrund seiner Flexibilität, Modellierungs- und Erkundungsmöglichkeiten besser geeignet als ein vordefinierter hierarchischer Ansatz. Während die Konsistenz dieser semantischen Ebene unternehmensweit sichergestellt wird, gibt ein graphenbasiertes Business Glossary den Datenverantwortlichen die Möglichkeit, die Besonderheiten ihrer jeweiligen Bereiche besser zu berücksichtigen.
Der Data Catalog muss daher den verschiedenen Bereichen die Gelegenheit geben, bei der Definition und Pflege des Metamodells und der Asset-Dokumentation zusammenzuarbeiten, um deren Qualität zu gewährleisten.
Um dies zu erreichen, muss der Datenkatalog auch ein geeignetes Berechtigungsmanagement anbieten, um eine eindeutige Aufteilung der Verantwortlichkeiten zu ermöglichen und jedem Bereichsleiter die Möglichkeit zu geben, die Dokumentation seines Bereichs selbst in die Hand zu nehmen.
Data as a product
Das zweite Prinzip des Data Mesh besteht darin, Daten nicht mehr als Asset zu betrachten, sondern als Produkt mit einer eigenen Benutzererfahrung und einem eigenen Lebenszyklus. Damit soll insbesondere vermieden werden, dass durch die Dezentralisierung der Verantwortlichkeiten erneut Silos im Unternehmen entstehen.
Jeder Bereich ist somit dafür verantwortlich, ein oder mehrere Datenprodukte für andere Bereiche zur Verfügung zu stellen. Aber über dieses Ziel der Reduzierung der Fragmentierung hinaus ermöglicht die Betrachtung von Daten als Produkt ein Vorgehen, das sich auf die Erwartungen und Bedürfnisse der Endnutzer konzentriert: Welche Personas sind Datenkonsumenten? In welchen Formaten nutzen die Benutzer die Daten? Mit welchen Tools? Wie kann die Zufriedenheit der Benutzer gemessen werden?
Mit einem zentralisierten Ansatz fällt es den Unternehmen nämlich schwer, auf die Bedürfnisse der Fachanwender einzugehen und zu skalieren. Das Data Mesh wird daher dazu beitragen, die Verbreitung der Datenkultur zu erleichtern, indem es die Hürde, die zur Nutzung der Daten überwunden werden muss, verringert.
Laut Zhamak Dehghani sollte ein Datenprodukt verschiedene Kriterien erfüllen, und der Data Catalog kann teilweise dabei helfen:
Entdeckbar: Der erste Schritt für einen Data Analyst, einen Data Scientist oder einen anderen Datenkonsumenten auf seiner Suche nach Daten besteht darin, zu wissen, welche Daten es gibt und welche Arten von Insights er entdecken kann. Der Data Catalog begegnet diesem Problem mit einer intelligenten Suchmaschine, die nach Schlüsselwörtern sucht, Tipp- und Syntaxfehler akzeptiert, Vorschläge generiert und erweiterte, intuitive Filtermöglichkeiten bietet. Der Data Catalog muss auch personalisierte Wege zur Discovery seiner Inhalte anbieten, um die verschiedenen Data Products besser zu fördern. Schließlich sollte die Such- und Navigationserfahrung im Data Catalog einfach sein und auf Marktstandards wie Google oder Amazon basieren, um das Onboarding für nicht-technische Nutzer zu erleichtern.
Verständlich: Daten müssen leicht verständlich und konsumierbar sein. Eine weitere Aufgabe des Data Catalogs ist es, den gesamten Kontext bereitzustellen, der für das Verständnis der Daten erforderlich ist: Beschreibung, zugehörige Geschäftskonzepte, Klassifizierung, Beziehungen zu anderen Datenprodukten etc. Die Fachbereiche können sich auf den Data Catalog stützen, um den Verbrauchern so viel Autonomie wie möglich beim Verstehen ihrer Datenprodukte zu geben. Ein Plus wäre eine Integration von Datentools und Sandboxes, um das Verhalten der Daten besser zu verstehen.
Vertrauenswürdig: Die Konsumenten müssen Vertrauen in die Daten haben, die sie verwenden. Auch hier spielt der Data Catalog eine wichtige Rolle. Ein Data Catalog ist kein Data-Quality-Tool, Qualitätsindikatoren müssen jedoch im Data Catalog automatisch abgerufen und aktualisiert werden können, damit sie für die Nutzer sichtbar sind (Vollständigkeit, Aktualisierungshäufigkeit usw.). Der Data Catalog sollte, wenn möglich, auch statistische Informationen über die Daten aufzeigen oder die Data Lineage rekonstruieren können, insbesondere durch automatisierte Systeme, um den Ursprung und die verschiedenen Transformationen zu verstehen.
Nativ zugänglich: Ein Datenprodukt sollte in der von den Personas (Data Analysts, Data Scientists usw.) erwarteten Form geliefert werden. Ein und dasselbe Datenprodukt kann daher potenziell in mehreren Formaten geliefert werden, je nach Verwendungszweck und Kompetenzen der Zielnutzer. Es sollte möglichst einfach sein, Schnittstellen zu den Tools herzustellen, welche die Nutzer verwenden. In diesem Punkt hat der Datenkatalog hingegen keine besondere Rolle zu spielen.
Nutzbar: Ein Schlüssel zum Erfolg eines Datenprodukts ist auch, dass es selbstständig konsumiert werden kann und dass es für sich genommen eine Bedeutung hat. Es muss so gestaltet sein, dass es die Notwendigkeit von Berührungspunkten mit anderen Datenprodukten minimiert, um selbst einen messbaren Wert für seine Konsumenten zu liefern.
Adressierbar: Sobald der Nutzer das von ihm benötigte Datenprodukt im Data Catalog gefunden hat, muss er leicht darauf zugreifen können oder in der Lage sein, auf einfache und effiziente Weise den Zugriff darauf anzufordern. Dazu muss der Data Catalog Schnittstellen zu Policy-Enforcement-Systemen aufweisen, die den Zugriff auf die Daten durch die Automatisierung eines Teils der Arbeit erleichtern und beschleunigen.
Sicher: Dieser Punkt hängt mit dem vorherigen zusammen. Die Nutzer müssen leicht auf die Daten zugreifen können, aber auf sichere Weise, je nachdem, welche Richtlinien für die Zugriffsrechte eingerichtet wurden. Auch diesen Aspekt erleichtert die Integration des Data Catalogs mit einer Policy-Enforcement-Lösung.
Interoperabel: Um den Austausch zwischen den Bereichen zu erleichtern und die erneute Bildung von Silos zu vermeiden, müssen Data Products auf Unternehmensebene festgelegten Standards entsprechen, damit jede Art von Datenprodukt problemlos konsumiert und Datenprodukte untereinander integriert werden können. Der Data Catalog muss auch die Möglichkeit bieten, die Metadaten der Datenprodukte zu verbreiten, um die Fachbereiche über APIs miteinander zu verbinden.
Self-serve data infrastructure
In einer Organisation mit einem Data Mesh sind die Fachbereiche dafür verantwortlich, die Data Products dem gesamten Unternehmen zur Verfügung zu stellen. Um dieses Ziel zu erreichen, müssen die Fachbereiche jedoch über Dienste verfügen, die ihnen die Einrichtung erleichtern und die Verwaltungsaufgaben so weit wie möglich automatisieren. Diese Dienste müssen die Komplexität der zugrunde liegenden Architektur verschleiern, um die größtmögliche Autonomie der Fachbereiche von den Infrastrukturteams zu gewährleisten.
In einer dezentralen Organisation wird diese Dienste-Ebene auch Kostensenkungen ermöglichen, insbesondere hinsichtlich der Belastung der Data Engineers, einer Mitarbeiterressource, die schwer zu finden ist.
Der Data Catalog ist Teil dieser Abstraktionsschicht und ermöglicht es den Fachbereichen, die Datenquellen, für die sie verantwortlich sind, einfach zu inventarisieren. Dazu muss der Data Catalog selbst einen Katalog von Konnektoren anbieten, der die verschiedenen von den Fachbereichen eingesetzten Technologien (Speicherung, Transformation usw.) unterstützt, und die Kuratierungsaufgaben so weit wie möglich automatisiert.
Mithilfe einfach zu bedienender APIs ermöglicht der Data Catalog den Fachbereichen, ihre fachlichen oder technischen Repositories einfach zu synchronisieren, ihre Qualitätsmanagement-Tools zu verbinden usw.
Federated computational governance
Das Data Mesh bietet einen dezentralisierten Ansatz für das Datenmanagement, bei dem die Fachbereiche eine gewisse Souveränität erlangen. Die Einrichtung einer föderalen Governance-Struktur ermöglicht jedoch die globale Kohärenz der Governance-Regeln, die Interoperabilität der Datenprodukte und ein Monitoring auf der Ebene des Data Mesh.
Das Data Office tritt daher eher als Vermittler auf, der die Governance-Prinzipien und -Richtlinien verbreitet, denn als Kontrolleur. Der CDO ist nicht mehr für die Qualität oder die Sicherheit verantwortlich, sondern definiert, was Qualität, Sicherheit usw. ausmacht. Die Bereichsleiter übernehmen auf lokaler Ebene die Umsetzung dieser Prinzipien.
Dieser Paradigmenwechsel ist vor allem durch die Automatisierung der Durchsetzung von Governance-Richtlinien möglich. Die Anwendung dieser Richtlinien wird dadurch im Vergleich zu einem zentralisierten Ansatz beschleunigt, da sie so nah wie möglich an der Quelle erfolgt.
Der Data Catalog kann auch hier bei der Verbreitung von Governance-Prinzipien und -Richtlinien eingesetzt werden, die im Data Catalog dokumentiert oder katalogisiert und mit den Data Products, für die sie gelten, verknüpft werden können. Der Data Catalog wird auch Metadaten für die Systeme bereitstellen, die für die Automatisierung der Anwendung von Regeln und Richtlinien zuständig sind.
Schlussfolgerung
In einer zunehmend komplexen und sich verändernden Datenumgebung bietet das Data Mesh eine sozio-architektonische Alternative zu zentralisierten Ansätzen, die Schwierigkeiten mit der Skalierung haben und sich schwertun, den Anforderungen der Fachbereiche hinsichtlich Qualität und Reaktionsfähigkeit gerecht zu werden.
Der Data Catalog spielt in dieser Organisationsstruktur eine zentrale Rolle, da er ein zentrales Zugriffsportal für die Discovery und die gemeinsame Nutzung von Datenprodukten im gesamten Unternehmen bereitstellt, den Fachbereichen die einfache Verwaltung ihrer Datenprodukte ermöglicht und Metadaten für die Automatisierung von Richtlinien liefert, die für eine föderal strukturierte Governance erforderlich sind.
