Data Mesh in der Finanzwirtschaft: Warum zentralisierte Datenteams scheitern.

Der Engpass des zentralen Datenteams

Viele Finanzinstitute haben ein zentrales Datenteam aufgebaut, das für alle Fachbereiche Daten bereitstellen und auswerten soll. Die Idee war bestechend: Datenwissen an einer Stelle bündeln, Standards schaffen, Insellösungen vermeiden. In der Praxis wird das zentrale Team oft zum Engpass. Daten gehören dorthin, wo das Fachwissen sitzt; wird jede Auswertung über ein zentrales Team geleitet, entsteht eine Warteschlange statt nutzbarer Daten.

Der Grund liegt in der Überforderung. Ein zentrales Team kann nicht das fachliche Wissen aller Bereiche haben. Es kennt die Kreditdaten nicht so gut wie die Kreditabteilung, die Vertriebsdaten nicht so gut wie der Vertrieb, die Risikodaten nicht so gut wie das Risikomanagement. Und es kann nicht für alle zugleich liefern, weil sich die Anfragen stauen.

Warum zentralisierte Datenteams scheitern

Zentralisierte Datenteams scheitern an einem Widerspruch: Daten sind fachlich, sie ergeben nur im Verständnis eines Geschäftsbereichs Sinn. Wird die Verantwortung zentral gebündelt, trennt sie sich von dem Wissen, das die Daten erst verständlich macht. Das zentrale Team verwaltet Daten, die es fachlich nicht durchdringt, und die Fachbereiche, die das Wissen hätten, sind von der Verantwortung entbunden.

Daraus entsteht Verantwortungsdiffusion. Niemand fühlt sich wirklich zuständig, die Datenqualität leidet, und die Datennutzung bleibt hinter dem Möglichen zurück. Wie sehr das KI-Vorhaben bremst, zeigt der Beitrag Ohne Datenstrategie keine KI.

Was Data Mesh ist und auf welchen Prinzipien es beruht

Data Mesh ist ein Organisationsmodell für Daten, das die Verantwortung dorthin verlagert, wo das Fachwissen sitzt. Beschrieben hat es Zhamak Dehghani, damals bei der Technologieberatung Thoughtworks, im Dezember 2020 auf martinfowler.com anhand von vier Prinzipien:

• Fachliche Eigenverantwortung der Domänen: Jeder Fachbereich, im Data Mesh „Domäne“ genannt, verantwortet seine Daten und deren Bereitstellung selbst.

• Daten als Produkt: Daten werden aufbereitet, dokumentiert und verlässlich bereitgestellt, und ihre Nutzer in anderen Bereichen werden wie Kunden behandelt.

• Self-Service-Datenplattform: Eine gemeinsame Plattform befähigt die Domänen, Datenprodukte eigenständig zu erstellen und zu betreiben.

• Föderierte Governance: Übergreifende Regeln gelten für alle und werden möglichst automatisiert über die Plattform umgesetzt.

Die Prinzipien wirken nur im Zusammenspiel. Eine Plattform ohne fachliche Eigenverantwortung ist nur ein neues zentrales Tool. Eigenverantwortung ohne gemeinsame Regeln führt zu Dateninseln, die nicht zusammenpassen.

Was „Daten als Produkt“ im Alltag verändert

„Daten als Produkt“ verändert die Haltung zu den Daten. Statt sie als lästige Nebensache zu verwalten, stellt eine Domäne ihre Daten so bereit, dass andere sie verlässlich nutzen können: mit Beschreibung, klarer Bedeutung jedes Feldes, Qualitätszusage und Ansprechperson. Das hebt die Datenqualität, weil die Domäne ein Interesse daran hat, dass ihr Produkt genutzt wird.

Ein Beispiel aus dem Vertrieb: Kundenmerkmale, auf denen Affinitätsmodelle rechnen, sind nur so gut wie ihre Pflege in der Beratung. Verantwortet der Vertrieb diese Merkmale als eigenes Datenprodukt, verbessert sich die Grundlage jedes Modells, wie der Beitrag zu Affinitätsmodellen und Datenqualität im Kernbanksystem zeigt.

Welche Rolle das zentrale Team im Data Mesh behält

Ein zentrales Team bleibt, aber mit anderer Aufgabe: Es verwaltet nicht mehr die Daten, sondern stellt Plattform, Standards und Regeln bereit, auf denen die Domänen ihre Daten verantworten. Es ist Ermöglicher, kein Flaschenhals. Diese veränderte Rolle verbindet die Eigenverantwortung der Domänen mit der Kohärenz, die eine gemeinsame Infrastruktur sichert, sodass Datenprodukte zusammenpassen und auffindbar sind.

Was eine Domäne in einer Bank oder einem Versicherer ist

Eine Domäne ist ein fachlich abgegrenzter Bereich mit eigenem Wissen, eigenen Prozessen und eigenen Daten. In einer Bank sind das etwa Kreditgeschäft, Zahlungsverkehr, Wertpapiergeschäft, Risikomanagement, Compliance oder Vertrieb; bei einem Versicherer etwa Antrag und Bestand, Schaden, Vertrieb und Rückversicherung.

Die Kunst liegt im richtigen Schnitt. Zu große Domänen erzeugen innerhalb der Domäne wieder den alten Engpass, zu kleine zersplittern die Verantwortung. Der richtige Schnitt folgt den Stellen, an denen sich Wissen und Prozesse natürlich gliedern. Für Institute im Verbund kommt hinzu, dass viele Daten im Kernsystem des Rechenzentrums liegen; die Domäne verantwortet dann vor allem Bedeutung, Pflege und Bereitstellung, nicht die Technik.

Wie Data Mesh zu Anforderungen an das Datenmanagement passt

Data Mesh schafft genau die klare Zuständigkeit, die Anforderungen an das Datenmanagement verlangen. Für bedeutende Institute fordern die MaRisk in AT 4.3.4 institutsweit geltende Grundsätze für Datenmanagement, Datenqualität und die Aggregation von Risikodaten, die von der Geschäftsleitung zu genehmigen sind, sowie eine Datenstruktur, die eine zweifelsfreie Identifikation, Zusammenführung und Auswertung von Daten erlaubt, möglichst mit einheitlichen Namenskonventionen.

Auch für Institute außerhalb dieses Anwendungsbereichs ist das eine hilfreiche Orientierung. Ein Modell, in dem klar ist, wer für welche Daten verantwortlich ist, wer ihre Qualität sichert und wer Auskunft über ihre Herkunft geben kann, erleichtert Revision, Prüfungen und jede spätere Automatisierung.

Welche Fehler beim Einstieg in Data Mesh häufig sind

Drei Fehler wiederholen sich. Der erste ist die Verwechslung mit einem Technikprojekt: Eine Plattform wird gebaut, die Verantwortung aber nicht verlagert. Der zweite ist der zu große Wurf, der das gesamte Institut auf einmal umstellen will. Der dritte ist die Vernachlässigung der Domänen, die zur neuen Verantwortung befähigt werden müssen, mit Zeit, Kompetenz und Unterstützung.

Alle drei haben eine gemeinsame Wurzel: die Unterschätzung der organisatorischen Dimension. Der Kern von Data Mesh ist die neue Verteilung von Verantwortung, nicht die Technik. Wie offene Schnittstellen die technische Seite ergänzen, beschreibt der Beitrag zu Headless-Architekturen in der Agentic-AI-Ära; wie Datenzugang Kundenplattformen prägt, der Beitrag zur Banking Super-App.

Wie der Weg zu Data Mesh schrittweise gelingt

Der Weg beginnt mit einer Domäne, in der das Potenzial groß und die Bereitschaft hoch ist. Sie übernimmt die Verantwortung für ihre Daten, baut ihr erstes Datenprodukt und sammelt Erfahrungen, aus denen die anderen lernen. Aus diesem ersten Ergebnis wächst das Modell Domäne um Domäne. Der schrittweise Weg begrenzt das Risiko und macht den Nutzen früh sichtbar: schnellere Datennutzung, bessere Datenqualität und eine tragfähige Grundlage für KI und datengetriebene Steuerung.

1. Den Engpass messen: Wartezeiten auf Auswertungen, offene Anfragen beim zentralen Team, wiederkehrende Qualitätsprobleme.

2. Eine Pilotdomäne wählen und eine verantwortliche Person mit Mandat und Zeit benennen.

3. Ein erstes Datenprodukt definieren mit Beschreibung, Qualitätszusage und Nutzern.

4. Die Rolle des zentralen Teams neu fassen: Plattform, Standards und Regeln statt Einzelauswertungen.

Häufige Fragen

Was ist Data Mesh in einfachen Worten?
Ein Organisationsmodell, in dem Fachbereiche die Verantwortung für ihre Daten selbst tragen und sie anderen als verlässliches Produkt bereitstellen, unterstützt durch eine gemeinsame Plattform und gemeinsame Regeln.

Braucht es mit Data Mesh noch ein zentrales Datenteam?
Ja, aber in anderer Rolle. Es stellt Plattform, Standards und Regeln bereit, statt alle Daten selbst zu verwalten und jede Auswertung selbst zu erstellen.

Eignet sich Data Mesh auch für kleinere Institute?
Das Prinzip der fachlichen Datenverantwortung eignet sich für jede Größe. Kleinere Institute brauchen meist keine eigene Plattform, profitieren aber von klar benannten Datenverantwortlichen je Fachbereich.

Weitere Beiträge zu Datenarchitektur, Datenqualität und Kernsystemen bündelt das Dossier Daten & Kernsysteme.

Wie lange ein Fachbereich heute auf eine neue Auswertung wartet, sagt oft mehr über die eigene Datenorganisation als jedes Architekturbild. Wir freuen uns über einen ersten Austausch zu dieser Frage.