Blog

Leitfaden für Realisten zur hybriden Mesh-Architektur (1): Einzige Quelle der Wahrheit vs. Demokratisierung

XiaoHan Li

Aktualisiert März 17, 2026

9 Minuten

Einführung

Der Kernpunkt der vielen praktischen Probleme von Data Mesh ist die Unfähigkeit, eine einzige Quelle der Wahrheit zu finden. In ihrem Buch Data Mesh bezeichnet Zhamak Dehghani die einzige Quelle der Wahrheit als "Mythos" und "unerreichbar". Das halte ich für eine unbegründete Spitzfindigkeit zur Verteidigung der offensichtlichen Achillesferse ihres Konzepts, der ich vehement widerspreche.

Der Autor des Buches Deciphering Data Architectures James Serra nannte Data Mesh "eine Lösung, die nach einem Problem sucht". Als Skeptiker der Datenverflechtung und überzeugter Verfechter der einzigen Wahrheitsquelle finde ich es dennoch sinnvoll, von bestimmten Prinzipien des Datenverflechtungskonzepts zu lernen, um bestehende zentralisierte Architekturen durch hybride Verflechtungsprozesse zu verbessern und gleichzeitig eine einzige Wahrheit zu erhalten.

Ich behaupte außerdem, dass Data Mesh und bestehende Hybrid Mesh-Implementierungen in erster Linie dem Datenentwicklungsprozess zugute kommen, aber den Zweck und die Art und Weise, wie Daten in der realen Geschäftswelt in Wert umgewandelt werden, übersehen. Diese Lücke führt zu einer Vielzahl von praktischen Komplikationen und Verwirrung bei der Implementierung. Zu diesem Zweck schlage ich ein alternatives Design für eine hybride Mesh-Architektur vor, die den geschäftlichen Nutzen erhöht.

In dieser Serie von Artikeln werde ich:

Bieten Sie Einblicke in die Anpassung von Data Mesh-Prinzipien zur Demokratisierung des Datenentwicklungsprozesses unter zentraler Führung,
Gehen Sie auf die praktischen Probleme ein, auf die Teams bei der Hub-and-Spoke-Implementierung häufig stoßen, und zeigen Sie praktikable Lösungen auf,
Schlagen Sie eine hybride Netzkonstellation vor, die den realen Anforderungen an die Datenmodellierung gerecht wird und für den Geschäftswert optimiert ist.

Die hier besprochene Architektur hält sich an den ELT-Prozess mit in dbt implementierten Datenmodellen.

Data Mesh-Konzept & Hybrid Mesh-Anwendung

Sechs Jahre nachdem Dehghani das Konzept des Datennetzes als Lösung für die Skalierung vorgeschlagen hat, bleibt die Idee eines reinen Datennetzes höchst hypothetisch und wird aufgrund technologischer und organisatorischer Beschränkungen wahrscheinlich nicht in die Produktion gehen.

In den letzten Jahren hat sich in der Branche ein hybrides Netzmuster herausgebildet, um die Vorteile der demokratisierten Entwicklung von Domaindaten zu nutzen und gleichzeitig einige zentralisierte Elemente beizubehalten, um die Akzeptanzbarriere zu senken.

In einer hybriden Mesh-Architektur ist jede Domäne befugt, ihre eigenen Datenprodukte zu entwickeln, während alle Domänen denselben Technologiestack verwenden, dieselbe gemeinsame Infrastruktur nutzen und alle Daten in demselben zentralen physischen Data Lake leben, der vom zentralen Datenteam gepflegt wird. (Im Gegensatz zu einer reinen Data Mesh-Architektur, bei der die Domänen die Kontrolle über verschiedene Technologien und Infrastrukturen sowie über separate Data Lakes haben).

[Abbildung 1: Hub-and-Spoke]

Eine typische Strategie für Hybridnetze ist das Hub-and-Spoke-Muster (Abbildung 1):

Ein zentrales Datenteam legt die gemeinsame Infrastruktur fest, nimmt Quelldaten auf und bereitet die Daten in der Staging-Ebene vor.
Mehrere Domänen-Teams übernehmen dann die Entwicklung ihrer Transformationen, erstellen ihre eigenen Karts, in ihrem eigenen Tempo, mit ihrem Wissen über die Domäne, ohne die Mühe, ein zentrales Datenteam anzufordern und auf es zu warten.

Einzige Quelle der Wahrheit vs. Demokratisierung

Eine einzige Quelle der Wahrheit ist nicht nur erreichbar, sondern auch ein Muss, um Daten in Geschäftswert zu verwandeln. Wir haben es immer wieder erlebt, dass bei unkoordinierter Autonomie der Bereiche verschiedene Teams sehr unterschiedliche Zahlen für wichtige Kennzahlen wie z.B. den Umsatz melden, und zwar auf der Grundlage unterschiedlicher willkürlicher Definitionen für dieselbe Kennzahl. Datenexperten können und haben seit langem eine einzige Quelle der Wahrheit geschaffen, was nur unter zentraler Durchsetzung möglich ist.

Die ersten Anwender des hybriden Netzes trugen dem Bedarf an konformen Dimensionen, kanonischen Entitäten und einer abgestimmten Definition von Metriken Rechnung. Verschiedene Branchenkollegen kamen überein, das überarbeitete Hub-and-Spoke-Muster mit einer gemeinsamen Integrationsschicht zu übernehmen, die vom zentralen Hub-Team gepflegt wird. Hier werden die Daten integriert, standardisiert, angepasst, angereichert und schließlich zwischen den Domänen ausgetauscht, um die gemeinsamen Bausteine zu bilden, auf denen die Domänen-Data-Marts basieren. (Abbildung 2)

[Abbildung 2: Angenommenes Hub-and-Spoke-Muster mit einer gemeinsamen Integrationsschicht].

Dieses häufig verwendete Hub-and-Spoke-Muster wurde nach den folgenden Grundsätzen entwickelt:

Ein zentrales Datenteam legt die gemeinsame Infrastruktur fest, nimmt Quelldaten auf und bereitet die Daten in der Staging-Ebene vor.
Die von mehreren Bereichen verwendeten Daten werden in der gemeinsamen Integrationsschicht, die vom zentralen Datenteam entwickelt wurde, angepasst und angereichert.
Domänenspezifische Daten werden innerhalb jeder Domäne auf der Grundlage der gemeinsamen Datenmodelle entwickelt, die von der Integrationsschicht (und manchmal direkt vom Staging) bereitgestellt werden.

Häufige Probleme bei der Implementierung von Hybridnetzen

Das Hub-and-Spoke-Design hört sich auf dem Papier großartig an, bis einige Monate nach der Implementierung praktische Probleme auftauchen, die bei der Konzeption nicht berücksichtigt wurden.

In der Praxis treten häufig folgende Probleme auf:

Die Domänen benötigen dieselbe Logik, und jede erstellt dieselben Modelle in ihren eigenen Marts (manchmal mit demselben Namen), ohne von den Aktivitäten der anderen Domänen zu wissen.
Das entscheidende Modell von Bereich B hängt von einer bestimmten Logik aus Bereich A ab, die noch nicht entwickelt wurde. Domänen haben unterschiedliche Prioritäten und Rückstände. Domäne B entscheidet sich dafür, die Logik von A wissentlich in Domäne B zu erstellen, damit sie die Modelle fertigstellen können, die sie dringend benötigen.
Bidirektionale Abhängigkeiten zwischen Domänen erschweren die Orchestrierung. Die erforderliche Reihenfolge der Datenaktualisierung zwischen Domänen könnte für einen Anwendungsfall A->B->C und für einen anderen C->A lauten. Implementierungsaufträge müssen auf der Ebene des detaillierten Modells geplant und zwischen Domänen verkettet werden. Zusätzliche Läufe könnten ausgelöst werden und zusätzliche Rechenkosten verursachen.
Die Domänen sind sich nicht immer einig über den Besitz von Daten. Die Entscheidungen über die Platzierung von Datenmodellen sind oft mit Verwirrung und Rätselraten verbunden.

Es gibt einige Gründe für diese Fallstricke.

Das Entwurfsmuster geht von der idealisierten Annahme aus, dass die Domänen eindeutig unabhängig sind und es keine Überschneidungen oder Querverweise zwischen den Domänen gibt. In der realen Geschäftswelt ist dies jedoch selten der Fall.

Die Unterscheidung, ob bestimmte Daten als gemeinsam genutzt oder als Eigentum einer Domäne betrachtet werden sollten und von welcher Domäne, ist oft nicht ganz klar, insbesondere wenn Abhängigkeiten bestehen. Mehrere Domänen können an verschiedenen Stufen einer einzigen Datenwertschöpfungskette beteiligt sein. Auch die Abhängigkeitsbeziehungen entwickeln sich im Laufe der Zeit weiter. Daten, die zuvor nur von einer Domäne genutzt wurden, können später von einer anderen Domäne benötigt werden, wenn neue Geschäftsanforderungen entstehen.

Ich habe mit einigen Datenarchitekten gesprochen, die der Meinung sind, dass ein demokratisierter Datenentwicklungsprozess mit einem unausweichlichen Kompromiss zwischen Duplikation und Geschwindigkeit einhergeht. Sie beschließen, ein gewisses Maß an Kompromissen zu akzeptieren. "Wir wollen, dass die Domänen die Daten erstellen, die sie benötigen. Wenn sie zufällig in jedem Bereich die gleichen Dinge entwickeln, dann ist das eben so. Letztendlich muss die Entwicklung vorankommen."

Andere, die wie ich auf die einzige Quelle der Wahrheit beharren, verfolgen einen anderen Ansatz.

Praktische Lösungen für die Implementierung eines Hybridnetzes

Lassen Sie es mich ganz offen sagen: Die praktische Lösung für die Probleme der Mesh-Domäne ist fast immer - eine Verlagerung nach oben. Mit anderen Worten, die Rückkehr zur Zentralisierung und die Abkehr vom Mesh.

Die Regeln sind einfach:

Querverweise zwischen Domänen sind nicht erlaubt. Domänendaten sind streng domänenspezifisch.
Wenn Daten von verschiedenen Domänen gemeinsam genutzt werden müssen, legen Sie sie an einem zentralen Ort ab.
Wenn die Daten einer Domäne von einer anderen Domäne wiederverwendet werden müssen, verschieben Sie sie an den zentralen Speicherort.

[Abbildung 3: Hybride Mesh Hub-and-Spoke-Architektur Praktische Lösung]

Abbildung 3 veranschaulicht die letztendliche Architektur in der praktischen Umsetzung. Alle Daten, die bereichsübergreifend gemeinsam genutzt und wiederverwendet werden, befinden sich in der zentralen Integrationsebene, wodurch eine einzige Wahrheitsquelle geschaffen und die Komplikationen der Abhängigkeiten ausgeglichen werden.

In Teil 2 dieses Artikels werde ich anhand von Beispielen detailliert erklären, was die einzelnen Ebenen enthalten und welche Abhängigkeiten zwischen den Ebenen bestehen.

Alternatives hybrides Mesh-Architekturdesign für Geschäftswert

Je weiter wir uns in der Datenwertschöpfungskette nach unten bewegen, desto mehr Abhängigkeiten verflechten die Geschäftseinblicke. Denken Sie zum Beispiel an die Notwendigkeit, verschiedene Fakten zu aggregieren, Profile oder Segmente von Kunden oder Produkten zu erstellen und Aktionen auf der Grundlage der Profile zu automatisieren.

Um den realen Geschäftsanforderungen gerecht zu werden, müssen Daten aus verschiedenen Bereichen oft am Ende des Prozesses zusammengeführt werden, wo die Daten in einen Geschäftswert umgewandelt werden. Die bestehende Hub-and-Spoke-Lösung kommt in erster Linie dem Datenentwicklungsprozess zugute, ist aber nicht für die Wertschöpfung aus Daten optimiert.

Beachten Sie den Abstand zwischen der Einfachheit des Hub-and-Spoke-Konzepts in Abbildung 2 und der tatsächlichen Komplexität bei der Implementierung, die in Abbildung 3 dargestellt ist.

Um den Anforderungen der realen Welt an die Datenmodellierung zur Schaffung von Geschäftswerten besser gerecht zu werden und die Komplexität der Architektur in der Praxis zu reduzieren, schlage ich ein alternatives Design zum Hub & Spoke-Muster vor: die Hybrid Mesh Constellation Architecture.

[Abbildung 4: Entwurfsmuster für hybride Maschenkonstellationen]

Das Constellation-Design (Abbildung 4) folgt ähnlichen Regeln wie die praktische Hub-and-Spoke-Lösung. Im Vorfeld wird eine zentrale Integrationsschicht eingerichtet, die als Grundlage für die Entwicklung des Bereichs dient. Am Ende wird eine weitere zentrale Schicht hinzugefügt, auf der Daten aus dem gesamten Unternehmen aggregiert werden, um ganzheitliche Erkenntnisse für das Unternehmen zu gewinnen.

[Abbildung 5: Hybride Mesh-Konstellationsarchitektur in der Praxis]

Die Constellation Architecture in der Praxis (Abbildung 5) folgt diesen Prinzipien:

Querverweise zwischen Domänen sind nicht erlaubt.
Wenn Daten von verschiedenen Domänen gemeinsam genutzt werden müssen, legen Sie sie auf der zentralen Integrationsebene ab.
Alle Aggregationen werden nachgelagert in der zentralen Aggregationsschicht implementiert, unabhängig davon, ob die Aggregation domänenspezifisch oder domänenübergreifend ist.
Die zentrale Aggregationsschicht ermöglicht nur die Aggregation und die notwendige nachgelagerte Reintegration, die auf Aggregationen beruht (z. B. ein Customer360-Modell, das mehrere Aggregationen kombiniert). Andere Arten der Integration müssen vorgelagert in der zentralen Integration erfolgen.

In Teil 2 dieses Artikels werde ich die verschiedenen Ebenen dieser Architektur näher erläutern und einen praktikablen Entscheidungsablauf skizzieren.

Hybride Netze als Governance-Architektur

Inzwischen haben Sie sicher den Elefanten im Raum bemerkt: Durch die Verlagerung von Daten an einen zentralen Ort (bei der Lösung der Probleme der hybriden Mesh-Implementierung) kehrt unsere Architektur zur traditionellen zentralisierten Architektur zurück und entfernt sich vom Mesh. Warum haben wir uns also überhaupt für die Implementierung eines Mesh-Musters entschieden?

Ich wende die Mesh-Prinzipien nicht auf die Herkunft der Datenmodelle an, sondern auf ihre Eigenschaften.

Betrachten Sie Hybrid Mesh weniger als Residenzarchitektur, sondern eher als Governance-Architektur. Ich plädiere für eine zentralisierte Datenresidenz mit demokratisierter Ausführung.

In Teil 2 werde ich die gesamte Governance-Architektur im Detail erläutern, einschließlich praktischer Richtlinien zum Thema "wer macht was und wann".

On-Demand ansehen

KI oder ROI? Architektur für den Erfolg

Lassen Sie Ihre Plattform nicht zu einem "goldenen Käfig" werden! Diese Sitzung ist wichtig für Führungskräfte, die den Erfolg von KI durch intelligentes Plattformdesign maximieren wollen.

Die wichtigsten Erkenntnisse:
- Die Rolle von Plattformen: Warum sie für die Skalierung von KI entscheidend sind.
- Benutzerzentriertes Design: Das Gleichgewicht zwischen Kontrolle und Benutzerfreundlichkeit.
- Praktische Schritte: Wie man Plattformen entwirft, die einen echten Mehrwert liefern.

Jetzt beobachten