Data Mesh vs. Data Lakehouse: Was die Architekturdebatte wirklich kostet

Ein Finanzdienstleister in Frankfurt hat 18 Monate und rund 4 Millionen Euro in den Aufbau eines zentralen Data LakehouseData LakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen → auf Databricks investiert. Als die Plattform produktionsreif war, hatten drei der größten Geschäftsbereiche längst ihre eigenen Data Pipelines aufgesetzt, mit einem Flickenteppich aus Snowflake, dbt und herstellerspezifischen Konnektoren. Das zentrale Team hatte das Richtige gebaut, aber für die falsche organisatorische Realität. Genau in dieser Lücke zwischen architektonischer Absicht und organisatorischem Verhalten scheitern die meisten modernen Datenvorhaben, ohne großes Aufsehen.

Das ist die offene Spannung in der Datenarchitektur im Jahr 2026: Das Tooling ist deutlich reifer geworden, die Organisationsmodelle, die man braucht, um es gut zu nutzen, haben nicht mitgehalten. Von CDOs werden folgenreiche Plattformentscheidungen erwartet, während sich Business-Anforderungen, Verfügbarkeit von Talenten und Governance-Erwartungen gleichzeitig verschieben.

Was in der modernen Datenarchitektur tatsächlich passiert

Das Data-LakehouseLakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen →-Muster, populär gemacht durch Databricks und stark beworben von Anbietern wie Snowflake (das eine eigene Interpretation des Konzepts vertritt), hat zwischen 2022 und 2025 eine breite Verbreitung im Unternehmensumfeld erreicht. Das Versprechen war real: die Flexibilität eines Data LakeData LakeEin Data Lake ist ein zentraler Speicher, der große Datenmengen im Rohformat ablegt, von strukturierten Tabellen bis zu unstrukturierten Dateien, bis sie gebraucht werden.Vollständige Definition ansehen → mit der Query-Performance und transaktionalen Zuverlässigkeit eines Warehouse verbinden. Offene Tabellenformate, insbesondere Apache Iceberg und Delta Lake, haben Teams in die Lage versetzt, ACID-Eigenschaften auf Object Storage durchzusetzen, was einen der ältesten Einwände gegen Lake-basierte Architekturen ausgeräumt hat.

Parallel dazu hat das Data-Mesh-Konzept, formalisiert von Zhamak Dehghani und veröffentlicht von ThoughtWorks, organisatorisch ernsthaft Zugkraft gewonnen. Das Kernargument: Datenqualitätsprobleme sind im Grunde soziotechnisch, nicht technisch. Daten in einer Plattform zu zentralisieren behebt nicht die Anreizstrukturen, die schlechte Daten überhaupt erst erzeugen. Mesh verlangt, Ownership neu zu verteilen: Jedes Domain-Team besitzt, veröffentlicht und pflegt seine eigenen Data Products, geregelt durch gemeinsame Standards, die auf Plattformebene durchgesetzt werden.

Bis 2026 hat sich die Debatte von „was ist besser“ zu etwas Unangenehmerem verschoben: Beide Ansätze sind teilweise kompatibel und teilweise im Widerspruch, und die meisten Unternehmen versuchen, beide gleichzeitig umzusetzen, ohne sich auf einen festzulegen. Gartner hat dieses Hybridisierungsrisiko in seiner Data-Management-Forschung markiert und weist darauf hin, dass Organisationen häufig das Vokabular von Data MeshData MeshData Mesh ist ein dezentraler Ansatz für Datenarchitektur und Organisation, bei dem Domänenteams ihre Daten besitzen und als Produkte bereitstellen, geregelt durch gemeinsame Standards.Vollständige Definition ansehen → übernehmen, während sie das zentralisierte Kontrollmodell beibehalten, das Mesh ausdrücklich in Frage stellt.

Das praktische Ergebnis nennen manche Architekturteams „Mesh Theater“: Domain Ownership auf dem Papier, während ein zentrales Data-Engineering-Team weiterhin die meiste Arbeit macht, weil den Domain-Teams die Fähigkeiten oder die Kapazität fehlen, ihre Data Products eigenständig zu verantworten.

Was das für den CDO bedeutet

Die Architekturentscheidung ist genauso eine Wette auf Talente wie auf Technologie. Ein Data Lakehouse mit einem zentralen Team braucht tiefe Platform-Engineering-Expertise, konzentriert an einer Stelle. Ein echtes Data-Mesh-Modell verlangt, dass diese Expertise über Domains verteilt ist, was schwerer zu besetzen, schwerer zu steuern und deutlich teurer ist, wenn man Redundanzen einrechnet. Keine der beiden Optionen ist günstiger. CDOs, die über architektonische Transformation Kosteneinsparungen versprechen, sollten diese Prognosen sorgfältig überprüfen.

In der Praxis unterscheiden sich die beiden Modelle am stärksten bei der Governance. Ein Lakehouse gibt Ihnen eine einzige Control Plane, was regulatorische Compliance, Data LineageData LineageData Lineage zeigt, wie Daten sich durch Systeme bewegen und dabei transformiert werden, von der Quelle bis zur Nutzung: woher sie kommen, was sie verändert hat und wohin sie gehen.Vollständige Definition ansehen → und Zugriffskontrolle deutlich leichter auditierbar macht. Das zählt erheblich in Financial Services, im Gesundheitswesen und in jedem Kontext, in dem Aufsichtsbehörden erwarten, dass Sie belegen, wer wann auf was zugegriffen hat. Ein Mesh-Modell kann dieselben Governance-Ergebnisse erreichen, aber nur, wenn die Ebene der „federated computational governance“ tatsächlich gebaut und durchgesetzt wird und nicht bloß in einem Architekturdiagramm dokumentiert ist. Die meisten Organisationen investieren hier zu wenig und entdecken die Lücke dann bei einem Audit oder einem Incident.

Das konkrete Risiko für den CDO im Jahr 2026 besteht darin, sich auf eine Referenzarchitektur festzulegen, bevor geklärt ist, ob die Organisation sie personell tragen und dauerhaft betreiben kann. Mehrere große europäische Banken haben öffentlich über die Umsetzung von Data-Mesh-Prinzipien gesprochen, aber der Markt für Engineers, die Self-Serve-Dateninfrastruktur auf Domain-Ebene bauen und betreiben kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen, bleibt extrem eng. Ein zentrales Plattformteam zu rekrutieren ist schon schwer genug. Zehn kleinere Plattformteams zu rekrutieren, eingebettet in zehn verschiedene Geschäftsbereiche, ist ein ganz anderes Problem.

Es gibt außerdem ein Problem mit Herstellereinfluss, das man direkt benennen sollte. Sowohl Databricks als auch Snowflake (Anbieter mit kommerziellem Interesse daran, wie Sie Ihre Architektur definieren) finanzieren einen erheblichen Teil der Case Studies, White Paper und Konferenzinhalte, die CDOs als Referenzmaterial nutzen. Unabhängige Analystenforschung von Häusern wie Gartner und Forrester ist bei behaupteten Ergebnissen tendenziell vorsichtiger, besonders bei Implementierungszeiträumen und Total Cost of Ownership. CDOs, die achtstellige Plattformentscheidungen treffen, sollten diese Quellen entsprechend gewichten.

Die Architekturentscheidung mit weniger Reue treffen

• Prüfen Sie die organisatorische Reife, bevor Sie die technischen Optionen prüfen. Die Frage ist nicht, ob ein Mesh-Modell architektonisch sauber ist, sondern ob Ihre Domain-Teams die Engineering-Kapazität haben, als Data ProductData ProductEin Datenbestand, der wie ein Produkt gemanagt wird: mit Owner, definierten Nutzern, garantierter Qualität und messbarem Geschäftswert.Vollständige Definition ansehen → Owner zu agieren. Lautet die Antwort nein, ist ein Lakehouse mit starken Domain-Zugriffsmustern der besser begründbare Ausgangspunkt.
• Behandeln Sie offene Tabellenformate als strategische Absicherung. Eine Standardisierung auf Apache Iceberg über Ihre Storage-Ebene hinweg hält Ihnen die Optionen bei Query Engines und Cloud-Providern offen. Das ist ein Bereich, in dem die herstellerneutrale Wahl auch die pragmatisch richtige ist.
• Bauen Sie die Governance-Ebene, bevor Sie sie brauchen. Werkzeuge für föderierte Governance wie DataHub, Atlan oder Collibra (letzteres ein kommerzieller Anbieter) können Standards über verteilte Ownership-Modelle hinweg durchsetzen, aber sie brauchen Investitionen, bevor Ihr Mesh wächst, und nicht erst, wenn 40 undokumentierte Data Products in Produktion sind.
• Sagen Sie klar, welches Architekturmodell Sie tatsächlich betreiben. Wenn Sie Mesh-Vokabular nutzen, aber mit zentraler Data-Engineering-Delivery arbeiten, ist das als Übergangszustand in Ordnung. Zum Problem wird es, wenn die Führung glaubt, die Domains seien eigenständig, und das Budget entsprechend plant.
• Trennen Sie die Frage der Storage-Architektur von der Frage des Organisationsmodells. Sie können ein Lakehouse betreiben und gleichzeitig Domain Ownership umsetzen. Die Verwirrung entsteht, wenn Teams das als sich gegenseitig ausschließende Optionen behandeln.

Das Frankfurter Beispiel vom Anfang dieses Artikels endete nicht im Scheitern. Das Unternehmen hat die Kontrolle schließlich an Domain-Teams föderiert und das zentrale Lakehouse als gemeinsame Infrastruktur behalten. Dafür brauchte es zwei weitere Jahre und erheblichen Rework. Mit Organisationsdesign statt Plattformauswahl zu beginnen hätte diese Komplexität nicht beseitigt, aber sie verringert.