In 2019, a global consumer-goods company we'll call Meridian centralized its data function. Every analyst, every pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →, every governance decision rolled up to a single CDO org of 400 people. Eighteen months later, the business units revolted: shipping times for new dashboards had gone from days to quarters, and the commercial teams had quietly rebuilt shadow analytics teams inside marketing. So Meridian swung the pendulum—full federation, data people embedded in each unit, minimal central control. Within a year they had eleven incompatible definitions of "active customer," three overlapping customer data platforms, and a regulator asking why consent data couldn't be reconciled across regions.
The lesson isn't that Meridian picked wrong twice. It's that they treated the operating model as a binary switch when it's actually a portfolio of decisions about where specific rights sit. This lesson gives you the decision architecture to get it right the first time—and to know when to evolve it.
Most CDOs frame the operating-model question as "where do the people report?" That's the wrong first question. The org chart is downstream. The upstream question is:
Break your data function into distinct activities and ask where each should live. A useful decomposition:
The three canonical operating models are really just three *default* answers to how these activities distribute:
| Activity | Centralized | Federated | Hub-and-Spoke |
|---|---|---|---|
| Platform/infra | Central | Central (usually) | Hub |
| Definitions/MDMMDMMaster Data Management (MDM) is the discipline of creating and maintaining a single, consistent, trusted version of an organization's core business entities like customers, products, and suppliers.View full definition → | Central | Local | Hub sets standard, spoke applies |
| Governance/policy | Central | Local (risky) | Hub owns, spoke executes |
| Analytics/DS | Central | Local | Spoke (near the business) |
| Data products | Central | Local | Shared |
Read the hub-and-spoke column carefully. It's not a compromise—it's a deliberate split: standards and platform centralize, execution and insight distribute. That's why it's become the dominant pattern for large enterprises, and why the industry's "data meshdata meshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.View full definition →" conversation is essentially a hub-and-spoke argument with better tooling.
Centralization gives you consistency, economies of scale, and a single throat to choke on compliance. One team, one platform, one definition of every metric. For a company under roughly 2,000 employees or with a single dominant business line, this is almost always right. The overhead of coordination is low because there's not much to coordinate.
It breaks on two axes: scale and domain distance. As the number of business domains grows, the central team becomes a queue. They lack context on the marketing funnelmarketing funnelFunnel analysis tracks how users move through a sequence of steps toward a goal, revealing where they drop off and which stages need improvement.View full definition →, the supply chain, the actuarial models—so every request requires expensive translation. Prioritization becomes political. This is exactly the trap Meridian hit: centralization optimizes for control at the direct expense of throughput and business proximity.
Federation puts data capability inside the business units, where the context lives. Speed goes up. Business relevance goes up. The commercial team's analysts actually understand commerce.
The failure mode is entropy. Without a strong center, you get definitional drift (Meridian's eleven "active customers"), duplicated spend, and—the one that ends careers—inconsistent governance. When each unit sets its own access and retention rules, you cannot answer a regulator's question about where all copies of a data subject's consent live. Pure federation is viable only when units are genuinely independent (a holding company, distinct regulated entities) or when you have unusually mature engineering discipline.
Hub-and-spoke is what most CDOs converge on for good reason. The hub owns the platform, the shared standards, the policy framework, and the reusable core data products. The spokes—embedded data teams in each domain—own analytics, domain-specific products, and execution against the hub's standards.
The critical design detail: spokes have a dotted line to the CDO and a solid line to the business (or vice versa—see below). Governance is not optional at the spoke; it's inherited. The hub publishes the "active customer" definition; spokes consume it and cannot fork it without a governance process.
Its failure mode is the ambiguous middle. When the hub-spoke boundary isn't explicit, you get either a hub that behaves like a bottleneck (reverting to centralized dysfunction) or spokes that quietly go rogue (reverting to federated entropy). Hub-and-spoke demands the most operational discipline of the three.
Don't pick a model from a menu. Derive it from four forces specific to your company.
1. Data maturity (the gating factor). A federated or hub-and-spoke model *requires* the ability to enforce standards without physically controlling the work. If your data catalogdata catalogA centralized inventory of an organization's data assets, enriched with metadata, that helps people find, understand, and trust the data they need.View full definition → is aspirational, your lineage is manual, and your governance runs on quarterly emails, distributing the work will distribute chaos. Low maturity → centralize first, then federate. You cannot delegate what you cannot yet standardize. This is why Meridian's federation failed: they distributed before they had the guardrails to make distribution safe.
2. Business heterogeneity. How different are the domains? A single-product SaaS company has low heterogeneity—centralization scales fine. A conglomerate spanning insurance, retail, and manufacturing has extreme heterogeneity; centralization guarantees a translation tax on every decision. High heterogeneity pushes toward spokes.
3. Regulatory concentration. In heavily regulated, cross-cutting environments (GDPR across regions, financial reporting, clinical data), the cost of inconsistent governance is existential. This pulls *policy* toward the hub even when execution distributes. Note this force acts on specific activities, not the whole model—hence the activity-by-activity table above.
4. Talent scarcity and geography. Can you actually hire enough senior data people to staff spokes? If the talent pool is thin, a central center of excellence with rotating deployment may be the only realistic option regardless of what the theory prefers.
Score each force. When maturity is low, that force dominates—centralize until you build the standards muscle. When maturity is adequate and heterogeneity is high, hub-and-spoke wins. Pure federation is rare and should trigger a "prove it" conversation.
A $4B specialty-chemicals firm: four divisions, moderate data maturity (a real catalog, semi-automated lineage), heavy regulatory exposure in one division (specialty pharma inputs), and a scarce talent market in its headquarters city.
Apply the forces: maturity is adequate (so distribution is on the table), heterogeneity is high (four genuinely different businesses), regulation is concentrated in one division, talent is scarce. The answer isn't one model—it's hub-and-spoke with an asymmetric spoke. The three commercial divisions get lean embedded spokes. The pharma division, given regulatory weight, keeps a heavier governance presence with the hub retaining tighter policy control. Because talent is scarce, the hub runs a shared platform team that all spokes draw on rather than each spoke building infrastructure. This is the judgment that separates a CDO from a framework: the model can be applied unevenly across the enterprise.
Assuming you land where most large enterprises do, here's the operational how-to that determines success or failure.
Define the spoke charter explicitly. Every spoke should have a written charter stating what it owns, what it inherits from the hub, and its SLAs to the business. Ambiguity here is the single biggest cause of hub-and-spoke failure.
Get the reporting lines right. There are two viable structures:
The second only works if standards are enforced by tooling, not by org authority. Which leads to the most important point:
Make governance a platform property, not a committee. The hub's power in a distributed model comes not from approving work but from making the compliant path the easy path. Certified data products, policy-as-code, and shared definitions must be *technically* enforced. A spoke building on the platform should get the right access controls and the canonical customer definition by default.
# Example: a data product contract the hub enforces on every spoke
data_product: customer_360
owner: commercial_spoke_emea
inherits_definitions_from: hub_master_data # cannot fork without governance PR
classification: pii_restricted # policy-as-code, hub-controlled
access_policy: role_based
sla:
freshness: 24h
availability: 99.5%
governance:
certified: true
steward: emea_data_leadWhen the definition and classification are declared as inherited and enforced in the pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.View full definition →, a spoke *cannot* silently invent its own "active customer" or downgrade PII controls. That's how you get federation's speed without federation's entropy.
Instrument the boundary. Track the metrics that reveal whether the model is drifting: number of forked/duplicate definitions (should trend to zero), time-to-first-dashboard (should stay low—if it climbs, the hub is bottlenecking), and percentage of data products built on certified platform assets versus shadow builds (your shadow-IT early-warning system).
Knowledge check
1. According to the lesson, what was Meridian's fundamental error across both reorganizations?
2. The lesson argues that the org chart (where people report) is the wrong first question. What is the correct upstream question?
3. Meridian's federated phase produced eleven definitions of 'active customer,' overlapping CDPs, and an inability to reconcile consent data. Which activity, if held centrally, would most directly have prevented these specific failures?
4. Select ALL correct answers. Based on the lesson's decomposition, which activities make up the data function whose decision rights must be individually placed?
Select all the correct answers.
5. Select ALL correct answers. What lessons does the Meridian case illustrate about pure centralization versus pure federation?
Select all the correct answers.
The operating model is not a permanent choice—it's a function of maturity that should evolve deliberately. The healthy trajectory for most growing companies:
Centralize → Hub-and-Spoke → Selective deep federation. Start centralized to build the standards, platform, and governance muscle. Once those are codified and enforceable in tooling, push execution out to spokes. Only the most mature organizations, with governance fully embedded in the platform, can safely federate deeply—and even they keep a hub for policy and core products.
The mistake Meridian made was skipping the maturity gate—jumping from centralized straight to federated without building the enforcement layer that makes distribution safe. The pendulum swing was a symptom of treating the model as an ideology rather than a maturity-dependent design.
Signals it's time to evolve *toward* distribution: the central team is a persistent bottleneck, business units are building shadow teams, and your standards are now enforceable in tooling. Signals you've distributed *too far*: definitional drift, governance gaps surfacing in audits, and duplicated infrastructure spend. Watch these actively—the right model this year is the wrong one in three.
1. Decompose before you decide. Don't pick a model off a menu—assign decision rights activity by activity (platform, definitions, governance, analytics, products). Most real answers are asymmetric splits, not pure archetypes.
2. Maturity is the gating force. You cannot delegate what you cannot standardize. If governance runs on emails rather than tooling, centralize first and build the enforcement layer before you distribute.
3. In hub-and-spoke, governance must be a platform property. Make the compliant path the easy path via policy-as-code and inherited definitions. The hub's power comes from tooling defaults, not committee approvals.
4. Write the spoke charter and get reporting lines deliberate. Ambiguity at the hub-spoke boundary is the top failure cause. Solid-line-to-CDO for regulatory weight; solid-line-to-business only when your tooling enforces standards automatically.
5. Instrument the boundary and evolve deliberately. Track duplicate definitions, time-to-first-dashboard, and shadow-build percentage. The right model is maturity-dependent—expect to move from centralized toward hub-and-spoke as your standards muscle strengthens, and re-evaluate annually.