Release management (the current Release & Deployment management in ITIL®) process is (as it should be) covering all releases those are deployed into the IT Service environment.
Traditionally in the IT domain, the ‘release’ term is more associated with software than hardware or any other assets. However in ITIL®’s approach to ITSM, the release always been ‘a collection of authorized changes’. These authorized changes can be software, hardware, their combination (service, servers, and infrastructure), configuration changes etc.
Having said this, though ITIL® principally goes with an all-encompassing definition of the word ‘Release’, the documentation of Release & Deployment Management often seem to slip into a (probably unintentional) bias towards Software. Such an inconsistency can lead to some significant misinterpretation of the best-practice, and the focus of release management can get confined into software alone.
Let us look at how ITIL® (specifically referring to the 2011 edition) introduces the Release and deployment management process:
The Scope of Release includes: ‘Physical assets such as servers, network, virtual assets, Applications and software, Trainings, Services including agreements and contracts’
However, the stated objectives of Release and Deployment contain statements like:
“…and that all release packages are stored in DML and recorded accurately in CMS”
“Deploy release packages from DML to live environment…”
DML is for software media components. So where are release packages containing Hardware stored? In DML itself? Such an interpretation unfortunately doesn’t fit with the definition and explanation of DML – where in, the references are only include Software and media components. (These references to DML are more prominent in 2011 edition, though was there for v3 as well).
Can Definitive Spares (DS) be the area where the Hardware components are controlled prior to deployment to the production environment? One tends to think it could be. But that is no where referred.
Coming back to the central point of this post, to create a right interpretation of the scope of ‘Release’, it is important that the following one of the following points are taken care of – either in the ITIL® documentation, or by the practitioners during the interpretation of the same:
· The Scope of Definitive Media Library (DML) should be extended to include ALL release packages. Unfortunately in such a case it will cease to be just a ‘Media Library’. Definitive Release Library (DLR) anyone?
OR
· Keep the scope of DML as is; but set aside/define definitive storage areas for storing and controlling release packages that contain non-software and non-media components (such as hardware) and refer to them from the release management process- the same way DML is referred from release management.
Till this is taken care of effectively, release and deployment management process scope can get constrained to only Software – which would be unfortunate and ineffective.
Any thoughts/ different view points out there on these are welcome…
Vinod Agrasala's ITSM / ITIL Blog 
January 18, 2012 at 8:52 pm
I agree. Release Management should include hardware, especially the type that will impact the core infrastructure. Storage Array, Router or Switch, or Firewall.
In fact, I would argue that most application/software teams probably have some level of quality of Release Management already but most infrastructure teams have little to no Release Management processes in place.
At least that has been my experience. And with the text and general discussion being software based, most infrastructure types don’t think Release applies to them at all.
I would think if you are starting with Release Management – the place where you may make the MOST impact the QUICKEST would be in Infrastructure rather than in software/applications.
February 21, 2012 at 3:39 pm
Bang on Alex!! I am working as a change manager and trying to develop a culture for release management with Infra teams for all the changes approved by me.. this blog will help surely.. Cheers!! 🙂
March 25, 2012 at 1:02 pm
Thanks Vinod again for a thought provoking article! I have a different point of view on this.
My understanding is that the best practice about release mgmt principles w.r.t non-software areas is not matured at this point and that it cannot be considered as a best practice for the Infrastructure domain.
When reading release management, I always got the feeling that the authors found Release principles in Software Development and tried to extend it to Infrastructure. This is why the documentation itself is highly biased towards software.
Just look at the concept of bundling of changes. That concept evolved in the software development domain. When developing software, there are multiple new requirements. The stakeholders may prioritize and decide to ‘bundle’ these change requests as part of the a release. I don’t see an equivalent in Infrastructure.
Even other concepts – V-model testing, deployment approaches, the idea of packaging – all are borrowed from the software development domain.
And its because the authors have tried to extend a software development best practice to Infrastructure that Release Management has not picked up steam in non-software areas. The tools for automating Release Management are heavily focussed on Software.
So, I believe that instead of extending Release Management to Infrastructure, it should be restricted to software. You cannot always take a best practice from one domain and successfully to apply it to another. RM best practices caters to a need / requirement may not have equivalents on Infrastructure.
Would love to know what everyone thinks of this.
March 26, 2012 at 8:42 pm
Arun,
I agree with the point that the Release management is not matured in Infrastructure area as much as in Software domain.
However, dont feel that is a reason to say that Release management practices should be restricted to Software area.
The release (and deployment) management is only bringing in a consistent framework of handling ‘Plan, Build, Test, Deploy and Verify’ of any component to the production environment as a part of an authorized change. This should be consistent for any part (CI) of Service management ( Service or Service component, Hardware or Software, Infrastructure or Application).
Best practice evolved in one area can be adopted into other area, if that helps in consistent approach (Wasn’t the case for Configuration managment & CMDB too? Most of the Strategic concepts are taken from Business Strategy etc)
Even if for a moment we take the argument forward that we restrict the RM practices to only Software:
– what would you call the domain of ‘Planning, Building, testing and Deploying’ hardware component as?
If we call that as some thing else (different from release management), then
– which approach will we take when we have to deploy a change that involves both software and hardware?
– Which approach will we take when a whole new Service need to be released to production?
These questions are addressed, if you have a consistent approach of Release of any component to Live environment – irrespective of whether it is hardware or Software.
My only contention here is that a little unbiased appraoch in documentation can make things more clear and consistent.
Would love to hear any thoughts further on this…
Vinod
March 27, 2012 at 2:00 am
I think that the term “release management” has somewhat different meanings in different domains.
For people who work in software development, I agree that it is all about how software changes should be bundled together, tested and made available to the customer. Even for a software company that sells software to paying customers, release management will involve components other than code, for example documentation, packaging, supported hardware lists, maintenance contracts…
For people who work in service management, delivering IT services to customers, I think that release management must include all components needed to deliver service. I do agree that some of the language in the ITIL Service Transition publication implies that releases only include software, but I think that the overall content shows clearly that the intent is to cover all configuration items that are needed to deliver the end to end service.
If you think that the ITIL publication needs clarification, or improvement, then please submit a changelog request at http://www.best-management-practice.com/changelog/
March 29, 2012 at 2:03 pm
@Vinod: In full agreement with you that ‘Planning, Building, testing and Deploying’ things to the IT environment (be it software, hardware or the full service) requires a consistent framework.
I also see the point that there would be a gap in this domain if we restrict Release to just software.
I think the whole problem is that ITIL authors havent given the ‘hardware’ aspect too much thought because of which the guidance tends to be software-oriented.
March 29, 2012 at 2:06 pm
So have you submitted a changelog request yet?
March 29, 2012 at 2:39 pm
@Stuart: nope just created a username and gave a search for ‘release’ Shows a lot of changes. I am planning to just read through them all before raising mine.
March 29, 2012 at 3:36 pm
When I wrote the 2011 update for ITIL Service Transition I was only allowed to make changes that had been authorized by the ITIL CAB, and these were based on changelog requests that had been submitted. So if you want this to be changed in the future you really do have to submit a changelog.
March 29, 2012 at 5:34 pm
@stuart: Thanks for pointing this out ! I definitely will be puting in a suggestion on this.
May 15, 2012 at 4:37 am
seo 2012…
[…]Let ‘Release’ be not biased towards Software « Vinod Agrasala’s ITSM / ITIL Blog[…]…