How a data team is organised — centralised under one function, federated across business units, or some hybrid — determines what it can accomplish, who it serves, and what kinds of problems it persistently cannot solve. The operating model is not a neutral organisational choice; it shapes outcomes as much as the team's technical capability.
How a data team is organised — centralised under one function, federated across business units, or some hybrid — determines what it can accomplish, who it serves, and what kinds of problems it persistently cannot solve. The operating model is not a neutral organisational choice. It shapes analytical outcomes as much as technical capability, and the trade-offs are real: what works well in one model is structurally difficult in another.
The Centralised Model
In a centralised operating model, all data engineering, analytics engineering, data science, and BI capability lives in a single team, typically reporting to a Chief Data Officer, VP of Data, or CTO. Business units request work from the central team; the central team prioritises, executes, and delivers.
Advantages:
Governance is tractable. The central team owns the data platform, the data standards, the certified content, and the tools. Decisions about data architecture, tool selection, and data quality are made once and applied consistently. This consistency is valuable: inconsistent metric definitions, duplicated data pipelines, and fragmented tool sprawl are all significantly harder to manage in a federated model.
Deep technical expertise is concentrated. Senior data engineers, Tableau architects, and data scientists work alongside each other, share knowledge, and maintain high standards. Skills that would not exist in a small business-unit team — streaming pipeline architecture, advanced ML infrastructure — are available centrally.
Disadvantages:
Demand consistently exceeds supply. Every business unit wants more analytical support than the central team can provide. The backlog grows; high-priority work from one business unit competes with high-priority work from another; all business units feel underserved. The central team becomes a bottleneck.
The team can become disconnected from business context. A data engineer who works on requests from five different business units in parallel does not develop deep understanding of any single business domain. Analyses that are technically correct but contextually wrong — because the analyst did not understand the business well enough to interpret the data correctly — are a structural risk.
The Federated Model
In a federated operating model, data capability is embedded in each business unit. The marketing team has its own analysts; the product team has its own analytics engineers; the finance team has its own data scientists. A small central team (or a platform team, or no central team) provides shared infrastructure and standards.
Advantages:
Deep domain knowledge. Analysts and engineers embedded in a business unit develop deep understanding of that unit's data, processes, and decisions. Contextually grounded analysis is more likely to be accurate and more likely to be acted on.
Responsiveness. Business units do not queue for shared resources; they have dedicated capacity. Priorities are set at the business unit level without competing with other functions.
Disadvantages:
Governance is difficult. Without a central governance function, metrics diverge across teams. The revenue number used by marketing and the revenue number used by finance are defined differently. Data pipelines are duplicated. Tool sprawl accumulates. The technical quality of work varies widely across teams — a senior data scientist embedded in the product team may produce excellent work; a junior analyst embedded in operations may produce technically flawed analyses without anyone to catch the errors.
Duplication of effort. Each business unit builds its own version of common data models, extract pipelines, and dashboards. The cumulative engineering cost of this duplication is high, and the inconsistency it produces creates analytical credibility problems at the organisation level.
The Hybrid Model
Most effective large-scale data functions operate in some version of a hybrid model: a central platform team provides shared infrastructure, governance frameworks, and standards; domain-embedded analytics engineers and analysts serve the specific analytical needs of individual business units.
The central team's responsibilities in the hybrid model:
**Data platform** — the cloud data warehouse, orchestration infrastructure, and data lake are operated centrally. Business unit teams build on top of this shared foundation rather than each maintaining their own data infrastructure.
**Data governance** — defining and enforcing the data quality standards, certified content criteria, metric definitions, and data access policies that apply across the organisation. The central team sets the standards; business unit teams comply and contribute to the standard-setting process.
**Platform enablement** — training business unit data practitioners on platform standards, tools, and best practices; providing a consultation function for complex architectural questions; reviewing and approving changes that affect shared infrastructure.
The business unit teams' responsibilities:
**Domain-specific analytics** — building and maintaining the data models, pipelines, and dashboards that serve their specific business domain. A product analytics engineer embedded in the product team builds the product data models on top of the shared platform, following the central team's standards.
**Business partnering** — attending planning meetings, understanding business strategy, translating business questions into analytical questions, and communicating analytical findings to non-technical stakeholders. This is where domain knowledge produces disproportionate value.
Choosing the Right Model
The factors that most influence the appropriate model:
**Organisation size** — small organisations (under 50 employees) do not have enough data work to support separate domain-embedded teams. A small central team or a shared analytics function is the appropriate model. Large organisations (over 1,000 employees) typically have enough domain-specific analytical work that federated or hybrid models are necessary.
**Domain diversity** — organisations where business units are highly diverse (a conglomerate with healthcare, retail, and manufacturing units) benefit from domain embedding because the analytical contexts are fundamentally different. Organisations where units are homogeneous (a national retail chain with identical business models in each region) benefit from centralisation because the same analytical frameworks apply everywhere.
**Maturity of governance** — organisations in early stages of data governance investment benefit from centralisation until governance standards are established; then federated execution can be layered on top of the stable governance foundation.
Our BI strategy and data architecture practice advises organisations on data function design and operating model evolution — contact us to discuss the right operating model for your data team.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →