It is a well established and accepted fact that Configuration management and change management are very thickly integrated processes.
The question what I get recently – as a trainer and consultant is :
Does any updates to CMDB has to be under the change management control?

While the overall answer is YES, I ensure to add the following almost always:  ‘Change management is not actually controlling the changes to CMDB (unless CMDB itself is a CI 🙂 – We will ignore that here) ; it is controlling changes to the CIs, and hence the changes/updates to CMDB automatically becomes under change management control.’

Now the question of an inquisitive mind is – are there any changes to CMDB that doesnt follow this rule?

The instant reaction is to shake head heavily and say NO! But as I repeatedly get these kind of questions (in fact the same question in my recently concluded ITIL Service manager training triggered me to write this blog) – I started looking around to see are there any scenarios where the CMDB gets updated without an associated change management transaction.


My initial findings/thoughts were – it happens in cases where:

  1. New Incident / problem records are linked to CMDB – But I tend to argue here that in such cases, CI records are not really getting updated. The linkage happens usually the otherway around.
  2. For service requests – But there I was plain wrong as they are mostly standard changes – which are automatically under change management control.

Then in various scenarios, I could find cases where there could be CI record updates without a corresponding change request/change record:

One of them – I came across in the most recent training itself:

Assume there is a CI – A network device. Due to design characteristics (or limitations/bug etc) – the manufacturer has specified that for optimal performance of this device, it need to be restarted at least once in 2 months of working time (time normally specified in hours).

In this case, “The date of last reboot” (or any other term referring to the same) becomes an important attribute of this CI. Now if we depend on change requests/records for this CI to update this attribute, we may miss a quite few updates – like a reboot that occurred due to the failure of power/UPS last week.

I have come across more instances like these in the past – but cant recollect all of them here. However, it is apparent that – though there is a thick interface between configuration management and change management, there can be cases where one is dependent on the other.

Similar debates happen between Release and Change management as well. Unfortunately or fortunately,  ITIL doesnt give clear answers to these – and that gives us ample moving space for interpretations and customizations. That, to me is one of the beauty of ITIL too.

Advertisements