A large enterprise wants to move from a central data team to a decentralised model. What determines whether that succeeds, and what does it not fix?

What decentralisation actually addresses

One symptom: a central team that owns every pipeline is a service desk whose capacity is the organisation's ceiling, and which lacks domain knowledge about the data it transforms. Moving ownership to producing domains puts the knowledge and the accountability in the same place.

What determines success

• A platform good enough that domains do not build their own. Without paved infrastructure — ingestion, storage, orchestration, catalogue, access control — decentralisation means every domain reinvents the stack badly. The central team's role changes from doing the work to making the work easy.
• Contracts and standards owned centrally. Ownership decentralises; standards do not. Without enforced contracts, decentralisation is fragmentation.
• Domains with capability and capacity. A domain with no data engineer will not become a data producer because an operating model said so.
• Discoverability. Federated data with no catalogue is data nobody can find.

What it does not fix

It does not reduce total effort; it redistributes it. The work still exists, now in more places, plus new coordination overhead. Organisations that adopt it to save money are disappointed.

It also does not fix bad data. A domain publishing poor-quality data now publishes it with a contract and an owner — which is genuinely better, but it is visibility, not quality.

The honest sequencing

Most enterprises are not ready for full decentralisation on day one. The transitional shape that works is central platform, central standards, and progressive domain ownership starting with the domains that have capability — expanding as capability grows rather than by mandate.