---

I (with Claude) went looking for something else entirely in our own Cloud Process Kit and found a missing CMDB instead. It was pure serendipity (and Claude!). 

What I was actually trying to work out was where ITAM and FinOps meet in cloud governance. There’s a lot of content out there (including a couple of our own whitepapers, if I’m honest) that talk about the two disciplines “governing the estate together,” without ever pinning down in which processes and steps the collaboration actually happens. So, I went through our own Cloud Process Kit RACIU to find out. 

I found the answer. But on the way I found a gap in our own kit that I think is the more interesting story. 

There’s no CMDB anywhere in the cloud kit 

Honestly, Claude looked really looked hard, guv! It just wasn’t there! Neither was configuration management, nor was it masquerading as part of the ‘ITSM Suite’ or a generic ‘ITSM role’. Both these last two existed, but the steps they were involved with, such as tagging updates, access requests, and process re-engineering, had nothing to do with configuration data. ITSM, as a role, shows up in sixteen tasks, and again, none of them are about reconciling cloud workload data into a configuration record. 

Compare that to Hardware and Software, where the CMDB is referenced throughout. It’s not one of the bodies buried in a generic ‘ITSM suite’, it’s a named system, and “Update CMDB” is often its own explicit task, because keeping that system accurate is understood to be part of the job, not an afterthought. On the cloud side, though, it’s nobody’s job! 

It’s not inconsequential, either. Even just considering ITAM, later in the same kit, ITAM is accountable for “Estimate Licensing Impacts” during the Cloud Contract Review process. However, that estimate is only as good as the asset data behind it. If cloud workload detail isn’t reliably making it into the CMDB, that assessment is being made on a partial picture, and there’s no step or role in the kit whose job it is to fix that. 

And while I was there – ITAM and FinOps barely meet either 

So back to my original question: where DO ITAM and FinOps intersect? The answer is in only ONE process, the Cloud Contract Review process, where ITAM contributes to two steps!  

I don’t think that’s a flaw, for what it’s worth. We needed to keep a very complex set of processes as simple as possible, and really, the only time traditional ITAM contributes directly and unequivocably to cloud lifecycle management is when it comes to reviewing licensing contracts that may have cloud based licenses, and cloud contracts that may benefit from existing software licenses. 

This also lines up with how the FinOps Foundation itself frames it — their Framework puts ITAM in a category called “Allied Personas”, disciplines that sit outside the core FinOps practice but need to coordinate with it, mainly around asset efficiency, contract compliance and purchase decisions rather than day-to-day cost optimisation. 

Cloud technical teams actually operate the cloud-based services, with ITSM providing key supporting processes such as end user access control, incident management etc. FinOps runs the financial rhythm of cloud spend. ITAM looks after entitlement and contract terms for licensing. ITAM and FinOps only really need to be in the same room when a contract decision touches both licensing and cost. Everywhere else, each can get on with its own job. 

Which takes us back to the CMDB point. In mature organisations, the one meeting point between ITAM and FinOps should rely on configuration data that nobody’s explicitly responsible for maintaining in our kit. 

How does it work for you? 

• Is there an actual, owned step that gets cloud workload data from your CLMS into your CMDB — or are you assuming it “just happens”? 

• If someone in your org is doing a licensing impact assessment on a cloud contract, where do you get that data from? Do you talk directly to FinOps, or are you able to take it direct from a CMDB?  

• Where do ITAM and FinOps meet in your cloud governance? Is there one clear handoff, or is it scattered across several processes with nobody obviously owning the join? If that’s the case, it might mean the two functions haven’t actually agreed who does what. 

If you want to have a poke through the RACI this is built from yourself, it’s free to download here. I’d genuinely be curious whether other people find the same gap, and whether it’s causing problems in practice, not just in theory! 

And I think the number one action Rory and I should consider when working on v2 is working out when the CMDB needs updating, and who (or what!) should be doing it! 

If you want to check my Claude’s work (and form your own opinion of which steps should involve configuration management) then download the (chargeable) full ITAM and CLMS process kit from the link below!