The heart of ITIL is the service catalogue
Oh dear. “The heart of ITIL is the CMDB”? No it isn’t. Not unless you are looking at ITIL from underneath. Yet another example of inside-out thinking instead of outside-in. Do customers care about the CMDB more than the Catalogue? No. Is ITSM about being customer-focused and service-centric? Well, I thought so.
The heart of ITIL is the service catalogue.
Here is an illustration from my recent service catalogue webinar for a different view of how ITIL fits together:
Of course you can't blame technical folk for seeing CMDB as the centre of the ITIL world.
Nobody is driving the cultural change to restore their line-of-sight to the customer.
The CMDB is cool technology, the catalogue often isn't.
I'll bet more sites have an asset database called a CMDB than have a service catalogue.
I'll bet more sites start their CMDB efforts before their catalogue than the other way around.
Read ITIL V3: compare the coverage of CMDB in Service Transition vs the coverage of catalogue in Service Design. More pages on CMDB than catalogue.
Somebody with online access please compare the number of mentions across the books - I can already bet on the result. Mentions of CMDB will outnumber Catalogue by at least 2:1. Check out Availability, Capacity, Continuity etc and see how many are based on the catalogue. None.
One of the greatest architectural failings of ITIL V3 is the woeful neglect of the catalogue as the pivotal artifact in the whole lifecycle. [no the portfolio ISN'T: even the portfolio pivots around the catalogue]
Made in New Zealand 
Comments
Vendor centric view
In my experience most techies get first exposed to ITIL through the concepts of Servicedesk (in its many forms) and SLAs, and even the most dense techies get that the goal is to improve customer satisfaction (and a measure of accountability, which is often disliked). Seeing the CMDB as the centre of ITIL suggest to me that someone has been overexposed to various ISVs pushing their CMDB as the be all and end all of ITIL.
everything looks like a CI
Good point. I'm busy blaming the books but probably the true villains here are the software vendors. I reckon their constant yammering had a bit to do with the skew in the books too...
Guess it is time to publish Rambling Kid Realitsm's next song
How does a service get into the catalog?
I'm not sure the catalog is the heart either - and I'm leaning towards the customer and their needs and wants, followed by the service portfolio. My logic, based upon ITIL alone, is that a service must travel through portfolio to arrive in the catalog. Perhaps we are missing a 'perspective' here. From who's perspective are we looking at the vital organs of ITIL?
What I do agree with - is that it is not the CMDB - which is a passive, gofer artifact that can ONLY be built with knowledge of services in hand. After all, each CI is meant to be connected to a service isnt it?
The Heart of ITIL
I agree with Ian, the heart of ITIL is the customer and their needs. We identify their needs and align with them when we charter the Service Portfolio. Which means that we are allocating all of the resources necessary to meet the customers agreed needs (at least the ones that IT can meet) through the services we currently offer (Service Catalog), the services we plan to offer (pipeline) and the services we plan to retire (recover resources).
What about the CMDB? Well, if I really take the CMDB out to its fullest, I would define a CI type called "service". For each service I offer, I have a CI that represents it. The attributes of the "service" CI are the same ones that would be in the SLA - things like service times, availability, performance etc. In true CMDB fashion, all of the other CI's that contribute to the delivery of the service are "related" to the service CI.
Back to the Service Portfolio and its chartering. Once chartered, a service enters the pipeline. Sometime in the future the service makes its way through Design then Transition into Operations. At each step along the way its "life cycle status" attribute (a standard attribute for any CI) should be updated to indicate its current status. As the service makes its way along from chartering to operational its representation in the CMDB grows - from an initial instantiation of the service only to include all of the other CIs representing the service. At the end, the CMDB contains a representation of all the services IT provides and all of the CIs required to make it happen.
With that done, the CMDB contains ALL of the info I need for a Service Catalog (Business and Technical). I can "create" a Business view of the Service Catalog by making a query of the CMDB asking for all CI of type "service" whose life cycle status is "operational". I can also create a Technical view of the Service Catalog similarly.
Is the CMDB the heart of ITIL? No - the customer is. However, a properly designed, implemented and maintained CMDB and all of its supporting processes can be be a real big help in making sure that we meet the customer's needs.
I tend to agree with Rob on
I tend to agree with Rob on this.
As an IT Organisation the sole purpose of its existence is to bring value to your customers, being internal or external ones.
All of your value-adding services should be listed in the Service Catalogue, if a customer does't find a fitting answer to his needs in there, well then it seems it's not YOUR customer, maybe he should shop somewhere else or you should adapt your service catalog. You shouldn't try to force unneeded services on him, it will only mess up your (long-term) relationship.
To me a service catalog is THE point to start to think about your CMDB. If you use a top-down break-up approach from services to IT components, you make sure you don't create any administrative overhead by documenting alot of unnecessary CIs. As this documentation is always managed by the operational teams, they often look at is as a burden, without actually realizing its potential. This is where a service-oriented mindset comes into play.
If you ever want to break down all traditional silos in an IT organization, you should learn your resources to "think service, not CI"