Data Mesh ist ein dezentrales Architekturparadigma für analytische Daten, das 2019 von Zhamak Dehghani bei Thoughtworks geprägt wurde. Der Ansatz bricht radikal mit der Tradition zentralisierter Data Warehouses und verlagert die Verantwortung für Daten dorthin, wo sie entstehen und verstanden werden: in die fachlichen Domänen. Für den deutschen Bankensektor, geprägt von regulatorischer Komplexität und gewachsenen Legacy-Strukturen, birgt das Konzept enormes Potenzial – aber auch erhebliche Herausforderungen.
Domain Ownership — Die Verantwortung für Daten liegt bei den fachlichen Domänen, nicht bei einem zentralen Datenteam. Jede Domäne stellt ihre Daten als eigenständiges Produkt bereit.
Data as a Product — Daten werden mit derselben Sorgfalt behandelt wie ein Softwareprodukt: mit klaren SLAs, Dokumentation, Qualitätsgarantien und definierten Schnittstellen.
Self-Serve Data Platform — Eine zentrale Infrastrukturplattform stellt Werkzeuge bereit, mit denen Domänenteams ihre Datenprodukte eigenständig erstellen und betreiben können.
Federated Computational Governance — Übergreifende Standards für Interoperabilität, Sicherheit und Compliance werden gemeinsam definiert und automatisiert durchgesetzt.
Architekturvergleich im Detail
Der Paradigmenwechsel vom Data Warehouse zum Data Mesh betrifft nicht nur die technische Architektur, sondern fundamental die Frage, wer in einer Organisation für Daten verantwortlich ist – und wie diese Verantwortung skaliert.
| Dimension | Data Warehouse | Data Mesh |
|---|---|---|
| Topologie | Zentralisiert – ein monolithisches Repository | Dezentral – verteilte, domänenspezifische Datenprodukte |
| Verantwortung | Zentrales BI-/Datenteam besitzt und pflegt alle Daten | Fachdomänen besitzen und verantworten ihre eigenen Daten |
| Skalierung | Technisch (mehr Speicher, mehr Compute) | Organisatorisch (mehr Teams können parallel liefern) |
| Governance | Top-down, zentral gesteuert | Föderiert, durch Policies und Automatisierung |
| Engpass | Zentrales Team wird zum Flaschenhals | Koordinationsaufwand zwischen Domänen steigt |
| Technologie | Einheitliche Plattform (Snowflake, Redshift, BigQuery) | Technologie-agnostisch – jede Domäne wählt eigene Werkzeuge |
Ein Data Warehouse bleibt die richtige Wahl, wenn die Organisation überschaubar ist, wenige Domänen existieren und ein zentrales Team die Datenlast bewältigen kann. Es ist bewährt, gut verstanden und hat ein ausgereiftes Tooling-Ökosystem. Ein Data Mesh wird dann relevant, wenn eine Organisation so groß und komplex wird, dass das zentrale Datenteam zum Engpass wird – typischerweise bei Dutzenden von Domänen mit eigenständigen Entwicklungsteams.
In der Praxis findet man häufig hybride Ansätze: Ein Data Warehouse oder Lakehouse als technische Basis, kombiniert mit Data-Mesh-Prinzipien wie Domain Ownership und Data-as-a-Product auf der organisatorischen Ebene.
Domänen-Modellierung für Banken
Banken sind historisch gewachsen, regulatorisch komplex und oft entlang von Produktsilos organisiert – was nicht zwingend die richtige Domänenstruktur für ein Data Mesh ergibt. Die methodische Basis liefert das Domain-Driven Design (DDD) nach Eric Evans.
DDD-Konzepte im Bankkontext
Bounded Contexts definieren klare Grenzen, innerhalb derer ein bestimmtes Fachmodell gilt. In einer Bank könnte „Kredit" in der Firmenkundendomäne etwas anderes bedeuten als in der Privatkundendomäne – und genau diese Mehrdeutigkeit muss explizit gemacht werden.
Ubiquitous Language sorgt dafür, dass innerhalb jeder Domäne eine einheitliche Fachsprache existiert. Gerade im Bankwesen, wo Begriffe wie „Position", „Exposure" oder „Settlement" je nach Kontext variieren, ist das entscheidend.
Context Mapping beschreibt die Beziehungen zwischen Domänen – wer liefert Daten an wen, wo gibt es Überschneidungen, wo Abhängigkeiten.
Kundendomänen — Privatkunden, Firmenkunden, institutionelle Kunden. Jede Domäne besitzt die Stammdaten und das Verhalten ihrer Kundengruppe.
Produktdomänen — Zahlungsverkehr, Kreditgeschäft, Wertpapiere/Capital Markets, Asset Management, Einlagen.
Querschnittsdomänen — Risikomanagement, Regulatory Reporting, Compliance/AML, Finance/Accounting.
Infrastrukturdomänen — Marktdaten, Referenzdaten, Wertpapierstammdaten, Counterparty-Daten, Pricing.
Methoden zur Domänen-Identifikation
1. Event Storming — In moderierten Workshops werden fachliche Ereignisse eines Geschäftsprozesses erfasst: „Trade erfasst", „Settlement angestoßen", „Regulatorische Meldung erzeugt". Die natürlichen Cluster dieser Events zeigen Domänengrenzen auf.
2. Business Capability Mapping — Bildet die Fähigkeiten der Bank unabhängig von der Organisationsstruktur ab. Man fragt: „Was muss die Bank können?" statt „Wer macht was?".
3. Value Stream Mapping — Verfolgt den Weg vom Kundenbedürfnis bis zur Wertlieferung und identifiziert natürliche Übergabepunkte – genau dort verlaufen oft sinnvolle Domänengrenzen.
4. Data Lineage Analyse — Nutzt bestehende Datenflüsse als empirische Grundlage. Wo Daten stark gekoppelt sind, gehören sie in dieselbe Domäne. Wo klare Schnittstellen bestehen, liegt eine Domänengrenze nahe.
Bankspezifische Herausforderungen
Regulatorische Querschnittsanforderungen wie BCBS 239, AnaCredit, DORA und MaRisk schneiden quer durch alle Domänen. Die Kunst liegt darin, regulatorische Anforderungen als konsumierende Domänen zu modellieren, die klar definierte Datenanforderungen an die liefernden Domänen stellen – statt eine zentrale „Regulatorik-Datenbank" zu bauen.
Shared Entities stellen eine besondere Herausforderung dar: Ein Kunde, ein Wertpapier oder ein Geschäftspartner existiert in vielen Domänen gleichzeitig. Hier braucht es das Konzept eines Polysemantic Data Product – jede Domäne hält ihre eigene Sicht auf die Entität, aber es gibt vereinbarte Identifier und Kernattribute als Golden Source, standardisiert über Federated Governance.
Legacy-Systeme vieler deutscher Banken kennen keine klaren Domänengrenzen. Ein pragmatischer Ansatz: Anti-Corruption Layers (ein DDD-Konzept) zwischen Legacy-Systemen und den neuen Domänen-Datenprodukten einziehen.
Pragmatisches Vorgehen: Implementierungs-Roadmap
Statt eines Big-Bang-Ansatzes hat sich ein iteratives Vorgehen bewährt. Die folgende Roadmap skizziert den empfohlenen Weg zur Data-Mesh-Einführung bei einer deutschen Bank:
Phase 1 – Pilotdomänen identifizieren: Zwei bis drei klar abgrenzbare Domänen mit motivierten Teams auswählen – etwa Wertpapier-Settlement und Marktdaten.
Phase 2 – Erste Datenprodukte definieren: Schnittstellen klären, Qualitätsstandards festlegen, SLAs vereinbaren. Anti-Corruption Layers zu Legacy-Systemen aufbauen.
Phase 3 – Self-Serve-Plattform aufbauen: Infrastruktur bereitstellen, mit der Domänenteams eigenständig Datenprodukte erstellen und betreiben können.
Phase 4 – Federated Governance etablieren: Erfahrungen aus den Pilotdomänen in übergreifende Governance-Standards überführen. Interoperabilität, Sicherheit und Compliance automatisiert durchsetzen.
Phase 5 – Skalierung auf weitere Domänen: Schrittweises Onboarding weiterer Domänen auf Basis der etablierten Standards und Plattform. Organisatorische Verankerung durch Mandat der Geschäftsleitung.