Centralized, federated, hub-and-spoke: how to actually choose

The org-design question never has a single right answer — but the wrong one is expensive. A framework for matching data team structure to organizational reality.

This is a working note from the practice — written for senior architects, CDOs and the leadership teams that hire them. The full edition will appear here shortly.

The short version

Centralized, federated, hub-and-spoke: how to actually choose touches on patterns we encounter regularly across DACH enterprise engagements. Like most architectural questions, the right answer depends on the organization, the workload and the team — but there are recurring decision points worth naming.

Subscribe to the practice updates below to get the full version when it publishes, or get in touch directly if you'd like to discuss how this applies to your specific situation.

The cost of the wrong structure

McKinsey's 2023 data and AI study found that organizations with centralized data teams were 1.4× more likely to report "excellent" data quality, but 0.7× as likely to report fast analytics delivery. Federated organizations flipped this: faster delivery, lower consistency. Neither extreme optimizes for both simultaneously — which is why 67% of large DACH enterprises in a 2024 Bitkom survey reported operating some form of hybrid or hub-and-spoke structure.

The organizational cost of a mismatched structure is concrete. In one manufacturing engagement, a fully centralized data team of 12 was serving 6 business units. Average lead time for a new dashboard request: 11 weeks. Business units had stopped submitting requests and were maintaining their own Excel "shadow BI." When we moved to a hub-and-spoke model — keeping the central team for governance and platform, embedding two data engineers per business unit — the lead time dropped to 8 days and Excel shadow BI usage declined by 60% within a year.

The three models and when each works

Centralized: One team owns all data infrastructure, pipelines, governance and reporting. Works when the organization has fewer than 500 data consumers, when regulatory compliance requires strict lineage control (pharma, financial services), or when the business units do not have the data literacy to operate independently. The ceiling is staffing: a central team of 20 cannot realistically serve 15 business units with diverse analytical needs.

Federated: Each business unit owns its own data infrastructure and reporting. Works at organizations where business units operate as independent P&L centers with distinct data domains and no cross-unit reporting requirements. Almost never works for group-level financial reporting — you end up with five definitions of EBITDA and no one who can reconcile them. We recommend full federation only at the domain level within a data mesh architecture, not as a company-wide operating model.

Hub-and-spoke: Central platform team owns infrastructure, governance, data quality standards and the golden record layer. Embedded domain teams (1–3 analysts or data engineers per business unit) own domain-specific pipelines and reporting. This is the most operationally complex model but scales best. The critical success factor is a clear contract between the hub and the spokes: what the platform team delivers (APIs, governed datasets, infrastructure), what the domain teams own (transformation logic, business rules, report design).

Making the decision: a three-question diagnostic

Question 1: How often do business units need data from other business units? If cross-domain data requests are rare (less than 20% of analytical work), federation is viable. If cross-domain reporting is the norm, you need a centralized layer — the only question is whether it is owned centrally or by a hub.

Question 2: What is the regulatory compliance burden? DSGVO, MiFID II, GxP, and Solvency II all impose audit trail and data lineage requirements that are easier to enforce with a centralized governance layer. If two or more of these frameworks apply, plan for a central hub regardless of how the domain teams are structured.

Question 3: How mature is data engineering talent across the organization? Hub-and-spoke requires capable data practitioners in each domain. If the talent pool is thin — which is the reality in most DACH mid-market companies — start centralized, build skills in the domains through embedded rotation programs, and plan a transition to hub-and-spoke over 18–24 months.