Data Mesh – Wer braucht es, wozu ist es gedacht, wie hilft es? Besonders sinnvoll ist das Modell für Unternehmen, die einen großen Datenbedarf haben und Daten als strategische Ressource nutzen wollen. Denn im Gegensatz zu herkömmlichen Modellen werden in dem dezentralen Modell Daten als internes Produkt behandelt.
Data Mesh ist ein methodischer Ansatz zur Verwaltung und Skalierung von Daten. Er zielt darauf ab, den Datenzugang zu demokratisieren, die Agilität zu verbessern, die Verantwortung zu stärken und die Herausforderungen im Zusammenhang mit der Skalierbarkeit und Komplexität großer Datenmengen zu bewältigen.
Der traditionelle Ansatz
In einer traditionellen Datenarchitektur folgt die Datenverwaltung in der Regel einem zentralisierten und monolithischen Ansatz. Hier sind einige Schlüsselkonzepte, die mit dem traditionellen Ansatz verbunden sind, zusammen mit den Herausforderungen:
- Zentrale Datenverantwortung: Ein zentrales Datenteam oder eine Abteilung ("Data-Warehouse-Team") ist für die Datenverwaltung zuständig. Dieses Team hat die Aufgabe, Daten zu sammeln, zu speichern, zu verarbeiten und im gesamten Unternehmen zu verteilen.
- Daten als Kostenstelle: Daten werden als Notwendigkeit und Kostenfaktor betrachtet und nicht als strategischer Wert, der erforscht werden kann. Beispielsweise werden Daten in erster Linie für betriebliche Zwecke und nicht für analytische Geschäftsentscheidungen verwendet.
- Komplexe ETL: Komplexe Prozesse werden oft geschaffen, um den Anforderungen verschiedener Teams gerecht zu werden und ein zentrales Data Warehouse zu unterhalten.
- Begrenzte Agilität: Geschäftsbereiche oder interne Abteilungen müssen datenbezogene Aufgaben an das zentrale Data-Warehouse-Team delegieren. Manchmal wird sogar die Berichterstattung auf diese Weise durchgeführt, weil das gesamte Wissen über die Art und Weise, wie die Daten organisiert und umgewandelt werden, in nur einem Team zentralisiert ist, was zu Engpässen bei der Entwicklung führt.
- Datenverwaltung und -qualität: Normalerweise liegt die Verantwortung für die Datenverwaltung und die Aufrechterhaltung der Datenqualität beim Data-Warehouse-Team. Dies kann jedoch zu einer Wissensabhängigkeit von einem einzigen Team führen.
- Skalierbarkeit: Da das Datenvolumen exponentiell ansteigt, sind zentralisierte Architekturen mit höheren Kosten und betrieblicher Komplexität konfrontiert.
Zusammenfassend lässt sich sagen, dass ein traditioneller Ansatz, der sich auf ein zentralisiertes Datenteam zur Verwaltung der gesamten Organisation stützt, sehr gut für Sicherheit und Governance sein kann. Jedoch kann er die Agilität und Skalierbarkeit behindern und sogar die Analysen einschränken, die andernfalls erreicht werden könnten, wenn es keine Engpässe bei der Entwicklung oder der Verarbeitungsleistung gäbe. Dies könnte ein guter Ansatz für eine Organisation sein, die sich auf die Sicherheit und Kontrolle von Daten konzentriert, wie zum Beispiel Regierungsorganisationen.
Der Data Mesh Ansatz
Data Mesh stützt sich auf einen dezentralen Ansatz für Dateneigentum und -analyse. Aufgrund dieses dezentralen Ansatzes hat die Organisation klar definierte Teams für Daten. Die Teamstruktur entspricht in der Regel derjenigen der geschäftsorientierten Teams. So hat beispielsweise der Marketingbereich ein eigenes Datenteam, der Finanzbereich ein weiteres und so weiter.
Das übergreifende Team, das alle anderen Bereiche unterstützt, ist die IT-Abteilung, die eine entscheidende Rolle bei der Unterstützung der verschiedenen Teams mit Tools und Infrastruktur sowie bei der Umsetzung von Data Governance und Qualitätsmaßnahmen spielt.
Einige Kernaspekte, die sich von einem traditionellen Ansatz unterscheiden, sind:
1. Dezentralisierung: Die Daten werden auf bereichsspezifische Teams oder Geschäftseinheiten verteilt. Diese Teams sind für die in ihrem jeweiligen Bereich erzeugten und verbrauchten Daten verantwortlich, wodurch ein Gefühl der Verantwortlichkeit und des Eigentums entsteht.
2. Daten als Produkt: Daten werden als ein erstklassiges Produkt betrachtet. Datenprodukte werden mit der gleichen Strenge entwickelt wie Softwareprodukte, und jedes Team ist für Daten, Qualität, Governance, Sicherheit, Dokumentation usw. verantwortlich.
3. Geringere Komplexität: Jedes Team ist für seine eigenen Datenprojekte und -bedürfnisse verantwortlich, was die Komplexität durch die Verteilung der Verantwortlichkeiten verringert. Das Ziel jedes Teams ist es, einem anderen Team (oder sich selbst) einen möglichst sauberen Datensatz zur Verfügung zu stellen.
4. Hohe Agilität: Geschäftseinheiten und bereichsspezifische Teams sind nun in der Lage, Daten selbst zu entwickeln und zu analysieren, so dass sie sich nicht mehr auf ein zentrales Datenteam verlassen müssen und Engpässe vermieden werden.
5. Data Governance und Qualität: Wie erörtert, wäre dies die Aufgabe eines IT-Teams; dies ist ein Punkt, in dem die traditionelle Architektur dominiert. Die Durchsetzung von Data Governance und Qualität ist keine leichte Aufgabe, wenn es mehrere Systeme statt eines zentralen gibt. Hier kommen auch die Rechenschaftspflicht und die Verantwortung der einzelnen Bereiche für die Daten ins Spiel.
6. Skalierbarkeit: Da die Daten jetzt für jeden Bereich partitioniert sind und jeder Bereich nur über die Daten verfügt, die er für die Ausführung einer Aufgabe benötigt, ist die Skalierbarkeit leicht zu erreichen, ohne den Overhead eines vollständigen Data Warehouse.
Zu beachten ist, dass wenn man dieser bereichsbezogenen Logik folgt, am Ende in jedem Bereich ein Datenteam existieren könnte, aber dies sollte aus Kostengründen zunächst vermieden werden. In der Regel beginnen die Bereichsteams damit, intern Mitarbeiter aus dem übergreifenden (IT-) Team für die Entwicklung und Analyse ihrer Daten „einzustellen“. Schließlich sollte ein bereichsspezifischer Datenmanager eingestellt werden, und wenn Bedarf besteht, würde das bereichsspezifische Datenteam dann organisch wachsen.
Data Mesh veranschaulicht - Ein simples Beispiel:
Dies ist ein sehr einfaches Beispiel dafür, wie ein Datengeflecht in einem FinTech-Unternehmen funktionieren würde. Nennen wir unser Unternehmen FinTechOne. FinTechOne bietet seinen Kunden Finanzdienstleistungen an und verfügt über 6 Domänen innerhalb des Unternehmens:
- Operational
- Finance
- Marketing
- IT
- Analytics
- Customer Relationship
Das IT-Team wäre, wie bereits erwähnt, die Säule, die alle anderen Teams stützt, und würde für sie sorgen mit:
- Leitlinien für den Aufbau von Datenmodellen und für die zu verwendende Nomenklatur
- Leitfäden für bewährte Praktiken bei der Verwendung von Instrumenten und Modellen
- Definition der Tools, die zur Verfügung stehen (z. B. nutzt diese Organisation nur die Microsoft-Cloud so würde die IT-Abteilung jede Entwicklung in einer anderen Cloud blockieren).
- Allgemeine Unterstützung
Da es kein zentrales Data Warehouse gibt, würde jedes Team Pipelines und Modelle für seinen eigenen Bedarf entwickeln. Nehmen wir an, das Marketingteam benötigt operative Daten, um mit den Kunden in Kontakt zu treten, und die Analyseteams wiederum benötigen die Daten des Marketingteams, um die Leistungskennzahlen zu analysieren.
Das operative Team wäre dafür verantwortlich, dem Marketingteam eine Möglichkeit zu bieten (individuell oder per Batch), saubere Daten, die sie benötigen, zu konsumieren, und das Marketingteam wäre dafür verantwortlich, die von ihm erstellten Daten zu speichern und auf die gleiche Weise für jedes andere Team verfügbar zu machen.
Data Mesh - Der Mix macht's
Beachte, dass dies nur einige der Schlüsselkonzepte von Data Mesh sind und dass es keine Einheitslösung für alle gibt.
Am besten wäre es, einige Konzepte aus jeder Methodik zu übernehmen; ein vollständiger Ansatz für ein Datengeflecht ist in bestimmten Organisationen vielleicht gar nicht möglich. Am häufigsten wird ein hybrider Ansatz gewählt: Man wählt jedes Konzept aus, das gut passt. Denke auch daran, dass einige Arten von zentralisierten Daten sehr nützlich sind und auch so bleiben sollten. Ein Beispiel sind Kundendaten, die in einem CRM-System gespeichert werden sollten, das allen zur Verfügung steht, denn es sollte nur eine einzige Quelle der Wahrheit geben, um keinen Bereich zu verwirren.
Zusammenfassend lässt sich sagen, dass ein Data Mesh-Ansatz in der Regel einen großen kulturellen Wandel erfordert, um ihn zu implementieren. Er hat jedoch das Potenzial, die Grenzen eines traditionellen Ansatzes zu überwinden, indem er die Verantwortlichkeiten für Daten verteilt, die Agilität verbessert und den Datenzugang demokratisiert, so dass Unternehmen ihre Daten letztlich besser als strategisches Kapital nutzen können.
