Die Datenorganisation und ihre Rollen gestalten

Als Cynthia Stoddard bei einem großen Unternehmenssoftware-Anbieter eine CDO-äquivalente Rolle übernahm, erbte sie 340 Personen, verteilt über Analytics, Engineering und Governance, die an sechs verschiedene VPs berichteten, von denen keiner an sie berichtete. Ihr Strategiedeck sagte „data as a product“. Ihr Organigramm sagte „Daten als Service-Ticket“. In der Lücke zwischen diesen zwei Sätzen scheitern die meisten CDO-Amtszeiten leise.

Das Problem des Organisationsdesigns ist täuschend einfach zu beschreiben und brutal in der Umsetzung: Ihre Struktur ist die physische Verkörperung Ihrer Strategie, und wenn beide sich widersprechen, gewinnt immer die Struktur. Menschen tun, was ihre Berichtslinie, ihre Incentives und ihr Umfeld ihnen vorgeben, nicht was Ihr Strategie-PDF verlangt. In dieser Lektion geht es darum, diese Lücke bewusst zu schließen.

Struktur folgt der Strategie, wörtlich, nicht als Wunschbild

Die erste Disziplin besteht darin, keine KKDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ästchen zu zeichnen, solange Sie das *Operating Model* nicht benennen können, das Ihre Strategie verlangt. Es gibt drei Archetypen, und die meisten Organisationen sind eine bewusste Mischung statt einer Reinform.

Zentralisiert. Alle Datentalente berichten an den CDO. Sie bekommen Konsistenz, Hebel auf knappe Spezialisten und eine einzige Verantwortungsinstanz für Governance. Sie verlieren Domänenkontext und Geschwindigkeit; die Geschäftsbereiche ärgern sich über die Warteschlange. Das funktioniert, wenn die strategische Priorität *Kontrolle herstellen* lautet: regulatorische Nachbesserung, ein zerstörtes Vertrauensverhältnis oder eine erstmalige Enterprise-Datenplattform.

Dezentral (föderiert). Datenteams sitzen in den Geschäftsbereichen, mit gestrichelter Linie zu Ihnen. Sie bekommen Domänenkompetenz und Business Ownership. Sie verlieren Standards, duplizieren Tooling und stellen fest, dass „Umsatz“ auf elf verschiedene Weisen definiert ist. Das funktioniert, wenn die Einheiten tatsächlich unterschiedliche Geschäfte sind und die Priorität *Geschwindigkeit nahe am P&L* ist.

Hub-and-Spoke. Ein zentraler Hub verantwortet Plattform, Standards und knappe Fähigkeiten; eingebettete Spokes sitzen im Business und verantworten die Delivery. Hier landen die meisten reifen Datenorganisationen, nicht weil es in Mode ist, sondern weil es die Kernspannung löst: Hebel im Zentrum, Kontext an der Peripherie.

Die Ermessensfrage ist, *was in den Hub gehört und was in den Spoke*, und genau hier machen CDOs es falsch. Die richtige Sortierregel ist nicht „wichtige Dinge ins Zentrum“. Sie lautet:

Zentralisieren Sie, was von Skalierung, Konsistenz oder Knappheit profitiert. Föderieren Sie, was von Kontext und Geschwindigkeit profitiert.

Schicken Sie jede Funktion durch diesen Filter. Data Platform Engineering profitiert von Skalierung → Hub. Business AnalyticsBusiness AnalyticsTechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen → profitiert von Kontext → Spoke. Data-Governance-Policy profitiert von Konsistenz → Hub, aber die *Umsetzung* von Governance profitiert von Kontext → Spoke. Diese einzelne Unterscheidung, Policy zentral, Umsetzung lokal, ist die wichtigste Strukturentscheidung, die Sie treffen werden, und wir kommen darauf zurück.

Schauen Sie, wie Netflix und JPMorgan hier aus nachvollziehbaren Gründen auseinandergehen. Netflix gibt eingebetteten Analysten enorme Autonomie, weil der strategische Engpass die Geschwindigkeit von Experimenten ist. JPMorgan zentralisiert deutlich stärker, weil der Engpass die regulatorische Belastbarkeit ist und die Kosten eines Datenfehlers in Consent Orders gemessen werden. Keines von beidem ist „Best Practice“. Jede Struktur ist eine Wette darauf, wo die Reibung liegt, die am meisten zählt.

Die Trennung von Governance und Delivery

Der häufigste strukturelle Fehler, den ich sehe, ist, Governance und Delivery in einem Team unter einer Führungskraft zusammenzulegen. Es fühlt sich effizient an. Es ist Gift.

Delivery-Teams werden am Ausliefern gemessen: Pipelines laufen, Dashboards gelauncht, Modelle in Produktion. Governance wird an Kontrolle gemessen: Qualität, Lineage, Zugriff, Compliance. Wenn dieselbe Führungskraft beides verantwortet, **gewinnt Delivery *immer* den täglichen Trade-off, weil Delivery eine Deadline hat und Governance ein Prinzip**. Qualität erodiert leise, bis ein Incident zur Abrechnung zwingt.

Die Lösung ist, die beiden Berichtslinien zu trennen und sie gleichzeitig zu einem gemeinsamen Workflow zu zwingen. Governance setzt Policy und verantwortet die Definition von „gut gemacht“. Delivery verantwortet „schnell gemacht“. Sie treffen sich am Punkt der Produktion, dem Gate, durch das Datenprodukte ausgeliefert werden.

Hier ist das Operating Pattern, mit dem das funktioniert, ohne einen bürokratischen Krieg auszulösen:

• Governance definiert die Controls als Code, nicht als Word-Dokument. Data ContractsData ContractsFormale Vereinbarung zwischen dem Team, das Daten erzeugt, und denen, die sie nutzen: legt Struktur, Bedeutung, Qualität und Verantwortung bei Fehlern fest.Vollständige Definition ansehen →, Qualitätsschwellen, Zugriffsrichtlinien und Klassifizierungsregeln leben in der PipelinePipelineAlle aktiven Verkaufschancen über die Phasen des Vertriebsprozesses hinweg, zusammen mit ihrem gesamten potenziellen Wert und ihrer Abschlusswahrscheinlichkeit.Vollständige Definition ansehen →, nicht in einem Review-Meeting.
• Delivery-Teams können sich innerhalb dieser Guardrails frei und schnell bewegen und eskalieren nur Ausnahmen.
• Der CDO verantwortet die Schlichtung, wenn beide kollidieren, und das werden sie.

Ein Data Contract ist das konkrete Artefakt, in dem diese Trennung real wird. ErErDas Verhältnis von Interaktionen (Likes, Kommentare, Shares) zur Reichweite eines Inhalts. Zeigt, wie stark die Zielgruppe reagiert, gemessen an der Zahl der Personen, die den Inhalt gesehen haben.Vollständige Definition ansehen → ist das Interface zwischen einem Datenproduzenten und seinen Konsumenten, und er erlaubt, Governance automatisch statt über Meetings durchzusetzen:

dataset: customer_transactions
owner: payments-domain-team
sla:
  freshness: 15m
  availability: 99.9%
schema:
  - name: customer_id
    type: string
    classification: PII      # löst Zugriffs- + Masking-Policy aus
    nullable: false
  - name: amount_usd
    type: decimal
    quality_check: "amount_usd >= 0"
consumers: [risk-analytics, finance-reporting]
breaking_change_policy: 30d_notice

Beachten Sie, was dieses Artefakt organisatorisch bewirkt. Das Feld owner erzwingt Accountability in der Domäne, eine Person, keine Warteschlange. Das Feld classification erlaubt der zentralen Governance, PII-Handling durchzusetzen, ohne jede Pipeline zu inspizieren. Die breaking_change_policy verhindert, dass ein Delivery-Team stillschweigend nachgelagerte Konsumenten zerschießt. Der Contract kodiert Ihr Org-Design in den Workflow, und das ist der einzige Ort, an dem Org-Design den Kontakt mit der Realität übersteht.

Das ist der Mechanismus hinter Data MeshData MeshData Mesh ist ein dezentraler Ansatz für Datenarchitektur und Organisation, bei dem Domänenteams ihre Daten besitzen und als Produkte bereitstellen, geregelt durch gemeinsame Standards.Vollständige Definition ansehen →, aber Sie brauchen das Buzzword nicht. Sie brauchen das Prinzip: Domänen verantworten ihre Datenprodukte end to end, das Plattformteam gibt ihnen gepflasterte Wege, und Governance wird *computational* föderiert, durchgesetzt von der Plattform, nicht von einem Komitee.

Rollen: wer tatsächlich was verantwortet

Titel vermehren sich und bedeuten von Firma zu Firma nichts. Gestalten Sie Ihre Organisation um *Accountabilities*, und hängen Sie dann Titel daran. Hier sind die Rollen, die zählen, und die Grenzentscheidungen, die sie funktionsfähig machen.

Der Data Product Manager ist die Rolle, in die die meisten CDOs zu wenig investieren und deren Auslassen sie am meisten bereuen. Wenn data-as-a-productdata-as-a-productEin Datenbestand, der wie ein Produkt gemanagt wird: mit Owner, definierten Nutzern, garantierter Qualität und messbarem Geschäftswert.Vollständige Definition ansehen → von der Folie in die Realität wandert, muss jemand ein Datenasset so verantworten, wie ein PM Software verantwortet: Roadmap, Konsumenten, SLAs und Lifecycle. Ohne diese Rolle sind „Produkte“ nur Tabellen mit besserem Marketing. Der DPM sitzt im Spoke, nah an der Domäne, und ist das menschliche Gegenstück zum Data Contract oben.

Der Data Platform / Data Engineering Lead verantwortet den gepflasterten Weg, also Ingestion, Transformation, Storage und Self-Service-Tooling, auf dem die Spokes bauen. Diese Rolle gehört eindeutig in den Hub. Der Failure Mode ist, jede Domäne ihre eigene Plattform bauen zu lassen; Sie finanzieren am Ende fünf halbe Plattformen und haben keinen Hebel.

Der Analytics Engineer / Domain Analyst sitzt im Spoke und macht aus rohen Domänendaten entscheidungsreife Modelle. Das ist Ihre Kontextschicht. Wenn Sie sie zentralisieren, nehmen Sie dem Business die Geschwindigkeit.

Der Data Governance Lead verantwortet Policy, Standards, den Datenkatalog und die Definition von Qualität. Hub. Aber entscheidend: Er verantwortet *Policy und Tooling*, nicht die tägliche Durchsetzung in jeder Domäne. Seine Aufgabe ist, das Richtige zum Einfachen zu machen, eingebettet in die Plattform.

Data Stewards sind die föderierte Umsetzung von Governance. Hier ist die Entscheidung, über die CDOs stolpern: *Stewards sollten nicht an Sie berichten.* Sie sollten respektierte Domänenexperten sein, die Datenqualität und Definitionen innerhalb ihres Geschäftsbereichs verantworten, mit einer gestrichelten Linie zur zentralen Governance. Ein Steward, der an die zentrale Governance berichtet, ist ein Außenstehender, der die Domäne kontrolliert; ein Steward, der zur Domäne gehört, ist ein Insider, der sie verbessert. Gleiche Tätigkeit, entgegengesetztes Ergebnis.

Ordnen Sie diese Rollen explizit der Hub/Spoke-Trennung zu:

Die Berichtslinien in dieser Tabelle *sind* Ihre Trennung von Governance und Delivery, konkret gemacht. Wenn Sie die Spalte „Zuhause“ für eine Rolle nicht füllen können, haben Sie noch nicht verstanden, wozu diese Rolle da ist.

Eine weitere Ermessensfrage: Die Spannweite zwischen Ihrem Plattformteam und Ihren eingebetteten Teams bestimmt Ihre Skalierungsgrenze. Wenn jeder Spoke drei zentrale Engineers braucht, um irgendetwas auszuliefern, ist Ihre Plattform nicht self-serve und Sie stoßen bei einem Dutzend Domänen an die Wand. Der Test ist schonungslos: *Kann ein Domänenteam ein neues Datenprodukt ausliefern, ohne ein Ticket beim Hub einzureichen?* Wenn nicht, haben Sie eine Serviceorganisation im Kostüm einer Produktorganisation.

Sequenzierung, Berichtslinien und die Reorg, die Sie noch nicht machen sollten

Die meisten CDOs versuchen, im ersten Monat das perfekte Ziel-Organigramm zu zeichnen und es in einer Big-Bang-Reorg auszurollen. Das scheitert zweifach: Das Design ist falsch, weil Sie noch nicht verstehen, wo die echte Reibung sitzt, und das politische Kapital verbrennt, bevor Sie Wert gezeigt haben.

Sequenzieren Sie die Struktur entlang Ihrer strategischen Phase. In einer Phase, in der Kontrolle hergestellt wird, tendieren Sie zur Zentralisierung, bündeln knappe Talente, etablieren Standards, gewinnen die Vertrauensschlacht. Mit steigendem Vertrauen und wachsender Plattformreife *föderieren* Sie bewusst nach außen und schieben Produkt-Ownership und Stewardship in die Domänen. Das Organigramm sollte ein Film sein, kein Foto. Kündigen Sie diese Entwicklung offen an: „Wir zentralisieren jetzt, um die Plattform zu bauen, und wir geben Ihnen die Ownership innerhalb von achtzehn Monaten.“ Das verwandelt eine bedrohliche Reorg in ein Versprechen.

Wohin sollten Sie als CDO berichten? Das ist ein Hinweis auf die Strategie, keine Frage der Vanity. Berichten Sie an den CEO oder COO, wenn Daten ein Hebel für Growth und Monetarisierung sind, dann brauchen Sie P&L-Nähe und Peer-Status mit den Leitern der Geschäftsbereiche. Berichten Sie an den CIO, wenn die Priorität Plattform- und Infrastrukturkonsolidierung ist. Berichten Sie an den CFO oder CRO, wenn das Mandat defensiv ist: Risiko, Compliance, Kosten. Die falsche Linie ist fatal: Ein CDO mit Monetarisierungsmandat, der an einen risikofixierten CRO berichtet, wird strukturell vom Mandat abgeschnitten, offensive Wetten einzugehen.

Das Problem der gestrichelten Linie ist der Kern föderierten Designs, und gestrichelte Linien funktionieren meist nicht von allein. Eine gestrichelte Linie ohne Hebel ist ein Vorschlag. Geben Sie ihr Zähne über drei Mechanismen:

1. Gemeinsame Ziele. Der Bonus des eingebetteten Analytics-Leads wird teils von Ihnen, teils vom Leiter des Geschäftsbereichs gesetzt. Geteiltes Incentive, geteilte Loyalität, bewusst so.
2. Kontrolle über den Karrierepfad. Wenn Sie unternehmensweit Beförderungen und Leveling für die Datenprofession verantworten, haben Ihre gestrichelten Linien Gravitation, auch wenn die durchgezogene Linie im Business liegt.
3. Kontrolle über die Plattform. Wenn die Domänen von den gepflasterten Wegen abhängen, die Ihr Hub baut, ist Ihr Einfluss strukturell, nicht politisch.

Dieser dritte Punkt ist das stille Geheimnis mächtiger CDOs. Diejenigen mit echter Autorität haben selten alle unter sich. Sie verantworten die Plattform, die Standards und die Profession, sodass die gesamte Organisation auf Schienen fährt, die sie gelegt haben, unabhängig von den Kästchen im Organigramm.

Ein Wort zu Conways Law, denn es regiert alles oben Genannte: Ihre Systeme werden Ihre Kommunikationsstruktur spiegeln. Wenn Sie Ingestion und Analytics auf zwei Teams aufteilen, die nicht miteinander sprechen, bauen Sie eine Pipeline mit einer Nahtstelle genau an dieser Grenze, und Datenqualität stirbt in der Lücke. Legen Sie Ihre Teamgrenzen dorthin, wo Sie die Systemschnittstellen *haben wollen*, und lassen Sie Conways Law für sich arbeiten statt gegen sich.

Wichtigste Erkenntnisse

• Sortieren Sie jede Funktion nach einer Regel: zentralisieren, was von Skalierung, Konsistenz oder Knappheit profitiert; föderieren, was von Kontext und Geschwindigkeit profitiert. Hub-and-Spoke ist die Antwort für die meisten reifen Organisationen, aber nur, wenn Sie diese Sortierung bewusst vornehmen.
• Trennen Sie Governance und Delivery in unterschiedliche Berichtslinien und führen Sie sie am Punkt der Produktion über Data Contracts wieder zusammen, die Controls als Code kodieren. Lassen Sie niemals eine Führungskraft beides verantworten, Delivery gewinnt den täglichen Trade-off immer.
• Stewards gehören zur Domäne, nicht zur zentralen Governance. Policy ist zentral; Umsetzung ist lokal. Ein Außenstehender, der eine Domäne kontrolliert, scheitert; ein Insider, der sie verbessert, hat Erfolg.
• Bauen Sie Autorität über die Plattform, die Standards und die Profession auf, nicht über Kästchen im Organigramm. Die mächtigsten CDOs verantworten die Schienen, auf denen alle fahren, und das lässt gestrichelte Linien wie durchgezogene wirken.
• Behandeln Sie das Organigramm als Film, nicht als Foto. Sequenzieren Sie die Struktur entlang Ihrer strategischen Phase, zentralisieren Sie, um Kontrolle herzustellen, föderieren Sie dann, um zu skalieren, und kündigen Sie den Weg an, damit eine Reorg als Versprechen gelesen wird und nicht als Drohung.