---
title: "Das föderierte Betriebsmodell"
description: "Zentralisierung vs. Dezentralisierung: warum das föderierte Modell die richtige Balance für große Cloud-Organisationen ist und wie Sie es umsetzen."
sidebar:
  order: 4
  label: "Föderiertes Modell"
source_url: "https://framework.stackit.cloud/de/advisory/cloud-centre-of-excellence/federated-model/"
source_file: "docs/de/advisory/cloud-centre-of-excellence/federated-model.mdx"
---

## Das Zentralisierungs-Paradoxon

Zu starke Zentralisierung: Der CCoE wird zum Engpass. Alle Entscheidungen müssen durch den CCoE — Teams werden langsamer, nicht schneller.

Zu wenig Zentralisierung: Jedes Team macht sein eigenes Ding. Schatten-IT, Inkonsistenz, keine gemeinsamen Standards, Compliance-Risiken.

Das föderierte Modell löst dieses Paradoxon durch eine klare Trennung: **Was muss zentral sein? Was darf dezentralisiert werden?**

## Das föderierte Prinzip: „Zentral entscheiden, lokal ausführen“

Zentral (CCoE) besitzt: Standards und Richtlinien, Sicherheitsleitplanken, IAM-Governance, FinOps-Reporting, Landing-Zone-Betrieb, das Schulungsprogramm und die gemeinsame IaC-Modulbibliothek. Dezentral (Workload-Teams) besitzen: Workload-Architektur, Deployment-Entscheidungen, Feature-Entwicklung, Cloud-Kosten-Verantwortung für den eigenen Workload, Workload-Betrieb, teaminterne Prozesse und workload-spezifische IaC-Module.

## Was zentral sein MUSS

**1. Sicherheitsleitplanken (nicht verhandelbar)**  
Geografische Einschränkung, Verschlüsselung, Netzwerkisolation, IAM-Grenzen — diese Kontrollen dürfen nicht dezentral gemanagt werden. Eine einzige falsche IAM-Richtlinie eines Teams kann die gesamte Plattform gefährden.

**2. Tagging-Standards und FinOps-Governance**  
Verwendet jedes Team eigene Tags, ist keine konsolidierte Kostenbetrachtung möglich. Tagging-Standards müssen zentral definiert und durch Leitplanken erzwungen werden.

**3. Landing-Zone-Infrastruktur**  
Hub-Netzwerk, zentrales Logging, DNS, On-Premises-Konnektivität — diese gemeinsam genutzten Dienste werden einmal erstellt und von allen Teams verwendet. Für eine dezentrale Steuerung sind sie zu kritisch.

**4. Compliance-Rahmenwerk**  
DSGVO-Verantwortlichkeiten, Regelungsabbildung, Revisionsdokumentation — zentral, da Compliance nicht dezentral delegierbar ist.

## Was dezentral sein KANN

**1. Workload-Architektur**  
Welche Managed Services nutzt ein Team? Wie ist die Anwendung aufgebaut? Das ist die Entscheidung des Teams — innerhalb der CCoE-Standards und Leitplanken.

**2. Deployment-Rhythmus und CI/CD**  
Teams deployen in ihrem eigenen Tempo. Der CCoE stellt CI/CD-Vorlagen zur Verfügung, aber der Deployment-Prozess liegt in der Verantwortung des Teams.

**3. Teaminterne Prozesse**  
Stand-ups, Sprint Planning, Code-Review-Prozesse — voll dezentral.

**4. Workload-spezifische Monitoring-Dashboards**  
Zentrales Logging ja, aber workload-spezifische Dashboards zur Anwendungsperformance sind Sache des Teams.

## Beispiel föderiertes Modell: Entscheidungsrahmen

| Frage                                                     | Entscheidungshoheit                                     |
| --------------------------------------------------------- | ------------------------------------------------------- |
| „Dürfen wir in Region X deployen?“                        | CCoE (Leitplanke entscheidet, keine Person)             |
| „Welche Datenbankgröße brauchen wir?“                     | Workload-Team (unter Anleitung von FinOps)              |
| „Müssen wir dieses Tag-Set nutzen?“                       | CCoE-Standard (nicht verhandelbar)                      |
| „Wie strukturieren wir unsere Microservices?“             | Workload-Team (innerhalb der Architekturstandards)      |
| „Kann unsere App direkt mit dem Internet kommunizieren?“  | CCoE-Leitplanke (voraussichtlich nein, außer genehmigt) |
| „Welches Framework nutzen wir für unser Backend?“         | Workload-Team                                           |

## Fehlerbild: falsche Zentralisierung

**Szenario:** Der CCoE erfordert, dass alle Terraform-Änderungen ein CCoE-Review-Gate durchlaufen. Ein Review dauert durchschnittlich 3 Tage.

**Ergebnis:** Teams deployen 3 Tage nach Bedarf. Kritische Sicherheitspatches warten 3 Tage. Teams umgehen das Gate mit manuellen Portalklicks. Der CCoE wird eher als Feind denn als Befähiger gesehen.

**Lösung:** Bei Standardänderungen (Ressourcen innerhalb des freigegebenen Typenbereichs, alle Leitplanken bestanden) kein manuelles Review — Leitplanken übernehmen automatisch die Kontrolle. Manuelle Reviews nur für Ausnahmen und neue Muster.

## Fehlerbild: falsche Dezentralisierung

**Szenario:** Teams dürfen ihre eigenen Netzwerkregeln festlegen.

**Ergebnis:** Team A öffnet Port 22 für die eigene IP. Team B öffnet Port 22 für 0.0.0.0/0. Nach 6 Monaten gibt es 47 verschiedene Netzwerkregelsätze; bei einem Sicherheitsaudit werden 12 kritische Feststellungen getroffen.

**Lösung:** Netzwerkrichtlinien sind CCoE-Standards, keine Teamentscheidungen. Teams können Ausnahmen beantragen — mit Begründung und zeitlicher Begrenzung.

## Praktische Schritte

1. **Entscheidungsrahmen dokumentieren**: Für jede große Cloud-Entscheidungskategorie definieren, wer entscheidet
2. **„Paved Roads“ gestalten** im IaC-Modulkatalog: Je mehr Standardmodule vorhanden sind, desto weniger Entscheidungen müssen die Teams selbst treffen
3. **Leitplanken kalibrieren**: nicht alles blockieren, was technisch möglich ist — nur Compliance- oder Sicherheitsverstöße
4. **Regelmäßige Retrospektive**: Wo ist der CCoE ein Engpass? Welche Standards sollten gelockert werden?