Das Organisationsmodell ist der Teil von Data Mesh, der am häufigsten unterschätzt wird. Die Prinzipien klingen klar, die Tools sind verfügbar — aber wer welche Rolle spielt, welche Interfaces zwischen Teams existieren, wie Entscheidungen fallen: Das muss explizit gestaltet werden, sonst entsteht Chaos.
Die drei Team-Typen
1. Domain Data Teams. Sitzen in den Fachdomänen (Marketing, Sales, Logistik, Produkt). Verantworten die Data Products ihrer Domäne.
Zusammensetzung (pro Domäne):
- Data Product Owner (1, fokussiert auf Strategie)
- Data Engineer(s) (1–3, fokussiert auf Pipelines)
- Data Analyst (optional, für komplexe analytische Produkte)
Im Mittelstand oft 2–3 Personen gesamt. In Konzernen 3–8.
2. Central Platform Team. Baut und betreibt die Self-Serve-Infrastruktur. Ersetzt nicht die klassische zentrale Data-Team-Funktion, sondern transformiert sich in eine Platform-Builder-Funktion.
Zusammensetzung:
- Platform Product Owner
- Platform Engineers (5–15)
- Data Governance Lead
- Reliability Engineers (für Monitoring, SLAs)
Das Platform-Team ist technisch tiefer als ein klassisches Data-Team, aber kleiner in direkt-anwenderfacing Arbeit.
3. Enabling Teams (optional). Temporäre Teams, die Domain-Teams bei Einführung coachen. Besonders in den ersten 2–3 Jahren der Mesh-Einführung wichtig.
Zusammensetzung:
- Data Coaches (Ex-Platform-Engineers)
- Data Governance Specialists
Enabling Teams lösen sich auf, wenn Domain-Teams eigenständig arbeiten können.
Die Governance-Ebene
Federated Governance braucht eine definierte Entscheidungs-Struktur.
Data Governance Council (zentral):
- Vorsitz: Chief Data Officer (oder vergleichbar)
- Mitglieder: Vertreter der großen Domänen, Platform Product Owner, Data Governance Lead, Rechtsabteilung, ggf. Security
- Tagt: monatlich
- Entscheidet: organisationsweite Standards, Policies, Prioritäten
Domain Stewards (dezentral):
- Pro Domäne ein Data Steward, der Governance-Regeln lokal umsetzt
- Bindet Data Product Owners an Standards
- Schnittstelle zum zentralen Council
Automation Layer:
- Governance-Regeln werden über Tools enforced (Schema-Validation, Access-Control, Quality-Checks)
- Manuelle Governance skaliert nicht über 10+ Domänen
Die C-Level-Rolle
Mesh-Transformation braucht klaren C-Level-Sponsor. Meist der Chief Data Officer (CDO), manchmal ein Chief Information Officer (CIO) oder ein dezidierter Head of Data.
Aufgaben der C-Level-Rolle:
- Vision und Strategie vorgeben
- Budget sichern (3–5 Jahre Commitment)
- Konflikt-Resolution zwischen Fachbereichen
- Vorstands-Reporting zum Transformations-Fortschritt
- Kultur-Wandel vorantreiben
Ohne C-Level-Sponsor scheitert jede Mesh-Initiative an Politik. Das Data-Team kann die Transformation nicht alleine durchdrücken.
Schnittstellen zwischen Teams
Domain Team ↔ Platform Team:
- Platform liefert Tools, Domain nutzt sie
- Regelmäßige Feedback-Meetings (monatlich)
- Feature-Requests via Issue-Tracker
- Shared Backlog für Platform-Entwicklung
Domain Team ↔ Domain Team (Konsument):
- Data Contract als formale Schnittstelle
- Direkte Support-Kanäle pro Data Product
- SLA-Monitoring und Issue-Eskalation
Domain Team ↔ Governance Council:
- Vertretung im Council durch Data Steward
- Policy-Input und -Feedback
- Compliance-Check-Ins
Platform Team ↔ Governance Council:
- Governance-Automation umsetzen
- Policy-Technisches-Design
- Monitoring-Gap-Reports
Transformations-Pfad pro Domäne
Eine Domäne durchläuft typisch diese Phasen:
Phase 1 — Discovery (Monat 1–3).
- Was sind unsere Daten-Assets?
- Welche Konsumenten, welche Use-Cases?
- Daten-Readiness-Bewertung
Phase 2 — Team-Aufbau (Monat 3–6).
- Data Product Owner einstellen/ernennen
- Data Engineer(s) zuweisen oder aufbauen
- Coaching durch Enabling-Team
Phase 3 — Erstes Data Product (Monat 6–12).
- Ein Data Product end-to-end designen und bauen
- Auf Platform deployen
- Erste Konsumenten anbinden
- Data Contract definieren
Phase 4 — Scaling (Monat 12–24).
- Weitere Data Products pro Quartal
- Domain wird weitestgehend eigenständig
- Enabling-Team zieht sich zurück
Phase 5 — Stability (ab Monat 24).
- Domain als Mesh-integriertes Element
- Kontinuierliche Weiterentwicklung
- Austausch mit anderen Domänen
Das sind ideale Pfade. Real passieren Delays, Re-Starts, Priorisierungs-Wechsel.
Kompetenz-Aufbau in Domänen
Das häufigste Hindernis ist fehlende Data-Engineering-Kompetenz in Fachdomänen.
Drei Strategien:
Strategie 1 — Umsiedlung. Ehemalige zentrale Data-Engineers werden in Domänen umgesetzt. Vorteil: vorhandene Kompetenz. Nachteil: manchmal Widerstand gegen Umstrukturierung.
Strategie 2 — Externer Neuaufbau. Neue Data-Engineers werden pro Domäne eingestellt. Vorteil: frisches Team. Nachteil: Recruiting dauert, Onboarding-Zeit.
Strategie 3 — Entwicklung aus Fachbereich. Interessierte Fachbereichs-Mitarbeiter werden zu Data Engineers ausgebildet. Vorteil: Domain-Know-how erhalten. Nachteil: 12–18 Monate Aufbau, nicht alle Kandidaten haben Eignung.
Die meisten Mesh-Einführungen mischen alle drei Strategien.
Häufige organisatorische Fehler
Fehler 1 — Platform-Team bleibt Zentralist. Das zentrale Data-Team baut weiter Pipelines für Domänen, statt Self-Serve-Tools. Mesh nur auf Papier.
Fehler 2 — Keine C-Level-Sponsor. Transformation ohne Top-Down-Commitment scheitert an Abteilungsgrenzen.
Fehler 3 — Zu schnell zu viele Domänen. Alle gleichzeitig umzustellen ist Big-Bang und scheitert. Pilot mit 1–2 Domänen, dann skalieren.
Fehler 4 — Data Product Owners ohne Authority. Product Owner, die keine Budget- oder Priorisierungs-Autonomie haben, sind nur Titel.
Fehler 5 — Enabling Team zu früh auflösen. Domain-Teams sind in den ersten 12–18 Monaten fragil. Enabling-Support zu früh zurückziehen führt zu Rückschritten.
Verbindungen: Einführung für die Prinzipien-Basis. Data Products als zentrales Artefakt. Data Citizens für die soziale Ebene.