Skip to main content

ITIL for BAs. Part IV; The Service Catalog

The Service Catalog is one of the primary artifacts of an ITIL-based organization and its orientation toward the business as an IT Service Provider.  The Service Catalog is the source of information on all IT Services in operation or being prepared for operation and identifies status, interfaces, dependencies, delivery levels, and other attributes.  And in the spirit of encapsulation, the Service Catalog is written in the language of IT’s customers, free of the details about how the service is delivered from an infrastructure point of view

Think of the Service Catalog as the IT “menu” and a Service Level Agreement as a particular customer’s order from that menu.  (Service Level Agreements and the Service Level Management process will be the topics of a future article.)

For the BA, the Service Catalog is in one sense an inventory of IT building blocks that contribute to the creation of business solutions.  The BA then is interested in, and dependent upon, the catalog in terms of its completeness, accuracy, and its suitability as the basis for specifying the requirements of an IT Service to meet business requirements.

itil1.png

Because of its importance in expressing IT’s purpose and value, the Service Catalog must be maintained through the Service Catalog Management process.  In looking at the key triggers, inputs, activities, and outputs of Service Catalog Management, it is clear that the BA has much to contribute toward the content and maintenance of a high-quality catalog:

Service Catalog Management Activities

  • Agreeing on and documenting the definition of an IT Service – that is “What do we mean by the term ‘service’?”  Services must defined to a level of granularity and detail to support their use in business cases in terms of functionality, risks, costs, and other attributes of interest to the customer, so the definitions decided by IT need to be useful to the BA.
  • Interfacing with the business to identify and document customers’ dependencies on the IT Services and those customers’ needs relative to business continuity (i.e., recoverability).  When IT is faced with the need to prioritize (and when it is not?!), decisions need to be based on their relative impact on the quality and availability of IT Services – guidance about which is received from those knowledgeable of the business cases for having those Services in operation.
  • Interfacing with the business to ensure that the information in the catalog is aligned to the business.  The Service Catalog needs to be accessible by various business stakeholders, and just as with business solutions in general, the BA would represent to IT any business requirements regarding the operation of the catalog.

Key inputs to the Service Catalog Management process are clearly in the BA’s domain and include:

  • Information on business strategy, financial plans, and current and future requirements
  • Business Impact Analysis – information on the risk, impact, and priority of each service

Much of the BA’s involvement in this process is indirect, addressed as part of the normal set of activities throughout the business solution life cycle.  In fact, many IT organizations have survived without any Service Catalog, so its role and value can be elusive – so let’s conclude with a few relevant points:

  • The goal of ITIL is to encapsulate all of IT in terms of IT Services, expressed in the language of IT’s customers – in other words, ITIL helps an IT organization separate the “what we do” from the “how we do it” – lifting from the Customers’ shoulders the significant burden of having to understand the IT infrastructure and its commensurate complexities, costs and risks.
  • The IT organization’s mission should be to deliver IT Services with a “service culture”: every IT contributor should be able to see his or her contribution to service quality and availability rather than working solely within his or her particular silo.
  • BAs themselves are also very driven to make a distinction between the what (business requirements) and the how (the solution to satisfy those requirements).

Back to the “menu” analogy we started with – imagine a restaurant where you can order a meal only after you understand the details about how the kitchen operates, what ingredients it has in stock, which kitchen tools are available, etc.

What about your IT organization?  What is the maturity of the IT Service Catalog?  Have you participated in the design and operation of such a catalog?