Everybody who has been working with the IT Infrastructure Library’s Release Management process has experienced the large legacy of the process coming from the Software Distribution history. When ITIL was last updated SW distribution was not such a big deal anymore and so the scope was changed. Unfortunately it was changed badly leaving a lot of legacy within the process. But what should be done to improve things?
ITIL says that the release management process is comparable to a lab. Well, then the lab should behave as a lab and the rest of the company should use it for it’s “R&D” capabilities.
Release Management should be responsible for everything NEW
So every time you want to integrate something which has never been used in your environment before, this is where release management should come in. Release management has to make sure that the new component (software, hardware or service) meets the following requirements:
- Does not interfere with the existing environment (Integration Testing)
- Is not a duplicate functionality within the portfolio (reduce the diversity)
- Can be managed with the current infrastructure (monitoring, reporting, backup, account management and more)
- Does not provide security risks (together with security management of course)
- Is supportable by existing or new personal and/or contracts
- Can be added to the CMDB, incl. verification and auditing
- Can be audited for compliance
Controlling the roll out would still be a part of the release management process, but only a part. The more important function would be for the release management to manage the portfolio of hardware, software and services used inside the company.
The portfoliois of course stored in the CMDB and is an integral part of every useful CMDB. Having a central portfolio allows all other CIs to reference this portfolio in a “is a” relationship. This drastically reduces the amount of data errors and typos in every CMDB and also reduces the effort of entering new CIs, because a lot of the information needed (things like manufacturer, product number, type etc.) is already known.
Release management is responsible to gather information about the new item. This will include naming, release, version and language information, purchasing and costing information, risk categories, servicing information and more. It is also responsible for listing requirements and conflicts and to clarify the installation process. All this data should be entered into the CMDB which should use this information to guide other CMDB users from Change-, Service Request- and Incident Management in adding and changing CIs.
Unfortunately I have no detailed information about the next ITIL release yet. So I can not verify that these best practices (to my experience) are added to the library. So if somebody is reading this who knows more, please let me know.