Check it out
awards
WiWo Award TRUSTEQ
BrandEins Berater 2026 Award
TRUSTEQ kununu awards
TRUSTEQ
CooperativeExcellence

Zeit, Verantwortung für Daten zu übernehmen

Data Mesh

Eine alte Binsenweisheit der Informatik besagt: Systeme funktionieren, bis sie es nicht mehr tun.

Einer der häufigsten Gründe für das Scheitern von bewährten Systemen ist Wachstum. Insbesondere im Umgang mit Daten kann es schnell passieren, dass Unternehmen zu groß für bestehende Architekturen werden. Das mag zunächst wie ein reines Skalierungsproblem aussehen, geht aber oft auf ein grundlegenderes Problem zurück: Kontext. Denn Daten sind nicht nur Spalten und Zeilen, sie tragen Bedeutung. Und wenn unklar ist, wer verantwortlich ist – dann geht genau diese Bedeutung verloren. Wie das Problem entsteht und wie Unternehmen es lösen können, das lesen Sie in diesem Blogpost.

Zentralisierung als Bottleneck

Viele Organisationen haben massiv in zentrale Datenplattformen investiert: DataLakes, Data Warehouses, dedizierte Data-Teams. Daten sollen zum Motor der Entscheidungsfindung werden. Und zunächst funktioniert das auch, Dashboards entstehen, Reports liefern erste Erkenntnisse und Führungskräfte nutzen den Wert von Daten. Doch mit dem Wachstum eines Unternehmens wächst auch der Bedarf:

  • Mehr Datenquellen
  • Komplexere Fragestellungen
  • Höhere Frequenz an Anfragen

Und plötzlich sind zentrale Architekturen überladen, Datenteams verlieren den Überblick und Mehrwert geht verloren. Aus dem ursprünglichen Enabler, dem zentralen Datenteam, wird ein Engpass.

Die Evolution moderner Datenarchitekturen

Moderne Datenarchitekturen mussten sich im Laufe der Zeit und je nach Bedarf stetig anpassen und weiterentwickeln:

Eine „Single Source of Truth: kuratierte Datensätze, verlässliches Reporting. Funktioniert so lange gut, bis die Nachfrage explodiert. Jede neue Metrik, jedes neue Dashboard, jede neue Datenquelle muss durch denselben Flaschenhals. Die Time-to-Insight steigt drastisch. Zusätzlich wächst die Komplexität der Datenmodelle. Immer mehr Sonderlogik wird eingebaut, oft historisch gewachsen und schlecht dokumentiert. Das führt dazu, dass selbst kleine Änderungen riskant werden. Diese Probleme führen zu Schattenlösungen:

  • Teams exportieren Daten nach Excel
  • Teams bauen eigene Pipelines
  • Teams definieren ihre eigenen KPIs

Damit ist die „Single Source of Truth“ faktisch verloren, obwohl sie formal noch existiert.

Die "Data-Lakehouse"- oder "Medaillon"-Architektur strukturiert Datenpipelines in drei Schichten:

  1. Bronze (Rohdaten)
  2. Silber (bereinigte und standardisierte Daten)
  3. Gold (business-ready-data)

Pipelines werden nachvollziehbarer und die Datenqualität steigt. In diesem Modell sind Verantwortliche je Verarbeitungsschicht klar benannt.

Technisch ist dieser Ansatz sauber, aber organisatorisch laufen auch hier alle Daten durch ein zentrales Plattform- oder Datenteam. Das Bottleneck-Problem bleibt.

Die Antwort ist nicht weniger Struktur, sondern eine bessere Verteilung.

„Wie verteilt man Verantwortung so, dass Datenorganisationen skalieren können?“

Die Antwort: Ownership.

Daten werden nicht mehr "abgelegt“, sie werden aktiv gestaltet und verantwortet. Fachbereiche (Domain-Teams) werden nicht länger nur Datenlieferanten, sie werden Owner von DataProducts.

Das bedeutet auch einen grundlegenden Perspektivwechsel: Daten entstehen nicht mehr nur als Nebenprodukt operativer Systeme, sondern werden bewusst als Produkt behandelt („Data as a Product“). Das funktioniert, weil die Fachbereiche ihre Daten am besten verstehen, sie kennen die Geschäftslogik, wissen, was sich ändert, und welche Entscheidungen getroffen werden müssen. Das bedeutet im Idealfall saubere, vertrauenswürdige und klar definierte Daten, die nachvollziehbar dokumentiert sowie für andere Teams unmittelbar nutzbar sind. Dafür braucht jedes Data Product:

  • Klare Definitionen
  • Konsistente Strukturen
  • Verlässliche Verfügbarkeit
  • Eindeutige Ownership
  • Dokumentierte Erwartungen

Data Mesh: Wie alles zusammenkommt

Die Forscherin Zhamak Dehghani beschrieb 2019 erstmals den Ansatz, der viele der vorherigen Ideen konzeptionell vereint: Das Data Mesh.

Die Idee: Wenn Domains ihre Daten als eigene Produkte behandeln, fließen diese nicht länger durch einen zentralen Engpass, sondern bewegen sich frei durch ein vernetztes System. Datenprodukte werden dadurch konsumierbar wie interne APIs: Andere Teams können sie unabhängig entdecken, verstehen und nutzen, ohne die zugrunde liegenden operativen Systeme oder Fachprozesse im Detail kennen zu müssen. Während Engpässe durch die verteilte Verantwortung reduziert und Daten durch gezieltes Domain-Wissen effektiver verarbeitet und strukturiert werden können, erfordert die Einführung einer Data-Mesh-Architektur gleichzeitig tiefgreifende organisatorische Veränderungen.

Teams und Systeme müssen neu ausgerichtet werden. Hinzu kommt die Herausforderung konsistenter Standards: Wenn etwa „Customer“ in jeder Domäne unterschiedlich definiert wird, entstehen neue Silos auf semantischer Ebene. Deshalb sind starke Governance-Strukturen und eine hohe organisatorische Reife entscheidend. Zudem bleiben Domänen voneinander abhängig, da Änderungen an einem Datenprodukt Auswirkungen auf viele andere Teams haben können. Auch das zentrale Data-Team verschwindet nicht, sondern übernimmt einen neuen Fokus auf Infrastruktur, Plattformen und Governance.

Ein funktionierendes Data Mesh benötigt demnach:

Fazit

Das Ziel moderner Datenstrategien ist es nicht mehr, Daten lediglich zu speichern oder zentral zu verwalten. Vielmehr geht es darum, Daten als eigenständige Produkte zu behandeln: mit klarer Verantwortung, definierten Qualitätsstandards und einem konkreten Nutzen für andere Teams und Entscheidungen im Unternehmen. Es geht darum, Daten nutzbar, vertrauenswürdig und skalierbar für das gesamte Unternehmen zu machen. Das Data-Mesh-Prinzip ist dabei kein reines Architekturkonzept, es ist ein organisatorischer Paradigmenwechsel.

Weg von zentraler Kontrolle, hin zu verteilter Verantwortung.

Dabei sind Data Warehouse, Medaillon Architecture und Data Mesh keinesfalls konkurrierende Ansätze. In Wahrheit ergänzen sie sich:

  • Data Mesh (Ownership-Modell): Domains verantworten ihre Datenprodukte
  • Medallion Architecture (Verarbeitungsmodell): Strukturierte Datenpipelines (Bronze, Silver, Gold)
  • Data Warehouse / BI Layer (Konsum-Modell): Business-User greifen über Dashboards und Analytics zu
"Welche Datenarchitektur letztlich die richtige für ein Unternehmen ist, hängt maßgeblich von Faktoren wie organisatorischer Skalierung, Anzahl unabhängiger Domänen, Teamgröße, Governance-Anforderungen und dem gewünschten Grad an Autonomie ab. Während Data Mesh insbesondere in stark skalierten Organisationen zentrale Bottlenecks auflösen kann, bringen Dezentralisierung und domänengetriebene Verantwortung zugleich höhere Anforderungen an Governance, Plattform-Engineering und operative Effizienz mit sich. Für kleinere Unternehmen oder überschaubare Datenlandschaften sind zentralere Modelle daher häufig weiterhin die pragmatischere Wahl. Gleichzeitig entwickeln sich moderne Datenarchitekturen kontinuierlich weiter, etwa durch Semantic- beziehungsweise Metrics-Layer, Data Contracts, Data-Platform-Engineering sowie AI- und LLM-native Ansätze wie Agentic Data Mesh, wodurch bestehende Konzepte zunehmend ergänzt und stärker miteinander integriert werden."

Sotirios Patsos

Consultant Data Solutions

Klingt spannend? In einem persönlichen Beratungsgespräch analysieren wir Ihre Datenarchitektur und entwicklen passende Lösungen.

Kontaktieren Sie uns!

Wir bieten maßgeschneiderte Beratung für Ihre strategischen Ziele und regulatorischen Anforderungen.

Expertengespräch vereinbaren