IT Service Management - etude de marche

Introduction
IT Service Management (ITSM) is evolving from the discipline of managing the infrastructure based purely on perceived technical requirements (for example, simply ensuring bandwidth is available), to managing the same infrastructure based upon organisational requirements (for example, ensuring bandwidth is available for those applications that are mission critical, and where necessary throttling bandwidth for non-essential applications or usage).

Stated in those bald terms this may not appear to be too onerous a task, but the reality is different. Organisational requirements change in a highly dynamic fashion, and infrastructure usage requirements change based on any number of factors, such as:

Application requirement based on time of day or month.
Process-based bandwidth requirements.
The requesting client for an infrastructure element.
Organisational hierarchical structures.
In order to create the management structure required involves a plethora of tools and disciplines. A total view into the infrastructure has to be provided as a central element. In order to provide �smart� management, all the available resources have to be mapped and made available to those tasked with ensuring continuity of service. Once this view has been created then it becomes possible to map the interdependencies of the objects within the infrastructure and manage them, while maintaining an overall business requirement viewpoint.

Elements of ITSM
As an example of this, we can take the helpdesk support environment. The first task has to be the prioritisation of problem resolution; working on a first-come, first-served basis has no business rationale to support it. Therefore the people tasked with problem resolution in this area must be given an understanding of the total organisational impact on non-resolution in order that effective prioritisation can take place.

This holistic view and control of the organisational environment is provided by configuration management. The complexities now present within IT infrastructures emphasise the need for automated configuration management to assist in the creation and maintenance of the map of the infrastructure. In many organisations it is impossible to even consider carrying out this task manually, and those that do attempt it will find that it is labour-intensive, expensive, and the resulting output persistently out of date. Of course, out of date information can be more dangerous and damaging than no information, and it can cause severe problems when decisions are made on false, incorrect configuration data.

Configuration management involves the identification and definition of the assets within the IT infrastructure such as switches, software, and servers, and the relationship between the various components. When stored in a central database such as an IT Infrastructure Library (ITIL) Configuration Management Database (CMDB) and it is updated to reflect changes, then up-to-date information is available so that the impact and risks of proposed changes to the infrastructure can be accurately assessed

Increasingly, proactive tools are coming to market that provide solutions in this space incorporating auto discovery. Organisations implementing best practice frameworks, such as ITIL or Control Objectives for Information and related Technology (COBIT), need a quick way to establish CMDBs, and these management products can provide the solution.

The reasoning behind ITIL is that certain functions are imperative in managing high-quality IT services. It provides guidelines on change management, problem resolution, service levels, capacity and contingency planning, and configuration management. Some enterprises try to do configuration management manually when they believe that it is needed; however, this highlights the problems associated with the lack of service management information. Change planning to assess the risks and impact of proposed changes can involve large teams of people and many meetings. Costs of services cannot be determined, and getting to the root causes of problems is complex and time consuming.

Although configuration management and the use of ITIL and/or COBIT, and the implementation of a CMDB, can be seen as central structures for ITSM, the story does not stop there. It is the associated tools that provide the working environment in which the correct decisions can be implemented.

Although ITSM covers a number of discrete activities, such as incident management, problem management, change management, release management, and security management, they all require a business or organisational focus to ensure optimisation of resource.
ITSM should not be seen as a firefighting exercise; a cost drain simply to ensure the �lights stay on�. ITSM has to be seen as a proactive discipline that brings value to the business by creating and allowing structured changes that will increase efficiencies.

Delivery of IT as a Service
The introduction and the rapid acceptance of the value of Service Oriented Architectures (SOAs) has focused attention on the provision of IT as a service, and this can be viewed both internally and externally. To a certain extent, this is a logical progression or an adjunct to utility computing, whereby IT assets are not limited to their implemented usage, but become part of a larger infrastructure requirement.

This has led to an understanding that IT provides a service that is not only cost-based, but has possibilities for revenue generation. For many years there has been talk of moving the IT function from a pure cost centre to a profit centre. Whilst for many this may be a step too far, it is imperative to at least start the progression by attempting to create a null position for IT cost.

This will require a deep understanding of the services provided by IT and the associated costs involved. If the provided services are all internal, then it becomes a matter of organisational choice whether this creation of a null cost position is treated as a �real� application with the introduction of chargeback, or maintained only within a reporting system. Whichever choice is made in this respect, it doe not remove the requirement for these structures to be put in place.

This has two major benefits. Firstly, it allows organisations to have a greater understanding of the value provided by IT, and with that greater understanding will come more accurate budgetary constraints. Secondly, this financial management aspect of IT will create a baseline understanding against which other operational IT models, such as outsourcing, can be measured.

Evolving to ITSM
From a technical perspective one only needs ITSM if one is delivering the functionality of IT as a service. If one is simply providing applications or network capability then there are a plethora of tools available to manage issues such as versioning control, patch management, and network optimisation. However, moving to a more service-centric architectural style does not remove the need for such tools � it simply means that they have to fit into a more flexible and usage-centric framework.

Take one such element as an example. Application version control in a purely technically-focused environment is often seen as ensuring the distribution of standard applications across the organisation in order to ensure that there are no incompatibility issues with the produced data. In a service-based environment this simplistic view is no longer supportable. There may be valid reasons why different versions are instantiated throughout different parts of the organisation, especially when it comes to those applications that cross internal boundaries to external partners.

Understanding the purpose of applications is central to ITSM, while this is not the case with simple infrastructure management, therefore IT support has to manage applications from both a service point of view and also from an infrastructure one. They have to understand the impact of change or non-change on both the internal infrastructure and also the external impact. One such dichotomy might exist when security becomes an issue; an application upgrade might be required to address a security problem. From an IT standpoint this is a simple task, and the latest application or patch will be applied across the enterprise. When the functionality of IT is provided as a service, and especially when it crosses organisation boundaries, the resolution of the problem is muddied. Not for one moment are we suggesting that security should be subservient to any other need, merely that the full ramifications of change have to be understood.

One of the issues that good ITSM can address is that of redundancy within implemented systems. It is well known that CPU utilisation, as one example, is typically between 17% and 25%, yet most organisations could operate both efficiently and safely with utilisation around the 75% mark. ITSM at the technical infrastructure level can help in reducing this under-utilisation, yet it has to do so with due regard to organisational perceptions and historical imperatives.

The new requirements will demand a greater level of control than ever before � it will become management at the micro level. Broad parameters that are currently implemented will become far more restrictive. The tools implemented will have to provide not just some conceptual grand design of management from a business perspective, but will also have to provide the technical capabilities required.

From an implementation viewpoint, on a green-field site the introduction of ITSM is relatively simple, as the associated tools will reference the framework implementation (such as the CMDB). However, few organisations have the luxury of starting from scratch; most will already have management tools in place. Typically, these will fall within the following categories:

Portfolio management.
Business Process Management (BPM).
Infrastructure management.
There is a high degree of synergy between the areas covered by the specific tool types and a total ITSM implementation, and it is imperative that these tools can become part of the ITSM solution. The synergistic nature is amply demonstrated when one examines the market dynamics. Two examples serve to demonstrate the point:

The acquisition of Niku (portfolio management tools) by CA for incorporation into its comprehensive management toolset.
The ongoing initiative by IBM to introduce the Tivoli code base into its higher-level WebSphere products
Both these examples indicate that the ITSM market is taking a much more business-centric view of management, and that totality of management is the way forward. The term Business Service Management (BSM) has been coined by BMC during its own re-invention and this is gaining traction in the market.

Acronyms aside, the value proposition for ITSM is plain to see. It is only by bringing the business management focus within infrastructure management techniques that IT can be progressed as a value provider in demonstrable ways.