Debunking the ITIL Technical Service Catalogue

 

We all know that ITIL alignment can be a battle. In between defining your configuration items (CIs) and your business services, you also have to create a CMDB, a business service catalogue, and a technical service catalogue… right?

Well, no.

In our opinion, you shouldn’t even consider defining your technical service catalogue until after your CMDB and business service catalogue are fully implemented.

Here’s why…

A Bad Place to Start

Let’s take a look at how the ITIL framework describes the technical service catalogue:

This is where we describe the services listed in the business catalogue, how the service is put together or delivered. Your technical service catalogue might include:

  • Links or references to other services which are essential for the delivery of the service
  • Configuration items (which are pieces of equipment)
  • Startup and shutdown procedures
  • Recovery and fallback information
  • Key support contracts

In practice, organisations typically fill their technical service catalogues with items that should really be either business services or CIs.

Doesn’t that seem a little… odd? At its core, the ITIL technical service catalogue is a duplication of entries that should already be in your CMDB and business service catalogue. But if those pieces of the puzzle are already in place, where does the technical service catalogue fit in?

To get a clearer picture of this apparent overlap, we’ll use an example.

More Work for Less Functionality?

Let’s imagine you have number of IIS servers, each doing a specific job for a specific application. Each of these is a CI, and they’re linked to various business services, such as payroll or intranet.

When defining your technical service catalogue, you might designate IIS a technical service. Above the IIS service you’ll have all of the business services that use IIS servers, and below you’ll have the IIS servers (CIs) themselves.

But… what’s the point? All of this requires a lot of additional work to define new relationships, but doesn’t add anything that wasn’t already available through your CMDB and/or business service catalogue.

And it gets worse.

Imagine there’s an incident within your IIS technical service. Since each IIS server is a separate configuration item, it’s highly unlikely that all of them have gone wrong at the same time. In reality, one of two things has most likely happened:

  1.    A business service – payroll, for example – has been interrupted
  2.    An individual IIS server (CI) has gone down

Either way, if you’re relying on your technical service catalogue, you’re going to encounter an issue.

Since each of your CIs is linked to a ‘catch-all’ technical service, which in turn links to a variety of business services, you’ve lost the 1-1 or 1-many relationship between each CI and the business service it facilitates. Without the direct relationships between business services and Configuration Items the running of Impact Analysis is going to be limited within your Incident, Problem and Change processes.

ITSM Software solutions very often require the creation of a Technical Service Catalogue in order to create relationships between business services and CI’s.   This in turn, creates a false priority for the Technical Services Catalogue over the creation of a Business Service Catalogue and the development of a relational CMDB.

Getting More From Less… The Right Way

Let’s take another look at the suggested contents of a technical service catalogue:

  • Links or references to other services which are essential for the delivery of the service
  • Configuration items (which are pieces of equipment)
  • Startup and shutdown procedures
  • Recovery and fallback information
  • Key support contracts

On the face of it, this might seem reasonable… But here’s the thing.

If your business service catalogue is properly defined, it will be linked to your contracts, third parties, the CIs that deliver each service, and so on. If your CMDB is properly defined, it will include contracts with third parties that support individual CIs, as well as technical documentation on how things are built and what they look like.

So what’s left to go in the technical service catalogue? You guessed it… Nothing!

The Sad Truth

The fact is that for various reasons, many organisations have a hard time defining their CMDB and business service catalogue. They assume their ITSM toolset will make everything a walk in the park… and get disillusioned pretty quickly when that turns out not to be the case.

In our opinion, then, the technical service catalogue is being used as a catch-all simply because implementing a fully functional CMDB and business service catalogue is often hard work.

But as we’ve already seen, relying on a technical service catalogue in the absence of a fully functional CMDB and business service catalogue would be extremely problematic. And if you do already have these in place and you’d like to check off the final box? Easy, everything you need is already in place, so defining your technical service catalogue requires little more than a set of links to those documents.

But dedicating time and effort to defining your technical service catalogue before laying the appropriate groundwork could be considered a serious waste of time and resources. Sadly, it’s all too common.

At a recent CMDB workshop, one of our attendants explained that his organisation has spent the past year attempting to define their technical service catalogue. They didn’t have their CMDB or business services fully in place, though, and their time had mostly been wasted on tail-chasing.

The worst part? If instead they’d focussed instead on defining their CMDB and business service catalogue, the technical service catalogue would have practically written itself.

Get it Right First Time

If you’re struggling with your CMDB or service catalogue, we’d love to help. In recent months, we’ve run a series of workshops designed to help you understand (and avoid) the common pitfalls organisations run into when implementing (or improving) their CMDB and Service Catalogue.

The workshops are run by Chris Hodder, one of the leading experts on CMDB and service catalogue design, and we’re vendor agnostic so you’re welcome regardless of which ITSM toolset you’re operating with.

But here’s the thing. We don’t want this to be just another seminar that you don’t get anything out of, so in order to come, you MUST bring at least three interesting CMDB / Service Design questions or problems… and Chris will help you solve them there and then.

Our next available dates are:

LONDON – 18th January, 2017            LEEDS – 19th January, 2017            DUBLIN – 15th February, 2017

Numbers are limited to just eight per session, so act quickly to avoid disappointment – You can register here.