1. Was ist Data Mesh?
Data Mesh ist ein soziotechnischer Ansatz, der Datenverantwortung an Domänenteams dezentralisiert. 2019 von Zhamak Dehghani (ThoughtWorks) formuliert, adressiert es die Skalierungsprobleme zentraler Datenplattformen.
Das Problem, das Mesh löst
Zentrale Datenteams werden zum Engpass. Ohne Domänenkontext bauen sie am Bedarf vorbei. Domänen warten Monate. Der monolithische Data Lake wird zum Data Swamp. Kommt dir bekannt vor?
Zentralisiert vs. Data Mesh
❌ Zentral (klassisch)
- • Ein Datenteam besitzt alles
- • Domänen werfen Daten „über die Mauer“
- • Zentrales Team ohne Domänenwissen
- • Monolithischer Data Lake
- • Lange Warteschlangen für Anforderungen
- • Datenteam = Bottleneck
✓ Data Mesh
- • Domänen besitzen ihre Data Products
- • Daten werden als Produkt mit SLAs geführt
- • Domänenexperten bauen Domänendaten
- • Föderierte, interoperable Data Products
- • Self-Service-Plattform schafft Autonomie
- • Skaliert mit der Organisation
Data-Mesh-Topologie
Domäne A
Orders
Data Product
Domäne B
Customers
Data Product
Domäne C
Inventory
Data Product
Self-Service Data Platform
Infrastructure • Tooling • Governance as Code
Föderierte rechnerische Governance
Globale Policies • Interop-Standards
Domänen besitzen Data Products, Plattform befähigt, Governance stellt Interoperabilität sicher
Kernpunkt
Data Mesh ist nicht nur Technologie – es ist Org-Change. Du verteilst Ownership, Verantwortung und Skills. Wer es nur als Technikprojekt behandelt, scheitert.
2. Die vier Prinzipien von Data Mesh
Vier Säulen tragen Data Mesh. Fehlt eine, kippt das System. Sie wirken zusammen.
1. Domänenorientiertes Ownership
Teams, die Daten erzeugen und verstehen, besitzen sie. Marketing besitzt Marketing-Daten. Sales besitzt Sales-Daten. Domänenexperten werden Data-Product-Owner.
2. Daten als Produkt
Behandle Daten wie ein Produkt mit Konsumenten. Es hat SLAs, Doku, Versionierung und einen Owner. Qualität liegt beim Domänen-Team, nicht beim zentralen Fix-it-Later-Team.
3. Self-Service Data Platform
Ein Plattformteam baut Infrastruktur, die Domänen autonom nutzen. Domänen sollen kein Kubernetes oder Spark verstehen müssen – sie bauen Data Products.
4. Föderierte rechnerische Governance
Globale Policies (Security, Compliance, Interop) werden zentral definiert, aber lokal automatisiert durchgesetzt. Governance ist Code, nicht Meeting.
| Prinzip | Verantwortlich | Schlüsseleffekt |
|---|---|---|
| Domänen-Ownership | Domänenteams | Kontext-Know-how, schnelle Iteration |
| Daten als Produkt | Data-Product-Owner | Qualität, Auffindbarkeit, Vertrauen |
| Self-Service-Plattform | Plattformteam | Domänenautonomie, weniger Reibung |
| Föderierte Governance | Governance + Plattform | Compliance, Interoperabilität |
3. Data Products im Detail
Ein Data Product ist nicht nur eine Tabelle. Es ist eine autonome Einheit mit Daten, Code, Infrastruktur und Metadaten – alles, was Konsumenten brauchen.
Acht Eigenschaften eines Data Products
Auffindbar
Im Datenkatalog gelistet. Konsumenten finden es ohne Nachfragen.
Adressierbar
Stabile, eindeutige Adresse (URI). Programmatisch erreichbar.
Vertrauenswürdig
Qualitätsmetriken, SLOs, Data Contracts. Erwartung ist klar.
Selbsterklärend
Schema, Lineage, Dokumentation eingebaut. Kein Stammeswissen nötig.
Interoperabel
Folgt globalen Standards für Formate, IDs, Semantik.
Sicher
Zugriffskontrolle, Verschlüsselung, Audit-Logs. Default compliant.
Nativ zugreifbar
Mehrere Zugriffswege: SQL, API, Files. Konsumenten dort abholen, wo sie sind.
Eigenständiger Wert
Liefert Business-Value allein. Nicht nur eine Staging-Tabelle.
Anatomie eines Data Products
Daten
- • Quelldaten
- • Transformierte Daten
- • Historische Snapshots
Code
- • Transformationslogik
- • Qualitätstests
- • Pipeline-Definitionen
Metadaten
- • Schema-Definitionen
- • Data Contracts
- • Lineage-Information
Beispiel: Data-Product-Manifest (YAML)
# orders-data-product/manifest.yaml name: orders domain: commerce owner: [email protected] version: 2.1.0 description: | Order transactions from all sales channels. Includes order items, totals, and fulfillment status. slo: freshness: 1h # Data no older than 1 hour availability: 99.9% # Uptime SLA quality_score: 95% # % of quality checks passing schema: type: delta location: s3://data-products/commerce/orders/ access: - sql: "SELECT * FROM commerce.orders" - api: "https://data.company.com/commerce/orders" lineage: sources: - system: shopify table: orders - system: pos table: transactions data_contract: primary_key: order_id not_null: [order_id, customer_id, order_date, total] quality_checks: - unique(order_id) - not_null(customer_id) - total >= 0 - order_date <= current_date()
Pro Tipp
Starte mit verbraucherorientierten Data Products
Publiziere nicht nur Roh-Tabellen. Denke vom Konsumenten her. Ein „Orders“-Produkt kann Bestellungen, Zahlungen und Fulfillment in einer denormalisierten Sicht kombinieren.
4. Self-Service Data Platform
Die Plattform macht Domänen-Ownership überhaupt praktikabel. Ohne sie erfindet jede Domäne Infrastruktur neu – Chaos. Die Plattform liefert meinungsstarke Abstraktionen, die kognitive Last senken.
Plattform-Fähigkeiten
Dateninfrastruktur
Storage (S3, Delta Lake), Compute (Spark, dbt), Orchestration (Airflow, Dagster). Domänen nutzen, Plattform betreibt.
Data-Product-Templates
Cookiecutter-Templates für neue Produkte. Vorgefertigtes CI/CD, Qualitätschecks, Katalog-Registration. In Minuten statt Wochen startklar.
Katalog & Discovery
Zentraler Katalog (DataHub, Atlan, Collibra) für alle Data Products. Suchen, browsen, Lineage verstehen.
Access & Security
Zentrale Identität, RBAC, Verschlüsselung. Domänen definieren Zugriffe, Plattform setzt durch.
Observability & Monitoring
Pipeline-Monitoring, Data-Quality-Dashboards, SLO-Tracking. Domänen sehen Gesundheit, Plattform aggregiert.
| Komponente | Plattform liefert | Domäne macht |
|---|---|---|
| Storage | S3-Buckets, Delta-Tabellen, Policies | Schreibt Daten an vorgegebene Pfade |
| Compute | Spark-Cluster, dbt-Umgebungen | Führt Transformationen aus |
| Pipelines | Airflow/Dagster-Infrastruktur | Definiert DAGs, Schedules |
| Qualität | Test-Framework, Dashboards | Schreibt Tests, setzt Schwellen |
| Katalog | DataHub/Atlan-Instanz | Registriert Produkte, fügt Doku hinzu |
Plattform ≠ zentrales Datenteam 2.0
Das Plattformteam baut Infrastruktur und Tools – keine Data Products. Wenn es weiterhin Domänendaten baut, habt ihr nicht dezentralisiert. Es befähigt, es liefert nicht.
5. Föderierte rechnerische Governance
Dezentralisierung ohne Governance endet im Chaos. Föderierte Governance bietet globale Standards mit lokaler Autonomie. Policies werden zentral definiert, aber automatisch im Code durchgesetzt.
Was global geregelt wird
Interoperabilitäts-Standards
- • Namenskonventionen (snake_case, Präfixe)
- • Globale IDs (Format customer_id)
- • Datums-/Zeitformate (UTC, ISO 8601)
- • Regeln für Schema-Evolution
Security & Compliance
- • Umgang mit PII (Maskierung, Verschlüsselung)
- • Zugriffsmuster
- • Aufbewahrungsrichtlinien
- • Anforderungen an Audit-Logs
Qualitätsstandards
- • Minimale SLO-Anforderungen
- • Verpflichtende Qualitätschecks
- • Dokumentationsstandards
- • Format der Data Contracts
Was Domänen entscheiden
- • Design des Data Products
- • Business-Logik
- • Update-Frequenz (über SLO)
- • Zugriff für bestimmte Konsumenten
„Rechnerisch“ = Governance as Code
Beispiel: Policy as Code (OPA/Rego)
# governance/policies/data_product.rego
package dataproduct
# All data products must have an owner
deny[msg] {
not input.manifest.owner
msg := "Data product must have an owner defined"
}
# PII columns must be tagged
deny[msg] {
column := input.schema.columns[_]
column.pii == true
not column.tags["pii"]
msg := sprintf("PII column %v must be tagged", [column.name])
}
# SLO freshness must be defined
deny[msg] {
not input.manifest.slo.freshness
msg := "Data product must define freshness SLO"
}
# Minimum documentation required
deny[msg] {
count(input.manifest.description) < 50
msg := "Data product description must be at least 50 characters"
}Pro Tipp
Governance in CI/CD, nicht im Meeting
Jeder PR eines Data Products läuft durch Policy-Checks. Nicht konform? Build bricht. Keine Approval-Komitees nötig. Plattform erzwingt Standards automatisch; Menschen prüfen Ausnahmen.
6. Umsetzungsfahrplan
Data Mesh ist ein mehrjähriger Weg. Nicht alles auf einmal. Klein starten, Wert beweisen, ausrollen.
Phase 1: Fundament (Monat 1–3)
Management-Commitment holen. 1–2 Pilot-Domänen wählen. Minimale Governance definieren.
- • Motivierte Pilotteams auswählen
- • Ist-Zustand und Pain Points dokumentieren
- • Definition „Data Product“ für eure Org festlegen
- • Plattformteam aufstellen (oder einstellen)
Phase 2: Erste Data Products (Monat 3–6)
Pilot-Domänen bauen erste Data Products. Plattform liefert minimale Infrastruktur.
- • 2–3 Data Products pro Pilotdomäne bauen
- • Einfachen Katalog bereitstellen (zur Not Spreadsheet)
- • Data-Product-Template etablieren
- • Learnings dokumentieren und iterieren
Phase 3: Plattform-Reife (Monat 6–12)
Plattformteam productisiert Learnings. Self-Service entsteht. Mehr Domänen onboarden.
- • Richtiges Data Catalog einführen
- • CI/CD für Data Products aufbauen
- • Governance-Checks automatisieren
- • 3–5 weitere Domänen onboarden
Phase 4: Skalierung (Jahr 2+)
Org-weiter Rollout. Plattform ist reif. Fokus auf Optimierung und Advanced Capabilities.
- • Alle Domänen liefern Data Products
- • Domänenübergreifende Produkte entstehen
- • Marketplace für Data Products
- • Kontinuierliche Plattformverbesserung
Aus der Praxis
Größter Fehler: mit der Plattform anfangen. Baue nicht zuerst eine schöne Self-Service-Plattform und suche dann Nutzer. Starte mit Domänen, die manuell Data Products bauen. Deren Schmerz definiert Plattform-Anforderungen.
7. Anti-Patterns vermeiden
Data Mesh als reines Tech-Projekt
Tools kaufen ohne Organisationsänderung. Mesh ist soziotechnisch – Org-Change zuerst, Tech stützt.
Zentrales Team baut weiter Domänendaten
Eingebettete Engineers „Domänenteam“ nennen, aber Reporting bleibt zentral. Echte Ownership = Domäne ist accountable.
Keine Plattform, nur Dezentralisierung
Domänen „ihr besitzt jetzt eure Daten“ sagen ohne Tools. Ergebnis: Duplikate, Chaos, Burnout.
Governance per Komitee
Monatliche Meetings statt automatisierter Checks. Policies auf Papier, nicht im Code.
Jede Tabelle = Data Product
Staging-Tabellen als Produkt labeln. Ein Data Product muss Business-Value liefern, nicht nur Daten exponieren.
Change Management ignorieren
Erwarten, dass Domänen Ownership übernehmen ohne Training, Incentives, Karrierepfade.
Reality Check
Passt Data Mesh zu euch?
Data Mesh ist evtl. nicht sinnvoll bei: weniger als 50 Leuten, nur einer Domäne/einem Produkt, gut laufendem zentralen Team oder fehlender Führung für Org-Change. Es adressiert Skalierungsprobleme – ohne Skalierungsdruck reicht oft ein starkes zentrales Team.
8. Häufige Fragen
Was ist Data Mesh?
Data Mesh ist eine dezentrale Datenarchitektur, in der Daten als Produkt verstanden werden und den Domänenteams gehören statt einem zentralen Team. Vier Prinzipien: Domänen-Ownership, Daten als Produkt, Self-Service-Plattform, föderierte rechnerische Governance. Von Zhamak Dehghani entwickelt.
Unterschied Data Mesh vs. Data Fabric?
Data Mesh: organisatorischer/architektonischer Ansatz mit Dezentralisierung und Domänenverantwortung. Data Fabric: technischer Ansatz mit Metadaten/AI für einheitliche Datenschicht. Mesh verändert Arbeitsweise; Fabric = Tools/Automation. Ergänzen sich.
Was ist ein Data Product im Mesh?
Ein Data Product ist eine autonome, auffindbare, adressierbare, vertrauenswürdige, selbsterklärende, interoperable und sichere Einheit. Enthält Daten, Metadaten, Transformationscode, Infrastruktur, Dokumentation. Domänenteams betreiben sie wie Microservices.
Wann sollte man Data Mesh meiden?
Nicht sinnvoll bei <50 Leuten, einer Domäne, funktionierendem zentralen Team, geringer Engineering-Reife für Self-Service oder fehlendem Leadership-Support. Data Mesh ist Org-Transformation, nicht nur Technik.
Visualisiere deine Data-Mesh-Architektur
Kartiere Domänen, Data Products und Plattform-Komponenten. Erstelle klare Diagramme, die deine Data-Mesh-Vision für Stakeholder und Teams greifbar machen.
Verwandte Guides
Medallion Architecture
Bronze-, Silver-, Gold-Schichten in deinen Data Products
Dimensional Modeling
Data Products entwerfen, die Analysts lieben
Data Contracts
Schnittstellen und Garantien für Data Products definieren
Data-Quality Best Practices
Qualität in deine Data Products einbauen
Data Lineage Best Practices
Datenflüsse über Domänen und Produkte verfolgen