---
title: "The Federated Operating Model"
description: "Centralisation vs. decentralisation: why the federated model is the right balance for large cloud organisations, and how to implement it."
sidebar:
  order: 4
  label: "Federated Model"
source_url: "https://framework.stackit.cloud/advisory/cloud-centre-of-excellence/federated-model/"
source_file: "docs/advisory/cloud-centre-of-excellence/federated-model.mdx"
---

## 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"

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

**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

**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

| 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

**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

**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

1. **Document the decision framework**: for each major cloud decision category, define who decides
2. **Create "paved roads"** in the IaC module catalogue: the more standard modules are available, the fewer decisions teams need to make themselves
3. **Calibrate guardrails**: do not block everything that is technically possible — only what violates compliance or security
4. **Regular retrospective**: where is the CCoE a bottleneck? Which standards should be loosened?