Rob England: What is a Technical Service Catalogue?

Amtrak 14th Street Coach Yard (Chicago, IL, US): A railway provides other functions: track gangs who maintain the trackwork, dispatchers who control the movement of trains, yard crews who shuffle and shift rolling stock. It is clear that these are not services provided by the railway to its customers. They are internal functions.

We are looking at railways (railroads) as a useful case study for talking about service management.

Last time we looked at the service catalogue of a railway.

We concluded that first and foremost, a service catalogue describes what a service provider does.

How often and what flavour are only options to a service or package of services.

ITIL refers to a technical service catalogue (TSC).  Where does that fit?

One thing everyone agrees on is the audience: a TSC is for the internal staff of the service provider, to provide them with supplementary information about services – technical information – that the customers and users don’t need to see.

But the scope of a TSC – what services go into it – is a source of much debate, which can be crudely categorised into two camps:

  1. TSC is a technical view of the service catalogue
  2. TSC is a catalogue of technical services

Those are two very different things.  Let me declare my position up front: I believe the answer is #1, a technical view of the service catalogue.  ITIL V3 was ambiguous but ITIL 2011 comes down clearly with #2.  This is unfortunate, as we’ll discuss.

Go back to what a service catalogue is: a description of what a service provider provides to their customers (and hence their users).  A good way of thinking of a service in this context is as something that crosses a boundary: we treat the service provider as a black box, and the services are what come out of that box.  A service catalogue is associated with a certain entity, and it describes the services that cross the boundary of that entity.  If they don’t come out, they aren’t a service, for that entity, depending on where we chose to draw the boundary.  To define what the services are, first define the boundary of the service provider.

Think of our railroad example from last time.  A railway’s service catalogue is some or all of:

  • Container transport
  • Bulk goods transport (especially coal, stone and ore)
  • Less-than-container-load (parcel) transport
  • Priority and perishables transport (customers don’t send fruit as regular containers or parcels: they need it cold and fast)
  • Door-to-door (trucks for the “last mile”)
  • Livestock transport
  • Passenger transport
  • etc etc

A railway provides other functions:

  • track gangs who maintain the trackwork
  • dispatchers who control the movement of trains
  • yard crews who shuffle and shift rolling stock within the yard limits
  • hostlers who prepare and park locomotives

It is clear that these are not services provided by the railway to its customers.  They are internal functions.

A railway provides track, rolling stock, tickets and stations, but these aren’t services either: they are equipment to support and enable the services.

A passenger railway provides

  • on train security
  • ticket collectors
  • porters
  • dining car attendants
  • passenger car cleaners

and a freight railway provides

  • container loading
  • consignment tracking
  • customs clearance
  • waybill paperwork

These all touch the user or customer, so are these services?  Not unless the customer pays for them separately as services or options to services.  In general these systems are just components of a service which the customer or user happens to be able to see.

So why then do some IT people insist that a technical service catalogue should list such “services” as networks, security or AV? (ITIL calls these “supporting services”). If the networks team wants to have their own catalogue of the services that only they provide, then they are drawing their own boundary around just their function, in which case it is not part of a technical service catalogue for all of IT, it is a service catalogue specifically for the networking team.  It is not a service provided by IT to the customer.

A technical service catalogue should be a technical view of the same set of services as any other type of service catalogue for the particular entity in question.   The difference is that it provides an internal technical view of the services, with additional information useful to technical staff when providing or supporting the services.  It includes information a customer or user doesn’t want or need to see.

A technical service catalogue for a railway would indeed refer to tickets and porters and stations and yard procedures and waybills, but only as components of the services provided – referred to within the information about those services – not listed as services in their own right.  I’m all for “supporting services” to be described within a service catalogue, but not as services.  They are part of the information about a service.  Supporting services aren’t services: they are component systems – CIs – underpinning the real services we deliver to our customers.

By adopting the concept of “supporting services” and allowing these to be called services within the catalogue of a wider entity that does not provide these services to a customer, ITIL 2011 contradicts its own description of “service”.

Service Design says:

Supporting services IT services that support or ‘underpin’ the customer-facing services.  These are typically invisible to the customer… such as infrastructure services, network services, application services or technical services.

Yet the in the prior section, such IT systems are clearly not a service:

IT staff often confuse a ‘service’ as perceived by the customer with an IT system.  In many cases one ‘service’ can be made up of other ‘services’ and so on, which are themselves made up of one or more IT systems within an overall infrastructure…  A good starting point is often to ask customers what IT services they use and how those services map onto and support their business processes

And of course it contradicts the generic ITIL definition of a service as something that delivers value to customers.  This is important because the concept of “supporting service” allows internal units within the service provider to limit their care and concern to focus on the “supporting service” they provide and allows them to become detached from the actual services provided to the customer.  There is no SLA applicable to “their” service, and it quite likely isn’t considered by service level reporting.

A railway ticket inspector shouldn’t ignore security because that is not part of his ‘service”.  A yard hostler should make sure he doesn’t obstruct the expeditious handling of rolling stick when moving locomotives, even though rolling stock isn’t part of “his” service.  The idea of “supporting service” allows and encourages an “I’m alright Jack” mentality which goes against everything we are trying to achieve with service management.

It is possible that Lou Hunnebeck and the team writing Service Design agree with me: that they intend there to be a distinction between supporting services and IT systems.  If so, that distinction is opaque.   And they should have thought more about how the “internal” services model would be misused- the problem I’m describing was common before ITIL 2011.

There is the case where the supporting services really are services: provided to us by a third party in support of our services to our customer.  For example, a railway often pays another company:

  • to clean the carriages out
  • to provide food for the bistro car;
  • to repair rolling stock
  • to provide the trucking over “the last mile”

Where we bundle these activities as part of our service to a customer and treat them as an Underpinning Contract, then from the perspective of the services in our service catalogue – i.e from the perspective of our customer – these are not services: they are CIs that should not be catalogued here.  If this – and only this scenario – is what Service Design means by a “supporting service”, I can’t see that called out explicitly anywhere.

Technical service catalogue should be a technical view of the services that we provide to our customers.  I wish ITIL had stuck to that clear simple model of a catalogue and kept IT focused on what we are there for.

Photo Credit

9 thoughts on “Rob England: What is a Technical Service Catalogue?”

  1. Great explanation.  This is a recurring question in the field, many organizations blur the lines too often between the types of services. 

  2. In my opinion a Technical Service Catalogue simply describes the technical skills an organisation has to offer.

    This way an internal organisation can easily assess if a new product can be built and supported.

    Demand Management
    Project Management
    Business alignment

  3. I total agree with you, but for me and when I had read in ITIL “IT staff often confuse a ‘service’ as perceived by the customer with an IT system. In many cases one ‘service’ can be made up of other ‘services’ and so on, which are themselves made up of one or more IT systems within an overall infrastructure…” I had sawn that IT systems where in fact the CIs. But like you said it should be more explicit.
    Great post by the way.

  4. This is an absolute gem of an article, Rob. You’ve made me (re)think hard about the core concepts of SCM and, as a result, my own understanding has progressed more in the last two weeks than it has in the last two years. Thank you!

    For what it’s worth, here’s my thoughts:

    1. The boundary concept is priceless. Everyone working in this area needs to grasp this.

    2. I’m in two minds about reserving the word “service” just for services which IT provides its customers.

    – On the one hand I love the clarity and focus that it brings – a service is always something we do for ‘real’ customers.

    – On the other hand, I’m not sure I’m ready to be anal about it – ITIL does prefix the word “service” with “supporting” or “customer-facing” to indicate that these are different beasts, and we use adjectives to change the meaning of nouns every day (e.g. playing card, credit card, birthday card).

    – It may be a moot point – when I’ve helped clients identify their supporting services (for want of a better name), the names of these supporting services rarely include the word “service” anyway – they end up with names that tend to describe the functions of IT’s organisational units, e.g. “Network Management”, “Storage Management”, “Hosting” (or “Server Management”), “Business Intelligence Applications Management”.

    3. I think it would be great if we could all get away from using non-IT examples (restaurants, railways) when talking about this topic. We all work in IT, can’t we use IT examples? If it promoted healthy discussion, I’d be happy to share a diagram or two that shows my understanding (using a real IT example) of how customer-facing services relate to supporting services and to (other) CIs such as systems, applications and servers.

    Thanks again for the brilliant post Rob.

    1. just to be pedantic: Hosting is a service, even in an internal IT department. The primary service of the classic IT department is to host the systems and data of the enterprise (yes, there are other services too, such as Managed Desktop).

      I really like using non-IT examples. Some folk really get it better that way.

      Thanks for your kind words. I think boundary of a Service catalogue is a really important idea too. it is analogous to 3rd Normal Form data normalisation. Don’t try and make one table store two logical entity types.

      1. Rob, thanks for this great article. I work for an MSP. Our customers pay us for technical services, basically the “keep these CI’s healthy”-service. The users -the employees or customers from our customer- consume the real services: mail and calendaring, file and print, managed desktop, etc. We don’t want to be just a supplier, we try to be a partner to our customers. To prove added value we would like to relate our service catalogue to the catalogue our customer offers their customers/users. Any suggestions?

        1. A customer doesn’t offer a service catalogue to their users. they offer a request catalogue to their users.
          They offer a service catalogue to THEIR customers.

          So be clear which one you mean. See other articles in this series discussing the difference.

          Either way you can align.

          But why?, what do you mean by “relate”? More specifically, what value is it you expect to provide? “Look I use the same language as you” is of no value unless they need you to. If so, for what reason? What do they gain by it?

          Once you are clear on the value they want, you can then be clear on the specific outcome you need to achieve to deliver that value.

          From that outcome(s) you have a requirements definition for the outputs you need to create.

          Now you can design a solution that delivers demonstrable value: you can follow the linkages.

          Does that help?

          1. A little bit late but thanks for your response. Things start to fall into place (after reading some of your books/blogs as well).

  5. I’ve been reading a lot of blogs about this recently. I’ve had a few internal conversations too. My understanding of this topic has definitely changed and I think my approach to this issue has changed (more nuanced) as well. Whether they are ‘services’ or ‘supporting services’ they need to be documented/understood – but the difference is still there in how you think about ‘what your goal’ really is – so I appreciated how you made that a bit clearer with the example of “A railway ticket inspector shouldn’t ignore security because that is not part of his ‘service”

    This was helpful, I’m glad you wrote this.

Comments are closed.