A recent survey suggests that two thirds of large organisations are looking to implement a service catalogue in the next few months. However, the same survey also stated that less than half could articulate what benefit the service catalogue would be to the business. Looks like we are in a classic technology hype cycle!
This certainly fits with our experience. We have been talking to organisations for over two years on plans to develop or purchase a service catalogue. Very few have one in place yet, and none have the full multi-tier service catalogue structure from the business down to IT components.
However, as I mentioned in a previous article, most SOA effort has been directed towards creating a service registry and repository to allow more effective governance and re-use of IT services. So where does the Service Catalogue fit into SOA?
What is a Service Catalogue?
In its simplest form, a service catalogue is a list of services provided by a organisation or function to a service consumer (external or internal customers) detailing the Performance (time and quality service levels), Functionality (a description of the inputs, outputs and transformation provided by the service), Costs (and cost model), and Delivery Model (how the service is provided). Some service registries contain a lot of this information, but few contain some of the more commercial attributes mentioned here. Also, , more information needs to be recorded for complex services amd design patterns than fro atomic services, and this capability is missing from many registries.
Why do we need a Service Catalogue?
In the new world of self-service and loose coupling, the ability to define what you offer in a standardised form to enable clients to understand and consume them efficiently is a key component of the way in which organisations are re-structuring themselves. The internal consequence is a multi-level set of business, functional (e.g. IT) and component (atomic) services that describe the internal (and external) supply chain and dependencies of the organisation.
Of course there is a great deal of confusion over the difference between a Configuration Management Database (CMDB) and a service catalogue particularly in the operations and service management functions of companies. Most internal IT departments now have a CMDB, linked to a help desk and change function. However, traditional CMDB products do not store the breadth of information to provide service catalogue capability. Some of the larger outsourcing companies have mature service catalogues as this is key to their costing and charging model and is defined in their contract with the client. This practice is now spreading to become standard practice for leaner, reshaped IT departments.
How do we build a Service Catalogue?
Because a service catalogue can provide a link from the business services a consumer or business customer can order, through to the atomic infrastructure services that perform some of the component functions, it is important to understand what information you currently have, and how easy it will be to create the complete service design and bill of materials.
Many organisations have a (partially complete) CMDB that describes the atomic IT services and components they have identified as part of their infrastructure estate. This is a good starting point for a bottom up build of the multi-level set of service catalogues you will eventually need.
Some organisations have created a separate set of business services that are offered as part of an end to end process view of business operations. This can act as the business layer for the service catalogue, but will require a detailed drill down of the IT (and other support) services consumed to deliver the business service.
To pull these layers together will require a mapping exercise of each service layer against the layers above and below. At this stage, this information can be captured in a spreadsheet or simple database. It is best to start with the list of attributes that are required for each layer so that the right information is sought and documented.
For a simple three layer service catalogue this first mapping exercise will identify the scale of the challenge. If this then looks quite daunting (which is true for most companies currently), then break down the exercise into three and start with either the business services (for those with a clear view of the business through perhaps a process mapping approach) or the infrastructure services, which for most companies will be simpler as you can start with the CMDB.
Once you have collated the service catalogues and understood what information is important to you, it may be wise to explore the commercial service catalogue offerings available. Some will have been developed as extensions of current CMDB or SOA registry products. Others have been designed from the ground up as standalone active catalogues offering a self-service to various stakeholders, with active and dynamic service discovery features. This is a immature but rapidly changing field currently, and the best fit for you will depend on your specific needs for features, and how you wish to integrate the functionality within your governance framework.
