Data Mesh nach dem Hype: Was wirklich funktioniert

Wenn man heute mit Unternehmen über Data Mesh spricht, fallen die Reaktionen selten eindeutig aus. Es sind keine grundsätzlichen Ablehnungen, eher irritierte Rückfragen, manchmal Skepsis, manchmal Ermüdung.

Solche Fragen sind keine Polemik. Sie entstehen in Gesprächen mit Fachbereichen, IT-Teams und Entscheidern, die sehr konkrete Verantwortung tragen. Verantwortung für stabile Prozesse, für regulatorische Anforderungen, für knappe Budgets und begrenzte personelle Ressourcen. In diesem Kontext wirkt Data Mesh oft wie ein Versprechen, das schwer einzulösen ist.

Gleichzeitig ist auffällig, wo Data Mesh sehr gut funktioniert. In technologiegetriebenen Unternehmen wie Netflix oder Zalando ist Datenverarbeitung ein zentraler Teil der Wertschöpfung. Die Nähe zwischen Fachlichkeit und Technologie ist hoch, das Skillgap gering. Unter diesen Bedingungen entfalten die Ideen von Data Mesh ihre volle Wirkung.

Für viele andere Unternehmen gilt das nicht. Ihre Wertschöpfung liegt in Industrieprodukten, Dienstleistungen oder regulierten Prozessen. Die Organisation ist darauf optimiert, nicht auf Datenarchitektur. Trotzdem wäre es ein Fehler, Data Mesh deshalb pauschal als nicht relevant abzutun. Denn jenseits der reinen Lehre enthält es Prinzipien, die auch in traditionelleren, weniger datenaffinen Organisationen sehr wirksam sein können.

Die Diskrepanz zwischen Anspruch und Wirklichkeit lässt sich gut erklären, wenn man die typischen Gründe betrachtet, an denen Data-Mesh-Initiativen in der Praxis ins Stocken geraten.

Ein häufiger Ausgangspunkt ist die Vorstellung, Data Mesh erfordere eine umfassende Reorganisation entlang von Daten-Domänen. In der Realität sind Unternehmen jedoch nicht um Daten herum gebaut, sondern um ihre Wertschöpfung. Produktbereiche, Serviceeinheiten, rechtliche Strukturen oder regulatorische Zuständigkeiten lassen sich nicht einfach neu zuschneiden, nur weil Datenflüsse es nahelegen würden. Die Folge ist ein organisatorischer Anspruch, der mit der tatsächlichen Steuerungslogik des Unternehmens kollidiert.

Hinzu kommt das Thema Datenkompetenz. Data Mesh setzt voraus, dass Fachbereiche Verantwortung für ihre Daten übernehmen können. In vielen Organisationen ist Data Literacy jedoch kein Zustand, den man beschließt, sondern eine Fähigkeit, die sich über Zeit entwickelt. Wenn Fachbereiche plötzlich für Modellierung, Qualitätssicherung oder technische Entscheidungen verantwortlich sein sollen, entsteht Überforderung. Nicht aus mangelndem Willen, sondern weil die Voraussetzungen fehlen.

Ein weiterer Bremsklotz liegt in der IT-Realität. Viele Unternehmen befinden sich erst am Anfang ihrer Cloud-Reise. Infrastrukturen sind historisch gewachsen, Prozesse stark zentralisiert, Sicherheits- und Betriebsfragen dominieren den Alltag. Unter diesen Bedingungen wirkt die Vorstellung einer föderalen Self-Service-Infrastruktur schnell abstrakt. Gleichzeitig kann eine unkoordinierte Dezentralisierung dazu führen, dass Governance, Sicherheit und Betrieb aus dem Blick geraten.

Schließlich zeigt sich in der Praxis ein sehr konkretes Risiko: Redundanz. Wenn nicht klar geregelt ist, wer welche Daten extrahiert, aufbereitet und bereitstellt, entstehen parallele Strukturen. Mehrere Versionen derselben Daten, unterschiedliche Definitionen, widersprüchliche Kennzahlen. Was als Autonomie gedacht war, untergräbt am Ende Vertrauen und Synergien.

Ein zentrales Problem vieler Data-Mesh-Initiativen liegt weniger in einzelnen Entscheidungen als in der zugrunde liegenden Logik. Data Mesh wurde häufig als etwas verstanden, das man entweder vollständig umsetzt oder gar nicht. Entweder radikale Dezentralisierung oder klassisches zentrales Data Warehouse. Entweder Domain Ownership oder zentrale Verantwortung. Entweder Self Service oder Governance. Diese „ganz oder gar nicht“-Logik erzeugt Erwartungshaltungen, die in der Praxis kaum erfüllbar sind.

In realen Organisationen lassen sich solche Gegensätze selten sauber trennen. Verantwortung, Betrieb, Architektur und Governance sind miteinander verflochten. Der praktische Wert von Data Mesh liegt deshalb darin, einzelne Prinzipien gezielt anzuwenden, um konkrete Probleme zu lösen. Betrachtet man erfolgreiche Umsetzungen unter diesem Blickwinkel, lassen sich vier wiederkehrende Leitgedanken erkennen.

Ein zentrales Anliegen von Data Mesh ist die Verlagerung von Datenverantwortung näher an die Fachlichkeit. In der Praxis wird dieser Anspruch jedoch oft mit organisatorischem Umbau gleichgesetzt. Fachbereiche werden neu zugeschnitten, Rollen umbenannt, Verantwortlichkeiten formal verschoben. Das allein führt jedoch selten zu besserem Umgang mit Daten.

Was tatsächlich wirkt, ist Enablement. Fachbereiche können nur dann Verantwortung für ihre Daten übernehmen, wenn sie befähigt werden, diese Verantwortung auszufüllen. Dazu gehören klare Prozesse, verständliche Modelle, technische Templates und begleitendes Coaching. Reorganisation verändert Zuständigkeiten auf dem Papier. Enablement verändert die tatsächliche Arbeitsweise. Data Ownership entsteht nicht durch neue Kästen im Organigramm, sondern durch die Fähigkeit, fachliche Entscheidungen auf Basis von Daten selbst treffen und verantworten zu können.

Ein weiterer häufiger Konflikt entsteht rund um die Frage, wie viel Dezentralität sinnvoll ist. Wird jede Domäne vollständig für ihre Datenintegration verantwortlich gemacht, entstehen zwangsläufig Redundanzen. Dieselben Quelldaten werden mehrfach extrahiert, aufbereitet und interpretiert. Was als Autonomie gedacht war, führt zu Silos und widersprüchlichen Ergebnissen.

Ein pragmatischer Ansatz trennt fachliche Verantwortung von technischer Integration. Gemeinsame Data Products auf einer zentralen Basisschicht stellen quellnahe, konsistente Daten bereit. Darauf aufbauend können Fachbereiche ihre eigenen Datenprodukte entwickeln, mit eigener Logik und eigenen Anforderungen. Synergien bleiben erhalten, während die fachliche Gestaltung dezentral erfolgt. Verantwortung liegt dort, wo sie sinnvoll ist, bei der fachlichen Interpretation, nicht bei der wiederholten technischen Erschließung derselben Daten.

Data Mesh wird häufig als Gegenentwurf zu zentralen Plattformen gelesen. In der Praxis zeigt sich jedoch, dass dezentrale Arbeit ohne eine stabile, gemeinsam betriebene technologische Basis kaum skalierbar ist. Fachbereiche sind selten in der Lage oder willens, sich um Infrastruktur, Sicherheit, Betrieb und Compliance zu kümmern.

Eine zentral gemanagte Plattform entlastet genau an dieser Stelle. Sie stellt standardisierte Umgebungen, Automatisierung und klare Leitplanken bereit. Fachbereiche können sich auf ihre fachliche Arbeit konzentrieren, ohne in technische Betriebsaufgaben gezogen zu werden. Das zentrale Betriebsteam ist dabei kein Relikt klassischer IT, sondern ein integraler Bestandteil moderner Datenorganisationen. Es sorgt dafür, dass Eigenständigkeit möglich wird, ohne dass Kontrollverlust oder Schatten-IT entstehen.

Föderale Governance bedeutet nicht weniger Regeln, sondern klar definierte globale Leitplanken mit dezentraler Verantwortung in der Anwendung. Zentrale Standards für Sicherheit, Begriffe und Zugriffsmodelle ermöglichen erst, dass Teams eigenständig arbeiten können, ohne Redundanz und Brüche zu erzeugen. Zentralisierung von Infrastruktur und Regeln steht damit nicht im Widerspruch zur Dezentralisierung, sondern schafft ihre Voraussetzung. Das verbindende Element sind gemeinsam verwaltete Metadaten.

Ein zentraler Data Catalog macht sichtbar, welche Daten existieren, wem sie gehören, wie sie genutzt werden und in welcher Qualität sie vorliegen. Diese Transparenz ersetzt Kontrolle durch Orientierung. Sie ermöglicht Wiederverwendung, klärt Ownership und schafft eine Grundlage für Qualitätssicherung und Steuerung. In verteilten Datenlandschaften ist ein gepflegter Katalog deshalb kein optionales Governance-Werkzeug, sondern der Ausgangspunkt dafür, dass föderale Verantwortung überhaupt funktionieren kann.

Data Mesh ist nicht als umfassendes Modell gescheitert, sondern an der Erwartung, es müsse vollständig und konsequent umgesetzt werden. In der Praxis zeigt sich ein anderes Bild. Dort, wo seine Prinzipien pragmatisch angewendet werden, entfalten sie Wirkung, oft ohne explizit so benannt zu werden.

Was bleibt, sind keine neuen Organigramme oder Architekturdiagramme, sondern ein veränderter Blick auf Verantwortung, Zusammenarbeit und Steuerung von Daten. Enablement statt Reorganisation, gemeinsame Datenprodukte statt isolierter Silos, Plattformen als Ermöglicher und Metadaten als Grundlage für Transparenz. In dieser Form lebt Data Mesh weiter, weniger als Zielbild, mehr als Denkrahmen für den Umgang mit wachsenden Datenlandschaften.