This model catalog was developed so that the special nature of working in higher education could be addressed while allowing sufficient flexibility to be adapted to a wide variety of institutions and to better align with challenges specific to higher education.

Although the terms "service portfolio" and "service catalog" might seem similar, the service catalog is "a database or structured document with information about all live IT services, including those available for deployment. The service catalog is part of the service portfolio."1  In contrast, the service portfolio is broader, encompassing the "complete set of services that is managed by a service provider. The service portfolio is used to manage the entire lifecycle of all services and includes three categories: service pipeline (proposed or in development), service catalog (live or available for deployment), and retired services."2  Figure 1 shows the relationship between the catalog, the portfolio, and IT service management (ITSM) overall. This paper focuses on the IT service catalog.

A mature service catalog is actionable. That is, it includes a request portal that enables users to submit simple forms to request aspects of services. The act of a user requesting access to a service, information, or advice is considered a "service request." Thus, services are a means of delivering value to customers, and service requests are the vehicles by which users request the value to be delivered. Service requests are basically actionable transactions by which consumers interact with and consume services.

Using the email service as an example, service requests can be specifically defined, such as a new email inbox, a new shared folder, or a new distribution list. When a service catalog is actionable, the user is able to search for the service (email) or specific features within the service (inbox, shared folder, etc.) and is presented with a method to request some aspect of the service (see figure 2).

Figure 2 shows three important points:

1. A service request can be a request for a single activity or task, or it can be a request for a bundle of activities or tasks.
2. A single service might have multiple service requests associated with it.
3. A service request that is a bundle of several service requests can contain requests that span more than one service.

For example, a hiring manager can place a single service request, "new hire," which triggers all of the requisite activities that a company needs to execute when a new hire comes on board. The manager need not know or remember each of the specific items in the request. This increases consistency and minimizes the room for errors, resulting in better service delivery. Sometimes, however, someone might need just one of the items in the bundle. When this is the case, that person can simply place a service request for that particular item (e.g., someone needs a new email account).

When devising a catalog, it is important to have a clear distinction between a service and its (possibly multiple) associated requests. In the example above we see that the email service has at least three associated service requests: a new email account, a public folder, and a mail group.

This document does not directly address service requests; the catalog only provides guidance down to the service offering level.

The IT service catalog is published information about all the IT services available at a given point in time. Think of the catalog as a menu at a restaurant and the portfolio as the restaurant's overall collection of recipes, which could include recipes under consideration or being developed (pipeline), those presently on the menu (catalog), and those that have been removed from the menu (retired). A necessary part of maintaining a single IT service catalog is defining specific audiences that will see certain service catalog information based on their particular roles and interests. It is unlikely that all the services in your catalog will be available to everyone at your institution, and people will appreciate seeing a list of only the services that are available to them.

Therefore, a single catalog will typically have many views based on the audience in the same way, for instance, that a dine-in menu might differ from a take-out menu. More important, a customer might be an end consumer (i.e., a diner) or another service-provider (e.g., the family cook who simply wants to buy a jar of the restaurant's famous marinara sauce to incorporate into a dish at home). The former is IT-to-consumer (or provider-to-consumer), the services around which are typically called business- or customer-facing services. The latter is IT-to-IT (or provider-to-provider), the services around which are typically called technical or supporting services. Again, views can determine which types of services particular customers (or customers playing particular roles) should see.3 

Views are one way of managing communication about what services are available to a specific group or constituency. This can be implemented in a low-tech manner, such as allowing visitors to your website to sort services based on their constituency. A more robust solution could leverage your institution's single sign-on technology to automatically filter and display relevant services based on the person's role (see figure 3).

Even within individual services, you might not want to display all the attributes of a service; for instance, the cost of providing the service might be displayed only to IT service providers and governance committee members. Some common views useful within higher education include:

• Faculty (depending on your needs, you might include or break out researchers, instructors, and visiting faculty separately)
• Students (depending on your needs, you might include or break out undergraduates, graduate and professional students, online students, prospective students, and applicants)
• Staff
• Alumni
• Parents
• Visitors and guests
• IT service management/operations/support (might need to see internal attributes and additional information not available to the wider community)
• Governance committee members (might need to see information on costs and other factors related to service delivery)

You might find that a single platform cannot easily accommodate storing and displaying all the information you want to keep in your service catalog. For example, you might want to store the structure of your service catalog within the configuration management database (CMDB) of your IT service management tool so that you can easily see how particular resource outages could affect certain services. On the other hand, you might find that the ability to view the catalog is better facilitated through a document-sharing system. In that case, your authoritative catalog might span more than one platform. Alternatively, you might not be ready to develop a full-fledged service and might find it easier to implement a public display of your catalog on a traditional website. Try to minimize the number of platforms you use for your service catalog and the amount of information overlap between those platforms. Establish and document a process for managing changes in the service catalog so that information is kept in sync.

A service is a "means of enabling value co-creation by facilitating outcomes that customers want to achieve, without the customer's having to manage specific costs and risks."4  The service is about the outcomes the IT service enables the user to achieve, not the activities performed by the IT service provider. When defining services, an IT organization needs to understand the business process the service will enable.

But what does that actually mean? Imagine the outcome you want is an elegant meal. You could do the work yourself, which means you would take on the specific costs (food, table linens, flowers, candles) and the risks (potentially burning the meal). An alternative is to go to a restaurant. In this case, the restaurant assumes the direct costs and risks and delivers something to your specifications, but the outcome is the same—you enjoy an elegant dinner. And even though the delivery mechanism was completely different, both options provide a dining service.

As you define services in the IT environment, it is important to keep the customer and user perspectives in mind. Services need to be recognizable by those who might use them. One of the activities the restaurant performs is to create the menu, and it is important that the items listed resonate with the menu's audience. As a customer, you would not recognize "season poultry" as a service, because the outcome you want to achieve is a completely prepared meal. Translated to the IT environment, "patch server operating system" is probably not recognized by most IT customers as an IT service. Instead, users probably expect this activity to be part of an IT service such as "manage server." The managed server service includes activities such as provisioning, installing, configuring, and maintaining servers in a data center, just as meal preparation includes washing vegetables, seasoning poultry, and cooking ingredients.

This means that services, including what they are called, should be defined based on outcomes desired by the service consumer. Doing so will ensure that an IT service provider will manage all the aspects of service management with these outcomes in mind, thereby providing value to the consumer. In this way, a service might be defined as a discrete element providing functionality and/or value to customers and which includes at least two participants:

• a service provider who offers to perform one or more tasks or activities to a certain specification; and
• a customer who is willing either to accept the offered specification of the work or to request and specify the work.

What qualifies as a service and what does not is sometimes subjective, and each organization will need to come to its own agreement regarding a definition. Depending on the maturity level of the service and the organization's service management approach, additional criteria might be applied to each service. For instance, services might be required to:

• Deliver something of value to the customer (i.e., not be a portion of a larger supply chain)
• Be orderable
• Have measurable metrics (e.g., capacity, performance, relevancy, satisfaction, and cost)

Of equal importance is defining what a service is not. Typically, applications and computer systems provide activities required by an IT service and are not considered services unto themselves.