Das Zentralisierungs-Paradoxon
Abschnitt betitelt „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“
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „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
Abschnitt betitelt „Praktische Schritte“- Entscheidungsrahmen dokumentieren: Für jede große Cloud-Entscheidungskategorie definieren, wer entscheidet
- „Paved Roads“ gestalten im IaC-Modulkatalog: Je mehr Standardmodule vorhanden sind, desto weniger Entscheidungen müssen die Teams selbst treffen
- Leitplanken kalibrieren: nicht alles blockieren, was technisch möglich ist — nur Compliance- oder Sicherheitsverstöße
- Regelmäßige Retrospektive: Wo ist der CCoE ein Engpass? Welche Standards sollten gelockert werden?