Change and Release concepts part 2

In the previous post I mentioned about multiple layers of authorisation, here’s another example which was given to me by an ITIL trainer a few years ago.

Take a commercial airline. A manager within that airline wants to run a new flight from London to Edinburgh. First he needs to seek approval to put that flight one – get the plane, pilots, staff, consumables. Once this business authorisation is granted he then needs authorisation from the other 2 business units (London airport and Edinburgh airport). Once this is granted and the flight is going ahead, he then needs authorisation for the two stages of implementation – take off and landing – fron the respective control towers.

Get the point here? One change process doesn’t easily fit everything required. You could implement a change authorisation workflow which has multiple approval steps and stages, but that will take a lot of work to set up to cater for all situations.

the answer, in my opinion anyway, is to specialise the change processes. One for the business requests, and one for the actual technical changes to configuration items.

A business request is “I want to accept PayPal online”.

The technical changes which could come from this would be a change to the website, a change to the payment gateway, a change to the firewall, a change to the accounts system, plus a series of changes to management reports.

The change to the website could actually be 3 changes: one for the database, one for the application layer (the logic which does the payment processing), one for the presentation layer (the visual elements).

So keep different request types separate. Business changes need a lot of scoping and understanding, technical changes need to be understood and risk assessed but are a lot more straightforward to process in volume. The ITIL V3 model quotes several change types as examples, check out the Service Transition book p47.