Release Policy: far from being a reality (Part 2)

By Laurent Duenas, March 15th 2013 


Consequences of this insufficient understanding


Failure to benefit from stabilization while maintaining agility

This consequence is linked to the failure to exploit the overlap between different scheduling modes (mentioned in the paragraph “Why 2 processes?”). This point is developed in detail in the next chapter about the implementation of Release Policy.

The IT Service is not deployed end-to-end

The lack of an overall “end-to-end” vision of the IT Service impacts the Build and use of Release units. Those are mainly designed and split into segmented angles of view (technical applications), which increases the risk of incomplete release. A number of examples of application deployments have generated Release incidents with workstations or servers, because the right JVM version or any other software component was missing, failing to be deployed at the same time as a coherent set.


Example: The example of JVM (Java Virtual Machines) found in several companies is revealing. Changes of application software versions on distant servers (often) do not operate once deployed. They fail to anticipate the evolution of the JVM version. The opposite example also exists. Some changes do integrate a JVM update simultaneously with the application version. But once deployed, other applications do not work anymore. A technical vision of Change Management often limits its scope to the field of expertise of the change initiator. Costs and efforts around new changes and deployments can be avoided if an end-to-end approach is adopted in the preparation of change.


Releases are not carried out with all guarantees 

Most of the time, Release activities are considered as a sequence of technical acts. Integration and deployment activities are organized to succeed each other in an optimal way, yet without ensuring that the “guarantees” that should be integrated into the IT Service are actually embedded. This unilateral vision very often impacts the quality of service.


Without “end-to-end” vision of the IT Service, validation tests do not aim at maintaining service levels, from the user's point of view. For example, packaged software undergoes technical tests. These tests generally target software deployment and self-installation. Then, software is deployed without any other guarantees on the capacity of the organization to offer a support complying with SLAs or an IT Service performance in actual operating conditions (response time, capacity to support workload, software use from distant locations, etc.).


Another example around the workstation: should the organization of task preparation and deployment be guided by cost optimization only, the consequence often results in split operations between the more competitive stakeholders in each specialty, without any precaution to ease their contribution (difficulty in interfacing their operations and their processes). As a result, from a global point of view, what we get is a complex and inefficient supply chain with bad final schedules and questionable quality.


For IT service customers, restricting oneself to a technical angle of view when carrying out these tasks removes all the value to the Release and Deployment Management process. This can be compared to a restaurant where tasks would be distributed to several cooks with a purely technical approach, regardless whether the final dish is good, salted or hot enough.

Example: The IT department of an airline company wished to split workstations management between several outsourcers. This choice was motivated by the will to reduce its dependence towards a single global partner. The split was based on scopes of intervention: one managed the central stock and the preparation of workstation staging; the other managed “on the fly” requests for workstation installation; another one managed installations in project mode; and other partners were in charge of workplace preparations. Of course, this split implied a coordination that was supposed to be brought by the ITSM tooling workflow (and its task distribution automated functions). From the user point of view, the result was bad: average response times on a workstation were above 12 days. 15% of them reached 20 to 30 days. The average time required to provide a workstation in an organized environment is 5 working days. However, no supplier failed to meet requirements and each one did comply with its OLA. The complexity of the global logistical chain was such that support (and latency) times between outsourcers did not allow to shorten time below 10 days. And if a grain of sand slipped into operations implementation, no defect circuit was launched and required times only increased. Here is the example of a technical approach in the design of a performance, which finally impacts users’ activities, since they cannot carry on working during the time.


As a reminder, the provision of a workstation within a delay accepted by the customer is also an SLA, less important than IT Service availability itself, but when it refers to newcomers or to the replacement of defective workstations, it affects many users and thus, business productivity in time.



Other articles

►  No link

External links

►  No link

Related products

►  Change & Release ...

Copyright © 2014 - PRACT Publishing