Jenseits der Plattform: Warum Architecture & Tools über Data Mesh hinausgehen müssen

In den letzten Jahren haben viele Unternehmen ihre Hausaufgaben gemacht: Es gibt moderne Datenplattformen, die Cloud ist etabliert, erste KI-Anwendungen laufen produktiv. Und dennoch bleibt das Gefühl: „Wir holen nicht das raus, was eigentlich drinsteckt.“

Die Ursache liegt selten in fehlender Technologie, sondern in einer Architektur, die zwar modern aussieht, aber im Alltag nicht richtig „greift“. Datenprodukte werden nicht konsequent genutzt, Governance funktioniert nur auf dem Papier, und die Interaktion der beteiligten Plattformen bleibt holprig.

Status quo der Daten Architektur: Gute Plattform, wenig Wirkung

Wir sehen bei Kundinnen und Kunden immer wieder ähnliche Muster:

• Ein leistungsfähiges Data Warehouse oder ein Data Lakehouse ist etabliert.
• Self-Service-Tools für Analytics und Reporting stehen bereit.
• Erste Data Products wie „Customer 360“ oder „Sales Dashboard“ existieren.

Trotzdem:

• Fachbereiche nutzen weiterhin ihre Excel-Schattenwelten,
• neue Datenprodukte kommen nur langsam in die Fläche,
• die Zahl der unterschiedlichen „Wahrheiten“ im Unternehmen nimmt eher zu als ab.

Der Grund: Architektur wurde zu oft als reines Technologieprojekt verstanden, nicht als Arbeitsmodus eines Datenökosystems.

Data Mesh: Vom Monolithen zum Ökosystem

Moderne Datenarchitektur besteht heute aus einem Zusammenspiel spezialisierter Plattformen: Analytics, Machine Learning, IoT, Echtzeit-Streaming, generative KI. Der entscheidende Schritt ist die Abkehr vom „einen großen System“ hin zu einem harmonisierten Ökosystem, das drei Dinge leistet:

• 1. Nahtlose Integration über Systemgrenzen hinweg: Daten fließen kontrolliert, aber reibungsarm zwischen operativen Systemen (ERP, CRM, Shop, Ticketing) und analytischen Plattformen – und wieder zurück.
• 2. Domain-orientierte Verantwortlichkeit: Teams aus Marketing, Vertrieb, Operations & Co. werden zu Domänen, die ihre Datenprodukte verantworten – mit klaren Schemata, Qualitätsanforderungen und Service Levels.
• 3. Föderierte Governance statt zentraler Flaschenhals-IT: Zentrale Leitplanken (Security, Compliance, Standards) definieren den Rahmen, innerhalb dessen Domänen schnell handeln können, ohne jedes Detail abzustimmen.

Konzepte wie Data Mesh fassen diese Prinzipien in eine Architekturphilosophie. In der Praxis scheitert die Umsetzung aber häufig an genau zwei Punkten: interner Interaktion und gelebter Governance.

Herausforderungen von Data Mesh: Interaktion & Governance im Alltag

Auch wenn die Plattform technisch gut aufgesetzt ist, bleiben typische Spannungsfelder:

• Schnittstellen zwischen Plattformen und Teams: Marketing braucht schnell ein neues Segment, Finance ein valides Reporting für den Vorstand, das Data-Science-Team will ein Experiment fahren – und alle drei konkurrieren um dieselben Daten und Ressourcen.
• Unklare Zuständigkeiten: Wem „gehört“ ein Data Product? Wer entscheidet über Änderungen am Schema? Wer priorisiert Anforderungen verschiedener Stakeholder?
• Governance als Bremsklotz oder blinder Fleck: Entweder setzt Governance zu spät ein („wir regeln das, wenn wir größer sind“) oder sie wird so rigid umgesetzt, dass Innovation kaum noch möglich ist.
• Kein zentraler Data Catalog oder Market Place: Entweder gibts gar kein Data Catalog Tool oder mehrere die nicht miteinander sprechen. Was bleibt sind Silos und nicht konsumierbare Assets.

Das Ergebnis sind neue Silos auf moderner Technologie: Marketing, Vertrieb, Operations und IT bauen jeweils eigene Dateninseln, nur diesmal in der Cloud.

Strukturiertes Setup für Data Mesh: Architektur als Enabler für Value

Damit Architektur nicht zum Selbstzweck wird, sondern die im ersten Blog-Beitrag beschriebene Value-Orientierung unterstützt, braucht es ein strukturiertes Setup aus drei Ebenen:

1. Infrastruktur & Plattformen

• Cloud-native Basis: Automatische Skalierung, flexible Ressourcennutzung, standardisierte Sicherheitsmechanismen.
• Self-Service-Fähigkeiten: Domänen können Datenprodukte erstellen, testen und deployen, ohne jedes Mal die zentrale IT zu blockieren.
• Standardisierte Schnittstellen: API- und Event-basiertes Design, das definierte Wege für Datenflüsse bietet – statt individueller Punkt-zu-Punkt-Integrationen.

2. Datenprodukte & Domänen

Data-as-a-Product: Jedes Data Product hat

• eindeutigen Owner
• definierte Abnehmer
• dokumentierte Qualitätskriterien (Aktualität, Vollständigkeit, Latenz)
• klare Service Level Agreements

Domänenorientierung: Teams wie „Sales & Marketing“, „Customer Service“ oder „Supply Chain“ verantworten ihre Data Products fachlich – von der Definition bis zur Weiterentwicklung.

3. Governance & Collaboration

Föderierte Governance-Modelle:

• Zentrale Policies (Security, Datenschutz, Compliance, Naming-Standards)
• Dezentrale Verantwortung für Umsetzung und Weiterentwicklung in den Domänen

Lebende Artefakte:

• Datenkataloge, die zeigen, welche Data Products existieren und wie sie genutzt werden können
• Data Contracts, die festhalten, welche Felder, Formate und Qualitätsstandards zwischen Producer und Consumer gelten
• Automatisierte Qualitätsprüfungen und Data Lineage, die Transparenz über Herkunft, Transformation und Nutzung schaffen

So entsteht eine Umgebung, in der Datenprodukte nicht nur gebaut, sondern auch vertrauensvoll und sicher genutzt werden, und zwar genau dort, wo die im ersten Blog-Beitrag beschriebenen „Actions“ stattfinden: in CRM-Systemen, Shops, Marketing-Automation, Service-Tools oder operativen Workflows.

Daten Architektur im Dienste der „Insight-to-Action“-Kette

Der vielleicht wichtigste Perspektivwechsel: Eine gute Datenarchitektur ist keine Sammlung moderner Tools, sondern die organisierte Fähigkeit, Daten in Wert zu übersetzen.

Das bedeutet, dass

• Use Cases treiben Architektur – nicht umgekehrt: Statt „Wir brauchen einen neuen Data Lake“ heißt es: „Wir wollen Churn senken, Upselling verbessern, Risiken früh erkennen – welche Architektur befähigt uns dazu?“
• Operative Systeme sind fester Bestandteil der Architektur: Es reicht nicht, Daten in eine Plattform zu ziehen. Relevante Erkenntnisse müssen zurück in die operativen Systeme fließen, damit Kampagnen, Preise, Bestände oder Service-Prozesse sich daran ausrichten können.
• Governance unterstützt Umsetzung, statt sie zu verhindern: Policies und Standards werden bewusst so gestaltet, dass sie einerseits regulatorische Anforderungen erfüllen, andererseits schnelle Iterationen und Experimente erlauben.

Wie adesso unterstützt: Vom Plattform-Projekt zum Datenökosystem

In Kundenprojekten sehen wir immer wieder, dass der Schritt vom „gut ausgebauten Technologie-Stack“ zum funktionierenden Datenökosystem der entscheidende ist. Typische Bausteine unserer Unterstützung:

• Analyse des bestehenden Plattform-Setups und Identifikation von Interaktions- und Governance-Lücken
• Design einer zielbildorientierten Datenarchitektur, die Fachdomänen, Data Products und Governance klar strukturiert
• Aufbau von Self-Service- und Data-as-a-Product-Konzepten, inkl. Rollen, Prozessen und Tooling
• Einführung von föderierter Governance mit klaren Verantwortlichkeiten, Data Contracts und automatisierter Qualitätsüberwachung

Das Ziel ist dabei immer gleich: Eine Architektur, die Value-Case- und Value-Measurement-Mechanismen nicht nur erlaubt, sondern aktiv erleichtert.

Nächster Schritt: Vom Lesen ins Handeln kommen

Wenn ihr das Gefühl habt, dass eure Datenarchitektur „auf dem Papier“ gut aussieht, im Alltag aber noch nicht richtig greift, gibt es zwei einfache Optionen:

Unverbindlicher Pre-Call: 30 Minuten, in denen wir die aktuelle Situation einordnen und mögliche nächste Schritte skizzieren oder über Architektur-Patterns, Governance-Ansätze und Praxisbeispiele für euer Szenario sprechen.

Bei Interesse reichen eine kurze Mail oder eine Kontaktanfrage mit dem Stichwort „Datenökosystem“ – dann melde ich mich mit Vorschlägen zurück.