Viele Organisationen haben ihre Architektur in den letzten Jahren konsequent entlang von Domänen und Microservices aufgebaut. In meinem derzeitigen Projektumfeld, dem Online-Einzelhandel, sind Beispiele für Domänen die Bereiche Suchen, Entdecken und Kaufen.
Dadurch sind die Teams unabhängiger geworden, verstehen ihre fachlichen Prozesse besser und können Features schneller entwickeln. Dabei verantworten sie auch ihre Daten sowie die Datenhaltung selbst und müssen nicht auf zentralen Datenbanken mit dem damit einhergehenden Abstimmungsaufwand arbeiten.
Durch diese Dezentralisierung entsteht jedoch in Bezug auf den Datenaustausch für zentrale Datenanalysen eine neue Herausforderung: Wer ist verantwortlich? Wie werden die Daten geteilt? Und wie lassen sich domänenübergreifend Erkenntnisse gewinnen, ohne wieder zentrale Engpässe (zentrales Datenplattform-Team) zu schaffen?
In meiner Arbeit in verschiedenen Teams bei einem Kunden habe ich genau diese Fragen mehrfach erlebt. Dabei wurde schnell klar: Die Antworten darauf hängen weniger von konkreten Tools ab, sondern davon, wie Organisationen Verantwortung für Daten verstehen – und wie gut dies zur bestehenden Architektur passt.
Ein möglicher Lösungsansatz ist Data Mesh. Hier steht die Bereitstellung und Nutzung analytischer Daten im Mittelpunkt. Dieser Ansatz lässt sich jedoch weiterdenken: Daten können nicht nur analytisch, sondern auch aufbereitet wieder operational genutzt werden. Darauf werde ich später noch genauer eingehen.
Data Mesh
Data Mesh ist ein soziotechnischer Ansatz für dezentrale Datenarchitekturen. Soziotechnisch bedeutet, dass der Ansatz sowohl technische Lösungen als auch die Zusammenarbeit und Verantwortung der Teams verbindet. Die Grundidee dabei ist, die Domänen (Teams) ihre Daten selbst verantworten (Domain Ownership), sie als Produkte (Data as a Product) bereitstellen und durch eine gemeinsame Plattform (Self-serve Data Platform) unterstützt werden. Governance wird dabei nicht zentral vorgegeben, sondern föderiert organisiert (Federated Governance). Ein konkretes Beispiel für ein Data Product aus meiner Praxis ist das Bereitstellen von Daten zu Newsletter-An- und Abmeldungen. Andere Teams können diese beispielsweise mit Bestelldaten verknüpfen und die Conversion Rate (wieviele Käufe entstehen durch die Newsletter tatsächlich) bestimmter Kampagnen ermitteln.
Für Organisationen, die bereits stark entlang von Domänen arbeiten, wirkt das zunächst wie eine logische Weiterentwicklung. Schließlich liegt das Wissen über die Daten ohnehin in den Teams, die sie erzeugen. Gleichzeitig wird dabei oft unterschätzt, was sich in Bezug auf die Zusammenführung und Analyse der Daten konkret verändert.
Data Mesh bedeutet nicht nur eine andere technische Architektur, sondern auch neue Erwartungen an Teams: Daten müssen aktiv aufbereitet, dokumentiert und für andere nutzbar gemacht werden. An diesem Punkt wird aus der theoretischen Idee schnell eine echte organisatorische Herausforderung.
Ausgangspunkt: Dezentrale Systeme, zentrale Herausforderungen
In modernen Architekturen besitzen und gestalten Teams ihre Services und Datenbanken unabhängig voneinander. Daten werden bewusst nicht direkt geteilt, sondern über APIs (synchron) oder Events (asynchron) zugänglich gemacht. Dieses Prinzip sorgt für lose Kopplung und klare Verantwortlichkeiten – und ist für operative Systeme Stand der Technik.
Für analytische Fragestellungen zeigt sich hier jedoch eine Schwierigkeit. Daten liegen verteilt in vielen Systemen, ihre Bedeutung unterscheidet sich je nach Domäne, und für übergreifende Analysen müssen sie erst zusammengeführt werden. Gleichzeitig entstehen stetig und zunehmend in kürzeren Zyklen neue Anforderungen. Dies wird oft durch Fachbereiche getrieben, die schneller zu Entscheidungen kommen wollen oder müssen.
In klassischen Setups wird diese Aufgabe häufig einem zentralen Datenplattform-Team übertragen. Das führt schnell zu Engpässen: fehlendes Domänenwissen, lange Durchlaufzeiten bei Änderungen und eine wachsende Kluft zwischen operativer Entwicklung und analytischer Nutzung.
Genau aus dieser Spannung heraus entsteht die Motivation für Ansätze wie Data Mesh.
Der Weg zum Data Mesh ist ein Lernprozess
Was ich in meinen Teams beobachtet habe: Der Weg zum aktiven Arbeiten im und mit dem Data Mesh verläuft selten geplant, sondern entwickelt sich schrittweise. Diese Entwicklung lässt sich gut als Reise in mehreren Stufen beschreiben und wird daher oft als Muster im Data-Mesh-Kontext verwendet (siehe Data Mesh Architecture).
Am Anfang steht ein System ohne analytischen Anspruch (Level 0 – No Data Analytics). Der Fokus liegt hier darauf, Funktionalität zu liefern und das System stabil zu betreiben. Analytische Daten spielen zu diesem Zeitpunkt kaum eine Rolle. Das ist meist der erste MVP des Produkts, das ein Team entwickelt.
Mit oder kurz nach dem Go-live entstehen erste Fragen – und damit der Übergang zu Level 1 – Operational Database Queries. Teams beginnen, ihre Produktionsdaten direkt über die Datenbanken auszuwerten. Das ist pragmatisch und ein wichtiger erster Schritt, um überhaupt ein Gefühl für die eigenen Daten zu entwickeln. Da der analytische Zugriff auf Produktionsdatenbanken jedoch Einfluss auf das System hat (Performance), ist dieser Ansatz nicht nachhaltig.
In Level 2 – Analyze own Data – verändert sich die Arbeitsweise: Teams nutzen erstmals gezielt eine bereitgestellte Datenplattform. Sie speichern und analysieren ihre eigenen Daten strukturiert und schaffen damit implizit ihr erstes (internes) Data Product. Entscheidungen werden zunehmend datengetrieben getroffen. Durch den Wechsel auf eine vom Produktivsystem unabhängige Datenplattform werden mögliche Performanceprobleme durch Analysen umgangen.
Der nächste Schritt zu Level 3 – Analyze Cross-Domain Data – ergibt sich fast zwangsläufig, sobald die eigenen Daten nicht mehr ausreichen. Dabei können sowohl das Team selbst oder auch die angeschlossenen Fachbereiche größere Einsichten in die Daten benötigen. Teams beginnen jetzt, Daten aus anderen Domänen einzubeziehen. Bei uns waren Use Cases beispielsweise A/B-Tests oder die Bewertung von Marketing-Kampagnen über mehrere Systeme hinweg. Diese sind nur mit unseren eigenen Daten nicht möglich gewesen. Hier zeigt sich erstmals der eigentliche Mehrwert eines Data Mesh.
In Level 4 – Publish Data Contract – wird die Zusammenarbeit verbindlich. Daten werden nicht mehr nur genutzt, sondern bewusst für andere bereitgestellt. Wesentlich sind hier klare Schnittstellen, definierte Semantik und entsprechende Vereinbarungen, beispielsweise für Aktualität und Änderungsfrequenz. Data Contracts und Governance gewinnen an Bedeutung.
Diese vier Stufen sind im Kern das, was Data Mesh beschreibt: eine schrittweise Verlagerung von Datenverantwortung in die Domänen, unterstützt durch eine Plattform und gemeinsame Regeln.
In meinem ersten Team sind wir die Reise in genau diesen vier Stufen gegangen. Eine wichtige Denkweise war dabei, analytische Daten nicht mehr nur als Nebenprodukt eines Services zu betrachten. Data Products bedeuten, für andere Teams wertvolle Daten aktiv bereitzustellen: mit klarer Semantik, definierten Zugriffsmöglichkeiten und der Erwartung, dass die anderen Teams sie nutzen können.
In der Praxis führte die Nutzung von Data Mesh für uns auch zu neuen und vor allem schnelleren Business-Entscheidungen basierend auf vorher nicht so einfach und flexibel möglichen Datenanalysen.
Wenn Daten zurück ins Produkt fließen
Das Rückführen der Daten aus der analytischen in die operationale Welt ist im eigentlichen Data Mesh-Ansatz ausgeschlossen bzw. nicht vorgesehen. Ich habe aber in einem Team festgestellt, dass, sobald Data Products etabliert sind und domänenübergreifend genutzt werden, ein neuer Bedarf entstehen kann: Die gewonnenen Erkenntnisse sollen nicht nur analysiert, sondern wieder in operative Systeme integriert werden.
Gerade bei komplexeren Fragestellungen, beispielsweise bei der Betrugserkennung, reicht die Perspektive einzelner Domänen nicht mehr aus. Erst die Kombination vieler Datenpunkte über mehrere Quellen (Datenprodukte) hinweg liefert verwertbare Ergebnisse. Diese entstehen typischerweise in der analytischen Welt. Gerade durch den Einsatz von KI in der Analyse von Daten entstehen hier Möglichkeiten, die in operativen Systemen so nicht vorhanden sind. Der eigentliche Mehrwert entsteht also erst, wenn die Ergebnisse zurück in die operativen Systeme fließen und dort für Entscheidungen genutzt werden können. Bei der Betrugserkennung können Kunden beispielsweise gewarnt werden, wenn Vorgänge (wie plötzliche Adressänderungen oder Bestellungen in großer Höhe anstatt des normalen Volumens) in ihren Konten in den analytischen Daten auffallen.
Für mich geht das neue Level 5 – Re-integrate Data – über den klassischen Data Mesh-Ansatz hinaus.
Durch den Wechsel von der analytischen zurück in die operative Welt verändern bzw. verstärken sich jedoch auch die Anforderungen an die Datenprodukte:
- Daten müssen nicht nur verfügbar, sondern auch hinreichend aktuell sein.
- Data Contracts werden kritisch für operative Nutzung.
- Integrationen müssen standardisiert und wiederverwendbar funktionieren.
- Daten im Data Mesh müssen vor Manipulation geschützt werden, um keine Angriffsvektoren auf Produktivsysteme zu öffnen.
Vor allem aber verschiebt sich die Rolle der Daten erneut: Sie sind nicht mehr nur Grundlage für Entscheidungen – sondern werden wieder selbst Teil der Produktlogik.
Was oft unterschätzt wird
Data Mesh ist weniger ein technisches Thema als eine Frage von Verantwortlichkeiten und Zusammenarbeit. Zwar ist der Aufbau einer Plattform wichtig, aber entscheidend ist, dass Teams ihre Daten wirklich als eigenen Bestandteil verstehen. Der Weg zu einem funktionierenden Data Mesh ist eine Reise. Teams entwickeln sich Schritt für Schritt weiter, und Stufen lassen sich nicht überspringen. Es ist auch vollkommen in Ordnung, wenn jedes Team auf einer anderen Stufe der Reise steht. Teams können und sollten aber von den Erfahrungen der anderen profitieren.
Der eigentliche Wert zeigt sich oft erst spät: nicht bei den ersten Auswertungen, sondern dann, wenn Daten über Domänengrenzen hinweg genutzt und vielleicht, wie in meinem Fall in Stufe 5, wieder in Produkte integriert werden. Spannend kann dieser Ansatz auch im Kontext von KI werden. Data Mesh schafft durch einen gepflegten Datenkatalog die Grundlage dafür, dass intelligente Systeme oder Agenten eigenständig passende Datenprodukte identifizieren, kombinieren und für unterschiedliche Use-Cases nutzen können.
Fazit
Data Mesh ist eine mögliche Antwort auf die Herausforderungen der Dezentralisierung in der Entwicklung für analytische Fragestellungen. Es ist kein schneller Architekturwechsel, sondern ein kontinuierlicher Lernprozess. Jedes Team muss diesen Weg in einer Data-Mesh-Architektur selbst gehen.
Die zentrale Verschiebung liegt in der Verantwortung, denn Daten werden dort gepflegt und bereitgestellt, wo sie entstehen. Langfristig entstehen daraus klare Vorteile: bessere Datenqualität, schnellere Entscheidungen und Systeme, die nicht nur Daten erzeugen, sondern sie auch wirksam nutzen. Ob dies nur analytisch geschieht oder, wie in meinem Fall, auch den Weg zurück ins Produktivsystem findet, muss dabei individuell bewertet und entschieden werden.
