Posted by: buzina | December 19, 2006

Wish for ITIL v3 – Release Management


I created a new post in my ITSM Series dedicated to release management. You can find it here.

ITSM Series #4: Release Management

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.



  1. […] July 4, 2008 Posted by buzina in ITIL. trackback Before ITIL v3 came out, I stated a whish on this blog for v3 to change the release management. Let’s review if this whish has somehow […]

  2. […] A while ago I had some high hopes on the then still forthcoming ITIL v3 release management. They were not fulfilled as I would have like it to be. So I will try to define what I would like to see in release management. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: