Change and CMDB: Which is the Chicken and which is the Egg?

Which comes first? Change or the CMDB? Do we design and populate our CMDB to support the change process or is the change process implemented to protect the integrity of the CMDB?

I believe it depends on who in the organisation is driving the move towards Service Management and ITIL.

1) If it is driven from a higher or management level there will be a focus on integrated, comprehensive processes which provide transparency, visibility and control. As such the change process makes clear the current state, and the future direction, of your IT infrastructure. The CMDB then becomes a necessary “baseline” for the Change process. It will be designed and populated accordingly with a focus on those elements of the Infrastructure which a) are vital to providing services and b )whose costs should be monitored.

2) The need for Service Management, (operating according to the principles of ITIL) can also be driven from “the bottom up”. In this case it is the Service Desk, support groups and other stakeholders who push for Service Management as a way of managing complexity, prioritising resource and establishing effective communication within IT and between IT and Business Management. Here the focus is on the operational issues, maintaining and restoring Services. As a result the CMDB is viewed as the starting place; a repository of information which will help resolve Support Requests. It is often based on (and/or confused with) an asset register and the focus will be on elements of the infrastructure whose failure impacts on services, rather than on the cost of the equipment. Given the subsequent importance of the CMDB in the support and delivery of Services, it becomes vital to protect the integrity of this information. This requires a Change Process, ensuring that Incidents are neither created nor made worse by unplanned changes.

This may seem like a subtle distinction and the change process and CMDB should be entirely compatible but I believe there can be issues with a Service Management implementation when there is not a consistent vision shared by all parties, or when different people view the change process and the CMDB through the lens of their own requirements.

This is one of the great advantages of the Alignability Process Model. Because it’s a complete Service management framework, designed as a piece with integrated and interdependent processes, it delivers the “command and control” required – meeting the management requirements. But with its detailed Work Instructions, automated workflow and very specific CI information it also enables the support and delivery of services to end-users on a daily basis – so the operational requirements are met. While enabling the effective use of Change and Configuration management “in the real world” it still provides the necessary checks and balances to ensure the processes are viable. For example, in APM, a Change cannot be closed without an update of the CMDB. Likewise it is strongly recommended that the Change co-ordinator and the Configuration co-ordinator are NOT the same person. In this way APM delivers the benefits of Service Management while mitigating the risks of the processes being subverted or degraded.

In conclusion, which comes first?

Ideally Change and Configuration need to be designed and implemented together, but I suggest that Configuration management should take the lead. A CMDB designed with a limited scope (to start with) allows quick and effective adoption of Change management. This allows Change to deliver value to the organisation, and perhaps as importantly be seen to deliver the benefits of Change management.