Data-Architektur-Guide

Data Mesh Guide

Dein zentrales Datenteam ist ein Flaschenhals. Jede Domäne will Daten, aber Requests stapeln sich monatelang. Data Mesh dreht das um: Domänen besitzen ihre Daten als Produkte, die Plattform ermöglicht Self-Service.

25 Minuten LesezeitFür Data- & Plattform-LeadsUmsetzungs-Patterns enthalten

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.

Was sich ändert: Data Engineers arbeiten in Domänenteams. Domänen verantworten Qualität und Verfügbarkeit. Das zentrale Team wird zum Plattformteam.

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.

Was sich ändert: Daten sind auffindbar, haben SLOs, Schemas, Docs. Domänen fragen „wer nutzt das?“ statt „wir kippen es irgendwohin“.

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.

Was sich ändert: Zentrales Team wird Plattformteam. Baut Tools, Templates, Automation. Senkt kognitive Last.

4. Föderierte rechnerische Governance

Globale Policies (Security, Compliance, Interop) werden zentral definiert, aber lokal automatisiert durchgesetzt. Governance ist Code, nicht Meeting.

Was sich ändert: Policies im Plattform-Code. Automatisierte Compliance-Checks. Autonomie der Domänen innerhalb von Guardrails.
PrinzipVerantwortlichSchlüsseleffekt
Domänen-OwnershipDomänenteamsKontext-Know-how, schnelle Iteration
Daten als ProduktData-Product-OwnerQualität, Auffindbarkeit, Vertrauen
Self-Service-PlattformPlattformteamDomänenautonomie, weniger Reibung
Föderierte GovernanceGovernance + PlattformCompliance, 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.

KomponentePlattform liefertDomäne macht
StorageS3-Buckets, Delta-Tabellen, PoliciesSchreibt Daten an vorgegebene Pfade
ComputeSpark-Cluster, dbt-UmgebungenFührt Transformationen aus
PipelinesAirflow/Dagster-InfrastrukturDefiniert DAGs, Schedules
QualitätTest-Framework, DashboardsSchreibt Tests, setzt Schwellen
KatalogDataHub/Atlan-InstanzRegistriert 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.