Der Engpass des zentralen Datenteams

Viele Finanzinstitute haben ein zentrales Datenteam aufgebaut, das für alle Fachbereiche die Daten bereitstellen und auswerten soll. Die Idee war bestechend: Man bündelt das Datenwissen an einer Stelle, schafft Standards und vermeidet, dass jeder Fachbereich sein eigenes Süppchen kocht. Doch in der Praxis erweist sich das zentrale Datenteam oft als Engpass, der die Datennutzung bremst, statt sie zu beschleunigen.

Der Grund liegt in der Überforderung. Ein zentrales Team kann nicht das fachliche Wissen aller Bereiche haben, das nötig wäre, um deren Daten wirklich zu verstehen und sinnvoll auszuwerten. 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 die Anfragen sich stauen. So wird das zentrale Team zum Flaschenhals, durch den alle Datennutzung gepresst wird und in dem sie sich staut.

Warum die Zentralisierung scheitert

Die Zentralisierung scheitert an einem grundlegenden Widerspruch. Daten sind fachlich, sie gehören zu einem Geschäftsbereich und ergeben nur im Verständnis dieses Bereichs Sinn. Die Verantwortung für die Daten zentral zu bündeln trennt sie von dem fachlichen Wissen, das sie 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 für ihre Daten entbunden.

Daraus entsteht eine doppelte Schwäche. Das zentrale Team ist überfordert, weil es fachliches Wissen für alle Bereiche haben müsste, das es nicht haben kann. Und die Fachbereiche fühlen sich nicht verantwortlich für ihre Daten, weil die Verantwortung beim zentralen Team liegt. Niemand fühlt sich wirklich zuständig, die Datenqualität leidet, und die Datennutzung bleibt hinter dem zurück, was möglich wäre. Die Zentralisierung, die Klarheit schaffen sollte, schafft Verantwortungsdiffusion.

Der Gedanke des Data Mesh

Data Mesh ist die Antwort auf dieses Scheitern. Der Grundgedanke ist, die Verantwortung für die Daten dorthin zu verlagern, wo das fachliche Wissen sitzt: in die Fachbereiche, die Data Mesh als Domänen bezeichnet. Jede Domäne wird für ihre eigenen Daten verantwortlich, sie pflegt sie, sie versteht sie, und sie stellt sie den anderen in einer nutzbaren Form bereit. Aus der zentralen Verwaltung wird eine verteilte Verantwortung, die dem fachlichen Wissen folgt.

Das löst den Engpass des zentralen Teams. Statt dass alle Datennutzung durch ein überfordertes Zentrum läuft, übernimmt jede Domäne die Verantwortung für ihre Daten, mit dem fachlichen Wissen, das nur sie hat. Die Kreditabteilung verantwortet die Kreditdaten, der Vertrieb die Vertriebsdaten, das Risikomanagement die Risikodaten. Jede Domäne kennt ihre Daten am besten und ist deshalb am besten geeignet, sie zu pflegen und bereitzustellen. Der Engpass löst sich auf, weil die Last auf viele Schultern verteilt wird, die jeweils das passende Wissen tragen.

Daten als Produkt

Ein zentrales Element des Data Mesh ist der Gedanke, Daten als Produkt zu begreifen. Jede Domäne stellt ihre Daten nicht als rohen Datenhaufen bereit, sondern als ein durchdachtes Produkt, das für die Nutzer aufbereitet, dokumentiert und verlässlich ist. So wie ein Produkt einen Kunden hat, dessen Bedürfnisse es erfüllt, hat das Datenprodukt Nutzer in anderen Domänen, deren Bedürfnisse es bedient. Die Domäne denkt von diesen Nutzern her und gestaltet ihr Datenprodukt entsprechend.

Dieser Produktgedanke verändert die Haltung zu den Daten. Statt Daten als lästige Nebensache zu behandeln, die man irgendwie verwaltet, behandelt die Domäne ihre Daten als ein Produkt, für das sie verantwortlich ist und auf dessen Qualität sie stolz ist. Das hebt die Datenqualität, weil die Domäne ein Interesse daran hat, dass ihr Produkt gut ist und genutzt wird. Aus der Pflicht, Daten zu verwalten, wird der Anspruch, ein gutes Datenprodukt zu liefern.

Die gemeinsame Infrastruktur

Damit die verteilte Verantwortung nicht ins Chaos führt, braucht Data Mesh eine gemeinsame Infrastruktur und gemeinsame Regeln. Die Domänen verantworten ihre Daten selbst, aber sie tun das auf einer gemeinsamen Plattform und nach gemeinsamen Standards, die sicherstellen, dass die Datenprodukte zusammenpassen und auffindbar sind. So bleibt die Eigenverantwortung der Domänen erhalten, ohne dass jede Domäne das Rad neu erfinden müsste oder Inseln entstünden, die nicht zusammenpassen.

Diese Infrastruktur und die Standards werden meist von einem zentralen Team bereitgestellt, aber dieses Team hat eine andere Rolle als das alte zentrale Datenteam. Es verwaltet nicht die Daten, sondern es stellt die Plattform und die Regeln bereit, auf denen die Domänen ihre Daten verantworten. Es ist ein Ermöglicher, kein Flaschenhals. Diese veränderte Rolle ist entscheidend, denn sie verbindet die Eigenverantwortung der Domänen mit der Kohärenz, die eine gemeinsame Infrastruktur sichert.

Was das für Finanzinstitute bedeutet

Für Finanzinstitute ist Data Mesh besonders relevant, weil sie viele Daten haben, die in verschiedenen Fachbereichen mit je eigenem Wissen liegen. Die Kreditdaten, die Vertriebsdaten, die Risikodaten, die Daten aus der Compliance, sie alle gehören zu Bereichen mit spezifischem fachlichem Wissen, das eine zentrale Stelle nicht haben kann. Genau hier zeigt sich die Schwäche des zentralen Datenteams und die Stärke des Data Mesh, das die Verantwortung dem Wissen folgen lässt.

Hinzu kommt, dass die Datennutzung in Finanzinstituten zunehmend wichtig wird, für die KI, für die Steuerung, für die Compliance. Wer seine Daten nicht gut beherrscht, kann diese Möglichkeiten nicht nutzen. Data Mesh bietet einen Weg, die Datennutzung aus dem Engpass des zentralen Teams zu befreien und auf eine tragfähige, verteilte Grundlage zu stellen. Das ist für Finanzinstitute, die ihre Daten zum Wert machen wollen, ein vielversprechender Ansatz.

Die vier Prinzipien im Zusammenspiel

Data Mesh ruht auf vier Prinzipien, die nur im Zusammenspiel ihre Wirkung entfalten. Das erste ist die fachliche Eigenverantwortung der Domänen, die die Daten dorthin gibt, wo das Wissen sitzt. Das zweite ist der Gedanke, Daten als Produkt zu begreifen, der die Qualität hebt. Das dritte ist die gemeinsame Self-Service-Plattform, die die Domänen befähigt, ohne sie zu bevormunden. Das vierte ist eine übergreifende Steuerung, die gemeinsame Regeln setzt, ohne die Eigenverantwortung zu ersticken.

Wer nur ein oder zwei dieser Prinzipien umsetzt, bekommt nicht den halben Nutzen, sondern oft gar keinen. Eine Plattform ohne fachliche Eigenverantwortung ist nur ein neues zentrales Werkzeug. Eigenverantwortung ohne gemeinsame Regeln führt zu Dateninseln, die nicht zusammenpassen. Erst das Zusammenspiel aller vier Prinzipien macht aus dem Data Mesh das, was es sein soll: eine verteilte, aber kohärente Datenarchitektur, in der die Verantwortung dem Wissen folgt und die Datennutzung sich aus dem Engpass befreit.

Was eine Domäne in der Bank ist

Der Begriff der Domäne ist für Finanzinstitute zunächst abstrakt, lässt sich aber konkret fassen. Eine Domäne ist ein fachlich abgegrenzter Bereich mit eigenem Wissen, eigenen Prozessen und eigenen Daten. In einer Bank sind das etwa das Kreditgeschäft, der Zahlungsverkehr, das Wertpapiergeschäft, das Risikomanagement, die Compliance oder der Vertrieb. Jeder dieser Bereiche erzeugt und nutzt Daten, die nur im Verständnis des Bereichs ihren vollen Sinn ergeben.

Die Kunst liegt darin, die Domänen richtig zu schneiden. Sie dürfen nicht zu groß sein, sonst entsteht innerhalb der Domäne wieder der alte Engpass. Sie dürfen nicht zu klein sein, sonst zersplittert die Verantwortung in unzählige Einheiten, die niemand mehr überblickt. Der richtige Schnitt folgt den fachlichen Grenzen, den Stellen, an denen sich das Wissen und die Prozesse natürlich gliedern. Dieser Schnitt ist eine der wichtigsten Entscheidungen beim Aufbau eines Data Mesh, denn er prägt die gesamte Architektur.

Die regulatorische Dimension

Für Finanzinstitute hat die Datenarchitektur immer auch eine regulatorische Dimension. Die Aufsicht verlangt, dass die Institute ihre Daten beherrschen, ihre Herkunft nachvollziehen und ihre Qualität sichern können. Die Grundsätze zur Datenaggregation und zum Risikoreporting, im Aufsichtsjargon als Datenhaushalt-Anforderungen bekannt, stellen hohe Ansprüche an die Datenqualität und die Nachvollziehbarkeit. Ein Datenwirrwarr, in dem niemand für die Daten verantwortlich ist, lässt sich mit diesen Anforderungen nicht vereinbaren.

Hier zeigt das Data Mesh eine oft übersehene Stärke. Indem es jeder Domäne die klare Verantwortung für ihre Daten gibt, schafft es genau die Zuständigkeit und Nachvollziehbarkeit, die die Aufsicht verlangt. Es ist klar, wer für welche Daten verantwortlich ist, wer ihre Qualität sichert und wer Auskunft über ihre Herkunft geben kann. Das Data Mesh ist damit nicht nur eine Architektur für mehr Effizienz, sondern auch eine, die der regulatorischen Pflicht zur Datenbeherrschung entgegenkommt.

Der Weg dorthin ist schrittweise

Niemand baut ein Data Mesh über Nacht. Der Weg dorthin ist schrittweise, und er beginnt am besten mit einer Domäne, in der das Potenzial groß und die Bereitschaft hoch ist. Diese erste Domäne übernimmt die Verantwortung für ihre Daten, baut ihr erstes Datenprodukt und sammelt die Erfahrungen, aus denen die anderen lernen. Aus diesem ersten Erfolg wächst das Mesh, Domäne um Domäne, bis es das ganze Institut umfasst.

Dieser schrittweise Weg hat den Vorteil, dass er das Risiko begrenzt und den Nutzen früh sichtbar macht. Statt ein riesiges Programm aufzusetzen, das erst nach Jahren Ergebnisse liefert, zeigt schon die erste Domäne, was das Data Mesh leisten kann. Dieser frühe Erfolg überzeugt die Skeptiker, motiviert die anderen Domänen und schafft die Grundlage für das weitere Wachstum. Er ist der Beweis, dass die verteilte Verantwortung funktioniert.

Die häufigsten Fehler beim Einstieg

Beim Einstieg in das Data Mesh wiederholen sich bestimmte Fehler. Der erste ist die Verwechslung mit einem reinen Technikprojekt, bei dem eine Plattform gebaut, aber die Verantwortung nicht verlagert wird. Der zweite ist der zu große Wurf, der das ganze Institut auf einmal umstellen will und sich dabei verhebt. Der dritte ist die Vernachlässigung der Domänen, die zur Verantwortung befähigt werden müssen und nicht einfach damit allein gelassen werden dürfen. Wer diese Fehler kennt, kann sie vermeiden.

Diese Fehler haben eine gemeinsame Wurzel: die Unterschätzung der organisatorischen und kulturellen Dimension. Wer das Data Mesh als Technik begreift, übersieht, dass sein Kern die neue Verteilung von Verantwortung ist. Wer den großen Wurf wagt, überfordert die Organisation. Wer die Domänen allein lässt, verkennt, dass sie Unterstützung brauchen, um die neue Verantwortung zu tragen. Die Vermeidung dieser Fehler beginnt deshalb mit dem richtigen Verständnis dessen, was Data Mesh wirklich ist.

Der wirtschaftliche Nutzen

Am Ende muss sich das Data Mesh wirtschaftlich rechnen, und es tut das auf mehreren Wegen. Es beschleunigt die Datennutzung, weil die Domänen ihre Daten selbst bereitstellen, statt auf das zentrale Team zu warten. Es hebt die Datenqualität, weil die Domänen ihre Daten als Produkt verantworten. Und es schafft die Grundlage für die KI und die datengetriebene Steuerung, die ohne beherrschte Daten nicht funktionieren. Diese Wirkungen summieren sich zu einem Nutzen, der den Aufwand des Übergangs rechtfertigt.

Dieser Nutzen ist umso größer, je stärker ein Institut auf seine Daten angewiesen ist. Und die Abhängigkeit von den Daten wächst, weil die KI, die Steuerung und die Compliance immer mehr von ihnen verlangen. Wer seine Daten beherrscht, kann diese Möglichkeiten nutzen, wer sie nicht beherrscht, bleibt zurück. Das Data Mesh ist deshalb keine Frage der technischen Mode, sondern eine Investition in die Fähigkeit, die eigenen Daten zum Wert zu machen. Wer diese Investition jetzt angeht, schafft sich einen Vorsprung, der mit der wachsenden Bedeutung der Daten immer wertvoller wird, und vermeidet, eines Tages festzustellen, dass die ungeordneten Daten zur Bremse für jede weitere Entwicklung geworden sind. Die Erfahrung anderer Branchen zeigt, dass der Übergang zwar Geduld verlangt, sich aber für jene auszahlt, die ihn entschlossen und mit dem richtigen Verständnis angehen, statt ihn als bloßes Technikvorhaben misszuverstehen. Wir begleiten Sie auf diesem Weg von der ersten Standortbestimmung bis zur ausgereiften Architektur.

Der Wandel ist mehr als Technik

Der Übergang zum Data Mesh ist nicht in erster Linie eine technische Frage, sondern eine organisatorische und kulturelle. Er verlangt, die Verantwortung für die Daten neu zu verteilen, die Domänen zur Verantwortung zu befähigen und die Haltung zu den Daten zu verändern. Das berührt gewachsene Strukturen und Gewohnheiten, und es ist deshalb anspruchsvoller als die Einführung einer neuen Technik. Die Technik unterstützt den Wandel, aber sie ersetzt ihn nicht.

Mehr zum Thema: Headless SaaS in der Agentic-AI-Ära: Warum Legacy-Plattformen scheitern werden und Banking Super-App: Was wirklich dahintersteckt und warum die meisten scheitern..

Gerade deshalb scheitern manche Versuche, Data Mesh einzuführen, an der Erwartung, es sei ein Technikprojekt. Wer nur die Plattform baut, aber die Verantwortung nicht verlagert und die Kultur nicht verändert, bekommt eine neue Technik auf den alten Strukturen und löst das Problem nicht. Wir helfen Ihnen, den Übergang zum Data Mesh als das anzugehen, was er ist: einen organisatorischen Wandel, der die Verantwortung dem Wissen folgen lässt und die Datennutzung aus dem Engpass befreit. Strategie und Umsetzung aus einer Hand. Beginnen Sie mit einem Workshop.