The IT Operating Model Discovery – Part 3
One map for ITSM & Cloud Management
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.
There's one place where the lack of a shared Operating Model hurts especially badly: the split between ITSM and Cloud Management.
The ITSM World
Tickets, SLAs, incidents, changes, CABs and SMOs.
The Cloud World
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.
Parallel universes: ITSM vs. cloud
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:
Cloud / CCoE
- Platform engineering
- Guardrails & identity
- Network & templates
- Cost controls
ITSM / SMO
- 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:
ITSM View
A P1 incident
DevOps View
A failed deployment
Cloud Logs View
A misconfigured network rule
Governance View
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.
From a board's perspective, there's only one service
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:
Clear accountability and role governance
End‑to‑end incident handling and reporting
Documented risk management and controls across suppliers and technologies
In other words: one story about how you operate, not two or three.
If your ITSM and cloud models are fundamentally different stories about how IT works, you will spend a lot of time in meetings stitching those stories together manually. That stitching work is pure overhead – and it's where things tend to break under pressure.
One Operating Model, many technologies
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:
Services and value streams
What the organisation actually delivers and relies on.
Roles and decision rights
Who owns what, who decides what, who provides data.
Information objects
Risks, incidents, changes, assets, controls, costs.
Governance routines
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.
How Andrew Campbell's canvas helps here
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:
Processes (Work)
Incident to resolution, change to deploy, request to fulfilment, "threat detected to risk mitigated".
Organization
Product owner, service owner, platform team(s), CCoE, security, operations teams.
Locations & Assets
On‑prem DC, Azure landing zones, SaaS platforms, OT sites, CMDB/CMDB‑lite,
Information
Observability tools, risk register, cost data, contracts, org. data.
Suppliers
Cloud provider(s), network providers, SaaS vendors, managed service partners.
Management system
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.
Where USM fits: One management system across ITSM and cloud
USM then gives you the management system language to run across both ITSM and cloud. Remember the layering from Part 2:
1
2
3
1
ITIL / COBIT / IT4IT
Detailed practices and implementations
2
USM
Management system – how we manage services, incidents, changes, requests and risks consistently
3
Campbell's Canvas
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.
You still need cloud‑specific frameworks and guidance (Azure CAF, AWS Well‑Architected, etc.). But they now sit inside an agreed IT Operating Model, rather than quietly defining one on their own.
A simple litmus test
Here's a practical test you can apply tomorrow. Think of one business‑critical, potentially NIS2‑relevant service. Then ask:
1
One-page flow
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?
2
Shared recognition
Would our ITSM leader, our CCoE lead and our CISO all recognise that one‑pager as "how it actually works here"?
3
Board & regulator ready
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.
One map first, then tools and policies
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:
One Operating Model
We will have one Operating Model for how we run services across ITSM and cloud.
Sketch it explicitly
We will sketch it explicitly – using something like Andrew Campbell's Operating Model Canvas – before we rewire tools or add more governance.
Activity library, not religion
We will treat USM/ITIL as our activity library, not as competing religions.
NIS2 shapes the model
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.