The Love Triangle - Config, Change And ReleaseBy Russell Steyn There is a love triangle imbedded deep in the heart of the ITIL (IT Infrastructure Library). One that is often mentioned in discussions in or around the water-cooler, but is not given the due consideration that it deserves.
"Like sand through the hourglass, so are the days of our lives" and any avid "soapie" follower will quickly tell you, that it's the love triangles in the story that amount to the most excitement, pleasure and intrigue!
These three processes are so closely intertwined, that it is not even funny. They need each other, they rely on each other, and they are interwoven, interbred and interdependent. Without the one, the others "pine" and are totally miserable - or should I say totally ineffective.
But why are these three so dependant on each other? Well, if you are planning a change, you need to know what the impact will be, what the risks are, what systems and services would potentially be affected, which business units need to be involved or approve, which technical areas are involved, what dependencies and vendor contracts may be impacted, which SLAs are affected or need to be updated, is DR required, or does an existing DR plan need to be updated, etc.?
How do you suppose you are going to do all this if you do not have information at your disposal? Information that is accurate, complete, meaningful, and possibly most importantly, information that you can trust? In short, you can't!
Change management relies on accurate, up-to-date information to plan effective changes.
Change Management itself is not a technical process. It is a facilitation process, a control process, a coordination process. Change Management is not a department of technical people waiting to implement changes.
Change Management does not do the implementation. It does not do the development or testing, nor the staging or cut-over to live. Change Management simply checks to see that the "T's" are crossed, the "I's" are dotted. It makes sure that the testing is happening, the staging was successful, the back-out plan is drawn up and tested, and that the change does not happen at a time that impacts the business adversely.
For all the physical aspects of the Change, Change Management relies on the process of Release Management. Therefore at a basic level, Change looks at the "What" needs to be done, and Release looks at the "How" best to do it.
Release Management, though not a department of developers and installers is more technical in nature than Change Management.
Release Management adds the "work smart, not hard" aspect to Change Management. i.e. We have a hundred changes to do this month, which can we bundle together, where can we pool resources, where is the software, who needs to be on site, has anyone contacted the vendor yet, at what time will we bring the system down, etc. It is plain to see how these physical aspects would fall outside of the scope of Change Management.
So Change Management relies on Release Management to make sure that the technical as well as non-technical aspects of the change/release are considered together. The non technical aspects of the release would be things like training (User/Technical/Customer), documentation (Installation guides, checklists, user manuals, troubleshooting guides, etc), parallel working if necessary, road shows, awareness, and user/customer involvement in testing, preparedness and signoff.
And, who better to assist in keeping the Config Database (CMDB) accurate and up-to-date than the process involved in the physical deployment. Those that saw it with their own eyes, that were there physically doing it, Release Management.
The Triangle Traits
- Configuration Management looks after all the logical aspects of the Change.
- Release Management looks after all the physical aspects of a Change.
- And Change Management looks after the Control of the Change.