Author: Mads Ruben Rennemo Written: January 2024

Whenever someone asks me, ‘How should we structure our Service Catalog?’, my first question back is ‘What do you mean by Service Catalog?’.

Sometimes this leads to hard discussions, and I'm sure a lot of you have experiences, good or bad, enlightening or horrific, revolving around this topic. That's why I decided to write a few words about it from my point of view, together with some messy slides, and perhaps some insights to make the conversation smoother.

Disclaimer: Our organization delivers a product for managing and tracking service-based IT cost and internal prices, as well as consulting in the management of IT.

Most of the major ITSM vendors have one thing in common: They fairly consistently refer to managing the “Service Catalog” as a way to update the items in the self-service portal. They’re not entirely wrong, and self-service is an important way to market the organization to its customers – but in order to successfully manage IT in a service-based way we have to realize that self-service is only one part of the picture.

In ServiceNow for instance, the Service Catalog is described as: Deliver products and services through a user-friendly interface. Empower employees and customers with self-service and faster request fulfillment.

In BMC Remedy you had Service Request Management (SRM), which is said to publish a Service Catalog where users can request what they need.

In Peregrine HP Micro Focus OpenText ServiceCenter Service Manager SMAX, there is a separate Service Request Catalog interface that lets you perform self service actions based on the Service Catalog. Fun fact for those who didn’t know: The CTO of Peregrine Systems was Fred Luddy, who later founded ServiceNow.

 

The piece that’s missing when only looking at Catalog Items, is the actual definition of the Service itself and the Service Offerings that belong to it. What’s also important for IT organizations, is the modeling of the rest of the underlying infrastructure, and how it is set up to support each Service.

In the document “Defining IT Service for the IT4IT Reference Architecture” by The Open Group from 2016, they are quite open about the fact that there are challenges with service terminology, and particularly in IT. “Even within the IT4IT content, the term “IT service” may be shorthand for any of the three (the interaction, the offers, or the system/service system). This will not be easily changed in the industry, but the alternative is to continue having confusing and unproductive interactions on this topic.”

The Service Catalogue is the most important piece of master data for managing IT as a business, connecting all the other Service Management practices and processes together. Whenever you create a new Incident, Change, Problem, whenever you have an SLA breach or the business complains, or whenever you handle a Request, it is related to one of the Services in the Service Catalog, which lists all the major classes of items we are managing and delivering together as an organization.

There are many standards for service modeling and defining the relationship between services, business functions, business processes, applications, service catalogs and IT infrastructure. Here are a few:

• The TBM Taxonomy, which describes Cost Pools, IT Towers and Services as a guideline for implementing Technology Business Management
• The ServiceNow Common Service Data Model (CSDM)
• The BIAN Service Landscape from the Banking Industry Architecture Network
• ArchiMate, TOGAF, IT4IT
• Ex-HP Universal CMDB & Service Manager Unified Data Model
• BMC Atrium/Remedy’s Common Data Model

This modeling is directly related to the ITIL v4 practice ‘Portfolio Management’, that consists of our Programs, Projects, Services and Products. The portfolio items are grouped further based on their lifecycle, where new services are ‘In Planning’, current services are ‘Operational’, and past historical services are ’Retired’. The Service Catalog only contains Operational services.

Services from the TBM Taxonomy

The TBM Taxonomy handily provides a best practice Service list, from Service Type and Service Category all the way down to predefined Services. At the bottom of the TBM Service Hierarchy comes the Service Offerings, which it includes some examples for, however the idea is that these will be provided individually by the organizations implementing TBM.

Modeling Services with Service Offerings and Service Elements

Most of the service models referenced above include some sort of Business Application class. In CSDM the Business Application appears to be a parent of the Application Service. In the UCMDB UDM, a Business Service may depend on one or more Infrastructure Services and/or Business Applications. The TBM Taxonomy appears to be lacking this point of view, or it has been compounded into services such as ‘Application Hosting’ and ‘Foundation Platform’.

We have decided to simplify these views drastically and claim that we have 1) a Service, and 2) a Service Offering/Service Element. Whether the Service is an Application Service, End User Service, Infrastructure Service or something else, is defined by the Category given to the Service CI.

As Applications are also delivered by the IT organization at a cost and consumed for their value, they should be part of the Service Portfolio as well. However, we don’t see the need to model a separate Business Application for them, as they can also be very well represented as a Service with Service Offerings, where the Service is of Category ‘Application Service’.

What we do however need, are some sort of component below each Service that allows us to model individual things that are not Offerings. We have chosen to call these ‘Service Elements’, and one example of their use would be an Email service that requires a Microsoft Exchange Production system, but also a Microsoft Exchange Test system for verifying and testing changes. In order to make change management, incident management, service measures and monitoring work properly for the Email service, we have to be able to distinguish between production and test. This can easily be done by creating two different Service Elements for the Service. They are not offerings, because the Exchange test environment is not something that we offer to customers, but they reside on the same level in the service model.

Here are a few concrete examples: End User Service

Infrastructure Service

Application Service

Does every service have to have a service owner and/or service manager?

Yes. At least you should strive to achieve ownership of every service, also for internal services. Some services may not be very material or important, but without ownership there is nobody accountable and nobody to manage the service – and then the question would arise: Are we even delivering this service?

The Service Owner should understand their own Service and Service Elements, and what impact introducing a new Service Element for their Service will have; in the service catalog documentation, in the Catalog Items, in the financial model, and so on. If the service is an application, the service owner is the de facto Application Owner.

Service Request Catalog Categories and structure

The structure of your Service Request Catalog will usually be completely different from your overall Service Portfolio structure. The reason being that the Service Request Catalog has to be as easy as possible to navigate for the self-service portal users. That means that we group Catalog Items together in a way that makes it logical to find them for an end user, regardless of if and how those catalog items are related to our Services. An example: New employee onboarding may trigger tasks related to many different services, such as an IAM/Identity & Access Management service, where the account is created and initial permissions are given; or a Holiday Tracking service, where your initial number of holidays per year is registered.

Business Services & Supporting Services

If you are in the IT organization, you will normally not be modeling Business Services. If you do, good on you! It means that you have a clear and concise understanding of how the Core Business operates outside of IT and how the IT services are consumed - which means you have a high maturity level and you are probably acting as an advisor to the business, focusing on real business outcomes. This is a large part of what we want to achieve.

Another item I cannot stress enough, is that the outcomes that a service provides to its consumers will differ depending on your point of view. I often hear that you can’t have a ‘Virtual Server’ Service Offering – because the business doesn’t care about what type of server they are using under the hood. This is correct, the business might not care – but ‘the business’ is not the only consumer of services in your organization. If you have a team performing Windows server management, and another team performing Linux server management, the services that they deliver will in fact be, servers. They do not deliver business applications. They are not delivering an Email service that the business can understand. They are delivering outcomes to another part of IT, mainly the Applications department, the End User department or similar. And for those consumers, having the ability to order and use a stable, managed, priced, standardized server, is a valuable outcome.

Is the Service Catalog part of the CMDB?

Yes. The services in the service catalog would normally be created as Configuration Items (CIs) in the Configuration Management Database (CMDB). These records are powering the other ITIL processes in the organization, such as Incident and Change Management. The Catalog Items that make out the self service portal are also considered to be part of the overall Service Catalog.

Should I model individual environment instances (Dev, Test, QA, Production) of my business application as separate services?

I like to take the organizational standpoint here: from a business and management point of view, different environments are almost always considered part of the same service. That’s why we recommend creating separate Service Elements for the different environments, but together within a single Service per application in the category ‘Application Services’.

This way, there is one Service with one Service description and one Service owner, but you still have full modeling support to enable the rest of your processes & practices.

Doing this also enables us to allocate cost separately for the different environments, and optionally also to a separate Run Service Element and Build Service Element. We can then decide whether Build cost is part of the Run price per application user, or if we recover our Build cost using a different methodology.

In what form is the Service Catalog represented and maintained?

This might sound like a trick question, but you’d be surprised. We usually recommend organizations to create an Excel or spreadsheet for their service catalog.

The single most important thing is that you have one list in one place that everyone in the organization can view and are able to find. Everyone might not be allowed to view every element in the Service Catalog, so you might provide several different views on the same dataset. There should also be one person or team in charge of managing the actual list of services. This would be the Service Catalog Manager/Service Portfolio Manager.

Why is the service catalog not in ServiceNow or your IT management system of choice? It could be! But then everyone needs a ServiceNow license to be able to view it. The service catalog might also contain many services that are delivered by the organization, or are charged out, but that are not operated through ServiceNow currently (for instance you might have a pool of Project Engineers that your business units may request on demand, so you create a service for it with an hourly price to charge them, but the process of requesting and delivering an engineer is not yet onboarded into ServiceNow).

Do I have to create and maintain a large document describing every service?

No. You don’t. Sometimes organizations get so wound up trying to write 50-page documents for every single service, that the service catalog doesn’t stand a chance to ever reach version 1.0 (sorry to all the organizations that feel personally affected by this statement; you’re not alone in trying to do this!).

Start by making a simple service list; go broad and put down what your think your organization is delivering. Usually it works best if this task is delegated to each department and each team. Then you can review the output and home in on the most important services first. Describe what they are for, make sure they have a clear ownership defined. Outline the Service Offerings and Service Elements for each Service.

For many large organizations that have IT service contracts to deliver their services internally to the various business units, the story is a slightly different as they would have a clear requirement to describe their ‘customer facing’ services using legal language, including support agreements, service guarantees, delivery times, service security, governance, pricing, invoicing, and so on. Even still, this is a body of work that is gradually achieved and where you have deadlines in advance. By starting with an initial broad overview, you can focus on expanding the information and documentation of the areas of highest importance.

Do I have to describe my processes?

Yes. If you don’t, it wouldn’t be much of a process – people will not be able to see how the process is supposed to work, and they will be making up their own steps along the way – and probably make different steps with each execution. This makes it hard to optimize, and you end up being dependent on individual people for performing tasks that could have been written down in order to be explained and executed by others.

Does my Service Catalog have to be beautiful?

If someone starts using adjectives such as ‘pretty’ and ‘colorful’, they are probably talking about the Service Request Catalog and the look and feel of the self service portal.

Muninex

In Muninex we allocate the cost that you've booked in your accounting system to the different services in the service catalog using a variety of allocation methods. We call this the direct cost of each service. Afterwards, we allocate from service A to service B to service C, depending on how the value chain is built up. You then get direct cost + indirect cost, combined to give you a Unit Cost and Total Cost of Ownership per service, which opens up a whole new set of possibilities.

Thanks for reading!

What is your opinion? Does this approach resonate with you? Was it already obvious?

For direct questions or feedback please let us know on contact@madsruben.de.

Was this text generated by AI? No, it was written by a human (this you can see clearly from the lack of using the word ‘Certainly!’). But probably it will become part of the AI corpus and can be used for automatically generating similar content in the future. Cheers!