« IT Governance Demystified | Main | Service Catalogs and SOA »

December 25, 2005

Best Practices for Service Catalog Design

Boris By Boris Pevzner

Most IT executive I talk to nowadays have a clear goal to “run IT like a business” (or some variant thereof), and they realize that “IT productization” around a common Service Catalog is an essential first step toward achieving this goal.  So the question I’ve been getting the most lately is not “Why do I need the Service Catalog?” but “Where do I start?”… closely followed by more detailed implementation questions: "How many layers should a hierarchical service catalog have?  Who owns each layer?  What is the relationship between the Service Catalog and the CMDB?"

Until recently, my response has been very much classic-consultative: “Here is a general hierarchical service model (like the one below), here are some examples for how we have applied this model to help IT shops like yours to put together their service catalogs; let’s spend some time together and figure out which one fits you best and use it as a starting point.”


However, in the last few months, as our Service Catalog practice continues to mature (and as the number of the Global 1000 service catalogs we’ve seen and/or helped develop has grown to a few dozen), I realized that we now have enough data to start shifting from the “consultative” service catalog design informed by industry best practices to the “normative” service catalog design based on the industry best practices.

At the high level, this “normative” service catalog design pattern that we are starting to use maps to the following three layers in the service hierarchy:

  1. IT Service Offerings (such as role-based employee bundles, application hosting services, etc.) – these are orderable IT services that an end user in a specific role (employee, partner, developer, etc.) will actually order – either through an IT liaison or directly through a self-service portal.
  2. IT Technology Products (such as specific business applications, email and messaging services, managed database service, “utility computing farm” service, etc.) – these are component services that are not directly orderable, but (a) provide building blocks for the orderable Service Offerings, and (b) directly map to the IT organization’s delivery/support capabilities (the “IT Factory”).
  3. IT Assets (such as servers, networks, facilities, personnel participating in service fulfillment, etc.) – these are grouped into technology-centric silos, which are essentially the individual “work benches” on the IT Factory “floor.”

The hierarchical relationships among these three layers fits well with Charlie Betz’s evolving “ERP for IT” data model, which represents this relationship thus:


Each of these three layers has its own set of organizational owners, key attributes, and use cases; and it is defined and maintained in a specific system of record within the overall IT ecosystem.  Here is a (very abbreviated) table summarizing this information:


Over the last few months, we’ve had good success getting clients to buy into this high-level model.  This has made our engagements more repeatable, as all of our service catalog projects are starting to converge to a common structure, which we believe truly represents current best practices among the Global 1000 IT organizations.

Watch this space as our Service Catalog model further matures and evolves… in the meantime, comments and ideas are most welcome!

Posted on December 25, 2005 | Permalink


TrackBack URL for this entry:

Listed below are links to weblogs that reference Best Practices for Service Catalog Design:


The comments to this entry are closed.