What is the relationship between the Service Catalog and the CMDB?

"What is the relationship between the Service Catalog and the CMDB?"  I have been getting this question regularly in the last three months as more people travel the ITIL maturity curve. As practitioners move from Incident, Problem, Change, Service Request to Service Level Management and Configuration, the service catalog appears as the key link between  these processes. But there's certainly a lot of confusion about how these concepts are related and how to relate these systems operationally. 

So over the next few postings I will lay out the points of integration between the CMDB and the Service Catalog, some of the issues I see with the CMDB vision and a prescriptive path to put integrate the catalog and the CMDB. In these posting, I am less concerned with the purity of theory and more with solving some very specific pains. Any comments are welcome.

Changes in Attitudes, Changes in Latitudes

As IT organizations from a silo, domain centric model of managing IT infrastructure to a service centric model, the big missing factor has been the lack of agreement and understanding about what is a “service.”

This lack of definition traditionally was not a problem, a service was calling the help desk. But with the growth of ITIL and ITSM practices, the "service" is at the center of this process framework.  It is a core element of Service Level Management, Configuration management, and Change management. For descriptions of these terms see here  and here. 

For those who have attended newScale courses or work with newScale software, you know the very practical definitions of a service we use in our catalog so I won’t repeat the definition and structure but re-iterate that a service is always defined from the point of view of a customer.  (I was at a recent Pink Elephant conference, listening to George Spalding, and he said “ITIL is all about the customer. It’s the reason for implementing ITIL.” I wholly agree.)

At its highest level, the service has four major parts, each with many sub parts and attribute. These for major parts are: Offer, Request, Activities and Resources.

There are many, many other elements that make up the service definition; at newScale we refer to these elements as the Service Catalog Reference Model. I will write more about this in the future.

• Offer contains Service Levels, pricing, terms and conditions among other attributes.
• Request contains ordering, configuration, governance and agreements sub-components and attributes.
• Activities include all major IT processes such as Request, Change, Problem, Availability, Financial and Relationship management. As well as others like vendor management and provisioning as      well.
• Resources include elements like vendors, or skills and labor and IT Systems.
  

IT Systems Resources are where the catalog and CMDB link to each other. The CMDB is where an IT system model is kept based on all the configuration items that make up that IT system.

Some vendors refer to these IT systems as “Business Services” – I find that adds to the confusion and misunderstanding to the definition of services. At best, a discovery tool will only discover 50% of what you have in your infrastructure. The rest has to come from logical definition that matters to a customer, that aligns with the enterprise business processes, and that can be compared to offerings from external provider – that is the job of the service catalog.

There are many non-discoverable elements to the definition of a service for a customer, such as pricing, support, delivery, billing, terms and conditions, and more. Add the need to publish the catalog, manage the relationship, track agreements, and the “business service” definition falls short of useful. I encourage people to use the more realistic definition of “IT system.” Leave services to the catalog and IT systems to the CMDB.

The service definition is a central object in the IT organization and it needs its own source of record for managing the service and customer lifecycle and the links to other relevant systems. This source is the service catalog repository. The service catalog is the source of truth for what IT offers to the business and consumers, the place where it’s requested, agreed, and managed. It also should serve as the source of record for planning, forecasting, and financial management. In this service catalog repository, there aspects of the service that feed the CMDB and are in turn fed by the CMDB. The core CI's that the CMDB and the catalog repository exchange is the “IT system” and its relevant sub-components. 

Example: Web Hosting

Let’s imagine an IT department that has a “service offering” of web-hosting at three different levels Silver, Gold and Platinum. The catalog would describe the service, what is included, the price or how is charged and the rest of the elements from the Service Catalog Reference Model that apply to this offering. (For the specific template, see our community site) The service offering also documents all the component services, including support, provisioning, maintenance, backup, availability management, etc. And under resources (“to-be provided”) it details the hardware, software, any configuration recipe that is included in the service at a silver, gold and platinum level. This notion of resources “to-be-provided” is core to the service catalog but not to the CMDB. The CMDB will manage the resources “as-they-are.”

Let’s say the marketing executive needs a new website for a new marketing promotion. The executive or their relationship manager goes to the service catalog and recommends: Web hosting, Silver level, includes Linux, one rack, 1 gigabyte per month, at $200 per month plus $100 per gigabyte of storage. The executive agrees with the recommendation and enters into a hosting agreement with IT.

This agreement now allows requests for provisioning and configuration to be carried out such as ordering servers, deploying licenses, granting access to users –the large variety of IT service activities that are part of the bundled service offering “Web Hosting –Silver”  This ordering, specifying and provisioning process is also part of the service catalog system. The service catalog software may need to tie to an inventory / asset system, CMDB – to update and or provision the necessary systems and settings. It may also tie to change management and other provisioning tools for managing delivery or to vendors who provided underpinning services.

 As the delivery process is building the system through either a workflow system or change management system, the CMDB CI’s are being added, or discovered and reconciled. The CMDB now has a new IT System that it will track, and will report the main elements back to the catalog system. The CMDB will then keep the actual consumption of storage and report it back as a subscription service being used by the specific business unit.

Once the web-hosting service is operational, the service catalog system plays a different role: Where before the catalog was published and ordered a service offering, the catalog software now manages a service agreement; where before it documented “resources to be provided” it now links to the CMDB to show “resources being used and consumed.”

Meanwhile, the marketing executive can go to their service catalog portal and see all the different services they have signed up for, the cost drivers, the service level agreements and the history of requests and consumption that service has undergone. The question of: “What does IT do for me? What does it cost? How well does it do it?” disappears.

And when the storage group needs to make changes in the SAN, they can see which IT system they are affecting, what the SLAis, what business process it is supporting, who to contact to notify, etc. 

The catalog system will manage the major changes to the service (in conjunction with the change management tool) as additional services are added and negotiated. It will also manage the lifecycle of that service– this is what is referred to as Service Portfolio Management. The CMDB will also be provides operational data that may be relevant for SLM and billing. 

Who’s on first? What’s on second? Start with  the Service Catalog

Now that we have a view of how the CMDB and the Service Catalog relate, the question is where to start? The answer depends on the specific pain you are trying to resolve and the level of maturity of your organization.

If you have persistent problems keeping key applications available, then you have to solve that now and doing a point solution CMDB may be the right thing—if your e-mail keeps going down, it makes sense to deal with that first. ITIL is about customer centricity.

Yet for most organizations it makes sense to start with the service catalog first that at least maps to an inventory of applications. Think of this as a first phase catalog. I will include elements such as descriptions, service level options, included services, categories, etc. But it will probably not include all the component services nor pricing or costs. 

You need this first phase catalog because the structure of your CMDB and the relationships need to make sense from the perspective of a service. And a service is always defined from the point of view of a customer.  So defining your services has to come first. This will drive the structure of meaningful relationships which will be updated in the CMDB.

Trying to create the service from the configuration items upward will not work. It’s like trying to construct a meal for a restaurant by documenting the relationship between kitchen appliances—it will not succeed. You start with a menu of offerings (your catalog), which then drive the procurement of ingredients, the assembly of recipes, and infrastructure of the kitchen.

The benefits of starting with a service catalog are several:

First, it will make your CMDB project more relevant and visible to the business because you will be able to paint a picture that aligns with their concerns in a language they can understand.

Second, it will reduce the amount of work you have to do because you can focus on high impact services first that affect your most important customers. Rather than trying to reconcile thousands of CI’s and attributes, you can start with business view of the service and focus on just those aspects that are relevant.

Third, the goal of the CMDB is reduce down time in operations by showing relationships between different items before changes happen. But downtime is also reduced if we can drive down the number of major changes to the infrastructure and are able to make changes recurrent. This is driven by standardization. And the service catalog is the central enabler to standardize what IT offers. Standardization will reduce your costs, and increase your overall systems availability. If you look at ITIL, we normally want to have different types of changes, common names for these are: pre-approved, standard and major. By standardizing services you can move more services from major or standard to pre-approved. 

Fourth, implementing a catalog first will reduce your project risk. An enterprise CMDB project is a multi-year effort; thus it could devolve into a very IT-Centric technical project which by the time it’s complete does not align to the services the customers care about. Starting with the service catalog, ensures that the CMDB project remains aligned with the customer’s concerns.

Finally, there’s the issue of compliance and financial reporting to consider. SOX and its assorted ilk are bringing a new view to IT: risk management. In the next few months, a nice person will step into your CFO’s office asking for some simple reports – stuff that surely is already under available. Your CFO will say, “no problem go talk to … “ You?  Your boss? They will be an auditor asking for documentation of which businesses consume what services and what resources support those services and how the costs are accounted for. They will be concerned with how costs are allocated depending on service consumption; is a business unit underpaying to make results look good? And they will want to understand risk as well. The service catalog will be the key lens through which what IT does will be viewed.

More coming in the next posting. Stay linked!