Skip to content
Beta

Adapting Operating Models

The technology is deployed. Now the real transformation begins: how teams work, who is responsible for what — and how to move from 'we operate IT' to 'we deliver value'.

In 1 trail

Cloud technology does not automatically change how your organisation develops and operates software. Many organisations have the same long deployment cycles after migration, the same silos between development and operations, the same manual processes — just now in the cloud.

This chapter addresses the organisational changes that make cloud effective: how teams are structured, how responsibility is distributed, how change management and incident response are adapted to cloud speed — and how to measure whether the transformation has actually taken place.

Restructure teams

The model of stream-aligned teams with genuine operational responsibility — and how a platform engineering team enables all others without becoming a bottleneck.

Infrastructure as Code

Why clicking in the console must no longer be the standard — and how Infrastructure as Code delivers reproducibility, security and speed simultaneously.

Adapt ITIL to cloud speed

Which change management processes must work differently in the cloud — and how to define Standard Changes so that compliance and agility are not opposites.

Measure success

The four DORA metrics as an objective measure of delivery performance — with benchmarks and a realistic improvement roadmap.

Operating Model Overview

When the operating model is not transformed

Section titled “When the operating model is not transformed”

A financial services provider migrated 40 workloads to STACKIT in eight months. Technically a success. Organisationally a sobering experience.

Deployment cycles: still six weeks. Not because the technology was too slow — but because the change management process continued to route every patch through a three-person CAB committee.

Manual configuration: still via the console. Not because no IaC tool was available — but because nobody had learned to use it, and nobody was given the time.

Costs: 60 % higher than budgeted. Not because STACKIT is expensive — but because no team took ownership of its cloud cost share.

EUR 420,000 in annual additional costs. The migration had succeeded. The transformation had failed.

Organisational workforce transition: the forgotten task

Section titled “Organisational workforce transition: the forgotten task”

Cloud transformation creates new roles and changes existing ones. System administrators become platform engineers. Infrastructure teams become DevOps teams. Some roles that exist today will no longer be needed in three years — at least not in their current form.

Communicating this reality openly and actively shaping it — with clear qualification paths, fair transition processes, and the works council as a partner — is not only morally required. It is strategically necessary. Anyone who does not have these conversations will lose exactly the people who are most urgently needed for the transformation.

The DevOps & YBIYRI chapter addresses this with concrete team topologies and role transitions.

Adapting operating models presupposes Cloud Empowerment — teams need the capability to practise new ways of working.

  1. Clarify team structure with DevOps & YBIYRI — before technical details are decided.
  2. Introduce Infrastructure as Code as the standard — not as an option.
  3. Automate delivery with CI/CD pipelines — bound to compliance gates.
  4. Adapt ITIL to cloud reality — without abandoning compliance.
  5. Measure progress with DORA Metrics — objectively and regularly.