Cloud Operating Model
Definition
Cloud Operating Model
A cloud operating model sets out who runs a cloud estate once the workloads are live: which teams exist, which roles they hold, and who is accountable for each decision. It answers who runs this now rather than what the platform will cost.
That distinction gets lost more often than you would expect. Cloud cost optimization asks what the running bill should be. An operating model asks who holds the authority to change it.
The model is an organisational design — not a technical one. It names humans, reporting lines and approval rights, then attaches each of them to a part of the platform.
Microsoft makes the same point in its Azure guidance, which says successful cloud adoption requires more than technical readiness and depends on an adoption plan built around the organisation.
Key takeaways
- A cloud operating model answers who runs the estate now, which is a different question from what the estate costs.
- It is an organisational design: teams, roles, approval rights and accountability, mapped onto a live platform.
- Most large estates land on a central platform team plus embedded engineers, a shape borrowed from centre of excellence thinking.
- Where a provider holds part of the model, accountability lives in contract clauses rather than in job descriptions.
How it works
An operating model turns a list of platform duties into named owners. Somebody approves new environments, somebody carries the pager, and somebody signs off a spend increase. The model writes those names down before the questions arrive.
A cloud operating model is a narrowed version of the business operating model, applied to one platform instead of the whole firm.
Most large estates settle on a central platform team with engineers embedded in delivery squads. That shape comes straight out of the centre of excellence models used elsewhere in the business.
The people doing the daily work are usually cloud engineers, sitting either in-house, with a provider, or across both.
Three shapes turn up most often: one fully central team, a federated model with a small core, or a devolved one where every squad runs its own platform. The middle option is the usual landing point.
Accountability is not the same as capacity. A model can name an owner for every duty and still fail, because the named owner already has a day job that fills the whole week.
The test of any model is whether it answers a short list of awkward questions.
| Question the model answers | Where it usually lands |
|---|---|
| Who approves a new environment? | central platform team |
| Who carries the pager at 2am? | on-call engineering rota |
| Who owns the security baseline? | a named security function |
| Who signs off a spend increase? | finance partner or product owner |
| Who decides what gets decommissioned? | the application owner |
When a provider holds part of the model, the accountability sits in a service level agreement clause rather than in a job description. That is a real difference — and it changes how escalation works.
Managing the split between internal teams and providers is vendor management work. It needs a named owner inside the model, not a shared inbox.
Models age badly when nobody revisits them. A shape that suited twelve workloads rarely suits ninety, so the sensible practice is an annual read-through against the current estate.
Write the model down, even if it runs to a single page. An undocumented operating model is really just whoever happened to answer the phone last time something broke.
Examples
Operating models are usually internal documents, but a few public bodies publish theirs. The clearest example sits inside the United States federal government, where a central team was set up specifically to run cloud work for other agencies.
The General Services Administration (GSA) runs a Cloud Adoption Center of Excellence, which describes its job as helping agencies select and design the right migration path. Its service offerings include cloud governance and acquisition support.
That centre published a GAO Covid-19 vaccine tracker dashboard on 6 October 2021 — a concrete output from a central team model rather than a policy document.
Microsoft’s Azure guidance is the vendor example. It frames organisational readiness as a prerequisite, not a follow-up, which is the same claim in different words.
In the BPO sector, the model often splits by layer. A provider runs the platform and the on-call rota — the client keeps application ownership and spend approval.
A mid-sized firm handing its platform to a managed-services provider still needs an internal owner. Somebody has to accept or reject the provider’s change requests, and that somebody belongs in the model.
Public sector bodies tend to publish more of this than private firms do, largely because procurement rules force the roles into writing before any contract is signed.
Smaller firms usually run a single team with no separation at all. That works until the first outage during a holiday week, at which point the rota becomes a written document.
Related terms
These five terms describe the pieces an operating model assembles. Two cover the organisational shapes it borrows, two cover how the work is coordinated and contracted, and one names the role doing the daily work.
- Automation Center Of Excellence: the central team pattern applied to automation rather than cloud.
- Agile Portfolio Management: the coordination layer that decides which teams work on what next.
- Business Operating Model: the firm-wide version of the same design, covering every function.
- Centers Of Excellence Models: the central-team shapes that most cloud models are built from.
- Cloud Engineer: the role that does the daily build, patch and on-call work.
FAQ
What is the difference between a cloud operating model and a cloud strategy?
The strategy says what you are trying to achieve and the operating model says who runs it afterwards. One is written before the move, the other governs life after it.
When should we design the operating model?
Before the first production workload lands, and then review it yearly. Designing it after an outage is the expensive version of the same exercise, and the version nobody enjoys.
Does a cloud operating model cover cost?
It covers who approves and who is accountable for spend, but not what the spend should be. The size of the bill is the cost optimization question.
Can a provider run our whole cloud operating model?
A provider can run most of the platform duties, but approval rights over spend and data usually stay with the client. Contracts split it explicitly for that reason.
How many people does a cloud operating model need?
Fewer than most teams expect, since the model defines accountability rather than headcount.
Providers building cloud delivery teams can compare capability across the Outsource Accelerator hubs.
Independent
