Centralisation Trade-off
The exchange between consistency and control gained by centralising a capability and the autonomy and speed retained by distributing it.
The same question recurs across architecture, tooling and organisation: one shared logging platform or per-team choices; a central data team or embedded analysts; one deployment pipeline or many.
Centralisation buys consistency, economies of scale, easier compliance and audit, deeper expertise concentrated in one place, and a single point of improvement.
Centralisation costs a queue. The central team becomes a bottleneck for everyone's change, decisions are made further from the work, and local needs are served badly because the shared solution must serve everyone. Teams route around it, which produces shadow systems and the worst of both arrangements.
The resolution that generally works is the paved road: centralise the default, not the mandate. A supported path that is genuinely easier than the alternatives, with an exception process for teams whose needs differ and who accept the ownership that comes with leaving the road.
That converts a control relationship into a product relationship, which is the difference between a platform team and a gatekeeper.
Two things that decide which way to lean: how much variation the domain genuinely requires — security policy needs less than data tooling — and whether the central team is resourced to serve demand, since an under-resourced central function produces all of centralisation's costs and none of its benefits.