Data Mesh
Data Mesh

Skalierbarkeit und Datenverantwortung mit Data Mesh

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:

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.

7. Datenverfügbarkeit: Die Daten sollten klar und für jeden Bereich verfügbar sein, damit sie nach eigenem Ermessen genutzt werden können. Es sollte von der IT definierte Schichten geben, die verschiedene Möglichkeiten des Datenzugriffs bieten. Zum Beispiel eine API-Datenzugriffsschicht für einzelne Datenpunkte und eine Tabellenzugriffsschicht für die Stapelverarbeitung.

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:


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:

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.

Willst du eine passende Datenstrategie für dein Unternehmen entwickeln und umsetzen?

Gastbeitrag von

Image_Capa
Francisco Capa

Bleib informiert und folge uns

Bleib informiert und folge uns

Standort Deutschland
Standort Portugal