A Fresh Look at Services and Your Service Catalog

A centrally located Service Catalog, available for your users and customers to peruse and choose from, that contains all of your IT services, is an idea that has been around for a long time in the IT Service Management space. And it has only grown in scope and sophistication. What started out as a simple spreadsheet then morphed into a separate application. It is now a standard-issue module included in most robust ITSM tool sets these days.

Whether this blog post breaks new ground for you or simply acts as a refresher, let’s spend a moment discussing your Service Catalog and the types of services you provide. Rather than serving as a roundup of Service Catalog tools and functionalities, let’s stick with the concepts and theories behind the various iterations of Service Catalogs as a way to help you think about the best ways to deploy, upgrade, or even reimagine yours. Along the way, we’ll discuss how a methodology called OBASHI™ just might revolutionize your entire approach to mapping business services and the IT components that support them.

A Service Catalog (or catalogue, depending on your longitude), can be very much like the menu in your favorite restaurant. The menu will list out all the yummy delicacies it has to offer, along with a brief description and prices for each to help you decide what you want. The part of the menu that you, the patron, see corresponds to what we in ITSM call the Business Service Catalog. But the kitchen gets a very different view, called the Technical Service Catalog. This back-office view provides the service providers (kitchen staff) with the recipes, ingredient lists, cooking and preparation instructions, and everything else needed to make good on the items listed in the customer-facing menu. This blog will discuss the relationships between these two views of the Service Catalog and how to go about identifying and defining the Business Services (menu items) you will offer and their place in that Service Catalog.

First Things First: Service Catalog Terminology

This section will act as a short glossary to define the terms I will use later in this post. Let’s begin by defining the term Service.

What is a service?

What this means is that it is up to us, the service provider, to work with our customers to identify how we can help them with technology to meet their goals and objectives. This also means that the maintenance, management, and provision of these services are all our responsibilities, freeing up our customers to use them as needed. A Service Catalog can contain several types of Services and we will discuss them here in this post.

What is a Service Catalog?

Service Catalogs act as Knowledge Management tools for the employees, service providers, and service consumers of an enterprise, allowing them to route their requests for services and service-related topics to the subject matter experts who own, operate, and are accountable for them. Each service within such Service Catalogs is usually very repeatable and has controlled inputs, processes, and outputs.

The Service Catalog is the only part of the Service Portfolio published to customers and is used to support the sale, provisioning, and delivery of services. The Service Catalog includes information about deliverables, prices, contact points, ordering, and request processes.

The tools/platforms that support simple Service Catalogs often provide the customer with the ability to order services, service offerings, and products mapped to pre-defined workflows. More sophisticated Service Catalogs may contain both IT services as well as customer-facing business services. These business services may pertain to internal customers in the form of HR or Facilities Management services and/or they could be for your external customers and describe the services you provide to them. Within the Technical Services Catalog portion of the larger Service Catalog, these services usually have an “IT-only” view that displays “Technical” or IT-facing services – the sort of services that one IT team might request from another IT team (and not something that a business user would ever request. Please see the diagram labeled The Service Catalog from ITIL v3 for a better view.

What is a Business Service?

For example, internal services such as HR, payroll, or facilities, or external services such as the delivery of Wealth Management services to customers of a bank or tax preparation services by a CPA office to its clients.

Business services are likely to be supported by one or more IT services, and in many cases may consist almost entirely of IT services — especially where the IT service is directly customer-facing.

These are the services that will be listed front and center for users and customers to see in the business services section of the Service Catalog.

What is a Technical Service?

Examples of these services would be backup and restore services, database services, software development services, information security services, and the like. To prevent confusion among users and customers, these are not public-facing services and so they will show up only in the view to the Technical Service Catalog which is available only to the IT organization.

What is the meaning of “Shift-Left?”

In a software development context, a shift-left approach might be characterized by moving testing activities closer to (or integrated with) development activities. In a support context, a shift-left approach might be characterized by providing self-help tools to end users.

For lack of a better term – the Actionable Service Catalog

For many organizations, all they really need in a Service Catalog is a place for their customers to access those service requests that are already approved, defined, and ready for customers to access and request. In many cases, these service requests are based on standard changes, those low-risk, preauthorized changes that are well-understood and fully documented — and which can be implemented without needing additional authorization. It is to the IT organization’s benefit to automate these standard-change-based service requests wherever possible to free up service desk staff for more important tasks and to make their provision as repeatable, predictable, and, above all, improvable as possible. This “Shifts Left” these requests considerably and helps to make users and customers more autonomous and self-sufficient.

These kinds of pre-defined service requests often center around granting access or distributing information. We typically see entries like these in the Actionable Service Catalog section:

Request for a service delivery action:

• Provide a report
• Replace a toner cartridge in a printer

Request for information:

• How do I make a pivot table in Excel?
• What are the hours for a particular office?

Request for provision of a resource or service:

• Provide a user with a phone or a laptop.
• Provide a development team with a virtual server.

Request access to a resource or service:

• I need to download Visio to my desktop.
• I need access to a SharePoint site.

And then, the weird ones:

• Feedback
• Compliments
• Complaints

As you can see, many, if not most, of these service requests can be partially, if not entirely, automated. Automation like this adds to the Shift-Left impetus and allows users and customers to get their catalog requests serviced even more efficiently and effectively. And, as mentioned earlier, this is all many organizations will ever require of their Service Catalog.

But we can do so much more.

The Technical Part of the Technical Service Catalog

Before we get to the business services, let’s begin with the IT technical services. These are the IT services that support everything that IT does. (Please have a look at the diagram below for more insight.) If the provision of services to the business is a railway bridge between us, the service provider, and our customers, then IT technical services are the trestle that supports that bridge. The diagram below comes from ITIL v3 and it demonstrates how business processes in the business service catalog are dependent upon the IT services below in the Technical Service Catalog.

The Service Catalog from ITIL v3

Identify each IT team’s service offerings.

Let’s start with the lettered services: Service A, Service B, and so on. A great way to begin this is to identify all the teams in your IT organization and then find out what are the five to ten technical services that each team offers. Some teams may offer more, others fewer, but the goal is to define what they all do. Depending upon on the ITSM tool your enterprise uses, this information may be captured in your Service Catalog. Even if you must store it in a separate database, this is still very important information to manage and maintain.

One way to do this is to list all of the IT tech services and color code them by the team that delivers them. Now you have this all in one place. This will be the universe of IT technical services we can do.

Sort and layer the services you provide to customers.

After capturing this information on your various technical teams and their contributions, the next step is to layer this under the services you provide to your users, even for the service requests listed in the Actionable Service Catalog.

Look again at The Service Catalog from ITIL v3 diagram to see how Service B supports both Business Process 1 and 2. This means if one of the teams that supports Service B is having a bad day, we will know in advance that Business Processes 1 and 2 might feel the heat. Likewise, if Business Process 1 goes down, we do not need to conduct a bug hunt from end to end of all our operations. Rather, we should concentrate our efforts on Services A and B exclusively.

Now that we have our IT technical teams sorted out, let’s turn our attention to those services that IT offers to users and customers.

Mapping Technical Services

Your enterprise consumes lots of services that IT directly provides to the users and customers. In this section, we will discuss how to quantify them and put them in the Service Catalog so that users, customers, and even sponsors know what they are getting and how, when, and where to expect it.

Your first task will be to identify the services that IT provides and then to define them. Common IT services might include VoIP services, data storage, backup and restore, firewall services, and cyber security, for example. Of all those services, probably the most used, understood, and ubiquitous of all is “Email as a Service,” so that will be our example.

While you may need to vary the content, the table below is a good starting place on your journey of service identification and definition. Everything below would be part of a business-facing Service Catalog listing for services.

To support and strengthen the services IT offers, we will want to attend to that back-office part of the Service Catalog: the Technical Service Catalog. Again, this part is not for general consumption; it supports IT in the provision of services. A tried-and-true tool to this end is the venerable service map. Service mapping begins in the data center (or the cloud) and extends out to the users.

The goal is to identify and capture the cloud/infrastructure elements that are required to deliver the service to users, in this case, email. Depending upon the sophistication of your enterprise ITSM tool, much of this work can be accomplished automatically with discovery services. Still, it is important to understand the logic behind this so you can augment with manual tracking where needed.

Let’s walk through the diagram for important content. Again, the purpose of a service map is to capture those elements (Configuration Items — CIs) needed to deliver a particular service, so economy is key. Less actually is more in this case.

• Messaging – In this example, ‘Email’ is an offering under ‘Messaging’.
• Email – We are interested in the desktop-client version of email, not the web client.
• Hardware – We want to identify the devices that are used to provide email. Whether physical or virtual, list the devices here (e.g., email servers, bridgehead servers, and others).
• Software – List only the software titles needed to deliver email, not all the software on these devices.
• Tech Services – I call this the “rooster tail” because of the colors. Please recall above when we discussed the importance of cataloging the IT teams and their technical contributions by color codes. This is where you get the colorful feathers for your rooster tail.
• Infrastructure – While not always on a service map, I like to include this as further support information so we understand how email travels through the physical infrastructure: routers, switches, hubs, etc.
• Settings – This section can serve as a miniature Configuration Management tool in case that practice is not yet mature enough to support your needs.
• Customers – For a less ubiquitous service, it is useful to know who the users and stakeholders are. In this way, we have a listing of who to contact if the service has issues or when changes or upgrades are to be made. For email, it is simple: everyone.

This is a process you can repeat for all your IT services. Now is the time to weigh the value of this exercise versus the effort it takes to capture and maintain the information. Is the juice worth the squeeze? You must decide this for yourself, but this exercise can be quite valuable in the support of highly reliable, mission-critical services.

Mapping Business Services

Finally getting to business services means that your Service Catalog has arrived at its maximum value. Now we will identify and define actual business processes and capture the underlying IT services needed to support them. Some enterprises may already have their processes fully mapped and understood. If that is the case, then your task is greatly simplified. But in many other enterprises, this will be a new and potentially valuable service IT can bring to the business table.

Two good things to remember about business services:

A business service is delivered to business customers by business units. And this counts for both internal and external customers. For example:

• The HR department serving its employees.
• The delivery of financial services to customers of a bank, or goods to the customers of a retail store, or an email service to an employee.

A business service may be supported by one or more IT service(s), and in many cases may consist almost entirely of IT services especially where the IT service is directly customer-facing.

• In a truly digitized company, the difference could be minimal between the customer facing and enabling services.

The first time I did this was for a small, local bank. Their datacenter was an abysmal mess with virtually no understanding of what they even had, let alone what it all did. We needed to figure out what actually supported banking operations and what was just generating heat in the datacenter. To do this, we needed to understand the business services and map them down to the datacenter level. This is how I backed into mapping business services.

First, we got a copy of the bank’s org chart and met with every leader who owned a box. We defined what each team did. As it turned out, they usually had three to eight business processes they performed. We mapped out the business processes and then mapped those processes down to the hardware in the datacenter. The bank would have been happy just to have the business processes mapped, the rest was gravy for them…until we told them that we identified nearly $1.5 million in excess storage. Then they were delighted.

This was a very rough way to do this process. We got a lot right, but we missed quite a bit too. Then a few years later I found what I considered to be the gold standard in mapping business services for IT purposes.

OBASHI

OBASHI is not one of those mysterious Japanese efficiency techniques from the 1990s, but rather, it is a structured approach for mapping logical and physical relationships between IT assets and resources. Think of it as the OSI Model for business services. OBASHI is the acronym for the layers it tracks.

Fergus Cloughley and Paul Wallis of Stroma Software, Ltd. developed the OBASHI framework in 2001 and they provide a formal tool and services to support it. For our discussion, we will look at it as a concept for understanding our business services.

While service mapping is an excellent tool, it begins in the datacenter and moves out from there. Where OBASHI shines is that it starts in the business and then gravitates into the IT sphere. This orientation is critical for understanding business services.

According to OBASHI, IT exists to manage data flow between business assets. The OBASHI layers proceed as such:

• Ownership Layer
• Business Process Layer
• Application Layer
• System Layer
• Hardware Layer
• Infrastructure Layer

The table below offers a more detailed explanation of what goes on in each layer.

The real magic of the OBASHI approach is in the visual diagram. OBASHI has us create a Business & IT diagram to capture this content and arrange it visually in something like a more advanced service map. Below is a very simple example of a B&IT diagram for an R&D process.

Please note that, as described above, just because a step occurs in the Business Process layer does not mean that there is a necessary IT application input. The step can be purely a human activity without any technology involved. Depending on the complexity of the task, there can be dependencies between and among elements on different layers.

This is truly a business-centric view of the services we provide in IT and an excellent way to understand and improve what we deliver. Working with our business customers on this process is truly an exercise in value co-creation.

Continual Improvement

A huge part of the value co-creation mentioned above is our ability to continually improve. Understanding business processes at this level allows IT to partner with the business and respond efficiently and effectively to change, whether it comes from technology, markets or the business itself.