Cloud operating models: assign the work that remains after migration

The migration project closes, but the application team still cannot get a shared network change approved. Finance receives a larger bill without knowing who can alter the consumption. During an outage, everyone knows their component and nobody knows who leads restoration.

These are operating-model failures. For an infrastructure director, moving the workload is only part of the transformation. The enduring job is to make responsibility, authority and support usable after the project team has moved on.

Managed services change the work rather than eliminate it

AWS distinguishes customer responsibilities by service: EC2 customers manage guest operating systems and applications, while abstracted services such as S3 leave a different set of data and permission responsibilities. “The cloud team owns it” is therefore too coarse a statement for an operating agreement.

Map the retained work to the actual service design. An application team may own behaviour and business restoration while a platform team owns shared foundations. Security can define policy and advise on exceptions without becoming the default operator of every control.

Do the same for suppliers and managed service providers. A support contract may supply expertise or response capacity; it does not automatically assign internal authority to accept an outage risk, change a business target or approve expenditure.

Make the platform offer legible to its users

A shared platform is easier to adopt when product teams understand what it provides and what remains theirs. Describe the supported patterns, response expectations, change route and limits in language a delivery team can use.

Then measure the complete request journey. If an advertised self-service environment still needs three private approvals, the platform has not removed the waiting time. That is an operating design issue the infrastructure director can address, not a reason to add another portal.

Distinguish the provider boundary from the internal one

A provider contract and service documentation help establish what the supplier operates. Your internal model must establish who handles everything the organisation still needs to decide. Do not assume that buying a managed service appoints an internal service owner or settles how teams share responsibilities.

For each workload, name the business owner, the team operating the application and the team responsible for shared platform capabilities. One person may hold several roles in a smaller organisation. The important part is that approval, execution and escalation are explicit.

Start with decisions that cross team boundaries

The NCSC cloud security principles provide a structured set of assurance questions, including identity, administration, operational security and audit information. They help a buyer examine the service, but the organisation must still decide who requests the evidence and acts on any gap.

We suggest building the operating model around recurring decisions rather than beginning with an organisation chart. Consider how a team launches a service, changes privileged access, responds to an incident, accepts a security exception and commits to a recurring cost.

Avoid the two easy extremes

A central team that must approve every small change can become a queue that product teams work around. Fully delegated operation can leave shared controls and dependencies without coherent ownership. Neither arrangement is automatically wrong; the choice depends on capability, risk and the services involved.

A practical middle ground is to define approved patterns for common work and a clear route for exceptions. Give workload teams room to operate within those patterns. Keep responsibility for shared foundations explicit, and make the support offer understandable: what the platform team provides, what it does not and how changes are requested.

For each approved pattern, specify which changes a workload team can make independently and which need platform support. The exception route should explain who decides, what information they need and how the requester gets an answer. That is the practical difference between delegated authority and an informal workaround.

Test it with three short scenarios

First, ask a team to explain how it would launch a workload using an unfamiliar managed service. Second, assume a shared dependency fails outside office hours. Third, introduce a sudden cost increase caused by legitimate growth. Follow each scenario until a named person makes the necessary decision.

In a hypothetical outage, the application team may own business restoration while the platform team diagnoses a shared network problem. The supplier may need to investigate its service, but the internal incident lead still needs an escalation route and a way to update the business. Write down that handover before relying on it.

Look for statements such as “security will decide” or “the cloud team owns that” without a named role and response expectation. They are signs that the operating model still contains an assumption.

Keep the agreement current

Review responsibility boundaries when teams, contracts or shared services change. Use incident reviews and delayed changes as evidence of where the agreement is unclear. A short operating model that teams actually use is more valuable than a comprehensive responsibility matrix that no longer describes how work gets done.

Use a service catalogue responders can trust to make the agreement usable. A cloud operating model is credible when the next incident, cost increase or unfamiliar workload reaches a person who has both the context and authority to act.