For effective service management, start with service assurance

To get the most out of the new, expanded ITIL, Compuware`s Richard Hepplestone argues that organisations require an in-depth, quantitative understanding of new applications and their context - an understanding that must be communicated across the entire IT function.

ITIL - the IT Infrastructure Library - is not intended to do the IT department`s job for it; its aim is to provide a procedural framework for that job. We should not be surprised, therefore, to find that a vital element is still missing from the ITIL scene, even though the library has recently been expanded to cover the development lifecycle (under the heading "application management") as well as the management of existing services.

In my opinion the element that is still missing from ITIL is an essential communication process to link two sets of people. At one end of this link should be the team responsible for the application before it goes live, such as the application development, testing and pre-production readiness groups. On the other end of the link, we have the operational team, who take charge once the application is live; they include the help-desk, incident management and problem management groups.

The operational team will need pre-production information about potential weaknesses and risk areas within the new application. This information is indispensable when it comes to tackling issues that may arise once the application is in production. For example, imagine that a live application`s performance suddenly plummets for no obvious reason. If the ops team has already been told that the application`s response is liable to degrade if server usage exceeds a certain percentage, then there is an obvious starting point for its investigations. Better still, the team can monitor server loading proactively to prevent the problem from occurring in the first place.

To supply this information, organisations need a pre-production `service assurance` process. At present, relatively few companies in my experience have mature service assurance disciplines in place, but thanks to automation these disciplines are actually within reach of most organisations. The aim of service assurance is to create a detailed profile of each new application, and to put that profile into the context of the environment in which the application will run.

Service assurance also provides a valuable baseline for every other stage of the application lifecycle. To see just how useful this baseline can be, let`s think about some of the groups defined within ITIL. The release management group, for example, is tasked with ensuring that new releases are delivered into production meeting the required standards of quality and robustness. Baseline information from service assurance will allow it to identify any quality shortfalls in the application, and prevent them from affecting the quality of the roll-out. Once the application is in production, the package of information generated by service assurance activities can be passed on to all the operational groups who help to look after it.

The change management group, on the other hand, has overall responsibility for allowing or denying changes to the production environment and needs proof that any given change is the right change. Baseline information from service assurance allows change management specialists to compare the "before" status with the intended "after" status, so they can verify that the effects of a proposed change will be positive. The same type of information enables the group to check whether the change is practical within the current production environment, or whether upgrades or adjustments are needed.

Service management groups too, will find the pre-production information helps with their job of ensuring that existing services are not jeopardised by new or changed applications. And when it comes to problem management, pre-production baselines and profiles can speed up troubleshooting: technicians now have a clear view of the problem domain, a reference frame for characterising the problem, and a predictive analysis environment for comparing the costs and benefits of alternative solutions.

What all this boils down to is, quite simply, enhanced control. Pre-production service assurance activities paint a picture of the production environment before an application is added, and predict the effects of adding that application. At the point where the application is put into production - and once it is actually in production - this picture can be used again and again to enhance understanding of change, its impact and its causes. There is no longer a need for IT to rely on users to report problems: with every dimension of service already measured or predicted, IT management is totally in control of the situation.

ITIL, particularly in its expanded form, provides valuable guidelines for improving the service IT offers to business. In my view, however, organisations that take the aims of ITIL seriously need to complement these guidelines with a strong pre-production service assurance discipline, which must establish communication lines through to IT operations. This two-pronged strategy makes it possible to protect existing IT assets at the same time as you ensure the success of new application deployments.