The centralisation paradox
Section titled “The centralisation paradox”Too much centralisation: the CCoE becomes a bottleneck. All decisions must pass through the CCoE — teams become slower, not faster.
Too little centralisation: every team does its own thing. Shadow IT, inconsistency, no shared standards, compliance risks.
The federated model resolves this paradox through a clear division: what must be central? what may be decentralised?
The federated principle: “Decide centrally, execute locally”
Section titled “The federated principle: “Decide centrally, execute locally””Centrally (CCoE) owns: standards and policies, security guardrails, IAM governance, FinOps reporting, landing zone operations, the training programme, and the shared IaC module library. Decentrally (workload teams) own: workload architecture, deployment decisions, feature development, cloud cost accountability for their own workload, workload operations, team-internal processes, and workload-specific IaC modules.
What MUST be central
Section titled “What MUST be central”1. Security guardrails (non-negotiable)
Geographic restriction, encryption, network isolation, IAM boundaries — these controls must not be managed decentrally. A single incorrect IAM policy from one team can compromise the entire platform.
2. Tagging standards and FinOps governance
If every team uses its own tags, no consolidated cost view is possible. Tagging standards must be centrally defined and enforced through guardrails.
3. Landing zone infrastructure
Hub network, central logging, DNS, on-premises connectivity — these shared services are built once and used by all teams. They are too critical for decentralised management.
4. Compliance framework
GDPR responsibilities, regulatory mapping, audit documentation — central, because compliance cannot be delegated decentrally.
What CAN be decentralised
Section titled “What CAN be decentralised”1. Workload architecture
Which managed services does a team use? How is the application structured? That is the team’s decision — within CCoE standards and guardrails.
2. Deployment rhythm and CI/CD
Teams deploy at their own speed. The CCoE provides CI/CD templates, but the deployment process is team responsibility.
3. Team-internal processes
Stand-ups, sprint planning, code review processes — fully decentralised.
4. Workload-specific monitoring dashboards
Central logging yes, but workload-specific application performance dashboards are the team’s concern.
Federated model example: decision framework
Section titled “Federated model example: decision framework”| Question | Decision authority |
|---|---|
| ”Are we allowed to deploy in region X?” | CCoE (guardrail decides, not a person) |
| “What database size do we need?” | Workload team (with FinOps guidance) |
| “Must we use this tag set?” | CCoE standard (non-negotiable) |
| “How do we structure our microservices?” | Workload team (within architecture standards) |
| “Can our app communicate directly to the internet?” | CCoE guardrail (probably no, unless approved) |
| “Which framework do we use for our backend?” | Workload team |
Failure pattern: wrong centralisation
Section titled “Failure pattern: wrong centralisation”Scenario: The CCoE requires that all Terraform changes pass through a CCoE review gate. A review takes an average of 3 days.
Result: Teams deploy 3 days after need. Critical security patches wait 3 days. Teams bypass the gate with manual portal clicks. The CCoE is seen as the enemy rather than the enabler.
Solution: For standard changes (resources within the approved type range, all guardrails passed) no manual review — guardrails take control automatically. Manual reviews only for exceptions and new patterns.
Failure pattern: wrong decentralisation
Section titled “Failure pattern: wrong decentralisation”Scenario: Teams are allowed to set their own network rules.
Result: Team A opens port 22 for their own IP. Team B opens port 22 for 0.0.0.0/0. After 6 months there are 47 different network rule sets; a security audit finds 12 critical findings.
Solution: Network policies are CCoE standards, not team decisions. Teams can request exceptions — with justification and a time limit.
Practical steps
Section titled “Practical steps”- Document the decision framework: for each major cloud decision category, define who decides
- Create “paved roads” in the IaC module catalogue: the more standard modules are available, the fewer decisions teams need to make themselves
- Calibrate guardrails: do not block everything that is technically possible — only what violates compliance or security
- Regular retrospective: where is the CCoE a bottleneck? Which standards should be loosened?