Datenteam-Struktur: Zentral vs Embedded vs Hub-and-Spoke

Die meisten Datenteams wachsen aus Versehen. Du stellst einen Data Engineer ein, dann einen BI-Entwickler, dann einen Analyst — und plötzlich hast du ein Team ohne klare Struktur, ohne Ownership, und keiner weiß, wer haftet, wenn die Pipeline bricht. Eine bewusst gewählte Datenteam-Struktur ist der Unterschied zwischen einem Team, das skaliert, und einem, das zum Bottleneck wird.

TL;DR

Drei dominante Modelle: Centralized (ein Team versorgt alle), Embedded (Daten-Leute sitzen in den Business-Units), Hub-and-Spoke (zentrales Plattform-Team plus Embedded-Praktiker). Jedes Modell hat eigene Failure-Modes. Org-Größe, Daten-Reife und Business-Struktur bestimmen, was passt — nicht Industrie-Trends.

• < 50 Leute: Centralized.
• 50–200 + Embedded-Analysten: Centralized + Außenposten.
• 200+ mit klaren BUs: Hub-and-Spoke.
• Embedded-only funktioniert nur, wenn deine BUs wirklich unabhängig agieren.

Warum Struktur wichtiger ist als Technologie

Firmen verbringen Monate mit der Wahl zwischen Databricks und Snowflake, denken aber selten gründlich nach: wer hat Ownership welcher Daten, wer ist On-Call für welche Pipeline, wer darf zu einem Datenrequest „Nein" sagen. Das Ergebnis: doppelte Pipelines, inkonsistente Metrik-Definitionen, ein zentrales Team, das permanent überfordert ist.

Struktur bestimmt:

• Wer Infrastruktur baut und betreibt
• Wer Autorität über Datenqualität und Governance hat
• Wie schnell BUs Antworten bekommen
• Ob Daten ein Bottleneck oder ein Multiplikator sind

Falsche Struktur ist teuer. Ein Datenteam mitten im Flug umzubauen — während Pipelines laufen und Dashboards live sind — ist eine der disruptivsten Aktionen, die du einer Datenorganisation antun kannst.

Die drei Modelle

Modell 1: Centralized Data Team

Ein Datenteam für die ganze Organisation. Alle Engineers, Analysten und Data Scientists berichten in eine Abteilung — meist an CDO, CTO oder VP Data.

graph TD
    A[CDO / VP Data] --> B[Data Engineering]
    A --> C[Analytics & BI]
    A --> D[Data Science]
    B --> E[Geteilte Infra
Pipelines · Warehouse · Governance]
    C --> F[Geteiltes Reporting
Dashboards · Metriken]
    D --> G[Geteilte Modelle
ML · Forecasting]

Stärken:

• Starke Governance — ein Team setzt Standards durch
• Keine Duplikation in Infra oder Tooling
• Tiefe Plattform-Expertise (weniger Generalisten nötig)
• Klare Verantwortung — ein Team besitzt Datenqualität

Failure-Modes:

• Wird Bottleneck bei wachsender Nachfrage — alle wollen Daten, ein Team liefert
• Distanz zum Business → langsame Feedback-Loops („das Dashboard passt nicht zu unserer Arbeit")
• Priorisierung wird politisch — wer kommt zuerst dran?
• Engineers werden Ticket-Erlediger statt Plattform-Bauer

Wann es funktioniert: Frühphase (< 100 Leute), regulierte Branchen mit harter Governance, homogene Daten-Needs über BUs.

Wann es bricht: Wenn Request-Queues regelmäßig 2+ Wochen laufen, wenn BUs Shadow-Analytics in Excel bauen, wenn das Team beim Business-Wachstum nicht mehr mitkommt.

Modell 2: Embedded Analytics

Daten-Praktiker — Engineers, Analysten, Data Scientists — sitzen direkt in den Business-Units. Marketing hat einen eigenen Analysten; Product einen eigenen Engineer. Kein zentrales Team, oder höchstens ein sehr dünnes.

graph TD
    A[Business Units] --> B[Marketing Pod
Analyst + Engineer]
    A --> C[Product Pod
Analyst + Scientist]
    A --> D[Finance Pod
Analyst + Engineer]
    E[Dünne Zentral-Infra
optional] -.-> B
    E -.-> C
    E -.-> D

Stärken:

• Kein Bottleneck — BUs bewegen sich im eigenen Tempo
• Tiefes Domänenwissen
• Enge Feedback-Loops — Analysten kennen den Business-Kontext intim
• Klare Verantwortung pro BU

Failure-Modes:

• Metrik-Inkonsistenz — drei Teams definieren „Revenue" auf drei Arten
• Infra-Duplikation — jede BU baut dieselben Pipeline-Patterns
• Einsame Daten-Leute — kein Peer-Review, kein technisches Wachstum
• Governance-Gaps — keiner achtet auf Cross-Team-Qualität

Wann es funktioniert: Firmen mit sehr unabhängigen BUs, starke Daten-Kultur, Speed-to-Insight als oberste Priorität.

Wann es bricht: Wenn cross-funktionale Fragen aufkommen und keiner sich auf Zahlen einigt, wenn Embedded-Analysten ohne Community vereinsamen, wenn Infra-Kosten durch Duplikation explodieren.

Modell 3: Hub-and-Spoke

Das Hybrid-Modell: ein zentrales Platform-Team (Hub) baut und pflegt geteilte Infra, Governance und Standards. Embedded-Praktiker (Spokes) sitzen in den BUs und nutzen diese Infra für ihre Domäne.

graph TD
    A[Data Platform Team
Hub] --> B[Geteilte Infra
Warehouse · Orchestrierung · Observability]
    A --> C[Standards & Governance
Metriken · Qualität · Access Control]
    B --> D[Marketing Spoke
Analyst + Analytics Engineer]
    B --> E[Product Spoke
Analyst + Data Scientist]
    B --> F[Finance Spoke
Analyst + Analytics Engineer]
    C --> D
    C --> E
    C --> F

Stärken:

• Verbindet zentrale Governance mit Embedded-Geschwindigkeit
• Keine Kern-Infra-Duplikation
• BUs behalten Ownership ihrer Arbeit
• Geteilte Standards machen cross-funktionale Analyse möglich
• Plattform-Team baut Leverage statt Tickets zu erledigen

Failure-Modes:

• Koordinations-Overhead — Hub und Spokes müssen regelmäßig reden, sonst driften Standards
• Spannung zwischen Hub-Autorität und Spoke-Autonomie („wir scheißen auf eure Data-Contracts, wir müssen liefern")
• Hub kann selbst Bottleneck werden, wenn er alles approven will
• Erfordert Management-Support auf beiden Seiten

Wann es funktioniert: Mittlere bis große Orgs (200+ mit eigener Daten-Headcount), klare BUs mit eigenen Datenflüssen, Firmen, die den Schmerz beider anderer Modelle kennen.

Wann es ringt: Wenn das Leadership Standards nicht durchsetzt, wird der Hub zahnlos. Wenn der Hub unterbesetzt ist, arbeiten Spokes drumherum. Das Modell braucht echtes Commitment, nicht nur ein Org-Diagramm.

Modell-Vergleich

Schlüsselrollen in einem modernen Datenteam

Unabhängig von der Struktur — diese Rollen zählen wirklich:

Data Engineer: Baut und betreibt Pipelines, transformiert Rohdaten, managt Orchestrierung und Infra. Besitzt die Reliability der Datenbewegung.

Analytics Engineer: Schnittstelle Engineering/Analytics. Baut modulare, getestete dbt-Models. Übersetzt Rohdaten in business-ready Tabellen. Zunehmend wichtigster Hire für daten-reife Orgs.

Data Analyst: Beantwortet Business-Fragen mit verfügbaren Daten. Besitzt Dashboards und Reports. In Embedded-Modellen die primäre Daten-Kontaktstelle pro BU.

Data Platform Engineer: Fokus auf die Plattform — Warehouse, Orchestrierung, Monitoring, Access Control. In Hub-and-Spoke das Hub-Team.

Analytics Engineer vs. Data Engineer: die unscharfe Linie. Viele Teams vermischen das — und leiden darunter: Engineers, die Pipelines bauen sollten, modellieren; Analysten, die Fragen stellen sollten, schreiben Transformationen, die in Produktion brechen.

Die Org-Entscheidung, die keiner treffen will

Die Wahl ist Funktion von Org-Größe, Daten-Reife und politischem Willen, Standards durchzusetzen.

Konstant unterschätzt: die Analytics-Engineer-Rolle. Teams, die in Analytics Engineers investieren, schlagen Teams, die die Lücke zwischen teurem Senior-DE und SQL-flachem Junior-Analyst lassen.

Praktische Empfehlung

Starte zentral. Die meisten frühen Teams sollten 1–2 Leute sein, die geteilte Infra bauen und die Top-Priority-Fragen beantworten. Wenn BU-Needs divergieren und Queues wachsen, in Richtung Hub-and-Spoke gehen. Embedded-only funktioniert nur bei wirklich unabhängigen BUs ohne cross-funktionale Metriken.

Strukturiere nicht reaktiv. Jedes Mal, wenn das Team „Bottleneck" genannt wird, ist der Reflex: mehr Headcount oder Reorg. Meist ist bessere Tools, klarere Priorisierung oder ein expliziter Data-Contract die bessere Lösung. Reorg ist teuer — mach es, wenn das Modell wirklich falsch ist, nicht wenn das Team einfach unterbesetzt ist.

Für Teams, die Self-Serve-Datenzugang erkunden — damit BUs ohne Ticket abfragen können — lassen Tools wie Harbinger Explorer Analysten ihre Daten via Natural-Language im Browser abfragen. Das ersetzt keine Plattform-Architektur, reduziert aber das Request-Volumen auf dem zentralen Team, während Embedded-Analysten SQL-Skills aufbauen.

Die richtige Struktur ist die, die funktioniert

Hub-and-Spoke ist für die meisten reifen Daten-Orgs die richtige Antwort. Aber „richtige Antwort" zählt nur, wenn Leadership sie stützt, das Plattform-Team finanziert ist und BUs Standards folgen wollen. Ein gut geführtes Centralized-Team schlägt jedes Mal ein dysfunktionales Hub-and-Spoke.

Wähle das einfachste Modell, das den aktuellen Bottleneck löst. Dann investiere in Tooling und Practices, die Self-Service ermöglichen — denn die beste Struktur ist die, die das Datenteam nicht für jede Antwort im Raum braucht.

FAQ

Wann sollte ich von Centralized auf Hub-and-Spoke wechseln?

Wenn dein Team 5+ Personen hat, deine Request-Queue konstant 2+ Wochen läuft und BUs anfangen, Schatten-Analytics in Spreadsheets zu bauen. Das ist das Signal.

Reicht ein Analytics Engineer statt eines Data Engineers?

In den ersten 12–18 Monaten oft ja. Ein starker Analytics Engineer mit dbt + ein managed Warehouse (BigQuery, Snowflake) deckt erstaunlich viel ab. Echtes Data Engineering wird relevant, sobald Streaming, Custom-Ingest oder hartes SLA-Tuning ins Spiel kommen.

Wie verhindere ich, dass mein zentrales Team zum Bottleneck wird?

Drei Hebel: (1) Self-Service-Tools (Natural-Language-Query, dbt-Self-Service), (2) klare Data-Contracts mit Stakeholder-Verantwortung, (3) eine harte Priorisierungs-Regel mit Eskalation an die Leitung statt politischer Verhandlung pro Ticket.

Sollte ich Data Mesh erwägen?

Data Mesh ist Embedded mit zusätzlicher Disziplin (Data-as-Product, Self-Serve-Plattform, Federated Governance). Für die meisten DACH-Mittelständler unter 500 Engineers ist das Overkill — Hub-and-Spoke deckt 90% der gewünschten Effekte.

Stand: 14. Mai 2026. Org-Strukturen sind kontextabhängig; nutze die Modelle als Denkrahmen, nicht als Rezept.