There's one place where the lack of a shared Operating Model hurts especially badly: the split between ITSM and Cloud Management.
Tickets, SLAs, incidents, changes, CABs and SMOs.
Landing zones, policies, cloud platforms and security controls.
If those two run on different maps, you don't just have a tooling problem. You have two competing versions of how IT works.
Most mid‑ to large‑size organisations have backed into hybrid and multicloud landscapes: on‑prem data centres, one or more public clouds, a growing SaaS estate, maybe some OT and edge thrown in for fun.
To cope, they tend to create:
- An ITSM "Operating Model" around the ITSM tool and traditional processes.
- A cloud Operating Model or cloud governance framework around the cloud platforms.
On paper this looks tidy. In reality, you end up with two universes:
- Platform engineering
- Guardrails & identity
- Network & templates
- Cost controls
- Incidents & changes
- Requests & service catalogue
- SLAs
Each side has its own language and KPIs, boards and decision forums, data models and dashboards. The same outage might be described as:
A P1 incident
A failed deployment
A misconfigured network rule
A "policy violation"
None of those are wrong – but they're not the same story. What I consistently see in organisations is two perfectly reasonable operating logics that never really meet: the cloud team optimising for speed and guardrails, and the ITSM team optimising for stability and control. Without a shared operating model, each side thinks the other "doesn't get it" – and they're both right.
The board does not care whether an outage came from a cloud misconfiguration, an on‑prem storage issue or a SaaS identity problem. They care that "Online banking" or "Citizen self‑service portal" was down, for how long, and what is being done to reduce the risk next time.
Regulators under NIS2 and similar administrations do not ask for separate ITSM and cloud reports. They ask for:
In other words: one story about how you operate, not two or three.
So what does "one map" actually mean? It does not mean pretending cloud and on‑prem are the same. They aren't. It means defining an IT Operating model that is technology‑agnostic at the top:
What the organisation actually delivers and relies on.
Who owns what, who decides what, who provides data.
Risks, incidents, changes, assets, controls, costs.
Which forums make which decisions, on what information.
Under that shared model, you can have different technical patterns for on‑prem, IaaS, PaaS, SaaS, OT, etc., different automation and tooling stacks, and different provider responsibilities under the shared responsibility model. But they all plug into the same service, role and governance structure.
This is also where a hybrid multicloud Operating Model becomes more than an infrastructure idea. When done well, it's a way of managing multiple environments as a single, adaptable ecosystem, with consistent policies, visibility and operating routines across them.
Andrew Campbell's Operating Model Canvas is particularly handy in this ITSM/cloud conversation, because it forces everyone to draw the same boxes.
For a critical service – say, "Digital citizen portal" or "Global order management" – you can literally stand at a board and fill in:
Incident to resolution, change to deploy, request to fulfilment, "threat detected to risk mitigated".
Product owner, service owner, platform team(s), CCoE, security, operations teams.
On‑prem DC, Azure landing zones, SaaS platforms, OT sites, CMDB/CMDB‑lite,
Observability tools, risk register, cost data, contracts, org. data.
Cloud provider(s), network providers, SaaS vendors, managed service partners.
CAB / change forum, risk committee, cloud governance board, NIS2 incident review, service review.
Suddenly the cloud governance board and the CAB are not two mysterious entities. They are just different parts of the same management system box for that service. The beauty of doing this visually is that it becomes painfully obvious where things are duplicated or missing:
- Two forums making similar decisions on different data.
- A risk that nobody really owns.
- A supplier whose responsibilities don't match the way incidents actually flow.
- A cloud control that exists in policy but not in the ITSM side of change or incident handling.
Once you see that on one canvas, you can have a much more honest conversation about design instead of personalities.
USM then gives you the management system language to run across both ITSM and cloud. Remember the layering from Part 2:
Detailed practices and implementations
Management system – how we manage services, incidents, changes, requests and risks consistently
Structure – how IT works here
When you treat cloud routines – e.g. "policy change", "landing zone change", "security control exception", "FinOps review" – as just more USM activities on the same Management System, a few things happen:
Your incident, request and change handling extend naturally into cloud and SaaS instead of living in a separate world.
Your NIS2‑relevant activities (risk management, incident reporting, supplier oversight) sit inside the same management system design instead of being bolted on by the security team.
Your ITSM and cloud tools become windows into the same Operating Model, rather than parallel universes.
Here's a practical test you can apply tomorrow. Think of one business‑critical, potentially NIS2‑relevant service. Then ask:
Can we, on one page, show how incidents, changes and risks for this service flow across on‑prem, cloud and SaaS – including who owns what and which forums decide what?
Would our ITSM leader, our CCoE lead and our CISO all recognise that one‑pager as "how it actually works here"?
Could we, in front of a regulator or board, use that same page to explain how we manage this service end‑to‑end?
If the honest answer is "no", you don't just have a tooling or governance issue. You have two or three incompatible Operating Models, and a lot of manual stitching work in between.
The good news is that fixing this does not start with a new tool or another framework. It starts with a whiteboard and a decision:
We will have one Operating Model for how we run services across ITSM and cloud.
We will sketch it explicitly – using something like Andrew Campbell's Operating Model Canvas – before we rewire tools or add more governance.
We will treat USM/ITIL as our activity library, not as competing religions.
We will let NIS2 and similar obligations shape roles and controls in the model, not bolt them on afterwards.
Once that map exists and leadership actually uses it, ITSM and cloud management stop being rival operating logics and become what they should have been all along: different angles on the same system.
By now we've covered two things: In Part 1, why ITSM without an Operating Model turns into theatre. In Part 2, what an IT Operating Model actually is (and isn't) – with Andrew Campbell's Operating Model Canvas and USM as practical anchors.