Target Operating Model & Collaborative Empowerment
Zuletzt aktualisiert am
Target Operating Model & Collaborative Empowerment
Der Mensch entscheidet über den Erfolg: dieser Trail baut ein föderiertes Betriebsmodell, eine CCoE-Betriebsrats-Partnerschaft und Weiterbildung auf.
CCoE-Struktur & Rollen
Aufbau der Cloud-Organisation mit klarer funktionaler Trennung zwischen Governance (CCoE) und technischem Plattform-Betrieb (Platform-Team).
Zwei Funktionen, eine Organisation: CCoE und Platform Team
Abschnitt betitelt „Zwei Funktionen, eine Organisation: CCoE und Platform Team“Bevor das Rollenmodell diskutiert wird, bedarf es einer strukturellen Grundsatzentscheidung — eine, die in der Praxis oft verschmolzen wird: Ein Cloud-Team besteht aus zwei funktional getrennten Bereichen, die unterschiedliche Dinge tun und unterschiedliche Kompetenzen erfordern.
Das Cloud Center of Excellence (CCoE) definiert, was gilt. Es ist verantwortlich für Governance, Richtlinien, Standards, den Servicekatalog und die Unterstützung von Anwendungsteams durch Beratung und Befähigung. Es beantwortet die Frage: „Wie müssen und dürfen Cloud-Umgebungen aussehen?“ Der CCoE ist der Hüter des Frameworks.
Das Cloud Platform Team setzt das Wie um. Es baut und betreibt die technische Plattform: Landing Zone, Netzwerkinfrastruktur, Automatisierung, Self-Service-Plattformen, Monitoring von Plattformkomponenten. Es übersetzt die Anforderungen des CCoE in die technische Realität.
In kleineren Organisationen können beide Funktionen von denselben Personen ausgeführt werden — die Trennung der Verantwortlichkeiten muss jedoch explizit bleiben. Ohne diese Trennung werden Governance-Entscheidungen stillschweigend durch Umsetzungsentscheidungen ersetzt oder es entstehen Governance-Dokumente, die niemand umsetzt.
Im folgenden Rollenmodell sind die Rollen entsprechend zugeordnet: CCoE Lead, Cloud Architect, Security Engineer und Enablement Specialist gehören in erster Linie zum CCoE. Platform Engineer und Operations Engineer gehören in erster Linie zum Platform Team. Mit beiden arbeitet der FinOps Analyst eng zusammen.
Das 7-Rollen-Modell
Abschnitt betitelt „Das 7-Rollen-Modell“Ein vollbesetzter CCoE deckt sieben Kernrollen ab. In kleineren Organisationen können Rollen kombiniert werden — die Funktion muss aber abgedeckt sein, auch wenn eine Person mehrere einnimmt.
| Rolle | Kernverantwortung | FTE (mittelständische Organisation) |
|---|---|---|
| CCoE Lead | Strategie, Stakeholdermanagement, Roadmap | 1,0 |
| Cloud Architect | Referenzarchitekturen, Designentscheidungen, Landing Zone | 1,0–2,0 |
| Platform Engineer | IaC-Modulbibliothek, CI/CD-Templates, Landing-Zone-Betrieb | 1,0–2,0 |
| Cloud Security Engineer | IAM-Governance, Policy-as-Code, DevSecOps | 1,0 |
| FinOps Analyst | Kostenoptimierung, Tagging, Showback/Chargeback | 0,5–1,0 |
| Cloud Enablement Specialist | Schulungsprogramm, Communities of Practice, Cloud Champions | 0,5–1,0 |
| Operations Engineer (SRE) | Observability, Incident Response, Runbooks | 0,5–1,0 |
Mindestbesetzung zum Start der Transformation: 4–5 FTE (CCoE Lead + Architect + Platform Engineer + Security + FinOps/Enablement kombiniert). Bei weniger als 4 FTE entsteht sofort ein struktureller Engpass.
Rollenprofil: CCoE Lead
Abschnitt betitelt „Rollenprofil: CCoE Lead“Profil: Erfahrene IT-Führungskraft mit Cloud-Verständnis und ausgeprägten Fähigkeiten im Stakeholder-Management. Muss in der Lage sein, strategische Gespräche auf CIO-Ebene zu führen und technische Teams gleichzeitig zu koordinieren.
Verantwortlichkeiten:
- Program Ownership der Cloud-Transformation
- Berichtslinie: CIO (direkt)
- Vorbereitung und Moderation des Cloud Strategy Board
- Eskalationspunkt bei teamübergreifenden Blockadethemen
- KPI-Reporting und Transformationsfortschritt
Häufige Fehler bei der Einstellung:
- Rein technisches Profil ohne Führungserfahrung: führt zu fehlender Einbindung der Stakeholder
- Reines Führungsprofil ohne Cloud-Verständnis: verliert an Glaubwürdigkeit beim Fachteam
- Interne Beförderung ohne Cloud-Hintergrund: riskant, wenn gleichzeitig Cloud-Wissen aufgebaut werden muss
Rollenprofil: Cloud Architect
Abschnitt betitelt „Rollenprofil: Cloud Architect“Profil: Senior Engineer mit tiefem Plattform-Verständnis. Kennt STACKIT-Architekturprinzipien, Networking, Sicherheitsarchitektur und Migrationsarchitekturmuster.
Verantwortlichkeiten:
- Referenzarchitekturen für wiederkehrende Workload-Typen (Web-Apps, Datenbanken, Batch Jobs, Streaming)
- Technische Beratung der Workload-Teams bei der Konzeption
- Architektur der Landing Zone und Weiterentwicklung
- Architecture Decision Records (ADRs) für plattformrelevante Entscheidungen
Rollenprofil: Platform Engineer
Abschnitt betitelt „Rollenprofil: Platform Engineer“Profil: IaC-Experte mit Praxisbezug. Schreibt Terraform-Module, baut CI/CD-Templates, betreibt täglich die Landing Zone.
Verantwortlichkeiten:
- IaC-Modulbibliothek (Paved Roads für Standardressourcen)
- CI/CD-Pipeline-Templates für Workload-Teams
- Betrieb und Aktualisierung der Landing Zone
- Leitplankenimplementierung und Testing
Beispielausgabe: Ein Terraform-Modul für eine standardmäßige STACKIT-SKE-Clusterkonfiguration, das von jedem Workload-Team verwendet werden kann, ohne die Netzwerk- und Sicherheitsdetails selbst verstehen zu müssen.
Rollenprofil: Cloud Security Engineer
Abschnitt betitelt „Rollenprofil: Cloud Security Engineer“Profil: Sicherheitsspezialist mit Cloud-Hintergrund. Versteht IAM, Policy-as-Code, DevSecOps und die regulatorischen Anforderungen der Organisation.
Verantwortlichkeiten:
- IAM-Governance: Rollenkonzept, Service-Account-Standards, PAM-Umsetzung
- Policy-as-Code: Terraform Sentinel oder OPA für automatisierte Leitplanken
- Security-Scanning-Integration in CI/CD-Pipelines
- Regulatory Compliance Mapping (DSGVO, TISAX, BAIT etc.)
- Incident Response bei Security Incidents in der Cloud
Rollenprofil: FinOps Analyst
Abschnitt betitelt „Rollenprofil: FinOps Analyst“Profil: IT-Controller oder Finance Professional mit Verständnis für Cloud-Kostenmodelle. Versteht sowohl finanzwirtschaftliche Anforderungen als auch technische Hebel zur Kostenoptimierung.
Verantwortlichkeiten:
- Überwachung und Eskalation der Tagging-Compliance
- Monatliche Showback-Berichte erstellen
- Identifikation von Optimierungspotenzialen (ungenutzte Ressourcen, Rightsizing)
- Budgetalarme und Anomalieerkennung konfigurieren
- FinOps-Reifegrad entlang Inform → Optimize → Operate entwickeln
Besetzungsstrategien
Abschnitt betitelt „Besetzungsstrategien“Strategie 1: Interne Umschichtung Geeignete interne Mitarbeitende werden für CCoE-Rollen freigestellt. Vorteil: organisatorischer Kontext bereits bekannt, keine Einarbeitung. Risiko: Cloud-Kompetenz muss aufgebaut werden, kann langsamer sein.
Strategie 2: Externe Rekrutierung Cloud-Experten werden neu eingestellt. Vorteil: sofort verfügbare Kompetenz. Risiko: Onboarding braucht Zeit, der Markt um Cloud-Talente ist umkämpft.
Strategie 3: Hybrid (empfohlen) CCoE-Kern aus 1–2 internen Führungskräften + 2–3 externen Cloud-Spezialisten. Intern: organisatorischer Kontext und Stakeholder-Beziehungen. Extern: technische Cloud-Tiefe und Transformationserfahrung. Nach 12 Monaten: Wissenstransfer, mehr interne Personen.
Strategie 4: Partnergestützter Start Start mit einem STACKIT-Partner oder Systemintegrator, der temporär CCoE-Rollen abdeckt, während interne Kapazitäten aufgebaut werden. Kostenintensiver, aber schneller zur Betriebsbereitschaft.
Häufige Fehler
Abschnitt betitelt „Häufige Fehler“Besetzung zu spät: Der CCoE-Aufbau beginnt, während die Migrationsteams bereits starten. Ergebnis: keine Standards für frühe Workloads, spätere Behebung notwendig.
Falsches Profil für den CCoE Lead: Rein technische Profile ohne Business-Stakeholder-Fähigkeit können keinen strategischen Dialog mit CIO und CFO führen.
FinOps zu klein: 0,2 FTE für FinOps ist nicht ausreichend. Kostenoptimierung ist keine Nebentätigkeit — ernst genommen kann sie zu erheblichen Einsparungen beim Cloud-Budget führen.
Praktische Schritte
Abschnitt betitelt „Praktische Schritte“- Rolleninventur: Welche der 7 Rollen kann intern besetzt werden? Welche sind extern zu besetzen?
- Freigabeplan: Mit den Abteilungsleitungen klären, wer für CCoE-Rollen freigestellt werden kann
- Rollenprofile erstellen und HR-Prozess für die externe Rekrutierung starten
- Partnereinschätzung: Welche STACKIT-Partner können temporär CCoE-Rollen besetzen?
CCoE-Charta
Ausarbeitung einer formellen CCoE-Satzung mit klaren Entscheidungsmatrizen und direktem Eskalationsrecht an den CIO.
Warum eine schriftliche Charta?
Abschnitt betitelt „Warum eine schriftliche Charta?“Eine Charta ist kein bürokratisches Dokument — sie ist der formelle Auftrag, ohne den der CCoE keine Befugnis hat, Standards durchzusetzen, Entscheidungen zu treffen oder Ressourcen einzufordern.
Ohne Charta: Der CCoE empfiehlt, aber die Teams folgen nicht, da keine Verpflichtung besteht. Der CCoE eskaliert, der Eskalationsweg ist jedoch unklar. Der CCoE blockiert Deployments, aber Geschäftsbereiche gehen daran vorbei direkt zum CIO.
Mit einer Charta: Die Regeln des Zusammenspiels sind klar, bevor der Konflikt entsteht.
CCoE-Charta-Vorlage
Abschnitt betitelt „CCoE-Charta-Vorlage“CLOUD CENTER OF EXCELLENCE — CHARTA
Abschnitt betitelt „CLOUD CENTER OF EXCELLENCE — CHARTA“Version: 1.0 Datum: [Datum] Freigegeben durch: [Name], CIO / Cloud Strategy Board Gültig ab: [Datum]
1. Mission
Abschnitt betitelt „1. Mission“Das Cloud Center of Excellence ermöglicht es [Unternehmen], Cloud-Technologie sicher, kosteneffizient und mit voller Souveränität zu nutzen. Es ist die zentrale Kompetenz- und Governance-Instanz für alle Cloud-Aktivitäten und trägt die Verantwortung für Standards, Enablement und Transformationsfortschritt.
2. Geltungsbereich
Abschnitt betitelt „2. Geltungsbereich“Diese Charta gilt für:
- Alle Cloud-Ressourcen auf [STACKIT / sonstige Plattformen]
- Alle Teams und Projekte, die Cloud-Infrastruktur nutzen oder deren Einsatz planen
- Alle Ausgaben für Cloud-Infrastruktur unabhängig von Kostenstelle oder Sparte
3. Auftrag und Befugnisse
Abschnitt betitelt „3. Auftrag und Befugnisse“Der CCoE ist berechtigt:
Standards setzen und durchsetzen:
- Cloud-Architekturstandards, Namenskonventionen und Tagging-Standards als verbindliche Vorgaben definieren
- Leitplanken-Richtlinien als Code implementieren und alle Umgebungen abdecken
- Compliance-Prüfungen für neue Workloads vor der Produktivbereitstellung durchführen
Entscheidungsauftrag:
- Technische Architekturentscheidungen mit plattformweiter Auswirkung (< [TEUR X] Budget-Auswirkung)
- Workload-Priorisierung für Migrationswellen
- Onboarding-Freigabe für neue Teams auf der Cloud-Plattform
- Ausnahmen von Leitplanken-Standards (Dokumentation erforderlich)
Eskalationsrecht:
- Der CCoE darf standardwidrige Deployments sperren
- Der CCoE kann an den CIO eskalieren, wenn Teams Aufträge nicht erfüllen
4. Entscheidungsmatrix
Abschnitt betitelt „4. Entscheidungsmatrix“| Entscheidungstyp | CCoE entscheidet | CCoE empfiehlt | Cloud Strategy Board |
|---|---|---|---|
| Technische Architekturstandards | ✓ | ||
| Priorisierung der Workload-Migration | ✓ | ||
| Leitplanken-Ausnahmen (< 30 Tage) | ✓ | ||
| Leitplanken-Ausnahmen (> 30 Tage) | ✓ | Entscheidet | |
| Anbieterentscheidungen | ✓ | Entscheidet | |
| Budget > [TEUR Y] | ✓ | Entscheidet | |
| Personalentscheidungen CCoE-Team | ✓ | Entscheidet |
5. Non-Mandat: Was der CCoE nicht macht
Abschnitt betitelt „5. Non-Mandat: Was der CCoE nicht macht“Der CCoE ist kein Gatekeeper für die täglichen Deployments. In der Verantwortung des Workload-Teams liegen:
- Deployment-Entscheidungen innerhalb der CCoE-Standards
- Workload-spezifische Architekturentscheidungen (nicht plattformweit)
- Betrieb der eigenen Workloads nach CCoE-Standards
6. Berichtslinie und Governance
Abschnitt betitelt „6. Berichtslinie und Governance“- Berichtslinie: CCoE Lead berichtet direkt an den CIO
- Quartalsbericht: Quartalsweise Executive Summary an das Cloud Strategy Board (KPIs, Risiken, Empfehlungen)
- Monatliches Statusmeeting: CCoE Lead + CIO, 30 Minuten
- Jährliche Überprüfung der Charta: Die Charta wird jährlich überprüft und bei Bedarf angepasst
7. Ressourcenbindung
Abschnitt betitelt „7. Ressourcenbindung“Die Organisation verpflichtet sich für den CCoE:
- [N] FTE interne Ressourcen (nach Name oder Rolle)
- [TEUR X] Jahresbudget für externen Support, Tools, Training
- Erreichbarkeit von C-Level-Sponsoren für Eskalationen
8. Erfolgsmessung
Abschnitt betitelt „8. Erfolgsmessung“Der CCoE wird quartalsweise an folgenden KPIs gemessen:
- Leitplanken-Einhaltungsquote (Ziel: >99 %)
- Cloud-Kosten vs. Budget (Ziel: ±10 %)
- Migrationsdurchsatz (Ziel: [N] Workloads/Quartal)
- Abschlussquote der Teamschulungen (Ziel: >80 % innerhalb von 12 Monaten)
- Incident Mean Time to Recovery (Ziel: <30 Minuten)
9. Dauer und Überarbeitung
Abschnitt betitelt „9. Dauer und Überarbeitung“Diese Charta ist unbefristet. Sie wird jährlich durch das Cloud Strategy Board überprüft. Wesentliche Änderungen des Mandats bedürfen der Freigabe durch den CIO.
Unterschriften:
| Rolle | Name | Datum |
|---|---|---|
| CIO | ||
| CTO | ||
| CFO | ||
| CISO | ||
| CCoE Lead |
Charta-Einführung: Kommunikation an die Organisation
Abschnitt betitelt „Charta-Einführung: Kommunikation an die Organisation“Die Unterzeichnung der Charta ist ein formelles Ereignis — und sollte als solches kommuniziert werden:
- All-Hands-Kommunikation durch den CIO: was der CCoE ist, was es für Teams bedeutet, wer im CCoE arbeitet
- Briefing der Abteilungsleitungen: konkret zum Entscheidungsauftrag — was der CCoE entscheidet, welche Teams eigenständig entscheiden können
- Veröffentlichung im Intranet: Charta für alle zugänglich
Das föderierte Betriebsmodell
Skalierung nach dem Leitprinzip "Zentral entscheiden, dezentral ausführen" für maximale Agilität der Produktteams innerhalb sicherer Grenzen.
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?
Rollenentwicklung & Betriebsrat
Proaktive Einbindung des Betriebsrats (§ 87 BetrVG), Abschluss von Qualifizierungsvereinbarungen und Begleitung der Mitarbeiter beim Rollenwandel.
Die Evolutionslandkarte der Rolle
Abschnitt betitelt „Die Evolutionslandkarte der Rolle“Die häufigste Angst bei Cloud-Transformationen lautet: „Meine Position wird verschwinden.“ Die richtige Antwort ist nicht Beruhigung, sondern eine konkrete Landkarte, die zeigt, wohin die Reise führt.
| Aktuelle Rolle | Cloud-Äquivalent | Neuer Fokus | Trainings-Track |
|---|---|---|---|
| Systemadministrator | Platform/Cloud Engineer | IaC, Managed Services, Automatisierung | Track C |
| DBA | Managed Database Specialist | Database-as-a-Service, Performance-Optimierung | Track C + D |
| Netzwerktechniker | Cloud Network Architect | Software-Defined Networking, VPC-Design | Track C + D |
| Security Analyst | Cloud Security Engineer | IAM, Policy-as-Code, DevSecOps | Track E |
| IT-Controller | FinOps Analyst | Cloud-Wirtschaftlichkeit, Tagging, Chargeback-Management | Track F |
| IT Operations | Site Reliability Engineer (SRE) | Observability, Incident Response, Runbooks | Track C |
| Unternehmensarchitekt | Cloud Solution Architect | Cloud-native Patterns, Multi-Service-Design | Track D |
| Projektleiter | Cloud Product Manager / Scrum Master | Agile Delivery, Teamkoordination | Track A + B |
Kernbotschaft: Die Cloud-Transformation eliminiert IT-Rollen nicht — sie entwickelt sie in Richtung höherwertiger Arbeit. Manuelles Konfigurationsmanagement wird durch IaC-Autorenschaft ersetzt.
Data Sovereignty Officer: eine aufstrebende Rolle
Abschnitt betitelt „Data Sovereignty Officer: eine aufstrebende Rolle“Während DACH-Organisationen ihre souveränen Cloud-Strategien operationalisieren, entsteht eine neue funktionale Rolle. In manchen Organisationen sitzt sie beim CISO, in anderen beim Datenschutzbeauftragten; in regulierten Branchen wird sie oft zu einer eigenständigen Funktion.
Aufgaben des Data Sovereignty Officers:
- Pflege der Workload-Klassifizierung (Souveränitätsstufen 1/2/3)
- Prüfung neuer Architekturvorschläge auf Souveränitätsimplikationen
- Zusammenarbeit mit dem Datenschutzbeauftragten bei Fragen zum Aufenthalt von Cloud-Daten
- Pflege der Souveränitätsmatrix als lebendes Dokument
- Kommunikation mit Kunden und Partnern über Souveränitätsnachweise
Profil: Eine Kombination aus technischem Cloud-Verständnis, datenschutzrechtlichen Kenntnissen und Kommunikationsfähigkeit. Oft besetzt mit einem erfahrenen Sicherheitsarchitekten mit Datenschutzhintergrund oder einem technisch weitergebildeten Datenschutzbeauftragten.
Betriebsrat: früh einbinden, nicht überrollen
Abschnitt betitelt „Betriebsrat: früh einbinden, nicht überrollen“In deutschen Organisationen hat der Betriebsrat ein Mitbestimmungsrecht bei Änderungen des Arbeitsplatzes, auch bei Änderungen der von Arbeitnehmern genutzten IT-Systeme (§ 87 Abs. 1 Nr. 6 BetrVG). Cloud-Transformation berührt diese Mitbestimmungsrechte in vielerlei Hinsicht.
| Bereich | Mitbestimmungsrelevanz | Empfehlung |
|---|---|---|
| Monitoring-Systeme (Observability) | Hoch — wenn Mitarbeiterverhalten messbar wird | Frühzeitige Information, klare Abgrenzung |
| Änderungen von Arbeitsabläufen | Mittel | Information vor Entscheidung |
| Neue Arbeitstools (Cloud-Konsole, IDEs) | Mittel | Betriebsvereinbarung bei substanziellen Änderungen |
| Rolleneliminierung oder -wechsel | Hoch | Qualifizierungsvereinbarung |
| Schichtarbeit / Rufbereitschaft | Hoch | Betriebsvereinbarung erforderlich |
Die goldene Regel: Den Betriebsrat vor der Entscheidung informieren — nicht danach. Vor vollendete Tatsachen gestellt zu werden, erzeugt Misstrauen und Widerstand. Wer ihn als Partner gewinnt, gewinnt einen Verbündeten.
Was der Betriebsrat typischerweise will:
- Sicherstellung, dass sich hinter der Transformation keine Redundanzentscheidungen verbergen
- Ein Qualifizierungscommitment mit konkreten Zusagen für Aus- und Umschulungen
- Transparenz über Monitoring und Datenschutz für Mitarbeitende
- Angemessene Vorankündigung vor Änderungen
Empfohlene Maßnahme: Vor der Verabschiedung der Cloud-Strategie lädt das Cloud Strategy Board den Betriebsratsvorsitzenden zum Informationsgespräch ein. Das Signal: „Wir nehmen Sie ernst.“
Qualifizierungsvereinbarung mit dem Betriebsrat
Abschnitt betitelt „Qualifizierungsvereinbarung mit dem Betriebsrat“In größeren Organisationen wird eine schriftliche Qualifizierungsvereinbarung empfohlen, die regelt:
- Welche Weiterbildungsangebote die Organisation für alle Mitarbeitenden bereitstellt
- Wie viel Arbeitszeit für Schulungen freigegeben wird
- Wie Mitarbeitende behandelt werden, wenn sie die Qualifizierung nicht erfolgreich abschließen
- Welche Rolle der Betriebsrat beim Monitoring des Qualifizierungsprogramms spielt
Praktische Schritte
Abschnitt betitelt „Praktische Schritte“- Rollenentwicklungslandkarte vervollständigen für alle IT-Rollen in Ihrer Organisation
- Einarbeitungsengagement formal kommunizieren (vor dem Betriebsrat)
- Informationsveranstaltung des Betriebsrats einberufen — vor dem Strategiebeschluss
- Qualifizierungsvereinbarung verhandeln mit dem Betriebsrat
- Rolle des Data Sovereignty Officers definieren und besetzen
Das 6-Track-Ausbildungsmodell
Rollenbasierter, kontinuierlicher Wissenstransfer entlang von sechs Ausbildungspfaden (von Cloud Awareness bis Security und FinOps).
Warum sechs Tracks statt ein Universalkurs
Abschnitt betitelt „Warum sechs Tracks statt ein Universalkurs“Cloud-Kompetenz ist keine einheitliche Größe. Ein CIO braucht strategisches Verständnis, kein Terraform-Wissen. Ein Platform Engineer braucht Terraform-Tiefe, keine FinOps-Details. Ein IT-Controller braucht Cloud-Economics-Know-how, kein Kubernetes-Wissen.
Sechs rollenspezifische Tracks stellen sicher, dass jede Person genau die Skills erhält, die sie für ihre Cloud-Aufgaben benötigt — nicht mehr und nicht weniger.
Track A — Cloud Awareness (alle Mitarbeitenden)
Abschnitt betitelt „Track A — Cloud Awareness (alle Mitarbeitenden)“Zielgruppe: 100 % der IT-Mitarbeitenden + relevante Sparten + Führungskräfte Dauer: 4 Stunden (verpflichtend, innerhalb von 6 Monaten nach Einführungsstart) Format: Interaktiver E-Learning-Kurs + optional Live-Q&A
Lernziele:
- Was ist Cloud? Was ist Sovereign Cloud?
- Was bedeutet STACKIT für unsere Organisation?
- Wie verändert sich meine Arbeit — und was bleibt?
- Warum setzen wir auf STACKIT statt auf US-Hyperscaler?
STACKIT-Relevanz: STACKIT University Track A deckt diese Themen mit STACKIT-spezifischem Kontext ab.
KPI: Abschlussquote Track A — Ziel: 100 % in 6 Monaten
Track B — Cloud Practitioner (IT-Generalisten)
Abschnitt betitelt „Track B — Cloud Practitioner (IT-Generalisten)“Zielgruppe: IT-Mitarbeitende ohne Cloud-Spezialisierung, Projektleiter, IT-Beschaffung Dauer: 12–16 Stunden Format: Blended Präsenz/Online + erste Sandbox-Übungen
Lernziele:
- Das STACKIT-Produktportfolio verstehen (Compute, Storage, SKS, Managed DB, Object Storage)
- Cloud-Kostenmodelle: Pay-as-you-go, Reserved Instances, Kostenoptimierung
- Sicherheitsgrundprinzipien: IAM, Least Privilege, Shared Responsibility
- Erste praktische Erfahrung: STACKIT Konsole, einfache Ressourcen erstellen
STACKIT-Relevanz: STACKIT University Track B + Hands-on Lab in der STACKIT Sandbox
Track C — Cloud Engineer (Platform Engineers, DevOps)
Abschnitt betitelt „Track C — Cloud Engineer (Platform Engineers, DevOps)“Zielgruppe: Platform Engineers, Sysadmins in Transition, DevOps Engineers Dauer: 40–80 Stunden Format: Fachlicher Intensivkurs + Projektpraxisaufgaben
Lernziele und -inhalte:
| Modul | Inhalt | Hands-on |
|---|---|---|
| IaC mit Terraform | Grundlagen Terraform, STACKIT Terraform Provider | Deploy VPC + VM |
| STACKIT SKS | Managed Kubernetes, Cluster erstellen, Workloads deployen | App auf SKS |
| Netzwerkkonfiguration | VPC, Subnetze, Firewallregeln, Hub-and-Spoke | Landing-Zone-Netzwerk |
| CI/CD-Integration | GitHub Actions / GitLab CI mit STACKIT | Pipeline aufbauen |
| Observability | STACKIT Observability, Logging, Alerting | Alarm konfigurieren |
| IAM in der Praxis | Service Accounts, Workload Identity, RBAC | IAM-Setup |
Track-C-Abschlussprojekt: Deployment eines kompletten Workloads (Webapplikation + Datenbank) auf STACKIT — mit Terraform, in SKS, mit CI/CD-Pipeline, mit Monitoring und Tagging.
STACKIT-Relevanz: STACKIT University Track C + CKA-Vorbereitung + Terraform-Associate-Vorbereitung
Track D — Cloud Architect (Enterprise Architects, Senior Engineers)
Abschnitt betitelt „Track D — Cloud Architect (Enterprise Architects, Senior Engineers)“Zielgruppe: Enterprise Architects, Senior Cloud Engineers, Technical Leads Dauer: 40+ Stunden Format: Workshop-Format + Architektur-Review-Fälle
Lernziele:
- Landing-Zone-Design: Hub-and-Spoke, Multiprojekt-Topologie, CIDR-Planung
- Hochverfügbare Architektur-Patterns auf STACKIT
- Migrationsarchitektur: 6R-Strategie (Rehost, Replatform, Refactor, Repurchase, Retain, Retire)
- Kostenoptimierungsarchitektur: Right-Sizing, Reserved Instances, Serverless Patterns
- Multi-Service-Design: wie Compute, Storage, Datenbank und Kubernetes zusammenarbeiten
Track E — Cloud Security (Sicherheitsteams)
Abschnitt betitelt „Track E — Cloud Security (Sicherheitsteams)“Zielgruppe: Security Analysts, CISO-Office, Compliance Manager Dauer: 30–50 Stunden Format: Fachkurs + Compliance-Mapping-Workshop
Lernziele:
- STACKIT IAM Deep-Dive: Federation, RBAC, Service Accounts, PAM
- Policy-as-Code: Terraform Sentinel, Open Policy Agent
- DevSecOps: Security Scanning in CI/CD-Pipelines
- Regulatory Compliance in der Cloud: DSGVO/TISAX/BAIT in der Praxis
- Cloud Incident Response: Forensik, Eindämmung, Wiederherstellung
STACKIT-Relevanz: STACKIT IAM Produktschulung + CCSP-Vorbereitung
Track F — Cloud FinOps (Controlling, IT-Management)
Abschnitt betitelt „Track F — Cloud FinOps (Controlling, IT-Management)“Zielgruppe: IT-Controller, CFO-Office, IT-Management Dauer: 16–24 Stunden Format: Business-orientiertes Seminar + Dashboard-Workshop
Lernziele:
- Cloud-Kostenmodelle: CAPEX vs. OPEX, Reserved vs. On-Demand
- Umsetzung der STACKIT Tagging-Strategie
- Erstellung und Interpretation von Showback-Berichten
- Aufbau von Chargeback-Modellen
- Verbesserung der Budgetsteuerung und Prognosegenauigkeit
STACKIT-Relevanz: STACKIT Billing Dashboard Workshop + FinOps Foundation Practitioner Vorbereitung
Timeline des Schulungs-Rollouts
Abschnitt betitelt „Timeline des Schulungs-Rollouts“| Monat | Aktivität |
|---|---|
| Monat 1 | Start von Track A für alle IT-Mitarbeitenden; Sandbox-Zugriff für technische Rollen |
| Monate 2–3 | Track C erste Kohorte (Platform Engineers + DevOps) |
| Monate 3–4 | Track B für IT-Generalisten; Track E erste Kohorte (Security) |
| Monate 4–6 | Track D für Architekten; Track F für das Controlling |
| Monate 6–12 | Weitere Kohorten, Cloud-Gilden aktiv, externe Zertifizierungen |
Häufige Fehler
Abschnitt betitelt „Häufige Fehler“One-size-fits-all: Ein allgemeiner Cloud-Kurs für alle ist Zeitverschwendung.
Schulung ohne Anwendung: Track C ohne unmittelbar anschließendes Praxisprojekt in der Sandbox verdunstet innerhalb von 2 Wochen.
Schulungen unter Zeitdruck: Die Anweisung an Teams, Schulungen bei 100 % Produktionsauslastung durchzuführen, führt zuverlässig dazu, dass Schulungen nicht stattfinden.