+50 XP

Data Mesh: Prinzipien, Erfolgsbedingungen & Kritik

Das Data Mesh ist das am meisten diskutierte Architekturparadigma der letzten fünf Jahre. Es hat leidenschaftliche Befürworter und ebenso leidenschaftliche Kritiker. Ein klares Verständnis davon, was es tatsächlich ist, welches Problem es löst und wann es angemessen ist, gehört für jede Data-Führungskraft dazu.

Das Problem, das Data Mesh löst

Data Mesh entstand aus einem spezifischen Fehlermuster in großen, datenintensiven Organisationen.

Das Muster: Ein zentrales Data-Team wird zum Bottleneck. Jede Domain (Produkt, Marketing, Finance, Operations) braucht Daten. Alle fragen sie beim zentralen Data-Platform-Team an. Das zentrale Team ist überlastet. Datenlieferungen dauern Wochen. Die Business-Stakeholder sind frustriert. Die Datenqualität ist inkonsistent, weil das zentrale Team die domänenspezifischen Feinheiten nicht kennt.

Zhamak Dehghani (damals bei Thoughtworks) diagnostizierte das als organisatorisches und architektonisches Problem, nicht als technisches. Ihre Lösung: Data Ownership an die Domains verteilen, die die Daten am besten verstehen.

Data Mesh Explained

Watch on YouTube

Wissenscheck

1. Welcher Natur ist laut Lektion das Problem, für das Data Mesh entwickelt wurde?

2. Wie verändert sich die Rolle des zentralen Data-Teams unter dem Prinzip der Self-Serve Data Platform?

3. Was beschreibt am besten, was „Data as a Product“ in einem Data Mesh bedeutet?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Aussagen, die die vier Prinzipien des Data Mesh korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Symptome des Fehlermusters, das zur Entstehung von Data Mesh geführt hat.

Wählen Sie alle richtigen Antworten aus.

Die vier Prinzipien des Data Mesh

1. Domänenorientierte, dezentrale Data Ownership

Daten gehören der Domain, die sie produziert, und werden von ihr bereitgestellt. Die Checkout-Domain besitzt die Checkout-Daten. Die Customer-Domain besitzt die Kundendaten. Jedes Domain-Team ist verantwortlich für Datenqualität, Zuverlässigkeit und Zugriff.

2. Data as a Product

Jede Domain produziert nicht einfach Daten, sie produziert ein Data Product. Ein Data Product hat einen Owner, ein SLA, Dokumentation, Schema, Discoverability. Es wird mit derselben Product-Management-Disziplin behandelt wie ein Softwareprodukt.

3. Self-Serve Data Platform

Das zentrale Data-Team wandelt sich vom Datenproduzenten zum Plattformanbieter. Es baut die Infrastruktur, mit der Domain-Teams Data Products produzieren und konsumieren, also Tooling, Standards und Infrastruktur, nicht die Daten selbst.

4. Federated Computational Governance

Globale Policies (GDPR-Compliance, Sicherheitsstandards, Schwellenwerte für Datenqualität) werden zentral definiert und von der Plattform durchgesetzt. Domain-Teams arbeiten innerhalb dieser Guardrails, haben aber Autonomie darin, wie sie sie umsetzen.

Wann Data Mesh Sinn ergibt

Data Mesh löst ein Skalierungs- und Autonomieproblem. Die Umsetzung erfordert erhebliche organisatorische Reife. Stellen Sie sich diese Fragen:

  • Haben Sie mehrere Produktdomänen mit klar getrennten Datendomänen? (< 3 Domains → Mesh ist überdimensioniert)
  • Ist das zentrale Data-Team ein Bottleneck? (Wenn nicht, existiert das Problem, das das Mesh löst, nicht)
  • Haben Ihre Domain-Teams ausreichende Data-Engineering-Fähigkeiten? (Mesh verlangt, dass jede Domain ihr Data Engineering selbst verantwortet, das ist eine erhebliche Anforderung an die Kompetenzen)
  • Steht die Führung hinter einer Neuordnung der Data Ownership? (Mesh ist eine organisatorische Veränderung, nicht nur eine technische)

Airbnb, Netflix und Intuit haben mesh-artige Architekturen umgesetzt. Sie hatten allerdings Hunderte Data Engineers und komplexe Multi-Domain-Organisationen. Für ein Unternehmen mit 500 Mitarbeitenden und einer Produktdomäne ist eine zentralisierte Architektur mit guten Prozessen wahrscheinlich besser.

Die Kritik

Data Mesh wird nicht überall geliebt. Häufige Kritikpunkte:

  • Duplizierungsrisiko: Ohne starke Governance erzeugen Domains überlappende, inkonsistente Versionen gemeinsamer Entitäten (Kunde, Produkt).
  • Kompetenzanforderung: Die meisten Domain-Teams haben nicht die Data-Engineering-Fähigkeiten, um hochwertige Data Products zu bauen. Sie verschieben das Problem, statt es zu lösen.
  • Komplexität: Federated Governance ist schwierig. Cross-Domain-Joins werden zu Problemen verteilter Systeme.

Die ehrliche Antwort: Data Mesh ist eine Lösung für ein spezifisches Problem bei entsprechender Größe. Zu früh oder ohne organisatorische Reife eingesetzt, schafft es mehr Probleme, als es löst.

Quizfragen

1. Welches organisatorische Problem will Data Mesh vor allem lösen?

A) Die Kosten der Datenspeicherung

B) Das zentrale Data-Team, das zum Bottleneck wird und die Datenlieferung an die Domains verlangsamt

C) Die Datensicherheit in der Cloud

D) Die Verarbeitungsgeschwindigkeit von SQL-Abfragen

Antwort: B

2. Welche neue Rolle hat das zentrale Data-Team im Data Mesh?

A) Eigentümer aller Daten der Organisation

B) Anbieter einer Self-Serve-Plattform, die die Domain-Teams nutzen, um ihre Data Products zu produzieren

C) Audit- und Compliance-Team

D) BI-Reporting-Team

Antwort: B

3. In welchem Kontext passt Data Mesh am besten?

A) Ein Startup mit 50 Mitarbeitenden und einem einzigen Produkt

B) Eine reife Multi-Domain-Organisation mit vielen Data-Teams und einem nachgewiesenen zentralen Bottleneck

C) Jede Organisation, die ihre Data Governance verbessern möchte

D) Eine Organisation mit wenig Data-Engineering-Kompetenz

Antwort: B

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Data Mesh nur in ausgereiften Multi-Domain-Organisationen mit nachgewiesenem Bottleneck einführen
Vollständiges Action Playbook ansehen

Verwandte Artikel

Aktuelle Blogartikel, die auf dieser Lektion aufbauen.