In recent years service catalog has grown in awareness and a growing number of commercial products are available. Yet the majority of implementations have been developed as in-house or ad-hoc projects. This article outlines the evolution of service catalog capabilities and the trade offs involved in building rather than buying.
As the broad movement toward IT service management (ITSM) continues, IT organizations are increasingly focused on delivering and managing services rather than just technology components. Internally, IT teams use technologies like the configuration management database (CMDB) to capture relationships between the many configuration items (CI) that make up a given service. This is helpful in several ways including giving IT the ability to assess the impact of a proposed change or troubleshoot declining service performance.
Yet, in order to fully realize the benefits of a service orientation, the IT organization must go beyond adopting ITSM tools and processes internally. It must also provide an external view of the services it provides, along with a mechanism to request those services. That is where the service catalog enters the picture.
The IT Infrastructure Library (ITIL) introduces service catalog in a minimal sense as a list of services that an organization provides to its users, whether employees or customers. The service catalog should contain a service name, description and any related options. Better yet, it may have additional information including service levels, service owner, associated processes for fulfillment, types of users eligible to request the service and cost or price information. This primitive form of a service catalog is useful for taking an initial inventory of existing IT services or perhaps even defining services for the first time. Approaching the service catalog as a list of services and corresponding attributes suggests that a simple spreadsheet can be used to implement a service catalog.
However, take note that the spreadsheet based service catalog does not offer mechanisms to automate the requests for services or the fulfillment of those services. Service information has been published, but is not actionable. This is the point at which too many IT organizations decide to develop their own service catalog tools. The thought process often goes like this: “We have some scripts in place to help automate the fulfillment of some common service requests like opening access to a shared network drive. And it is relatively easy to develop a webpage with linkages to these scripts so that users can initiate their own requests. Let’s build it ourselves!” Thus emerges the basic, actionable, “request oriented” service catalog.
Unfortunately, there are a couple classes of problems that emerge from this type of home-grown service catalog. One has to do with the challenges and costs associated with building your own tool. The other relates to limiting the much greater potential that service catalogs have beyond automating service requests.