When you think about the dynamics of an ITIL Change Advisory Board (CAB) – and, in particular, the Change Manager and other members of the CAB – they have a tough row to hoe. Depending on how the change management process is designed within a given organisation, the CAB is often the most significant approval gate in the process. This places a great deal of responsibility and pressure on CAB members to make well-informed decisions about whether to approve a given change request.
To make matters worse, the members of the CAB are often one step removed from the intimate details of the potential upstream and downstream dependencies affected by a proposed change. Many change processes depend on involvement from subject matter experts (SMEs) from one or more than one IT domain across the organisation. But given the scale and complexity of large IT landscapes, involving SMEs puts CAB members in a difficult position, as they try to balance the tension between allowing the work to progress by approving a change and reducing the risk of an unplanned outage because the change was implemented.
Say a change is made to a production router instead of the non-production peer of the router, and the changedre-route all traffic associated with the router through a non-production/backup link that doesn’t have the capacity to deal with the increased traffic. The result would be a major degradation in network performance, which can take a while to become apparent, and even longer to troubleshoot and repair.
A root cause analysis may uncover two problems:
- The naming of the two routers were so similar, that it was easy to get confused about which one was production and which one wasn’t.
- The CAB had approved the change without being able to see (or even read) the dependencies that would be impacted by the change.
If parties had been able to visualise dependencies as part of the actual change request from within the ServiceNow platform via an accurate CMDB, the issue could have been spotted prior to the CAB approving the change.
It’s important to recognise that implementing change creates risk (i.e. the risk of an unplanned outage). A well conceived change management process and a well informed CAB help to reduce the risk associated with change requests.
Any sophisticated change management process will include the concept of a risk assessment as part of the process. The risk assessment, which is typically a series of questions about the potential to cause unintended consequences as a result of the change, can either be “gamed” (i.e. answered in a way to dial back the risk rating once all questions have been answered) or can be informed through access to data. The most important data for safe-guarding the change management process are Configuration Items (CIs), because they help to illuminate dependencies and possible points of failure.
If everyone involved in the change management process has access to an accurate CMDB, including the upstream/downstream interdependencies and the CI metadata — environment type, criticality rating and so on — they can dramatically reduce the risk of unplanned outages resulting from poorly informed change requests.
It’s time to solve CMDB automation!
