Service Catalog, what do you exactly mean?

These days everybody is referring to a Service Catalog whatever that means. Unfortunately there is some misunderstanding between people as sometimes they are referring to SOA and sometimes to IT Service Management.

An ITSM Service Catalog describes all services that are offered by a service provider. In some cases, all services offered by the IT department of a company. The Service Catalog is part of the entire Service Level Management process. The Service Catalog describes the standard services offered, based on which agreements are made with clients. These agreements are subsequently covered in Service Level Agreements. It also becomes the basis for documenting procedures and processes in an IT organization.

Depending on the purpose the organization hopes to achieve, the service catalog may be rich in detail or simply provide a top level explanation of services. An IT department manages, maintains and supports part of the IT infrastructure of the Organization. This infrastructure consists of a large quantity of products with which services can be provided.

These services are described in the Service Catalog.

To first identify services, we have to work from the perspective of the core business purposes. Then, look at what IT offerings support those services. After the core purposes, we have to move into those supporting areas that IT also serves, such as administrative or general organizational support. The entire Service Catalog should be viewed from the customer’s perspective. Some services can be further broken down into sub services as well.

For every service a clear description and all relevant characteristics are included. Based on this a client can assess the business application and the usefulness of a service for their own organization.

After looking at services from the business perspective, we start to define each service with the following information:

-Service Name (a simple description, preferably the same name the customer would use)
-Service Description (high-level description of the service written in language customers can understand)
-Support Contact Point (Where should the customer begin an inquiry or report problems regarding the service?)
-Responsible Manager (Contact person responsible for the service)
-Customers/Users (What set of customers (specific or general) utilizes this service?)
-Detailed Specifications (Some items may not require all of these elements, but possible elements to include in specifications are):

• Inputs (hardware, software, infrastructure, customer inputs, etc.)
• Outputs (final products viewed from a customer perspective)
• Default items always included
• Optional items the customer may request or pay extra for
• Excluded items which are never included
• Service hours of availability
• Up-time and service availability goals
• Support provided
• Performance standards for the service
• Customer procedures for starting, changing or ending the service
• Charges (if appropriate)
• Disaster/recovery
• Data Integrity
• Security
• Training
• Etc.

A Service Catalog is intended for all clients of an IT department, in other words, the business unit managers and/or their representatives that want to be extensively informed about the services offered by the IT department of his company.

An SOA Service Catalog has another goal: to manage, organise and reuse services. One of the key promises of SOA is reuse on a much more granular level than one could ever hope to achieve with pure object oriented techniques, but reuse isn't something that we get for free. Particularly, reuse problems arise when others within a teamdepartmententerprise don't realise that we have already defined and/or built a particular service that they could reuse.

To achieve in some way that objective, a SOA Service Catalog needs to exist and document the basis of each service. To build such a Service Catalog is not an easy task as you will need to first define the granularity of your services (please refer to my previous post: What is a Service?) which decribes the differences between an SOA Service and an ITSM Service).

As for an ITSM Service Catalog, information has also to be identified and captured:

• Service name
• Description
• Type of service (e.g. business, application specific, data, etc)
• Service level agreements and other quality of service characteristics (e.g. performance, scalability, security, availability, etc)
• For each service operation
• Operation name
• Description
• Request/response messages input/output parameters and possible errors
• Pre-conditions
• Post-conditions
• Whether the operation is idempotent

SOA Service catalogs leverage both Web services (application services (provided by reusable software components) that are typically found further down around the middle of the IT stack) and BPM to eliminate an expensive burden on business. To be effective, that service catalog must contain services in the language of the customer, must be transactional and finally flexible.

For sure both Catalogs relate one to the other but what is contained inside is quite different. The SOA Service Catalog should be considered as a Service Registry. The future will tell us how to link both catalogs once synergies between ITSM and SOA will be better documented and companies will have reach an upper level of maturity in these two domains.