Release Strategy: Size vs Frequency

Something I’ve run up against several times at several different organisations is making sure that the release process, policy and schedule is fit for purpose not only in terms of being compliant with best practice (such as ITIL) and controls (such as COBIT) and any other requirements within the business, but also to ensure that your change and release structure can cope with the volume of change.

Let’s assume your organisation has two broad categories of changes which are bundled into releases – new business functionality in the form of BCRs (Business Change Requests) and problem fixes.

We’ll also assume that you have a monthly release model which includes:

1. Scope and Design finalisation (1 week)
2. Build & Test finalisation (2 weeks)
3. Running an automated regression pack (1 week plus 2 days for final fixes to go as deltas on top of the main release)
4. Cutover and implementation activity (3 days)
5. Early Life Support (2 weeks) (ELS is an ITIL term which used to be called release warranty – in essence, a period of enhanced support following a release or where incidents/problems follow an accelerated support model compared with normal Business As Usual support).

Continue reading

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.

Change & Release Concepts part 1

In a simplified view of the world, if you want to change something, you raise a change request, it gets approved, it gets built, it gets implemented.

Wait – when does it get approved? Before or after it gets built? How about if during the design or build stage it has to be split into several changes?

A fundamental problem with some service management and change models is that they don’t allow for varying stages of approval or authorisation.

Think of what happens in real life:

1. You want to change a web page to accept payments for a new payment processor
2. You put together a proposal and go through an approval process for the concept of wanting to change it – including some business case approval, high level technical approval.
3. The business analysts and development leads get a hold of and start speccing it out in detail, then coming up with designs to meet those specs.
4. At this point, they know roughly the which changes to which services, systems or components they need to make.
5. Those system or service owners (service managers and product managers) may not have been consulted initially (at step 2) and therefore need to have sight of what changes are required and be able to approve or reject those changes.
6. The changes get built and tested
7. Finally, you usually have to go through some kind of approval to implement the change, either on it’s own or as part of a release.

That’s three layers of approval:
One for the concept of making the change
One for the specific piece of technology change
One to deploy it once it’s been built and tested

So how does a single change management process cope with those three?

It doesn’t. If you use ITIL, you’re lucky if one process covers two of them.

Introduction

This blog will show you how to implement change, release and configuration management.

It’s broadly ITIL V3 aligned.

It includes some concepts and tools that work for me, and may do for you with some customisation.