In vielen Unternehmen führt das rasante Wachstum der Datenvolumen, die zunehmende Komplexität bestehender Datenarchitekturen und die heterogenen Anforderungen unterschiedlicher Fachbereiche dazu, dass klassische zentralisierte Ansätze, wie Data Lakes, Data Warehouses oder Lakehouses, zunehmend an ihre Grenzen stossen.
Genau hier setzt das Data Mesh Konzept an: Anstelle einer monolithischen, zentral gesteuerten Plattform verlagert es die Verantwortung in dezentrale Domänen und betrachtet Daten konsequent als eigenständige, verantwortungsvoll gemanagte Datenprodukte. Dabei basiert Data Mesh auf folgenden Prinzipien:
- Domain Ownership: Vollständige fachliche Verantwortung der Domänen für ihre jeweiligen Datenprodukte
- Data as a Product: Definition klarer SLAs, umfassende Metadaten, sowie expliziter Qualitäts- und Sicherheitsregeln für jedes einzelne Datenprodukt und der technische Zugang aller Informationen via einer API.
- Self-Service-Datenplattform: Bereitstellung wieder verwendbarer Infrastrukturbestandteile wie Pipelines, Storage, Transformationen, Sicherheit und Monitoring.
- Föderierte Governance: Übergreifende und flexible Umsetzung von Standards und Policies, die durch Domänenautonomie ergänzt werden.
Ausgangslage bei IT-Logix
Bei IT-Logix sind wir seit Jahren auf zentralisierte DWH- und BI-Landschaften spezialisiert. Klassische relationale Data Warehouses, Data Lakes und Lakehouses standen stets im Mittelpunkt unserer Projekte. Wir haben uns einen Namen gemacht mit bewährten und standardisierten ETL-Prozessen, dimensionalen Datenmodellen, Data Vault Modellen sowie zentral verwalteten Metadaten-, Sicherheits- und Qualitätsrichtlinien. Hierbei haben wir uns immer auf best-in-class Software-Lösungen konzentriert.
Müssen wir unsere bisherigen Ansätze nun verwerfen?
Mit dem Aufkommen von Data Mesh stellt sich zwangsläufig diese Frage – vor allem dann, wenn man bisher erfolgreiche zentralisierte Architekturen betrieben hat.
Unsere Antwort: Eine hybride, pragmatische Strategie
Data Mesh eignet sich primär für grosse Unternehmen, die bereits über eine hohe Reifegradstufe hinsichtlich ihrer Datenkultur verfügen. Für mittlere und kleinere Unternehmen sehen wir weiterhin den zentralisierten Ansatz bedeutend zielführender. Im Kontext von grossen Unternehmen, bedeutet das für uns bei IT-Logix jedoch nicht ein «Entweder-Oder», sondern vielmehr ein gezieltes und pragmatisches Kombinieren des Besten aus beiden Welten.
Wir übernehmen das Data-Mesh-Mindset, indem wir:
- den Governance-Gedanken stärker in den Vordergrund rücken,
- Domain-driven Ownership etablieren,
- Daten konsequent als eigenständige Produkte behandeln,
- und eine leistungsfähige Self-Service-Datenplattform bereitstellen.
Gleichzeitig setzen wir bei der technischen Umsetzung weiterhin auf bewährte Patterns beim Aufbau von Data-Pipelines: automatisierte und generische Datenanbindungspattern, zuverlässige Historisierung, Delete Detection und Delta Loads stellen sicher, dass eine dezentrale Architektur langfristig wartbar und erweiterbar bleibt. Idealerweise werden diese technischen Patterns zentral entwickelt und den Domain-Teams als Standard-Templates bereitgestellt.
Wir halten dabei an der bewährten Layer-Architektur (Bronze, Silber und Gold) fest, wobei im Gold-Layer nach wie vor dimensionale Datenmodelle für analytische Datenprodukte genutzt werden.
Einführung von Data Mesh: Unser Vorgehen
Fakt ist, dass in jeder grossen Unternehmung ein oder auch mehrere Data Warehouses, Data Lakes oder Lakehouses bestehen. Um einen agilen Weg in eine Data Mesh Architektur gehen zu können empfehlen wir ein mehrstufiges Vorgehen.
- Governance-Rahmen schaffen
Zunächst werden die Stakeholder für das Data-Mesh-Konzept sensibilisiert und umfassend geschult. Gemeinsam werden Richtlinien, Rollen und Verantwortlichkeiten in einem föderierten Governance-Modell definiert. Es werden dezentrale Teams aufgebaut und ein übergreifendes Governance Board geschaffen. - Skills in den Domain-Teams aufbauen
Durch gezielte Schulungen und individuelles Coaching wird dezentrale Expertise in Bezug auf das Datenprodukte Mindset, Daten-Pipelines, Datenqualitätsregeln und Security-Policies etabliert. Dies basierend auf dem Wissen und den Erfahrungen aus der bestehenden zentralen Organisation. - Technologische Plattform bereitstellen
Grosse Unternehmen setzen in der Regel auf eine standardisierte Plattform wie Microsoft Fabric. In Kombination mit Azure Purview und den Shortcut-Funktionalität ist die Microsoft Fabric mittlerweile auch multi-cloud-fähig. Metadaten aus AWS, GCP und On-Premises können nahtlos in die Microsoft Fabric integriert werden. Damit stellt Microsoft ein ausgereiftes Data Mesh Framework zur Verfügung.
Auch evaluieren wir derzeit im Umfeld von Multi-Cloud- und Hybrid-Architekturen eine Vielzahl weiterer innovativer Lösungen, die in jüngster Zeit am Markt erschienen sind.
Die Microsoft Fabric und alternative Plattformen bieten somit nicht nur Self-Service-Funktionalitäten für Storage, Datenaufbereitung, Monitoring und Security, sondern unterstützen auch die technische Umsetzung föderierter Governance-Modelle und ermöglichen so eine effiziente Skalierung dezentraler Datenprodukte. - Start im Gold-Layer
Eine zentralisierte Datenarchitektur stellt mehrheitlich einen Zugriffs-Layer mittels Views oder analogen Konzepten im Gold-Layer zur Verfügung. Darauf werden Analysen, BI-Reports oder Dashboards aufgebaut. Auf dieser Schicht sollten die ersten Erfahrungen mit der Definition von Datenprodukten gesammelt werden. Aktuell ist es sehr oft der Fall, dass lediglich der Name des Datenobjektes und die Attribute mit ihren Datentypen bekannt sind. Das höchste der Gefühle ist eine grafische Visualisierung in einem Datenmodell oder eine Beschreibung in einem (sehr oft veralteten) Datenkatalog, und im besten Fall eine textuelle Tabellen- und Attributbeschreibung.
Datenprodukte gehen einen Schritt weiter. Das Ziel soll einerseits sein, die Daten via einer standardisierten API zur Verfügung zu stellen, inkl. der Metadatenbeschreibung, enthaltenen Qualitätsprüfungen, Security-Policies, Abhängigkeiten und ihrem Aktualisierungs- und generellem Gesundheitszustandes.
Auch müssen die API’s in einer Registry erfasst sein, damit diese für alle Benutzer auffindbar sind. In der Microsoft Fabric mit dem Konzept des OneLakes in Kombination mit Azure Purview sind bereits einige der oben genannten Eigenschaften abgedeckt. Mit etwas zusätzlichen Customizing der Plattform können auch weitere Eigenschaften erfüllt werden.
Nachdem die Datenprodukte definiert wurden, sollten alle bestehenden Analysen und BI-Reports auf die neuen APIs umgestellt werden. Dienen einzelne Analysen wiederum als Grundlage für weitere Datenprodukte, so sind auch diese Analysen als eigenständige Datenprodukte zu modellieren und über eine eigene API verfügbar zu machen. - Organisation in Domänen umsetzen
Der obige Schritt wird zeigen, ob die Organisation bereit ist, mit dem Data Mesh Konzept umzugehen. Zudem wird man feststellen, dass viele Analysen und BI-Reports viel Zusatzlogik enthalten oder auch redundant aufgebaut sind, so dass bereits ein erster Mehrwert durch die Konsolidierung von Datenprodukten erreicht werden kann.
Ist man erfolgreich mit der Migration im Gold-Layer wird sukzessive mehr Verantwortung in die fachlichen Domänen verlagert. Beispielsweise wird die Verantwortung der Kundendimension an die Domäne Sales übertragen, die Materialdimension an die Domäne Logistik oder die Debitoren-/Kreditorendimension and Domäne Finanzen. Auch in diesem Schritt werden alle Datenobjekte als Datenprodukte beschrieben und via API zur Verfügung gestellt.
Wichtig dabei ist, dass die bewährten Methoden der dimensionalen Modellierung und Datenverarbeitung (z.B. Slowly Changing Dimensions Typ 2) erhalten bleiben. In einer Data Vault geprägten Datenarchitektur erfolgt die Zuordnung von Hubs, Satelliten und Links, gebündelt zu sogenannten «Ensambles» konsequent zu den jeweiligen Domänen. Auch hier werden selbstverständlich die bewährten Methoden der Datenmodellierung und Datenverarbeitung beibehalten. - Abgrenzung im Bronze-Layer
Im Bronze-Layer setzen wir weiterhin auf ein zentrales Team, das generische, standardisierte Ingest-Prozesse betreibt, da in diesem Stadium noch kein tiefgehendes Domänenwissen erforderlich ist. So bleibt dieser Layer bewusst klassisch organisiert, während Verantwortung und Ownership für Silber- und Gold-Layer effektiv in die Domänen-Teams übertragen werden.
Unser Fazit
Mit diesem hybriden Ansatz, der bewährte Data Warehouse Techniken mit dem innovativen Data Mesh Mindset kombiniert, schaffen wir eine skalierbare, wartbare und domänengetriebene Datenarchitektur, die gezielt auf die Bedürfnisse moderner, datengetriebener Unternehmen ausgerichtet ist.
Gerne begleiten wir Sie auf dem Weg zu Ihrer individuellen Data Mesh Lösung und stehen mit unserer langjährigen Erfahrung sehr gerne beratend zur Seite oder wir analysieren ihre bestehende Data Mesh Architektur mittels unserem Data Mesh Audit.