Target Operating Model & Collaborative Empowerment
Last updated on
Target Operating Model & Collaborative Empowerment
People, not technology, determine transformation success: a federated operating model, a CCoE and works council partnership, and systematic upskilling.
CCoE Structure, Roles & Platform Setup
Build the cloud organization with a clear functional separation between governance in the CCoE and technical platform operations in the platform team.
Two functions, one organisation: CCoE and Platform Team
Section titled “Two functions, one organisation: CCoE and Platform Team”Before the role model is discussed, a structural fundamental decision is needed — one that in practice is often conflated: a Cloud Team consists of two functionally separate areas that do different things and require different competencies.
The Cloud Centre of Excellence (CCoE) defines what applies. It is responsible for governance, policies, standards, the service catalogue, and supporting application teams through consulting and enablement. It answers the question: “What must and may cloud environments look like?” The CCoE is the guardian of the framework.
The Cloud Platform Team implements how. It builds and operates the technical platform: Landing Zone, network infrastructure, automation, self-service platforms, monitoring of platform components. It translates the CCoE’s requirements into technical reality.
Both functions can be performed by the same people in smaller organisations — but the separation of responsibilities must remain explicit. Without this separation, governance decisions get silently replaced by implementation decisions, or governance documents that nobody implements.
In the role model below, roles are assigned accordingly: CCoE Lead, Cloud Architect, Security Engineer, and Enablement Specialist belong primarily to the CCoE. Platform Engineer and Operations Engineer belong primarily to the Platform Team. FinOps Analyst works closely with both.
The 7-role model
Section titled “The 7-role model”A fully staffed CCoE covers seven core roles. In smaller organisations, roles can be combined — but the function must be covered, even if one person takes on several.
| Role | Core responsibility | FTE (mid-sized organisation) |
|---|---|---|
| CCoE Lead | Strategy, stakeholder management, roadmap | 1.0 |
| Cloud Architect | Reference architectures, design decisions, landing zone | 1.0–2.0 |
| Platform Engineer | IaC module library, CI/CD templates, landing zone operations | 1.0–2.0 |
| Cloud Security Engineer | IAM governance, policy-as-code, DevSecOps | 1.0 |
| FinOps Analyst | Cost optimisation, tagging, showback/chargeback | 0.5–1.0 |
| Cloud Enablement Specialist | Training programme, Communities of Practice, Cloud Champions | 0.5–1.0 |
| Operations Engineer (SRE) | Observability, incident response, runbooks | 0.5–1.0 |
Minimum staffing to start transformation: 4–5 FTE (CCoE Lead + Architect + Platform Engineer + Security + FinOps/Enablement combined). With fewer than 4 FTE, a structural bottleneck emerges immediately.
Role profile: CCoE Lead
Section titled “Role profile: CCoE Lead”Profile: Experienced IT leader with cloud understanding and strong stakeholder management capability. Must be able to conduct CIO-level strategic conversations and coordinate technical teams simultaneously.
Responsibilities:
- Programme ownership of the cloud transformation
- Reporting line: CIO (direct)
- Preparation and facilitation of the Cloud Strategy Board
- Escalation point for cross-team blocking issues
- KPI reporting and transformation progress
Common hiring mistakes:
- Purely technical profile without leadership experience: leads to absent stakeholder engagement
- Pure leadership profile without cloud understanding: loses credibility with the technical team
- Internal promotion without cloud background: risky when cloud knowledge must be built at the same time
Role profile: Cloud Architect
Section titled “Role profile: Cloud Architect”Profile: Senior engineer with deep platform understanding. Knows STACKIT architecture principles, networking, security architecture, and migration architecture patterns.
Responsibilities:
- Reference architectures for recurring workload types (web apps, databases, batch jobs, streaming)
- Technical consulting for workload teams during design
- Landing zone architecture and continued development
- Architecture Decision Records (ADRs) for platform-relevant decisions
Role profile: Platform Engineer
Section titled “Role profile: Platform Engineer”Profile: Hands-on IaC expert. Writes Terraform modules, builds CI/CD templates, operates the landing zone daily.
Responsibilities:
- IaC module library (paved roads for standard resources)
- CI/CD pipeline templates for workload teams
- Landing zone operations and updates
- Guardrail implementation and testing
Example output: A Terraform module for a standard STACKIT SKE cluster configuration that any workload team can use without needing to understand the networking and security details themselves.
Role profile: Cloud Security Engineer
Section titled “Role profile: Cloud Security Engineer”Profile: Security specialist with cloud background. Understands IAM, policy-as-code, DevSecOps, and the regulatory requirements of the organisation.
Responsibilities:
- IAM governance: role concept, service account standards, PAM implementation
- Policy-as-code: Terraform Sentinel or OPA for automated guardrails
- Security scanning integration into CI/CD pipelines
- Regulatory compliance mapping (GDPR, TISAX, BAIT, etc.)
- Incident response for security incidents in the cloud
Role profile: FinOps Analyst
Section titled “Role profile: FinOps Analyst”Profile: IT controller or finance professional with cloud cost model understanding. Understands both finance requirements and technical cost optimisation levers.
Responsibilities:
- Monitor and escalate tagging compliance
- Create monthly showback reports
- Identify optimisation potential (idle resources, right-sizing)
- Configure budget alerts and anomaly detection
- Develop FinOps maturity along Inform → Optimise → Operate
Staffing strategies
Section titled “Staffing strategies”Strategy 1: Internal redeployment Suitable internal employees are released for CCoE roles. Advantage: organisational context already known, no onboarding. Risk: cloud competency must be built up, can be slower.
Strategy 2: External recruitment Cloud experts are newly hired. Advantage: competency immediately available. Risk: onboarding takes time, market for cloud talent is competitive.
Strategy 3: Hybrid (recommended) CCoE core of 1–2 internal leaders + 2–3 external cloud specialists. Internal: organisational context and stakeholder relationships. External: technical cloud depth and transformation experience. After 12 months: knowledge transfer, more internal people.
Strategy 4: Partner-supported start Begin with a STACKIT partner or system integrator who temporarily covers CCoE roles while internal capacity is being built. More cost-intensive but faster to operational readiness.
Common mistakes
Section titled “Common mistakes”Staffing too late: CCoE build-up begins while migration teams are already starting. Result: no standards for early workloads, later remediation required.
Wrong profile for CCoE Lead: Purely technical profiles without business stakeholder capability cannot conduct strategic dialogue with CIO and CFO.
FinOps too small: 0.2 FTE for FinOps is not enough. Cost optimisation is not a part-time task — it can deliver significant cloud budget savings when taken seriously.
Practical steps
Section titled “Practical steps”- Role inventory: Which of the 7 roles can be filled internally? Which must be filled externally?
- Release plan: Clarify with department heads who can be released for CCoE roles
- Create role profiles and start the HR process for external recruitment
- Partner assessment: Which STACKIT partners can temporarily cover CCoE roles?
CCoE Mandate & Charter
Draft a formal CCoE charter with clear decision matrices and a direct escalation path to the CIO.
Why a written charter?
Section titled “Why a written charter?”A charter is not a bureaucratic document — it is the formal mandate without which the CCoE has no authority to enforce standards, make decisions or demand resources.
Without a charter: the CCoE recommends, but teams do not follow, because no obligation exists. The CCoE escalates, but the escalation path is unclear. The CCoE blocks deployments, but business units go around it directly to the CIO.
With a charter: the rules of engagement are clear before the conflict arises.
CCoE Charter Template
Section titled “CCoE Charter Template”CLOUD CENTRE OF EXCELLENCE — CHARTER
Section titled “CLOUD CENTRE OF EXCELLENCE — CHARTER”Version: 1.0 Date: [Date] Approved by: [Name], CIO / Cloud Strategy Board Effective from: [Date]
1. Mission
Section titled “1. Mission”The Cloud Centre of Excellence enables [Company] to use cloud technology securely, cost-efficiently and with full sovereignty. It is the central competence and governance authority for all cloud activities and bears responsibility for standards, enablement and transformation progress.
2. Scope
Section titled “2. Scope”This charter applies to:
- All cloud resources on [STACKIT / other platforms]
- All teams and projects using or planning to use cloud infrastructure
- All cloud infrastructure expenditure regardless of cost centre or business unit
3. Mandate and Authorities
Section titled “3. Mandate and Authorities”The CCoE is authorised to:
Set and enforce standards:
- Define cloud architecture standards, naming conventions and tagging standards as binding requirements
- Implement guardrail policies as code and cover all environments
- Conduct compliance reviews for new workloads before production deployment
Decision mandate:
- Technical architecture decisions with platform-wide impact (< [TEUR X] budget impact)
- Workload prioritisation for migration waves
- Onboarding approval for new teams to the cloud platform
- Exceptions to guardrail standards (documentation required)
Escalation right:
- The CCoE may block deployments that violate standards
- The CCoE may escalate to the CIO when teams do not comply with mandates
4. Decision Matrix
Section titled “4. Decision Matrix”| Decision type | CCoE decides | CCoE recommends | Cloud Strategy Board |
|---|---|---|---|
| Technical architecture standards | ✓ | ||
| Workload migration prioritisation | ✓ | ||
| Guardrail exceptions (< 30 days) | ✓ | ||
| Guardrail exceptions (> 30 days) | ✓ | Decides | |
| Provider decisions | ✓ | Decides | |
| Budget > [TEUR Y] | ✓ | Decides | |
| CCoE team personnel decisions | ✓ | Decides |
5. Non-mandate: what the CCoE does not do
Section titled “5. Non-mandate: what the CCoE does not do”The CCoE is not a gatekeeper for daily deployments. The following lies within workload team responsibility:
- Deployment decisions within CCoE standards
- Workload-specific architecture decisions (not platform-wide)
- Operation of own workloads in accordance with CCoE standards
6. Reporting line and governance
Section titled “6. Reporting line and governance”- Reporting line: CCoE Lead reports directly to CIO
- Quarterly report: Quarterly executive summary to Cloud Strategy Board (KPIs, risks, recommendations)
- Monthly status meeting: CCoE Lead + CIO, 30 minutes
- Annual charter review: Charter reviewed annually and adjusted as necessary
7. Resource commitment
Section titled “7. Resource commitment”The organisation commits for the CCoE:
- [N] FTE internal resources (by name or role)
- [TEUR X] annual budget for external support, tools, training
- C-level sponsor availability for escalations
8. Success measurement
Section titled “8. Success measurement”The CCoE is measured quarterly on the following KPIs:
- Guardrail compliance rate (target: >99 %)
- Cloud costs vs. budget (target: ±10 %)
- Migration throughput (target: [N] workloads/quarter)
- Team training completion rate (target: >80 % within 12 months)
- Incident mean time to recovery (target: <30 minutes)
9. Duration and revision
Section titled “9. Duration and revision”This charter is open-ended. It is reviewed annually by the Cloud Strategy Board. Material changes to the mandate require CIO approval.
Signatures:
| Role | Name | Date |
|---|---|---|
| CIO | ||
| CTO | ||
| CFO | ||
| CISO | ||
| CCoE Lead |
Charter introduction: communicating to the organisation
Section titled “Charter introduction: communicating to the organisation”The charter signing is a formal event — and should be communicated as such:
- All-hands communication by CIO: what the CCoE is, what it means for teams, who works in the CCoE
- Department head briefing: specifically on the decision mandate — what the CCoE decides, what teams can decide independently
- Intranet publication: charter accessible to everyone
The Federated Operating Model
Scale by the guiding principle of deciding centrally and executing locally, for maximum agility of product teams within safe boundaries.
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?
Role Evolution & Works Council Partnership
Proactively involve the works council under Section 87 of the German Works Constitution Act, conclude qualification agreements, and support employees through role change.
The role evolution map
Section titled “The role evolution map”The most common fear in cloud transformations: “My position will disappear.” The right response is not reassurance — it is a concrete map that shows where the journey leads.
| Current role | Cloud equivalent | New focus | Training track |
|---|---|---|---|
| System Administrator | Platform/Cloud Engineer | IaC, managed services, automation | Track C |
| DBA | Managed Database Specialist | Database-as-a-Service, performance optimisation | Track C + D |
| Network Engineer | 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 economics, tagging, chargeback management | Track F |
| IT Operations | Site Reliability Engineer (SRE) | Observability, incident response, runbooks | Track C |
| Enterprise Architect | Cloud Solution Architect | Cloud-native patterns, multi-service design | Track D |
| Project Manager | Cloud Product Manager / Scrum Master | Agile delivery, team coordination | Track A + B |
Core message: Cloud transformation does not eliminate IT roles — it evolves them towards higher-value work. Manual configuration management (low value) is replaced by IaC authorship (higher value).
Data Sovereignty Officer: an emerging role
Section titled “Data Sovereignty Officer: an emerging role”As DACH organisations operationalize their sovereign cloud strategies, a new functional role is emerging. In some organisations it sits with the CISO, in others with the Data Protection Officer; in regulated industries it often becomes a standalone function.
Responsibilities of the Data Sovereignty Officer:
- Maintaining workload classification (sovereignty levels 1/2/3)
- Reviewing new architecture proposals for sovereignty implications
- Liaison with the Data Protection Officer on cloud data residency questions
- Maintaining the sovereignty matrix (living document)
- Communicating with customers and partners about sovereignty evidence
Profile: A combination of technical cloud understanding, data protection law knowledge and communication capability. Often filled by: an experienced security architect with a data protection background, or a Data Protection Officer with technical further training.
Works council: engage early, do not steamroller
Section titled “Works council: engage early, do not steamroller”In German organisations, the works council (Betriebsrat) has co-determination rights regarding workplace changes, including changes to IT systems used by employees (§ 87 Para. 1 No. 6 BetrVG). Cloud transformation touches on these co-determination rights in many respects.
What co-determination means in cloud transformation:
| Area | Co-determination relevance | Recommendation |
|---|---|---|
| Monitoring systems (Observability) | High — if employee behaviour becomes measurable | Early information, clear demarcation |
| Changes to working processes | Medium | Information before decision |
| New work tools (cloud console, IDEs) | Medium | Works agreement for substantial changes |
| Role elimination or change | High | Qualification agreement |
| Shift work / on-call | High | Works agreement required |
The golden rule: Inform the works council before decisions are made — not after. Confronting the works council with a fait accompli creates distrust and resistance. Engaging them as a partner wins a transformation ally.
What the works council typically wants:
- Assurance that no redundancy decisions are hidden behind the transformation
- A qualification commitment — concrete promises for training and retraining
- Transparency about monitoring and data protection for employees
- Adequate advance notice before changes
Recommended measure: The Cloud Strategy Board invites the works council chair to an information meeting before the cloud strategy is adopted. The signal: “We take you seriously.”
Qualification agreement with the works council
Section titled “Qualification agreement with the works council”In larger organisations, a written qualification agreement is recommended that governs:
- Which training offerings the organisation provides for all employees
- How much working time is released for training
- How employees are treated if they do not successfully complete the qualification
- What role the works council plays in monitoring the qualification programme
Practical steps
Section titled “Practical steps”- Complete the role evolution map for all IT roles in your organisation
- Formally communicate the training commitment (before the works council)
- Convene the works council information meeting — before the strategy resolution
- Negotiate a qualification agreement with the works council
- Define and staff the Data Sovereignty Officer role
The Six-Track Training Model & Cloud Empowerment
Deliver role-based, continuous knowledge transfer along six training tracks, from cloud awareness to security and FinOps.
Why six tracks instead of one universal course
Section titled “Why six tracks instead of one universal course”Cloud competency is not a uniform quantity. A CIO needs strategic understanding, not Terraform knowledge. A platform engineer needs Terraform depth, not FinOps details. An IT controller needs cloud economics expertise, not Kubernetes knowledge.
Six role-specific tracks ensure that each person receives exactly the skills they need for their cloud responsibilities — no more, no less.
Track A — Cloud Awareness (All staff)
Section titled “Track A — Cloud Awareness (All staff)”Target group: 100% of IT staff + relevant business units + management Duration: 4 hours (mandatory, within 6 months of adoption start) Format: Interactive e-learning course + optional live Q&A
Learning objectives:
- What is cloud? What is sovereign cloud?
- What does STACKIT mean for our organisation?
- How does my work change — and what stays the same?
- Why are we choosing STACKIT instead of US Hyperscalers?
STACKIT relevance: STACKIT University Track A covers these topics with STACKIT-specific context.
KPI: Track A completion rate — target: 100% within 6 months
Track B — Cloud Practitioner (IT generalists)
Section titled “Track B — Cloud Practitioner (IT generalists)”Target group: IT staff without cloud specialisation, project managers, IT procurement Duration: 12–16 hours Format: Blended in-person/online course + first sandbox exercises
Learning objectives:
- Understand the STACKIT product portfolio (Compute, Storage, SKS, Managed DB, Object Storage)
- Cloud cost models: pay-as-you-go, reserved instances, cost optimisation
- Basic security principles: IAM, least privilege, shared responsibility
- First hands-on experience: STACKIT console, creating simple resources
STACKIT relevance: STACKIT University Track B + hands-on lab in STACKIT sandbox
Track C — Cloud Engineer (Platform engineers, DevOps)
Section titled “Track C — Cloud Engineer (Platform engineers, DevOps)”Target group: Platform engineers, sysadmins in transition, DevOps engineers Duration: 40–80 hours Format: Technical intensive course + project practical tasks
Learning objectives and content:
| Module | Content | Hands-on |
|---|---|---|
| IaC with Terraform | Terraform fundamentals, STACKIT Terraform Provider | Deploy VPC + VM |
| STACKIT SKS | Managed Kubernetes, create clusters, deploy workloads | App on SKS |
| Network configuration | VPC, subnets, firewall rules, hub-and-spoke | Landing zone network |
| CI/CD integration | GitHub Actions / GitLab CI with STACKIT | Build a pipeline |
| Observability | STACKIT Observability, logging, alerting | Configure an alert |
| IAM in practice | Service accounts, workload identity, RBAC | IAM setup |
Track C final project: Deploy a complete workload (web application + database) on STACKIT — with Terraform, in SKS, with CI/CD pipeline, with monitoring and tagging.
STACKIT relevance: STACKIT University Track C + CKA preparation + Terraform Associate preparation
Track D — Cloud Architect (Enterprise architects, senior engineers)
Section titled “Track D — Cloud Architect (Enterprise architects, senior engineers)”Target group: Enterprise architects, senior cloud engineers, technical leads Duration: 40+ hours Format: Workshop format + architecture review cases
Learning objectives:
- Landing zone design: hub-and-spoke, multi-project topology, CIDR planning
- High-availability architecture patterns on STACKIT
- Migration architecture: 6R strategy (Rehost, Replatform, Refactor, Repurchase, Retain, Retire)
- Cost optimisation architecture: right-sizing, reserved instances, serverless patterns
- Multi-service design: how compute, storage, database and Kubernetes work together
Track E — Cloud Security (Security teams)
Section titled “Track E — Cloud Security (Security teams)”Target group: Security analysts, CISO office, compliance managers Duration: 30–50 hours Format: Technical course + compliance mapping workshop
Learning objectives:
- 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 the cloud: GDPR/TISAX/BAIT in practice
- Cloud incident response: forensics, containment, recovery
STACKIT relevance: STACKIT IAM product training + CCSP preparation
Track F — Cloud FinOps (Controlling, IT management)
Section titled “Track F — Cloud FinOps (Controlling, IT management)”Target group: IT controllers, CFO office, IT management Duration: 16–24 hours Format: Business-oriented seminar + dashboard workshop
Learning objectives:
- Cloud cost models: CAPEX vs OPEX, reserved vs on-demand
- Implementing STACKIT tagging strategy
- Creating and interpreting showback reports
- Building chargeback models
- Improving budget management and forecast accuracy
STACKIT relevance: STACKIT Billing Dashboard Workshop + FinOps Foundation Practitioner preparation
Training rollout timeline
Section titled “Training rollout timeline”| Month | Activity |
|---|---|
| Month 1 | Launch Track A for all IT staff; sandbox access for technical roles |
| Months 2–3 | Track C first cohort (platform engineers + DevOps) |
| Months 3–4 | Track B for IT generalists; Track E first cohort (security) |
| Months 4–6 | Track D for architects; Track F for controlling |
| Months 6–12 | Further cohorts, cloud guilds active, external certifications |
Common mistakes
Section titled “Common mistakes”One-size-fits-all: A general cloud course for everyone wastes time.
Training without application: Track C without an immediately following practical project in the sandbox evaporates within 2 weeks.
Training under time pressure: Instructing teams to complete training while maintaining 100% production load reliably results in training not happening.
Trail historyAdded Sep 10, 2026?UpdatedNo updates · 1 bar = 1 week i
- ?Name not public?Name not publicThe Cloud Framework team knows who this is. The name is not shown on the site.