Print page

The current glut of software tools, suites and bolt-on products oriented towards the ITIL® Service Management suite is rich, colorful, and profoundly lacking in one respect -- there are no compelling tools to automate Service Delivery processes.

By Mike Drapeau and Dwight Stewart

What is available for the five Service Delivery processes pales in comparison to what is commercially available to support their more prevalent companion five Service Support processes. At an itSMF local interest group event held in October 2006, seventeen software vendors, each focus on capturing a greater share of the ITSM market, presented their wares.

Of the full range of software offerings, only one had a stand-alone Service Catalog product, a handful had some sort of Service Level Agreement (SLA) modeling, and all spent their marketing punch in showing how they supported some or all of the Service Support processes.

None touted their ability to automate or even to specifically support, from end-to-end, any of the Service Delivery processes. This lack of support, at least as indicated by vendor attendance at a local itSMF event, spurred us to thought – what was it about the five Service Delivery processes that made them such an automation outcast?

The biggest casualty of this ‘gap’ is the success of ITIL implementations that involve Service Delivery.

This article shares insights and offers suggestions as to the reasons behind this lack of attractive Service Delivery-specific tool sets and provides recommendations on how organizations might mitigate the impact.

What Service Delivery tools are actually available?

Not satisfied that the population of ITSM-enabling software vendors was well represented at the itSMF local event, we attempted to uncover as many examples of Service Delivery-oriented software as we could find. We found three vendors offering products specifically for Service Delivery. There are other, more numerous offerings that focus like a laser on just one aspect of just one of the Service Delivery processes. Typically, such software is oriented towards a technical discipline, as the integration and communication necessary to track and report detail to support Service Delivery needs oftentimes requires functionality unique to a certain type of technology (e.g. capacity management information derived from mainframe planning and analysis jobs).

What do that Talking Heads say?

Frankly, not much. A quick read reveals the tools explored are those in support of Incident, Problem, and Change Management – again all Service Support processes. Finally and most ironically, there was at one time an OGC-sponsored publication entitled Service Delivery Tools that has since gone out of print.  The “tool gap” reflects where we are collectively in terms of ITIL maturity. A recent report of the top ITIL initiatives for the respondents for the coming year were:

• 63.7% - Configuration Management/CMDB

• 57.1% - Incident/Problem management

• 57.1% - IT Service Catalog

• 52.1% - Change and Release Management

Only one of the four initiatives listed is even related to Service Delivery and, further investigation reveals that the IT Service Catalog is created as a stepping stone to the CMDB not a full-figured implementation of Service Level Management. The hope has been that, as more businesses complete their Service Support implementations, they might press for better Service Delivery automation. This hope has yet to be realized.

What about the little Service Delivery Automation that is Available?

Almost every tool in the ITIL universe has a module entitled “SLM” or that at least boasts the creation of SLAs or possibly capturing Service Level Requirements. But few are directly tied to IT Service Catalogs and fewer still to a CMDB (Configuration Management Database) and, more importantly, they do not cover any of the other many attributes and requirements of the overall Service Level Management process (communication, coordination, documentation, strategic planning, etc.)

In the same way, there are tools which address various aspects of the other four Service Delivery processes, but none are integrated with the others. For example:

• There are numerous Capacity Management tools that introspect the most minute elements in a certain aspect of technology but none that roll up all the information into a Capacity Plan that stretches across the domains

• There are many Disaster Recovery Plan management tools and an almost infinite array of software packages to automate recovery through replication, mirroring, and fail-over – but none that follow the lifecycle of IT Service Continuity Management from inception at Business Impact Analysis through all the stages ending with ongoing Operational Management

• There are many component-specific tools that compile analyze, and report on component failure conditions, do trend analysis, and, in the rare occasion, publish information of use to an Incident Management system. Still, there are none that cross all the technology domains and also none that roll up their information to assist in developing the ITIL-required Availability Plan.

Key Element – Knowledge Management

One key element is missing from all these tools and, arguably, it is the most important ingredient for any successful Service Delivery software platform -- Knowledge Management. What the Service Delivery processes all have in common in their definitions is that they all require the creation, update and management of ‘strategic’ plans as well as tactical documentation. Some examples of these are ITSCM recovery policies and procedures, Capacity Plans, Availability Plans, SLA’s and OLA’s, and CFIA analyses. What these anticipate is a tool that automates their creation, revision, distribution, update, and usage over time. This is the same task that many other tools perform for the transactional forms of the Service Support processes (e.g. Problem tickets, Incident Tickets, CI records, Release documents, and RFCs). The latter is easier to automate than the former so, in the end, the immediate (and easy) trumps the important (and more difficult) software challenge.

With all of the above in mind, what are some of the reasons why Service Delivery tools are still in their infancy, even in Europe where ITIL implementations are common and longstanding? Here are a couple of clues:

1. Service Support processes are more tactical in nature while Service Delivery processes are more strategic. Service Support processes are the most pressing, daily needs for the IT department. Due to the intense immediacy of the issues caused by poor Service Support and the relative ease with which one can diagnose the source of the problem. ITIL implementation tool investment for these processes is frequently more highly prioritized.

2. Since Service Support processes are more transaction-oriented, they require more ‘headcount’. Many Service Support transactions have very high daily volumes, requiring significant headcount to process whereas Service Delivery documentation involves plans, agreements and reports developed by few and used by some. IT Managers can identify more readily the necessary financial justification to implement a Service Support tool in terms of time savings or quality improvement per transaction. On a more pecuniary note, the larger headcount of Service Support ‘users’ implies greater potential license sales for the software vendors.

3. Regulatory compliance orients organizations to give priority to ITIL projects that involve the CMDB. Sarbanes-Oxley compliance has given a big boost to investment in Asset Management and Configuration Management. The areas which directly interact with Configuration Management (i.e. Service Support processes) benefit from this windfall or ‘forced’ implementation. The result has been that Service Delivery implementations and purchasing of related tools are often shelved until the CMDB and related projects are completed.

What to do…

First, start with an ITIL assessment that is vendor and tool independent. This will allow you to focus on what ITIL Service Delivery areas best leverage your future success, rather than what might be the easiest tool to implement. This will help avoid emulating the age-old problem of the drunk looking for his keys under the streetlight, rather than where he lost them.

If your best route into ITIL is via Service Delivery path, look for a process design that leave options open for future software developments and presents the issues of automation, knowledge management, and documentation workflow with eyes wide open.

As an aside, consider alternate solutions to Service Delivery automation in the form of a service (such as using a disaster recovery vendor for a turnkey Service Continuity solution) or a person (such as an existing staff member who already has the technical skills required for Availability and Capacity, but just needs ITIL training to mesh these skills with the overall ITSM implementation needs.)

Either way, the lack of powerful and highly touted tools for Service Delivery is a natural consequence of the process definitions and the current marketplace. Don’t let this deter you from pursuing a Service Delivery implementation if that is your greatest need. New Service Delivery solutions will be arriving in the marketplace this year. One of them may meet your requirements, even though it doesn’t have the visibility or market share of a high end Service Support tool.

Subscribe Its Free!

RSS Stay up to date!

PDF Pass it around!

Where to go from here:

• digg (discuss or comment) on this article. Show your support for DITY!
• Subscribe to our newsletter and get new skills delivered right to your Inbox, click here.
• Download this article in PDF format for use at your own convenience, click here.
• Use your favorite RSS reader to stay up to date, click here.

Related articles:

• Browse back-issues of the DITY Newsletter, click here.