Data Mesh und Data Lakehouse gehören zu den dominierenden Konzepten moderner Datenarchitekturen. In der Praxis zeigt sich jedoch schnell, dass nicht jede Organisation von denselben Mustern profitiert – und dass viele Implementierungen an organisatorischen Rahmenbedingungen scheitern.
1. Was versprechen die Konzepte?
Data Mesh adressiert vor allem organisatorische Skalierungsprobleme: Domänen übernehmen Verantwortung für ihre Datenprodukte. Das Lakehouse versucht, die Stärken von Data Warehouse und Data Lake zu kombinieren.
- Data Mesh: Daten als Produkt, dezentrale Ownership
- Lakehouse: ACID-Funktionalität auf skalierbarem, günstigem Storage
- Beide: Trennung von Compute und Storage, Fokus auf Self-Service
2. Wo liegen die echten Herausforderungen?
Aus Architektursicht sind die technischen Patterns gut beschreibbar. Die eigentlichen Risiken liegen in Governance, Verantwortlichkeiten und dem Reifegrad der Teams. Ohne klare Domänenschnitte und Produktverantwortung führt Data Mesh eher zu „Daten-Silos 2.0“ – nur in moderner Verpackung.
Entscheidend ist, wie gut Fachbereiche und IT zusammenarbeiten, wie tragfähig Domänen zugeschnitten sind und ob Plattformteams in der Lage sind, stabile Self-Service-Plattformen zu betreiben.
3. Wie können IT-Entscheider sinnvoll starten?
Statt „Big Bang“-Transformationen empfiehlt sich ein iterativer Ansatz: mit wenigen, klar abgegrenzten Domänen beginnen, erste Datenprodukte aufbauen und bewusst messen, wo Wert entsteht.
- Klein anfangen: 1–2 Domänen mit klarer Ownership auswählen
- Datenprodukte explizit definieren (Schnittstellen, SLAs, Qualitätsmetriken)
- Metriken wie Time-to-Insight, Datenqualität und Onboarding-Zeit beobachten
Data Mesh und Lakehouse sind keine Selbstzwecke. Sie sind dann sinnvoll, wenn sie echte organisatorische Probleme adressieren – und wenn Teams befähigt werden, Verantwortung für Daten ernsthaft zu übernehmen.