Service Catalog: To Build or Buy?
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. Lets 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.
Challenges and Costs
It is challenging, to say the least, for an enterprise IT department to compete with commercial software vendors in developing tools. Commercial products receive millions of dollars in R&D investment and offer scale and reliability far surpassing most internal efforts. This is especially important as service catalogs are now more likely to include both IT and non-IT services.
Some of the more popular non-IT services include employee on-boarding and off-boarding for HR, and equipment and office supply orders for the purchasing department. Employee on-boarding can require complex orchestration across many business departments including payroll, facilities, telecommunications, and IT. And functions like purchasing require integration with third party service providers and ordering systems. The service catalog has evolved into a critical enterprise application and requires a tool of that same caliber.
How does the ad hoc tool get multiple language support for multi-national businesses? What is the cost of ongoing maintenance and enhancements? What happens when your lead developer leaves the company? Commercial service catalogs help IT organizations quickly move past these challenges so they can focus on their own unique value add. Rather than spending time developing tools that already exist, IT staff can focus their energy on automating and improving critical business and IT services.
Limiting ITSM Maturity
Beyond the more classic challenges and costs around building a tool in-house, the service catalog is also very much a moving target. Leading service catalogs provide significant value beyond service publishing or automated request fulfillment. Service catalogs are becoming a gateway to higher levels of ITSM maturity. These service catalogs integrate capabilities including demand and financial management, service level management and service portfolio management.
As the central point for linking users and IT, the service catalog is well positioned to track or even control service demand. Leading offerings provide facilities for establishing service costs and corresponding prices. While most IT organizations have not developed to the point of charging business units based on actual usage, service catalogs with integrated demand and financial management capabilities provide greater understanding and control of service costs. Similarly, service catalogs with integrated service portfolio or service level management capabilities, provide far greater potential for the maturing IT organization.
The most common use case is automated request fulfillment, but IT groups need to consider their longer term growth and maturity. Organizations that build their own service catalogs will not position themselves to achieve higher levels of ITSM maturity. Instead they risk sinking their investment into tools with limited capabilities and lacking the quality, flexibility, scale and performance of commercial offerings. Service catalog is becoming so much more than service visibility and automated request fulfillment. For the majority of IT organizations, the recommendation is to start with a commercial service catalog offering.
Paul Burns is a senior analyst with Boulder, Colorado-based