Katalog
concept#Daten#Architektur#Governance#Plattform

Data Mesh

Organisatorisches und architektonisches Paradigma zur dezentralen Verantwortlichkeit für Daten als Produkt durch domänenorientierte Teams.

Data Mesh ist ein organisatorisches und architektonisches Paradigma zur dezentralen Bereitstellung und Verantwortung von Daten als Produkt durch domänenorientierte Teams.
Aufstrebend
Hoch

Klassifikation

  • Hoch
  • Organisatorisch
  • Organisation
  • Reif

Technischer Kontext

Datenkataloge und Metadatensysteme (z. B. Amundsen, DataHub)Pipeline- und Orchestrierungstools (z. B. Airflow, dbt)Datenplattformen und Lager (z. B. Snowflake, BigQuery)

Prinzipien & Ziele

Daten als Produkt: Domänen besitzen und betreiben ihre Datenprodukte.Domänenorientierung: Verantwortlichkeit und lokale Expertise liegen bei Produktteams.Self-Serve-Plattform: Bereitstellung von Tools und Automatisierung zur Unterstützung der Domänen.
Umsetzung
Unternehmen, Domäne

Use Cases & Szenarien

Kompromisse

  • Fragmentierung der Datenlandschaft ohne klare Standards.
  • Ungleichmäßige Reife der Domänen führt zu Qualitätsunterschieden.
  • Fehlende Plattform-Features verursachen operativen Mehraufwand in den Domänen.
  • Start klein mit klaren Erfolgskriterien und iterativem Aufbau
  • Automatisiere wiederkehrende Aufgaben in der Plattform
  • Definiere maschinenlesbare Verträge und dokumentiere im Katalog

I/O & Ressourcen

  • Domänenwissen und fachliche Ansprechpartner
  • Rohdatenquellen und bestehende Datenpipelines
  • Plattform-Tooling (Catalog, CI/CD, Monitoring)
  • Versionierte, dokumentierte Datenprodukte mit SLAs
  • Metadaten und Verträge zur automatischen Integration
  • Messbare Verbesserungen in Durchlaufzeit und Datenqualität

Beschreibung

Data Mesh ist ein organisatorisches und architektonisches Paradigma zur dezentralen Bereitstellung und Verantwortung von Daten als Produkt durch domänenorientierte Teams. Es betont Domänenverantwortung, interoperable Datenprodukte, Self-Serve-Plattformen und föderierte Governance. Die Einführung erfordert organisatorische Veränderungen, klare Schnittstellen und Investitionen in Plattformen und Automatisierung.

✔

  • Skalierbare Teamorganisation mit klarer Datenverantwortung.
  • Schnellere, domänennahe Datenlieferungen und bessere Produktqualität.
  • Reduzierte zentrale Engpässe und bessere Kontextkenntnis bei Datenprodukten.

✖

  • Erfordert hohe organisatorische Reife und veränderte Verantwortungsmodelle.
  • Investitionen in Plattform- und Automatisierungsfunktionen sind notwendig.
  • Interoperabilität und Konsistenz über Domänen sind anspruchsvoll sicherzustellen.

  • Zeit bis zur Bereitstellung eines Datenprodukts

    Messung der durchschnittlichen Dauer von Anforderung bis zur Produktion eines Datenprodukts.

  • Anzahl produktiver Datenprodukte pro Domäne

    Zählt die aktiven, dokumentierten und SLA-getesteten Datenprodukte einer Domäne.

  • Datenqualitäts- und SLA-Erfüllungsrate

    Prozentsatz der Datenprodukte, die definierte Qualitätsmetriken und SLAs einhalten.

Zalando — domänenorientierte Datenteams

Zalando berichtet über domänennahe Teams und Plattformansätze zur Verteilung von Datenverantwortung.

ThoughtWorks Pilotprojekte

ThoughtWorks hat das Konzept popularisiert und Anleitungen für Piloten und Prinzipien veröffentlicht.

Community-Implementierungen und Open-Source-Beispiele

Mehrere Open-Source-Projekte und Community-Sammlungen zeigen Patterns, Tools und Best Practices.

1

Pilotdomäne auswählen und ein Kern-Datenprodukt definieren

2

Self-Serve-Plattform-Bausteine bereitstellen (CI/CD, Catalog, Observability)

3

Vertrags- und Qualitätsmetriken einführen (Schemas, SLAs, Tests)

4

Föderierte Governance-Strukturen implementieren und skalieren

⚠️ Technische Schulden & Engpässe

  • Inkonsistente Schemas in frühen Datenprodukten
  • Temporäre Integrationen ohne Automatisierung
  • Fehlende Observability führt zu manuellen Fehlersuchen
Zentrale DatenplattformMetadaten- und KatalogpflegeDomänenübergreifende Schnittstellen
  • Einführung ohne Plattformunterstützung führt zu Wildwuchs
  • Delegation von Verantwortung ohne notwendige Fähigkeiten in Domänen
  • Alle Governance-Aufgaben zentralisieren und trotzdem Dezentralität postulieren
  • Überschätzung der Fähigkeit von Domänen, sofort produktreife Daten bereitzustellen
  • Unklare Schnittstellen zwischen Plattform und Domänen
  • Vernachlässigung der Metadaten- und Katalogpflege
Domänenkenntnis und Data-Product-MindsetPlattform-Engineering und AutomatisierungserfahrungDatenmodellierung, APIs und Verträge (Schemas)
Skalierbarkeit von Organisation und DatenlieferungInteroperabilität und maschinenlesbare VerträgeAutomatisierung, Observability und SLA-Überwachung
  • • Organisatorische Zustimmung für Rollen- und Verantwortungsänderungen erforderlich
  • • Budget und Ressourcen für Plattformaufbau und Betrieb müssen bereitgestellt werden
  • • Vorhandene Legacy-Systeme können Integration und Modernisierung erschweren