Change, Project, and Release: the core of IT Service Supply Chain (Part 4)
By Laurent Duenas, March 15th 2013
The trains and travelers metaphor
In order to illustrate these different levels of concern and planning, let us take the analogy of a train and its travelers.
On the one hand, there are travelers whose goals are to reach their destination, each of them for different reasons, and above all according to their own schedule. All travelers lead their lives independently of one another and it can happen – or not - that they all board the same train.
On the other hand, we have trains. They operate according to a schedule, with departure and arrival times. Whether all travelers with bookings are present or not, the train leaves on schedule. A late traveler will get on the next train. He will not be able to have a train chartered for him alone at the time he wants.
In our analogy, the traveler is a change, the train is the release. The release transports changes at fixed dates. But, as for travelers, changes in their design phase can suffer from delays and miss the release planned. They should normally board the next release planned. “True life” shows us that they don't.
This is one of the most important notions of Change and Release process, especially the latter witht the concept of Release Policy. Yet, this notion is almost never present in companies, neither as it is widely documented in the ITIL framework, However, the complementary nature of synergy between both "Change” and “Release*” processes is essential.
Analogy between Release Policy and trains schedule
* Only changes correcting a high priority incident whose impact justifies that a risk should be taken through an additional release can be urgently released (and have the status of urgent change). A single delay, without business impact, cannot justify such risk-taking. As a consequence, build teams alone do not make the decision to categorize a change into “urgent change”.
This guarantees stability in order to limit any potential impact on the availability of Services for user and limits any unexpected workload variation for integration teams.
► As the Release mode includes changes complying with business-approved schedule, it does not risk to disrupt Service availability outside time slots
► As they no longer work on a “day to day” basis, integration teams do not depend any more on development hazards (which, by their nature, depend on business hazards), and thus, have a better control on their workload, their schedules and last but not least, their budgets
► No link
► No link
► No product
Copyright © 2014 - PRACT Publishing