Die richtige Datenarchitektur für die Organisation wählen, die Sie tatsächlich haben

Entscheidungen zur Datenarchitektur sind immer folgenreicher geworden, da Organisationen stärker auf Analysen, Automatisierung und KI setzen. Der Druck ist verständlich. Führungskräfte wünschen sich sauberere Berichte, schnellere Erkenntnisse, bessere Governance und Daten, die für Teams und Systeme leichter nutzbar sind. Das Problem besteht darin, dass Gespräche über moderne Datenarchitekturen oft in Trendbegriffe abgleiten, bevor die Organisation eine grundlegendere Frage beantwortet hat: Welches Betriebsmodell können wir tatsächlich unterstützen?

In diesem Zusammenhang tauchen häufig zwei Ansätze auf: Data Mesh und Data Fabric. Sie werden oft so diskutiert, als handle es sich um konkurrierende Technologien. Diese Darstellung ist zu vereinfachend. Data Mesh ist in erster Linie ein Betriebsmodell, das auf Domänenverantwortung und Daten als Produkt basiert. Data Fabric ist in erster Linie eine Integrations- und Governance-Architektur, die Metadaten, Automatisierung und Vernetzung nutzt, um Daten systemübergreifend leichter auffindbar, steuerbar und nutzbar zu machen.

Beide Ansätze können wertvoll sein. Beide können jedoch auch kostspielige Probleme verursachen, wenn sie aus den falschen Gründen ausgewählt werden. Ein Data-Mesh-Vorhaben kann scheitern, wenn Domänenteams noch nicht bereit sind, Verantwortung für Datenprodukte zu übernehmen. Ein Data-Fabric-Vorhaben kann scheitern, wenn die Organisation die Plattform als magische Schicht betrachtet, die schlechte Datenqualität, unklare Verantwortlichkeiten oder schwache Governance ausgleichen wird.

Die richtige Frage lautet nicht: „Welche Architektur ist besser?“ Die bessere Frage lautet: „Welches Modell passt zur Reife, Governance-Kultur, Teamstruktur und den kurzfristigen Geschäftszielen der Organisation?“

Data Mesh: Verantwortung als Architektur

Data Mesh verändert die Frage, wer für Daten verantwortlich ist. Statt sich auf ein zentrales Datenteam zu verlassen, das Daten für alle anderen sammelt, bereinigt, modelliert, dokumentiert und bereitstellt, verlagert Data Mesh die Verantwortung näher an die Geschäftsdomänen, die die Daten am besten verstehen.

In einem ausgereiften Data-Mesh-Modell veröffentlichen Domänenteams Daten als Produkte. Das bedeutet, dass die Daten nicht einfach in eine gemeinsame Umgebung gekippt werden. Es gibt klare Verantwortlichkeiten, Dokumentation, Qualitätserwartungen, Zugriffsmuster und eine definierte Zielgruppe. Das Domänenteam ist dafür verantwortlich, die Daten für andere nutzbar zu machen, und nicht nur dafür, sie für den eigenen operativen Bedarf zu erzeugen.

Das ist das Versprechen. Die Herausforderung besteht darin, dass dies nicht nur eine technologische Veränderung ist. Es ist eine organisatorische Veränderung. Flexera beschreibt Data Mesh als einen dezentralisierten Ansatz, der domänenspezifische Teams befähigt, ihre Daten zu verwalten und dafür Verantwortung zu übernehmen. Alation stellt den Ansatz als hilfreich dar, wenn das zugrunde liegende Problem unklare Verantwortlichkeiten, Engpässe in einem zentralen Datenteam oder uneinheitliche Datenqualität in verschiedenen Domänen umfasst. Das sind reale Probleme, aber ihre Lösung erfordert mehr als die Installation eines Tools. Sie erfordert Domänenteams, die über Zeit, Fähigkeiten, Anreize und Unterstützung verfügen, um verantwortliche Datenbesitzer zu werden.

Hier geraten viele Data-Mesh-Initiativen in Schwierigkeiten. Ein Führungsteam mag die Idee der Dezentralisierung begrüßen, aber die Domänenteams verfügen möglicherweise nicht über eine einheitliche Datenreife. Eine Gruppe kann über starke Analysefähigkeiten und saubere operative Systeme verfügen. Eine andere ist möglicherweise auf Tabellenkalkulationen, informelle Definitionen und manuelle Bereinigung angewiesen. Diese Domänen als gleichermaßen bereit für die Verantwortung über Datenprodukte zu behandeln, kann mehr statt weniger Uneinheitlichkeit schaffen.

Data Fabric: Automatisierung und Vernetzung als Architektur

Data Fabric verfolgt einen anderen Weg. Statt mit dezentralisierter Verantwortung zu beginnen, konzentriert sich der Ansatz darauf, Daten in einer komplexen Umgebung zu verbinden, zu steuern und nutzbar zu machen. Eine Data Fabric kann Metadaten, Katalogisierung, Datenherkunft, Zugriffsrichtlinien, Automatisierung und Integrationsschichten verwenden, damit Teams Daten über Data Warehouses, Data Lakes, Anwendungen, Cloud-Plattformen und operative Systeme hinweg finden und nutzen können.

Das kann für Organisationen attraktiv sein, die schneller einen Nutzen erzielen müssen oder deren Daten über viele Systeme verteilt sind, die aber noch nicht bereit für ein umfassendes Modell mit Domänenverantwortung sind. Atlan beschreibt Data Fabric als einen Ansatz, der weniger kulturelle Umbrüche als Data Mesh erfordert, dafür aber mehr technische Reife. SAP beschreibt Data Fabric ebenfalls als einen Ansatz, der sich darauf konzentriert, wie Daten verbunden, gesteuert und nutzbar gemacht werden, während Data Mesh den Schwerpunkt darauf legt, wie die Verantwortung für Daten verteilt wird.

Der Vorteil ist praktisch. Eine Data Fabric kann dazu beitragen, manuelle Integrationsarbeit zu reduzieren, die Einheitlichkeit der Governance zu verbessern und Teams einen stärker vereinheitlichten Zugriff auf Daten zu ermöglichen, ohne jedes Domänenteam vom ersten Tag an zu einer vollständig ausgereiften Organisation für Datenprodukte machen zu müssen.

Doch Data Fabric birgt eigene Risiken. Wenn die Plattform zum Ort wird, an dem jedes Problem rund um Datenzugriff, Governance, Transformation und Integration gelöst werden muss, kann sie zu einem neuen Engpass werden. Die Organisation zentralisiert möglicherweise die Komplexität unter einem moderneren Namen. Wenn die Metadaten unzureichend, die Quellsysteme unübersichtlich oder die Verantwortlichkeiten unklar sind, kann die Fabric diese Probleme sichtbar machen, statt sie zu lösen.

Die beiden Modelle lösen unterschiedliche Probleme

Die nützlichste Art, Data Mesh und Data Fabric zu vergleichen, besteht darin, zu fragen, welches Problem die Organisation tatsächlich lösen möchte.

Wenn das größte Problem darin besteht, dass die Verantwortung für Daten unklar ist, zentrale Datenteams überlastet sind, Domänenteams gemeinsamen Datensätzen nicht vertrauen und Fachexperten zu weit von Entscheidungen über Datenprodukte entfernt sind, kann Data Mesh die bessere langfristige Richtung sein.

Wenn das größte Problem fragmentierte Systeme, uneinheitlicher Zugriff, manuelle Governance, schwache Datenherkunft, schlechte Auffindbarkeit und zu viel Reibung beim Verschieben von Daten zwischen Umgebungen sind, kann Data Fabric der praktischere erste Schritt sein.

Viele Organisationen werden letztlich Elemente aus beiden Ansätzen benötigen. SAP beschreibt die beiden Ansätze als unterschiedlich, aber ergänzend: Data Mesh gibt Domänenteams mehr Kontrolle, während Data Fabric eine technische Grundlage für die Verbindung und Steuerung von Daten im gesamten Unternehmen bereitstellt. Diese hybride Sichtweise ist oft realistischer, als die Entscheidung als Entweder-oder-Wahl zu behandeln.

Dennoch kommt es auf die Reihenfolge an. Eine Organisation, die noch nicht für verteilte Verantwortung bereit ist, kann Schwierigkeiten bekommen, wenn sie direkt in Data Mesh einsteigt. Eine Organisation, die ausschließlich in eine Fabric-Schicht investiert, kann ebenfalls Probleme bekommen, wenn niemand die Bedeutung, Qualität und den Nutzen der verbundenen Daten verantwortet.

Häufige Fehler bei Data Mesh

Fehler bei Data Mesh entstehen häufig dadurch, dass das Betriebsmodell unterschätzt wird. In Strategiebesprechungen mag die Architektur elegant klingen, doch die tägliche Arbeit ist weniger glamourös.

Teams führen Tools ein, bevor die Domänenteams verstanden haben, was es bedeutet, Verantwortung für ein Datenprodukt zu übernehmen.
Die Führung unterschätzt den organisatorischen Wandel, der für verteilte Entscheidungsfindung erforderlich ist.
Die Organisation geht davon aus, dass die Datenreife in allen Domänen gleich ist, obwohl dies nur selten der Fall ist.
Die Governance wird nur dem Namen nach dezentralisiert, während Genehmigungen und Standards weiterhin über ein zentrales Team als Engpass laufen.
Domänenteams erhalten Verantwortung, ohne über die Kapazitäten, Schulungen oder Anreize zu verfügen, um hochwertige Datenprodukte zu pflegen.

Das Ergebnis kann frustrierend sein. Die Organisation glaubt möglicherweise, sie dezentralisiere, hat aber lediglich die Verwirrung verteilt. Statt eines zentralen Engpasses gibt es nun uneinheitliche Praktiken in den Domänen, lückenhafte Dokumentation, unklare Standards und ein Governance-Modell, dem niemand vollständig vertraut.

Häufige Fehler bei Data Fabric

Data-Fabric-Initiativen scheitern auf andere Weise. Das Risiko besteht weniger darin, Verantwortung zu schnell zu verteilen, sondern eher darin, anzunehmen, dass die Plattform die gesamte darunterliegende Unordnung auffängt.

Teams betrachten die Fabric als universelle Lösung für eine schlechte Qualität der Quelldaten.
Metadaten, Datenherkunft und Katalogisierung werden als technische Pflichtaufgaben statt als Grundlagen der Governance behandelt.
Die Organisation verbindet Systeme, ohne zu klären, wer für zentrale Definitionen, Kennzahlen und Erwartungen an die Datenqualität verantwortlich ist.
Der Zugriff wird einfacher, aber das Vertrauen verbessert sich nicht, weil die Nutzer weiterhin nicht wissen, welche Daten korrekt sind.
Die Fabric-Plattform wird zu einer Abhängigkeit, die fortlaufende Investitionen, architektonische Disziplin und operative Verantwortung erfordert.

Eine Data Fabric kann die Navigation durch die Datenumgebung erleichtern. Sie kann schlechte Daten jedoch nicht von selbst in gute Daten verwandeln. Sie kann widersprüchliche Definitionen von Umsatz, Kunde, Bestand, Auslastung oder Risiko nicht auflösen. Das sind Fragen des Geschäfts und der Governance, für die weiterhin menschliche Verantwortung erforderlich ist.

Auswahlkriterien, die wirklich zählen

Bevor Führungskräfte eine Richtung wählen, sollten sie die Organisation ehrlich bewerten. Die wichtigsten Kriterien sind nicht abstrakt.

Reifegrad der Fachbereiche: Können die Fachbereiche Datenprodukte mit angemessener Konsistenz definieren, pflegen, dokumentieren und unterstützen?
Stärke der Governance: Verfügt die Organisation bereits über klare Standards für Qualität, Zugriff, Datenherkunft, Datenschutz und Verantwortlichkeiten?
Technische Kompetenz: Können die Teams die erforderliche Plattform sowie die Prozesse für Automatisierung, Integration, Katalogisierung, Überwachung und Support betreiben?
Kulturelle Bereitschaft: Ist die Organisation mit verteilter Verantwortung vertraut, oder hängt die Entscheidungsfindung weiterhin stark von zentraler Kontrolle ab?
Ziele für KI und Analytik: Benötigt die Organisation gesteuerte, wiederverwendbare Datenprodukte für fortgeschrittene Anwendungsfälle, oder braucht sie zunächst bessere Vernetzung und Auffindbarkeit?
Veränderungskapazität: Wie viel organisatorische Veränderung kann das Unternehmen aufnehmen und gleichzeitig das Tagesgeschäft bewältigen?

Diese Kriterien sollen den Fortschritt nicht verlangsamen. Sie helfen, kostspielige Scheinlösungen zu vermeiden. Eine Datenstrategie, die den Reifegrad ignoriert, wird meist zu einer Tool-Implementierung. Eine Tool-Implementierung, die Verantwortlichkeiten ignoriert, wird meist zu einem weiteren Datenbereinigungsprojekt mit einem besseren Dashboard.

Wie Ridiculous Engineering diese Entscheidung betrachtet

Bei Ridiculous Engineering betrachten wir Datenarchitektur sowohl als technisches als auch als organisatorisches Designproblem. Schema, Plattform, Integrationen und Automatisierung sind wichtig. Ebenso wichtig sind Verantwortlichkeiten, Prozesse, Governance, Anreize und die Fähigkeit der Teams, das Erstellte zu pflegen.

Dies ist besonders wichtig, da sich Organisationen auf KI-gestützte Arbeitsabläufe vorbereiten. KI-Systeme sind nur so nützlich wie das Datenumfeld, in dem sie eingesetzt werden. Wenn Daten schlecht gesteuert, uneinheitlich definiert, schwer nachzuverfolgen oder über Systeme ohne klare Verantwortlichkeiten verstreut sind, verwandelt KI sie nicht auf magische Weise in zuverlässige Geschäftsinformationen. Sie erzeugt möglicherweise lediglich selbstsicherere Antworten aus schwachen Eingaben.

Unsere Aufgabe besteht darin, Kunden dabei zu helfen, gerade lange genug innezuhalten, um die richtige Architekturentscheidung zu treffen, bevor sie sich auf einen kostspieligen Weg festlegen. Das kann bedeuten, den aktuellen Datenreifegrad zu bewerten, Fachbereiche und Verantwortlichkeiten zu kartieren, Governance-Lücken zu identifizieren, Optionen für Datenplattformen zu prüfen, Integrationen zu modernisieren oder eine schrittweise Roadmap zu entwickeln, die der Organisation bessere Daten verschafft, ohne sie zu einem Reifegradmodell zu zwingen, das sie noch nicht unterstützen kann.

Manchmal ist die richtige Antwort, sich in Richtung Data Mesh zu bewegen. Manchmal ist es sinnvoll, zunächst in eine Data-Fabric-Schicht zu investieren. In anderen Fällen ist ein hybrider Ansatz der praktikable Weg: Er verbessert Vernetzung und Governance und bereitet die Fachbereichsteams schrittweise darauf vor, im Laufe der Zeit Datenprodukte höherer Qualität zu verantworten.

Die Entscheidung sollte zur Realität passen, nicht zur Wunschvorstellung

Data Mesh und Data Fabric sind keine Zauberwörter. Sie sind unterschiedliche Methoden, Verantwortung, Governance und Zugriff in einer komplexen Datenumgebung zu organisieren. Sie können zusammen funktionieren, aber nur, wenn die Organisation versteht, welches Problem jeder Ansatz lösen soll.

Die Gefahr besteht darin, sich von Wunschvorstellungen leiten zu lassen. Ein Unternehmen möchte vielleicht dezentral organisiert sein, arbeitet aber weiterhin mit zentraler Entscheidungsfindung und einem uneinheitlichen Reifegrad der Fachbereiche. Ein anderes strebt möglicherweise eine ausgefeilte Data Fabric an, verfügt jedoch nicht über die erforderliche Disziplin bei Metadaten und die operative Verantwortung, um sie zuverlässig zu halten. In beiden Fällen beginnt die Architektur, sich von der Realität zu entfernen.

Der bessere Ansatz ist ehrlicher. Beginnen Sie dort, wo die Organisation tatsächlich steht. Verstehen Sie, welche Datenprobleme die größten Reibungsverluste verursachen. Identifizieren Sie Lücken bei den Verantwortlichkeiten. Entscheiden Sie, welche Fähigkeiten zuerst verbessert werden müssen. Wählen Sie anschließend eine Architektur, die die nächste Reifestufe unterstützt, statt so zu tun, als hätte die Organisation sie bereits erreicht.

Wenn Ihre Organisation Data Mesh, Data Fabric oder ein umfassenderes Vorhaben zur Datenmodernisierung prüft, kann Ridiculous Engineering Sie dabei unterstützen, die Zielkonflikte zu bewerten, eine realistische Roadmap zu entwerfen und die Systeme sowie Betriebsmodelle aufzubauen, die erforderlich sind, damit die Architektur in der Praxis einen Nutzen bringt.

Die beste Datenarchitektur ist nicht die mit dem modischsten Namen. Es ist diejenige, die Ihre Organisation betreiben, steuern, ihr vertrauen und im Laufe der Zeit verbessern kann.

Quellen und weiterführende Literatur: Flexera: Data Mesh vs. Data Fabric, Alation: Data Fabric vs. Data Mesh, Atlan: Data Mesh vs. Data Fabric, SAP: Data Fabric vs. Data Mesh, Apptad: Data Mesh vs. zentralisiertes Data Warehouse

Data Mesh oder Data Fabric: Die Dezentralisierungsentscheidung, die Millionen kostet