Data Mesh vs. Data Fabric vs. Data Lakehouse: Was wirklich Sinn macht

Die Ausgangslage: Drei Begriffe, eine Verwirrung

Wer heute als Chief Data Officer eine Datenstrategie verantwortet, hört drei Begriffe sehr häufig: Data Mesh, Data Fabric und Data Lakehouse. Anbieter positionieren sie oft als Alternativen. Berater empfehlen mal das eine, mal das andere. Und im Vorstand bleibt die Frage hängen: Welche Datenarchitektur brauchen wir eigentlich?

Die ehrliche Antwort lautet: Die Frage ist falsch gestellt. Die drei Konzepte liegen auf unterschiedlichen Ebenen.

Wer sie direkt vergleicht, vergleicht ein Organigramm mit einem Netzwerkplan und einem Gebäude. Alle drei sind wichtig. Aber sie beantworten verschiedene Fragen.

In diesem Artikel ordnen wir die Begriffe sauber ein. Wir zeigen, wann welcher Ansatz Sinn macht, wo die typischen Fehler liegen und wie Sie eine Entscheidung treffen, die auch in fünf Jahren noch trägt. Dabei schauen wir bewusst auch auf den Teil, der in den meisten Architekturdebatten fehlt: die Qualität und Konsistenz der Stammdaten, die durch jede dieser Architekturen fließen.

Was ist Data Mesh, Data Fabric und Data Lakehouse?

Bevor wir vergleichen, brauchen wir klare Definitionen. Viele Missverständnisse entstehen, weil die Begriffe unscharf verwendet werden. Die folgenden Definitionen stützen sich auf die Primärquellen der jeweiligen Konzepte.

Data Mesh: Definition

Data Mesh ist ein dezentrales, soziotechnisches Organisationsmodell für analytische Daten. Fachdomänen übernehmen die Verantwortung für ihre Daten und stellen sie als Datenprodukte bereit – auf einer gemeinsamen Self-Service-Plattform und unter föderierter Governance.

Den Begriff prägte Zhamak Dehghani, damals bei Thoughtworks, im Mai 2019. Ihr Ausgangspunkt war eine Beobachtung: Zentrale Datenplattformen auf Basis eines Data Lake hätten „gemeinsame Fehlermuster, die im großen Maßstab zu unerfüllten Versprechen führen”. Ein zentrales Datenteam wird zum Flaschenhals, weil es die Fachlichkeit aller Domänen verstehen müsste.

Im Dezember 2020 formulierte Dehghani vier Prinzipien:

1. Domänenorientierte, dezentrale Daten-Ownership: Die Fachbereiche, die Daten erzeugen, sind auch für deren analytische Bereitstellung verantwortlich.

2. Daten als Produkt: Daten werden wie ein Produkt behandelt – mit klaren Konsumenten, Qualitätszusagen und Dokumentation.

3. Self-Service-Dateninfrastruktur als Plattform: Eine zentrale Plattform nimmt den Domänen die technische Komplexität ab.

4. Föderierte, automatisierte Governance: Globale Standards werden gemeinsam festgelegt und möglichst automatisiert in der Plattform durchgesetzt.

Wichtig ist: Data Mesh ist keine Software, die man kaufen kann. Es ist vor allem eine Entscheidung darüber, wer im Unternehmen für Daten verantwortlich ist. Die Technologie folgt dieser Entscheidung.

Data Fabric: Definition

Data Fabric ist ein Architektur- und Designkonzept, das verteilte Datenquellen über eine metadatengetriebene Integrationsschicht verbindet. Ziel ist ein einheitlicher, möglichst automatisierter Zugriff auf Daten – unabhängig davon, wo sie physisch liegen.

Gartner beschreibt Data Fabrics als „flexible, belastbare Integration von Daten über Plattformen und Geschäftsanwender hinweg”. IBM definiert die Data Fabric als moderne Datenarchitektur, die mit „intelligenten und automatisierten Systemen” Silos aufbricht und Datenmanagement im großen Maßstab optimiert.

Der Kern einer Data Fabric sind Metadaten. Gemeint sind nicht nur technische Metadaten wie Tabellennamen und Datentypen. Gemeint sind auch Geschäftsbegriffe, Datenherkunft (Lineage), Nutzungsmuster und Qualitätsmerkmale. Aus diesen Metadaten kann eine Data Fabric Empfehlungen ableiten, Integrationen teilweise automatisieren und Richtlinien zentral durchsetzen.

Anders als Data Mesh setzt Data Fabric nicht primär an der Organisation an. Es setzt an der Technik an. Die Verantwortung für Daten kann zentral bleiben oder verteilt sein – die Fabric funktioniert in beiden Fällen.

Data Lakehouse: Definition

Ein Data Lakehouse ist eine Plattformarchitektur, die kostengünstigen, offenen Objektspeicher eines Data Lake mit den Management- und Performance-Funktionen eines Data Warehouse kombiniert – etwa ACID-Transaktionen, Versionierung, Indizierung und Abfrageoptimierung.

Das Konzept wurde 2021 in einem wissenschaftlichen Paper von Michael Armbrust, Ali Ghodsi, Reynold Xin und Matei Zaharia (Databricks, UC Berkeley, Stanford) beschrieben. Die Autoren definieren das Lakehouse als „Datenmanagementsystem auf Basis von kostengünstigem und direkt zugänglichem Speicher, das zugleich klassische analytische DBMS-Funktionen bietet”.

Die Motivation war ein Problem der damals verbreiteten Zwei-Ebenen-Architektur aus Data Lake und Data Warehouse. Laut dem Paper ist es „schwierig und teuer”, beide Systeme konsistent zu halten. Neue Daten bräuchten oft Tage, bis sie im Warehouse ankommen. Und Unternehmen zahlten doppelt für Speicher, weil Daten kopiert werden.

In der Praxis wird ein Lakehouse häufig in Schichten organisiert. Databricks nennt dieses Muster Medallion-Architektur: Eine Bronze-Schicht mit Rohdaten, eine Silber-Schicht mit bereinigten und zusammengeführten Daten und eine Gold-Schicht mit konsumfertigen Datenmodellen. Die Silber-Schicht soll laut Databricks eine „Enterprise-Sicht” auf alle zentralen Geschäftsobjekte liefern. Genau hier entscheidet sich, ob die Daten konsistent sind – dazu später mehr.

Zum Vergleich: Data Lake und Data Warehouse

Um die drei Konzepte einzuordnen, lohnt ein Blick auf ihre Vorgänger.

Ein Data Warehouse führt laut IBM Daten aus verschiedenen Quellen in einem zentralen Speicher zusammen, der für Abfragen und Analysen optimiert ist. Die Daten werden vor dem Laden bereinigt und in ein festes Schema gebracht. Das macht Warehouses verlässlich für Reporting. Es macht sie aber auch starr und teuer bei großen, unstrukturierten Datenmengen.

Ein Data Lake speichert laut IBM große Mengen Rohdaten „im Originalzustand”, meist in günstigem Cloud-Objektspeicher. Das schafft Flexibilität, etwa für Machine Learning. IBM warnt aber auch vor dem bekannten Risiko: Ohne Metadaten, Struktur und Governance werden Data Lakes zu „Data Swamps”, in denen gute Daten nicht mehr auffindbar sind.

Wie sich ein Data Warehouse von operativem Master Data Management unterscheidet, haben wir in einem eigenen Beitrag beschrieben: Data Warehouse vs. Multi-Domain Master Data Management.

Kurze Geschichte der Datenarchitektur

Die drei Konzepte sind Antworten auf Probleme ihrer Vorgänger. Wer die Entwicklung kennt, versteht besser, welches Problem jedes Konzept löst.

Die letzte Zeile ist bemerkenswert. Nach Jahrzehnten der Diskussion über Speicher, Plattformen und Organisation rückt die Frage nach der Bedeutung der Daten in den Mittelpunkt. Genau das ist der Kern von Stammdatenmanagement.

Die Einordnung in einem Satz

Ein einfaches Bild hilft. Stellen Sie sich Ihre Datenlandschaft als Stadt vor:

• Data Lakehouse ist das Gebäude, in dem Daten gelagert und verarbeitet werden.

• Data Fabric ist das Straßen- und Leitungsnetz, das alle Gebäude miteinander verbindet.

• Data Mesh ist die Stadtverwaltung: Es regelt, welches Viertel wofür zuständig ist und nach welchen gemeinsamen Regeln gebaut wird.

• Stammdaten sind das Grundbuch und der Stadtplan. Ohne sie weiß niemand, welches Grundstück wem gehört und welche Straße wohin führt.

Dieses Bild zeigt bereits die zentrale These dieses Artikels: Die Frage lautet selten „Mesh oder Fabric oder Lakehouse?“. Sie lautet: „Welche Kombination passt zu unserer Organisation – und haben wir das Fundament dafür?”

Warum ist die Wahl der Datenarchitektur 2026 so relevant?

Die Architekturfrage ist kein Technik-Detail mehr. Sie entscheidet darüber, ob KI-Projekte skalieren, ob regulatorische Anforderungen erfüllt werden und ob Investitionen in Datenplattformen sich auszahlen. Fünf Kennzahlen zeigen, warum.

KPI 1: KI scheitert an Daten, nicht an Modellen

Gartner prognostiziert, dass Unternehmen bis Ende 2026 60 % der KI-Projekte abbrechen werden, die nicht durch KI-fähige Daten gestützt sind. In derselben Erhebung unter 1.203 Datenmanagement-Verantwortlichen gaben 63 % an, nicht über die richtigen Datenmanagement-Praktiken für KI zu verfügen – oder sich darüber nicht sicher zu sein.

Für die Architekturfrage heißt das: Ein neues Lakehouse oder eine Data Fabric löst das Problem nicht automatisch. Es kommt darauf an, ob die Daten darin vertrauenswürdig, konsistent und semantisch verständlich sind.

KPI 2: Erfolgreiche Unternehmen investieren ins Fundament

Eine Gartner-Umfrage unter 353 D&A- und KI-Verantwortlichen zeigt: Unternehmen mit erfolgreichen KI-Initiativen investieren bis zu viermal mehr (gemessen am Umsatz) in Grundlagen wie Datenqualität, Governance und Change Management als Unternehmen mit schwachen KI-Ergebnissen. Unternehmen mit der höchsten Reife bei KI-fähigen Daten erzielen laut Gartner bis zu 65 % bessere Geschäftsergebnisse.

KPI 3: Governance-Initiativen scheitern ohne Geschäftsbezug

Gartner erwartet, dass bis 2027 80 % der Data-and-Analytics-Governance-Initiativen scheitern – mangels einer echten oder bewusst herbeigeführten Krise. Gartner-Analyst Saul Judah bringt es auf den Punkt: „Ein D&A-Governance-Programm, das keine priorisierten Geschäftsergebnisse ermöglicht, scheitert.”

Für Data Mesh ist das besonders relevant. Föderierte Governance ist eines seiner vier Prinzipien. Wer Governance nicht an Geschäftsziele knüpft, verteilt beim Mesh vor allem die Unordnung.

KPI 4: Semantik wird zum Kostenfaktor

Im Mai 2026 prognostizierte Gartner: Unternehmen, die Semantik in KI-fähigen Daten priorisieren, werden bis 2027 die Genauigkeit ihrer agentischen KI um bis zu 80 % steigern und Kosten um bis zu 60 % senken. Gartner empfiehlt, eine Kontextschicht als festen Bestandteil der D&A-Infrastruktur aufzubauen.

Semantik bedeutet hier: Alle Systeme verstehen unter „Kunde”, „Gesellschaft” oder „Produkt” dasselbe. Genau diese gemeinsame Bedeutung stiften Stammdaten und ein konsistenter Golden Record.

KPI 5: Deutsche Unternehmen nutzen ihr Datenpotenzial kaum

Laut Bitkom-Studie zur Datenökonomie schöpfen 60 % der deutschen Unternehmen ab 20 Beschäftigten ihr Datenpotenzial „eher wenig” oder „überhaupt nicht” aus. Befragt wurden 605 Unternehmen. Auch auf Führungsebene ist das Bild ähnlich: In der Deloitte-CDAO-Umfrage 2026 gaben 95 % der befragten Chief Data and Analytics Officers an, ihr Unternehmen nutze den Wert seiner Daten nicht voll aus. 61 % nannten Datenqualität und Datenzugang als kritisch für den KI-Erfolg.

Die Kennzahlen im Überblick

Die Botschaft dieser Zahlen ist eindeutig. Unternehmen haben selten ein Speicher- oder Rechenproblem. Sie haben ein Problem mit Verantwortung, Bedeutung und Qualität ihrer Daten. Jede Architekturentscheidung muss sich daran messen lassen, ob sie dieses Problem löst.

Die 4 Wurzelursachen: Warum Datenarchitekturen ihre Versprechen nicht halten

Data Warehouse, Data Lake, Data Lakehouse – jede Generation versprach, das Datenproblem endgültig zu lösen. Trotzdem stehen viele Unternehmen heute vor ähnlichen Fragen wie vor zehn Jahren. Das liegt selten an der gewählten Technologie. Es liegt an vier Ursachen, die jede Architektur erbt, wenn niemand sie aktiv angeht.

Wurzelursache 1: Verantwortung ohne Fachlichkeit

In vielen Unternehmen ist ein zentrales Daten- oder BI-Team für alle analytischen Daten zuständig. Dieses Team kennt die Technik, aber nicht jede Fachlichkeit. Es weiß, wie man eine Pipeline baut. Es weiß aber nicht immer, warum der Vertrieb einen Kunden anders zählt als die Buchhaltung.

Genau diese Beobachtung war der Ausgangspunkt von Data Mesh. Dehghani beschreibt, dass zentrale Plattformen Daten-Ownership an einer Stelle bündeln und Spezialisten von Datenquellen und Datenkonsumenten isolieren. Das Ergebnis sind lange Warteschlangen und Daten, die technisch korrekt, aber fachlich missverständlich sind.

Wurzelursache 2: Fehlende gemeinsame Bedeutung

Der zweite Grund ist semantisch. Jedes operative System hat sein eigenes Verständnis zentraler Geschäftsobjekte.

Im ERP ist ein Kunde eine Debitorennummer. Im CRM ist er ein Account mit mehreren Kontakten. Im Beteiligungsmanagement ist dieselbe Firma vielleicht eine Gesellschaft mit eigener Rechtsform und Beteiligungsquote.

Werden diese Daten in ein Lakehouse geladen oder über eine Fabric verbunden, bleiben die Widersprüche bestehen. Sie werden nur schneller sichtbar – oder schlimmer: unbemerkt in Berichte und KI-Modelle übernommen. Gartner warnt genau davor: Ohne Semantik und Geschäftskontext arbeiten KI-Agenten ungenau und neigen zu Halluzinationen.

Wurzelursache 3: Governance als Dokument statt als Prozess

Viele Governance-Programme produzieren Richtlinien, Rollenbeschreibungen und Glossare. Was fehlt, ist die Verankerung im Alltag. Eine Datenrichtlinie, die nur in einem PDF steht, wird von keiner Pipeline geprüft und von keinem Fachbereich gelebt.

Gartner bestätigt das im September 2026: In einer Umfrage unter 223 D&A-Verantwortlichen war kulturelle Ablehnung der wichtigste Grund für das Scheitern von Governance-Initiativen – wichtiger als fehlendes Budget (60 % gegenüber 40 %). Gartner-Analyst Anurag Raj ergänzt: KI-fähige Daten erfordern auch „KI-fähige Stakeholder”.

Wurzelursache 4: Architektur als Ersatz für Strategie

Die vierte Ursache ist strategisch. Unternehmen kaufen eine Plattform, bevor sie wissen, welche Geschäftsfragen sie damit beantworten wollen. Die Architekturentscheidung wird dann zur Ersatzhandlung. Man migriert vom Warehouse in den Lake, vom Lake ins Lakehouse – und stellt fest, dass sich die Datenqualität nicht verändert hat.

Eine Architektur ist ein Werkzeug. Sie verstärkt, was bereits da ist. Klare Verantwortung, gemeinsame Begriffe und gute Stammdaten werden durch eine moderne Architektur wertvoller. Unklare Verantwortung, widersprüchliche Begriffe und schlechte Stammdaten werden durch sie nur teurer.

Kein Architekturproblem, sondern ein Ownership- und Semantikproblem

An dieser Stelle lohnt ein Perspektivwechsel. Die Debatte „Data Mesh vs. Data Fabric vs. Data Lakehouse” wird meist als Technologiefrage geführt. In Wirklichkeit beantwortet jedes der drei Konzepte genau eine von drei Fragen:

Eine vierte Frage beantwortet keines der drei Konzepte vollständig: Was bedeuten die Daten – und welche Version ist die richtige?

Wenn das Vertriebssystem 1.200 aktive Kunden zählt und das ERP 1.450, hilft keine Architektur allein. Data Mesh macht zwei Domänen für ihre jeweilige Zahl verantwortlich – aber welche gilt? Data Fabric verbindet beide Quellen – zeigt aber zwei Wahrheiten. Das Lakehouse speichert beide Versionen performant und versioniert – löst aber nicht den Widerspruch.

Diese vierte Frage beantwortet Master Data Management. Es definiert, was ein Kunde, eine Gesellschaft oder ein Produkt ist. Es führt Dubletten zusammen und erzeugt einen Golden Record – die eine verlässliche Version eines Geschäftsobjekts. Erst diese Version macht Datenprodukte im Mesh vergleichbar, Verknüpfungen in der Fabric eindeutig und die Silber-Schicht im Lakehouse konsistent.

Der notwendige Switch lautet daher: Ihre Datenarchitektur hat kein Speicherproblem. Sie hat ein Bedeutungsproblem. Wer zuerst die Bedeutung der zentralen Geschäftsobjekte klärt, kann danach jede der drei Architekturen erfolgreicher umsetzen.

Eine ausführliche Einführung in das Thema bietet unser Beitrag Master Data Management: Definition und Praxis.

Data Mesh vs. Data Fabric vs. Data Lakehouse: Die Entscheidungstabelle

Jetzt wird es konkret. Die folgenden zwei Tabellen sind das Herzstück dieses Artikels. Die erste vergleicht die drei Konzepte systematisch – inklusive Data Lake und Data Warehouse als Referenz. Die zweite übersetzt den Vergleich in eine Entscheidung für Ihre Ausgangslage.

Systematischer Vergleich der Datenarchitekturen

Die Entscheidungstabelle für Ihre Ausgangslage

Die Empfehlungen in dieser Tabelle sind Einschätzungen auf Basis der zitierten Primärquellen und unserer Projekterfahrung, keine starren Regeln. Sie helfen Ihnen, die richtige erste Frage zu stellen.

So lesen Sie die Entscheidungstabelle

Drei Muster fallen auf.

Erstens: Data Mesh steht fast nie am Anfang. Es setzt voraus, dass Fachbereiche bereit und fähig sind, Verantwortung für Daten zu übernehmen. Wo das noch nicht der Fall ist, führt ein Mesh zu verteilter Unordnung.

Zweitens: Data Fabric und Data Lakehouse ergänzen sich häufig. Das Lakehouse speichert und verarbeitet. Die Fabric verbindet das Lakehouse mit Systemen, die nicht migriert werden.

Drittens: Eine Zeile verändert alle anderen. Wenn zentrale Geschäftsobjekte widersprüchlich sind, ist die Architekturentscheidung zweitrangig. Dann ist der erste Schritt, den Golden Record herzustellen.

Kombinationen statt Entweder-oder

In der Praxis entscheiden sich große Unternehmen selten für genau eines der drei Konzepte. Häufiger sind Kombinationen:

• Lakehouse + Fabric: Das Lakehouse ist die zentrale analytische Plattform. Die Fabric bindet operative Systeme, Altsysteme und externe Quellen an, ohne alles zu kopieren.

• Fabric + Mesh: Die Domänen verantworten Datenprodukte. Die Fabric liefert Katalog, Lineage und automatisierte Richtliniendurchsetzung. IBM beschreibt genau dieses Zusammenspiel: Eine Data Fabric stelle die Fähigkeiten bereit, um ein Data Mesh umzusetzen, indem sie viele Aufgaben bei der Erstellung von Datenprodukten automatisiere (IBM, 2024).

• Mesh + Lakehouse: Jede Domäne betreibt ihre Datenprodukte auf einer gemeinsamen Lakehouse-Plattform. Die Plattform ist das „Self-Service”-Prinzip des Mesh in technischer Form.

Auch Gartner sieht Fabric und Mesh nicht als Gegensätze. In einer Analyse vom Januar 2025 empfiehlt Gartner, beide Ansätze zu kombinieren – etwa für bessere Auffindbarkeit von Wissen, höhere Governance-Reife und eine Balance zwischen zentralen und domänenspezifischen Ergebnissen.

Die drei Ansätze im Detail: Wann sie wirklich Sinn machen

Die Tabellen geben die Richtung vor. Für eine fundierte Entscheidung brauchen Sie aber auch die Details: Was bringt jeder Ansatz konkret, was kostet er, und woran erkennen Sie, dass Sie bereit dafür sind?

Data Mesh: Wann es Sinn macht – und wann nicht

Data Mesh macht Sinn, wenn Ihr Unternehmen aus mehreren großen, fachlich eigenständigen Bereichen besteht. Typische Beispiele sind Konzerne mit mehreren Geschäftseinheiten, Banken mit getrennten Sparten oder Industrieunternehmen mit eigenständigen Werken und Produktlinien. In solchen Organisationen ist ein zentrales Datenteam fast zwangsläufig ein Engpass.

Die Vorteile:

• Fachwissen bleibt dort, wo es entsteht. Wer die Daten erzeugt, versteht sie am besten.

• Das zentrale Datenteam wird entlastet und kann sich auf die Plattform konzentrieren.

• Datenprodukte haben klare Verantwortliche, Qualitätszusagen und Konsumenten.

• Die Organisation skaliert: Neue Domänen können hinzukommen, ohne dass ein zentrales Team mitwachsen muss.

McKinsey beschreibt den Nutzen von Datenprodukten mit konkreten Werten: Neue Anwendungsfälle könnten bis zu 90 % schneller umgesetzt werden, und die Gesamtbetriebskosten könnten um 30 % sinken. Wichtig: McKinsey bezieht sich dabei auf das Prinzip „Daten als Produkt managen”, nicht auf Data Mesh als Gesamtmodell. Datenprodukte sind auch ohne vollständiges Mesh möglich.

Data Mesh macht keinen Sinn, wenn:

• Ihr Unternehmen nur wenige Fachdomänen hat und ein kleines Datenteam völlig ausreicht.

• Die Fachbereiche weder Kapazität noch Kompetenz haben, Datenprodukte zu verantworten.

• Es keine gemeinsame Plattform gibt, die den Domänen die Technik abnimmt.

• Zentrale Geschäftsobjekte noch nicht einheitlich definiert sind.

Den letzten Punkt unterschätzen viele. Im Mesh erzeugt jede Domäne eigene Datenprodukte. Wenn die Domäne „Vertrieb” einen Kunden anders identifiziert als die Domäne „Finanzen”, lassen sich ihre Datenprodukte nicht zuverlässig verknüpfen. Data Mesh braucht daher domänenübergreifende Referenzdaten – also einen gemeinsamen Golden Record für Kunden, Gesellschaften, Produkte oder Standorte.

Reifegrad-Signal: Sie sind bereit für Data Mesh, wenn mindestens eine Fachdomäne bereits heute ein Datenprodukt mit klarem Verantwortlichen, dokumentierter Qualität und echten Konsumenten betreibt.

Data Fabric: Wann es Sinn macht – und wann nicht

Data Fabric macht Sinn, wenn Ihre Datenlandschaft heterogen ist und es auch bleiben wird. Das betrifft die meisten etablierten Unternehmen im DACH-Raum: ERP-Systeme on-premises, CRM in der Cloud, Fachanwendungen in einzelnen Abteilungen, dazu Altsysteme, die niemand mehr anfassen will. Eine vollständige Migration in eine zentrale Plattform ist oft weder wirtschaftlich noch realistisch.

Die Vorteile:

• Daten bleiben, wo sie sind. Die Fabric schafft einen einheitlichen logischen Zugriff.

• Ein zentraler Katalog macht Daten auffindbar und verständlich.

• Richtlinien – etwa zu Datenschutz oder Zugriffsrechten – lassen sich zentral definieren und überall durchsetzen.

• Metadaten ermöglichen Automatisierung: von Integrationsvorschlägen bis zur Qualitätsüberwachung.

Gartner bezifferte das Potenzial 2021 deutlich: Der eigentliche Wert einer Data Fabric liege in ihrer Fähigkeit, die Datennutzung mit eingebauter Analytik dynamisch zu verbessern – und so den Aufwand für Datenmanagement um bis zu 70 % zu senken. Dieser Wert ist als Obergrenze zu lesen. Er setzt eine ausgereifte Metadatenbasis voraus.

Data Fabric macht keinen Sinn, wenn:

• Ihre Metadaten unvollständig oder veraltet sind. Eine Fabric ist nur so intelligent wie die Metadaten, auf denen sie arbeitet.

• Sie erwarten, dass die Fabric widersprüchliche Daten automatisch auflöst. Sie verbindet Daten, sie harmonisiert sie nicht.

• Ihre Datenlandschaft klein und homogen ist. Dann ist der Aufwand höher als der Nutzen.

Reifegrad-Signal: Sie sind bereit für eine Data Fabric, wenn Sie einen Datenkatalog mit Geschäftsbegriffen pflegen und wissen, welche Systeme die führenden Quellen für Ihre zentralen Geschäftsobjekte sind.

Data Lakehouse: Wann es Sinn macht – und wann nicht

Ein Data Lakehouse macht Sinn, wenn Sie heute zwei getrennte Welten betreiben: ein Data Warehouse für Reporting und einen Data Lake für Data Science. Das Lakehouse führt beide zusammen. Es ist besonders attraktiv, wenn KI und Machine Learning eine wachsende Rolle spielen und Sie dafür auch unstrukturierte Daten wie Dokumente, Logs oder Sensordaten nutzen wollen.

Die Vorteile:

• Eine Plattform für BI, Data Science und KI statt zwei getrennter Systeme.

• Offene Datenformate reduzieren die Abhängigkeit von einzelnen Anbietern. Das CIDR-Paper nennt offene, direkt zugängliche Formate wie Apache Parquet als Grundprinzip.

• ACID-Transaktionen und Versionierung schaffen Verlässlichkeit und Nachvollziehbarkeit.

• Geringere Speicherkosten durch kostengünstigen Objektspeicher.

Die Verbreitung wächst. In einer von Dremio finanzierten Umfrage unter 500 IT- und Datenverantwortlichen aus Unternehmen mit mehr als 1.000 Beschäftigten gaben 65 % an, bereits mehr als die Hälfte ihrer Analysen auf einem Data Lakehouse auszuführen. Da die Studie von einem Lakehouse-Anbieter beauftragt wurde, sollten Sie diesen Wert als Branchenrichtwert und nicht als repräsentativen Marktanteil lesen.

Ein Data Lakehouse macht keinen Sinn, wenn:

• Ihre Analysen fast ausschließlich strukturiertes Standard-Reporting sind und Ihr bestehendes Warehouse gut funktioniert.

• Sie erwarten, dass die Plattform Datenqualität automatisch herstellt. Die Medallion-Schichten strukturieren den Prozess – die fachliche Bereinigung müssen Sie trotzdem leisten.

• Die Migration nur aus Technologie-Begeisterung erfolgt, ohne konkrete Anwendungsfälle.

Reifegrad-Signal: Sie sind bereit für ein Lakehouse, wenn Sie klar benennen können, welche Geschäftsobjekte in der Silber-Schicht als „Enterprise-Sicht” zusammengeführt werden – und aus welcher führenden Quelle diese stammen.

Die Rolle der Stammdaten in jeder Architektur

Ein Muster zieht sich durch alle drei Ansätze. Jede Architektur braucht an einer bestimmten Stelle eine verlässliche Referenz für zentrale Geschäftsobjekte:

Deshalb betrachten wir Master Data Management nicht als vierte Alternative. Es ist die Querschnittsschicht, die alle drei Architekturen tragfähig macht. Ein Multi-Domain-MDM liefert den Golden Record als Datenprodukt an das Mesh, als führende Referenz an die Fabric und als vertrauenswürdige Quelle an die Silber-Schicht des Lakehouse.

Die häufigsten Direktvergleiche im Überblick

Viele Fragen drehen sich nicht um alle drei Konzepte gleichzeitig, sondern um konkrete Paare. Die folgenden Abschnitte beantworten die drei häufigsten Vergleiche kompakt.

Data Fabric vs. Data Mesh: Der direkte Vergleich

Die beiden Begriffe werden am häufigsten verwechselt. Beide versprechen, Datensilos zu überwinden. Der Weg dorthin ist aber grundverschieden.

Die Kurzformel: Die Data Fabric verbindet Daten. Das Data Mesh verteilt Verantwortung. Wer eine heterogene Landschaft schnell nutzbar machen will, beginnt eher mit der Fabric. Wer ein zentrales Datenteam als Engpass erlebt, denkt eher in Richtung Mesh. Und wer beides erlebt, kombiniert die Ansätze.

Data Lakehouse vs. Data Warehouse: Der direkte Vergleich

Das Data Warehouse ist seit Jahrzehnten das Rückgrat des Unternehmensreportings. Das Lakehouse tritt an, es zu ergänzen oder abzulösen.

Die Kurzformel: Das Warehouse ist optimal für bekannte Fragen. Das Lakehouse ist optimal, wenn neue Fragen und KI-Anwendungsfälle dazukommen. Ein funktionierendes Warehouse müssen Sie nicht aus Prinzip ablösen. Wenn Sie aber parallel einen Data Lake betreiben und Daten zwischen beiden kopieren, lohnt sich die Prüfung eines Lakehouse.

Data Lake vs. Data Warehouse: Der klassische Vergleich

Dieser Vergleich ist älter, aber für das Verständnis wichtig. Er erklärt, warum das Lakehouse überhaupt entstanden ist.

Viele Unternehmen betrieben lange beide Systeme parallel. Genau diese Zwei-Ebenen-Architektur beschreibt das Lakehouse-Paper als teuer und fehleranfällig. Das Lakehouse ist der Versuch, die Stärken beider Welten in einer Plattform zu vereinen.

Was das für CDOs und Data Stewards konkret bedeutet

Eine Architekturentscheidung betrifft verschiedene Rollen sehr unterschiedlich. Für die beiden wichtigsten Zielgruppen dieses Leitfadens fassen wir die Konsequenzen zusammen.

Für Chief Data Officers

Als CDO tragen Sie die Verantwortung dafür, dass die Datenstrategie messbaren Geschäftswert liefert. Für die Architekturfrage heißt das:

• Entscheiden Sie auf der richtigen Ebene. Trennen Sie die Fragen „Wer?“, „Wie?” und „Wo?“. Das macht Diskussionen mit IT, Fachbereichen und Anbietern deutlich klarer.

• Verankern Sie die Entscheidung im Geschäft. Präsentieren Sie dem Vorstand keine Architektur, sondern Anwendungsfälle mit erwartetem Nutzen.

• Sichern Sie das Fundament ab. Machen Sie Stammdatenqualität zu einem expliziten Bestandteil der Architektur-Roadmap, mit Budget und Verantwortlichen.

• Planen Sie in Stufen. Eine Zielarchitektur mit Mesh, Fabric und Lakehouse kann sinnvoll sein. Der Weg dorthin sollte aber in überschaubaren, nachweisbar erfolgreichen Etappen verlaufen.

Für Data Stewards

Als Data Steward sichern Sie die Qualität der Daten im Alltag. Für Sie verändert jede Architektur den Arbeitsalltag anders:

In allen drei Fällen bleibt Ihre zentrale Aufgabe gleich: dafür sorgen, dass ein Kunde ein Kunde ist und eine Gesellschaft eine Gesellschaft – über alle Systeme hinweg. Werkzeuge mit klaren Workflows für die Stammdatenpflege machen diese Aufgabe skalierbar.

Lösungsansatz: In 6 Schritten zur passenden Datenarchitektur

Wie kommen Sie von der Analyse zur Entscheidung? Der folgende Fahrplan hat sich als Struktur bewährt. Er ist bewusst technologieneutral. Er führt Sie von der Geschäftsfrage zur Architektur – nicht umgekehrt.

Schritt 1: Geschäftsziele und Anwendungsfälle festlegen

Beginnen Sie nicht mit der Architektur. Beginnen Sie mit drei bis fünf konkreten Anwendungsfällen, die in den nächsten 12 bis 24 Monaten Wert schaffen sollen. Beispiele: ein KI-Assistent für den Kundenservice, ein konsolidiertes Konzernreporting oder eine automatisierte Meldung an Aufsichtsbehörden.

Für jeden Anwendungsfall klären Sie: Welche Daten werden gebraucht? Wie aktuell müssen sie sein? Wer nutzt das Ergebnis? Diese Fragen bestimmen später, welche Architektur passt.

Schritt 2: Die zentralen Geschäftsobjekte identifizieren

Listen Sie die Geschäftsobjekte auf, die in mehreren Anwendungsfällen vorkommen. Meist sind es wenige: Kunde, Lieferant, Produkt, Mitarbeiter, Gesellschaft, Standort. Prüfen Sie für jedes Objekt:

• In welchen Systemen existiert es?

• Welches System ist heute führend – und ist das allen bekannt?

• Gibt es eine einheitliche Definition?

• Wie hoch ist der Anteil an Dubletten oder widersprüchlichen Datensätzen?

Dieser Schritt ist unspektakulär, aber entscheidend. Er zeigt Ihnen, ob Ihr Fundament trägt. Praktische Methoden dazu finden Sie in unserem Leitfaden Datenqualität verbessern.

Schritt 3: Organisation und Reifegrad ehrlich bewerten

Bewerten Sie Ihre Organisation entlang von vier Fragen:

1. Gibt es in den Fachbereichen Personen, die Verantwortung für Daten übernehmen können und wollen – etwa Data Owner und Data Stewards?

2. Existiert ein Governance-Gremium, das Entscheidungen trifft und durchsetzt?

3. Sind Datenrichtlinien technisch verankert oder nur dokumentiert?

4. Wie hoch ist die Datenkompetenz außerhalb der IT?

Die Antworten bestimmen, ob Data Mesh realistisch ist oder ob ein zentral geführter Ansatz besser passt. Eine strukturierte Bewertung ermöglicht der Data Governance Reifegrad Check, den wir weiter unten vorstellen.

Schritt 4: Die Systemlandschaft kartieren

Erfassen Sie Ihre bestehende Systemlandschaft: Welche Quellen gibt es? Wo liegen sie – on-premises, in der Cloud, bei Dienstleistern? Welche Systeme werden in den nächsten Jahren abgelöst, etwa im Rahmen einer S/4HANA-Migration?

Wenn viele Systeme bestehen bleiben, spricht das für eine Data Fabric. Wenn ohnehin eine Konsolidierung ansteht, kann ein Lakehouse die neue analytische Basis bilden.

Schritt 5: Die Zielarchitektur als Kombination entwerfen

Nutzen Sie jetzt die Entscheidungstabelle. Entwerfen Sie die Zielarchitektur auf drei Ebenen:

• Organisation: Zentral, föderiert oder dezentral (Mesh)?

• Integration: Wie werden Quellen verbunden und Metadaten verwaltet (Fabric-Funktionen)?

• Plattform: Wo werden Daten gespeichert und verarbeitet (Lakehouse, Warehouse oder beides)?

Ergänzen Sie eine vierte, oft vergessene Ebene: Semantik und Stammdaten. Legen Sie fest, wo der Golden Record für jedes zentrale Geschäftsobjekt entsteht und wie er an Mesh, Fabric und Lakehouse verteilt wird.

Schritt 6: Mit einem Leuchtturm starten und schrittweise skalieren

Setzen Sie nicht alles auf einmal um. Wählen Sie einen Anwendungsfall mit hohem Geschäftswert und überschaubarem Risiko. Bauen Sie dafür die notwendigen Bausteine auf: den Golden Record für die betroffenen Geschäftsobjekte, die Integration der Quellen, die Plattform für die Auswertung.

Messen Sie den Erfolg an Geschäftskennzahlen, nicht an technischen Meilensteinen. Erst wenn der erste Anwendungsfall Wert liefert, skalieren Sie auf weitere Domänen. So knüpfen Sie Governance an Geschäftsergebnisse – genau das, was laut Gartner über Erfolg und Scheitern entscheidet.

Der Fahrplan auf einen Blick

Checkliste: 10 Fragen vor der Architekturentscheidung

Bevor Sie sich auf Data Mesh, Data Fabric oder Data Lakehouse festlegen, sollten Sie die folgenden Fragen mit Ja beantworten können. Jedes Nein ist ein Hinweis auf eine Lücke, die Sie vorher schließen sollten.

• Haben wir drei bis fünf priorisierte Anwendungsfälle mit messbarem Geschäftswert?

• Sind unsere zentralen Geschäftsobjekte unternehmensweit einheitlich definiert?

• Wissen wir für jedes dieser Objekte, welches System führend ist?

• Kennen wir den Anteil an Dubletten und widersprüchlichen Datensätzen?

• Gibt es benannte Data Owner und Data Stewards in den Fachbereichen?

• Werden Governance-Regeln technisch geprüft und nicht nur dokumentiert?

• Pflegen wir einen Datenkatalog mit Geschäftsbegriffen und Datenherkunft?

• Wissen wir, welche Systeme in den nächsten drei Jahren bestehen bleiben?

• Können wir die Herkunft von Daten nachweisen, die in KI-Modelle fließen?

• Hat der Vorstand die Architekturentscheidung mit einem Geschäftsziel verknüpft?

Weniger als sechs Ja-Antworten sind ein deutliches Signal: Investieren Sie zuerst in Governance und Stammdaten. Mit sieben bis acht Ja-Antworten ist ein zentral geführtes Lakehouse oder eine Fabric realistisch. Ab neun Ja-Antworten können Sie auch über ein Data Mesh nachdenken. Diese Schwellenwerte sind eine Orientierungshilfe aus unserer Sicht, kein wissenschaftlich validiertes Modell.

Best Practices: Was in der Praxis wirklich funktioniert

Theorie ist das eine. Was unterscheidet Datenarchitekturen, die nach drei Jahren noch Wert liefern, von denen, die als teure Plattform ohne Nutzer enden? Sieben Prinzipien haben sich bewährt.

1. Semantik vor Technologie

Klären Sie die Bedeutung der zentralen Geschäftsobjekte, bevor Sie eine Plattform auswählen. Ein unternehmensweites Glossar mit verbindlichen Definitionen ist der günstigste und wirksamste Baustein jeder Datenarchitektur. Es ist zugleich die Grundlage für die Kontextschicht, die Gartner für agentische KI empfiehlt.

2. Führende Systeme eindeutig festlegen

Für jedes Geschäftsobjekt und jedes Attribut sollte klar sein, welches System führend ist. Ist das ERP führend für die Bankverbindung eines Lieferanten? Ist das Beteiligungsmanagement führend für die Rechtsform einer Gesellschaft? Diese Festlegung verhindert, dass Mesh-Domänen, Fabric-Verbindungen oder Lakehouse-Pipelines unterschiedliche Wahrheiten weitertragen.

3. Datenprodukte klein und konkret starten

Ein Datenprodukt braucht keine Mesh-Strategie für das ganze Unternehmen. Starten Sie mit einem Produkt, das einen klaren Konsumenten hat. Definieren Sie Verantwortlichen, Qualitätszusagen, Aktualisierungsrhythmus und Dokumentation. Erst wenn das funktioniert, folgt das nächste.

4. Governance in die Plattform einbauen

Föderierte Governance funktioniert nur, wenn Regeln automatisiert geprüft werden. Dehghani spricht bewusst von „computational governance” – Governance, die von der Plattform ausgeführt wird. Das gilt genauso für Fabric und Lakehouse: Zugriffsrechte, Klassifizierungen und Qualitätsregeln gehören in die Technik, nicht nur ins Handbuch. Wie ein tragfähiges Rahmenwerk aussieht, zeigt unser Beitrag zum Data Governance Framework.

5. Nachvollziehbarkeit von Anfang an

Regulatorische Anforderungen verlangen zunehmend, dass Unternehmen die Herkunft und Verarbeitung ihrer Daten belegen können. Für Hochrisiko-KI-Systeme fordert der EU AI Act in Artikel 10, dass Trainings-, Validierungs- und Testdaten „Data-Governance- und Datenverwaltungsverfahren” unterliegen. Sie sollen zudem „relevant, hinreichend repräsentativ und so weit wie möglich fehlerfrei und vollständig” sein.

Lineage in der Fabric, Versionierung im Lakehouse und eine historisierte, stichtagsbezogene Stammdatenhaltung sind die technischen Antworten darauf. Mehr zu den Pflichten finden Sie in unserem EU AI Act Leitfaden für Unternehmen.

6. Echtzeit gezielt einsetzen

Nicht jeder Anwendungsfall braucht Echtzeitdaten. Für agentische KI wird Aktualität aber wichtiger. Gartner erwartet, dass der Einsatz von Data Streaming für agentische KI von unter 15 % im Jahr 2025 auf über 60 % im Jahr 2028 steigt. Planen Sie Ihre Architektur so, dass sie Streaming dort ermöglicht, wo es Wert schafft – ohne jede Pipeline darauf auszulegen.

7. Kultur als Teil der Architektur behandeln

Die beste Architektur scheitert, wenn niemand sie lebt. Gartner empfiehlt, Data Governance als Business-Enabler und „Teamsport” neu zu positionieren und sie direkt in Geschäftsabläufe einzubetten. Für Data Stewards bedeutet das: Ihre Arbeit muss im Alltag sichtbar und einfach sein – etwa über klare Workflows zur Freigabe und Korrektur von Stammdaten.

Praxis-Case: Wie ein zentraler Golden Record 1.400 Gesellschaften beherrschbar macht

Architekturdebatten bleiben oft abstrakt. Deshalb ein Blick auf ein Beispiel, das zeigt, warum die Qualität zentraler Geschäftsobjekte jeder Architekturentscheidung vorausgeht.

Die Ausgangslage

Die PATRIZIA SE ist ein international tätiger Investmentmanager für Immobilien und Infrastruktur. Das Unternehmen verwaltet ein Vermögen von über 50 Milliarden Euro mit rund 1.400 Gesellschaften in mehr als 15 Ländern.

Mitarbeitende brauchten schnellen Zugriff auf Beteiligungsstrukturen. Organigramme und Berichte für Jahresabschlüsse, Bankanfragen und KYC-Prüfungen wurden manuell erstellt. Das kostete erheblich Zeit und Ressourcen.

Die Lösung

PATRIZIA setzt den Goldright Legal Entity Manager ein. Alle Beteiligungsdaten werden zentral und historisiert verwaltet, inklusive Dokumenten. Organigramme und Berichte entstehen automatisiert und auf Knopfdruck. Stichtagsbezogene Auswertungen sind möglich, und die Lösung ist an externe Systeme angebunden.

Die Ergebnisse

Automatisierte Organigramme und Berichte werden heute bei Bedarf erzeugt. Historische Beteiligungsverhältnisse sind mit wenigen Klicks abrufbar. Die Datenqualität im gesamten Portfolio hat sich deutlich verbessert. Susanne Päsler, Legal Entity Management bei PATRIZIA, betont, wie sehr die automatisierten Beteiligungsorganigramme ihren Arbeitsalltag vereinfacht haben.

Was der Fall für die Architekturfrage bedeutet

Der Fall ist kein Data-Mesh- oder Lakehouse-Projekt. Gerade deshalb ist er lehrreich. Er zeigt, was jede Datenarchitektur in einem Unternehmen mit über 1.400 Gesellschaften als Erstes braucht: eine verlässliche, historisierte Version der Gesellschaftsstruktur.

Stellen Sie sich vor, ein solches Unternehmen würde ohne diese Grundlage ein Data Mesh aufbauen. Die Domäne „Fonds” würde Gesellschaften anders zuordnen als die Domäne „Finanzen”. Eine Data Fabric würde beide Sichten verbinden – und zwei widersprüchliche Konzernstrukturen anzeigen. Ein Lakehouse würde beide Versionen speichern, aber nicht entscheiden, welche stimmt.

Mit einem stichtagsbezogenen Golden Record für Gesellschaften wird jede dieser Architekturen tragfähig. Der Golden Record wird zum Datenprodukt im Mesh, zur führenden Referenz in der Fabric und zur vertrauenswürdigen Quelle in der Silber-Schicht des Lakehouse. Diese Einordnung ist unsere Interpretation des Falls – sie beschreibt das Architekturprinzip, nicht ein konkretes Projekt bei PATRIZIA.

Fallstricke: Was Sie bei Data Mesh, Data Fabric und Data Lakehouse vermeiden sollten

Aus der Entscheidungstabelle lassen sich typische Fehler ableiten. Die folgenden acht Fallstricke begegnen Unternehmen immer wieder.

Fallstrick 1: Data Mesh als Reorganisation von oben

Ein Mesh lässt sich nicht per Organigramm verordnen. Wenn Fachbereiche Datenverantwortung übertragen bekommen, ohne Kapazität, Kompetenz und Plattform, entsteht keine Datenkultur. Es entstehen neue Silos mit neuem Namen.

Besser: Starten Sie mit einer Domäne, die motiviert und fähig ist. Lassen Sie den Erfolg für sich sprechen.

Fallstrick 2: Data Fabric als Wunderwerkzeug

Eine Data Fabric verspricht Automatisierung. Diese Automatisierung basiert auf Metadaten. Sind die Metadaten lückenhaft oder widersprüchlich, automatisiert die Fabric die Lücken und Widersprüche.

Besser: Investieren Sie zuerst in einen gepflegten Katalog und eindeutige Geschäftsbegriffe.

Fallstrick 3: Das Lakehouse als größerer Data Lake

Viele Lakehouse-Projekte laden Daten in die Bronze-Schicht und erreichen nie eine verlässliche Silber-Schicht. Das Ergebnis ist ein moderner Data Swamp – mit besserer Technik, aber denselben Problemen.

Besser: Definieren Sie vor dem Start, welche Geschäftsobjekte in der Silber-Schicht harmonisiert werden und wer dafür verantwortlich ist.

Fallstrick 4: Architektur ohne Geschäftsziel

Wenn die Plattformauswahl vor den Anwendungsfällen steht, fehlt der Maßstab für Erfolg. Das Projekt wird zum Technologieprojekt und verliert die Unterstützung des Managements.

Besser: Knüpfen Sie jede Architekturentscheidung an messbare Geschäftsergebnisse.

Fallstrick 5: Stammdaten als nachgelagertes Thema

Der häufigste Fehler: Stammdaten werden als Thema für „später” eingeplant. Später ist dann zu spät, weil sich Dubletten und Widersprüche bereits in Datenprodukten, Berichten und KI-Modellen verteilt haben.

Besser: Stellen Sie den Golden Record für die wichtigsten Geschäftsobjekte vor oder parallel zur Architektur her. Wie eine MDM-Strategie dafür aussieht, beschreibt unser Fahrplan zur MDM-Strategie.

Fallstrick 6: Begriffe als Synonyme behandeln

In Projektpräsentationen werden Data Mesh und Data Fabric oft austauschbar verwendet. Das führt zu falschen Erwartungen. Wer ein Mesh erwartet, plant organisatorische Veränderungen. Wer eine Fabric erwartet, plant Integrationstechnologie.

Besser: Nutzen Sie die Fragen „Wer?“, „Wie?” und „Wo?” aus diesem Artikel, um Begriffe im Projekt sauber zu trennen.

Fallstrick 7: Anbieter-Lock-in unterschätzen

Viele Plattformen werben mit „offen”. Prüfen Sie genau, welche Formate, Kataloge und Schnittstellen wirklich offen sind. Das Lakehouse-Konzept wurde ausdrücklich mit offenen Datenformaten begründet.

Besser: Bewerten Sie bei jeder Plattform, wie aufwendig ein späterer Wechsel wäre.

Fallstrick 8: Data Stewards vergessen

Architekturentscheidungen werden oft zwischen CDO, IT und Anbietern getroffen. Die Data Stewards, die Datenqualität im Alltag sichern, sind selten beteiligt. Dabei entscheiden sie, ob Datenprodukte, Fabric-Metadaten und Silber-Schichten im Betrieb verlässlich bleiben.

Besser: Beziehen Sie Data Stewards früh ein und geben Sie ihnen Werkzeuge, die ihre Arbeit erleichtern.

Fazit: Data Mesh, Data Fabric oder Data Lakehouse – was wirklich Sinn macht

Data Mesh, Data Fabric und Data Lakehouse sind keine Konkurrenten. Sie beantworten drei unterschiedliche Fragen.

Data Mesh klärt, wer für Daten verantwortlich ist. Data Fabric klärt, wie verteilte Daten verbunden werden. Das Data Lakehouse klärt, wo und wie Daten gespeichert und verarbeitet werden.

Was wirklich Sinn macht, hängt von Ihrer Organisation ab.

Ein zentrales Team mit klarem Reporting-Fokus startet meist mit einem Lakehouse. Eine heterogene, gewachsene Systemlandschaft profitiert von einer Data Fabric. Große, eigenständige Geschäftsbereiche mit hoher Datenreife können mit Data Mesh skalieren. In den meisten Unternehmen ergibt sich am Ende eine Kombination.

Eine Frage beantwortet keines der drei Konzepte allein: Was bedeuten die Daten, und welche Version ist die richtige? Diese Frage entscheidet darüber, ob Ihre Investition in eine neue Datenarchitektur Wert schafft oder nur bestehende Widersprüche schneller sichtbar macht. Die Antwort liefert ein konsistenter Golden Record für Ihre zentralen Geschäftsobjekte.

Unsere Empfehlung als Schlussfolgerung aus diesem Leitfaden: Treffen Sie die Architekturentscheidung nicht isoliert. Klären Sie zuerst Ihre Geschäftsziele, Ihre zentralen Geschäftsobjekte und Ihren Governance-Reifegrad. Nutzen Sie dann die Entscheidungstabelle, um die passende Kombination zu finden. Und starten Sie mit einem Anwendungsfall, der schnell messbaren Wert liefert.

Der erste Schritt ist eine ehrliche Standortbestimmung. Der Data Governance Reifegrad Check zeigt Ihnen in rund 15 Minuten, wo Ihre Organisation steht – und welche Datenarchitektur realistisch zu Ihnen passt.

Quellenverzeichnis

Armbrust, M., Ghodsi, A., Xin, R., Zaharia, M.: Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. - https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

Bitkom e. V.: Data Economy – Studienbericht - https://www.bitkom.org/sites/main/files/2025-09/bitkom-studienbericht-data-economy.pdf

Databricks: Medallion Architecture (Glossar) - https://www.databricks.com/glossary/medallion-architecture

Dehghani, Z.: How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh - https://martinfowler.com/articles/data-monolith-to-mesh.html

Dehghani, Z.: Data Mesh Principles and Logical Architecture - https://martinfowler.com/articles/data-mesh-principles.html

Deloitte: Chief Data and Analytics Officer Survey Finds CDAOs Acting as AI Trailblazers - https://www.deloitte.com/us/en/about/press-room/chief-data-and-analytics-officer-survey-finds-cdaos-acting-as-ai-trailblazers.html

Dremio / Propeller Insights: State of the Data Lakehouse 2024 - https://www.dremio.com/wp-content/uploads/2023/11/whitepaper-2024-state-of-the-data-lakehouse_report.pdf

EU AI Act, Artikel 10: Daten und Daten-Governance - https://artificialintelligenceact.eu/article/10/

Gartner: Gartner Identifies the Top Strategic Technology Trends for 2022 - https://www.gartner.com/en/newsroom/press-releases/2021-10-18-gartner-identifies-the-top-strategic-technology-trends-for-2022

Gartner: Gartner Predicts 80% of D&A Governance Initiatives Will Fail by 2027 - https://www.gartner.com/en/newsroom/press-releases/2024-02-28-gartner-predicts-80-percent-of-data-and-analytics-governance-initiatives-will-fail-by-2027-due-to-a-lack-of-a-real-or-manufactured-crisis-

Gartner: How Data Leaders Can Complement Fabric and Mesh Approaches - https://www.gartner.com/en/documents/6132959

Gartner: Lack of AI-Ready Data Puts AI Projects at Risk - https://www.gartner.com/en/newsroom/press-releases/2025-02-26-lack-of-ai-ready-data-puts-ai-projects-at-risk

Gartner: Organizations with Successful AI Initiatives Invest Up to Four Times More in Data and Analytics Foundations - https://www.gartner.com/en/newsroom/press-releases/2026-04-16-gartner-says-organizations-with-successful-ai-initiatives-invest-up-to-four-times-more-in-data-and-analytics-foundations

Gartner: Lack of Semantics Causes Inaccurate AI Agents and Wasted Spending - https://www.gartner.com/en/newsroom/press-releases/2026-05-11-gartner-says-lack-of-semantics-causes-inaccurate-artificial-intelligence-agents-and-wasted-spending

Gartner: Gartner Identifies the Top Trends for Data and Analytics - https://www.gartner.com/en/newsroom/press-releases/2026-06-16-gartner-identifies-the-top-trends-for-data-and-analytics

Gartner: 60% of Organizations That Ignore Data Governance Culture Challenges Will Fail to Govern AI Successfully by 2027 - https://www.gartner.com/en/newsroom/press-releases/2026-09-21-gartner-predicts-60-percent-of-organizations-that-ignore-data-governance-culture-challenges-will-fail-to-govern-ai-successfully-by-2027

IBM: What Is a Data Fabric? - https://www.ibm.com/think/topics/data-fabric

IBM: Data management vs. data fabric vs. data mesh. - https://www.ibm.com/think/topics/data-management-vs-data-fabric-vs-data-mesh

IBM: What Is a Data Lake? - https://www.ibm.com/think/topics/data-lake

IBM: What Is a Data Warehouse? - https://www.ibm.com/think/topics/data-warehouse

McKinsey & Company: Desai, V., Fountaine, T., Rowshankish, K.: How to unlock the full value of data? Manage it like a product. - https://www.mckinsey.com/capabilities/quantumblack/our-insights/how-to-unlock-the-full-value-of-data-manage-it-like-a-product