Service is defined in terms of the CMDB
Dear Wizard
A comment on this IT Skeptic blog said "I have always considered ITIL to be distinct from SM. It considers itself 'good practise' in other words an accumulation of experience or body of knowledge. Wheras SM is based on the concept of a 'service' which is defined in terms of a CMDB. To me both service and CMDB are not clearly defined and lead to confusion. ITIL for all it's faults is a framework take it or leave it wheras SM and iso20000 is a standard based on unclear concepts."
Is it true that service is defined in terms of a CMDB?
Signed
W.T.F.
Dear W
That comment originated from the domain of a major IT supplier. Those guys really know their ITSM and we should listen closely to what they have to say. Of course service is defined in terms of a CMDB. What is a service but an aggregation of IT resources? It is obvious really once you have it explained. All our hierarchal taxonomies need some root entity at the top, and the service is it. That is the primary purpose of a service definition; to provide the base class from which all our technologies can be derived.
Of course some people like to attach waffly descriptions to services to give the business some idea of what we do for them, but that should not distract us from the essential function of service definition, which is to allow us to organise and anchor our technological descriptions of the IT environment.
Good luck!
The ITIL Wizard
Made in New Zealand 
Comments
A service is a type of product
Fed up with making this point Mr Wizard - perhaps you can inject it into your crystal ball for posterity. A service is a type of product and the extent to which a product is a physical good or an intangible service is classified by product managers using the 'goods service continuum'.
The IT audience needs to STOP reinventing the service wheel here.....
Oh - and a CMDB is actually defined in terms of a service.....
you're weakening perfectly good satire
Um, not a root node on a taxonomy. That's the "is-a" relationship, aka inheritance or subtyping. As a supertype, Service might subtype into Application and Infrastructure Service (at least that's how I view it). But it would't be a root node, to Ian's point; it itself is a subtype of Product and we could probably argue that Product is a subtype of that useless abstraction Configuration Item. But this exercise doesn't tell you anything at all about the IT resources supporting the service.
I think you're looking for a composition ("has-a") relationship; we don't use the term "root" there idiomatically. "Containing" or "aggregating" object, component, perhaps package.
To Ian's point, the CMDB itself would be a recursive service back to the business processes of IT.
I get the broader joke...
Charles T. Betz
http://www.erp4it.com
an example
And CMDB is a product - ask any vendor - except where it is SaaS where it is a service sold as a product. So the SaaS provider company would be in a "has-a" relationship with their product which is a service which is a CMDB right? And the client would have a "depends-on" relationship to the CMDB service which defines their own products which are services.
it is important to get this clear, readers, because if you don't grasp it properly you can't function as an IT provider.
Perhaps an example will help. Your relationship to your coffee mug is "has-a" and it is known as a container. Your relationship to the coffee however is "depends-on", and the coffee comes in a package. The coffee is a product and so is the mug, unless of course you got it free from a vendor, in which case the vendor's product "depends-on" the mug. Your mug is part of a service only if the cleaners take it away for you. Your coffee is a service only if you have the kind of PA we all dream of.
I hope this makes it clear - this stuff really matters to providing effective IT support.
Fata Morgana
The problem with a service is that it's often as clear as a Fata Morgana (you know, the sort of images one can see in a desert) but also as intangible a a fata morgana. If you get close to it, it disappears. I think this is one of the most challenging aspect of service management.
On one side we have the business with its business activities and processes. They (ought to be) quit clear in their description and their relative importance to the business. It's the business' reponsablity to manage them.
On the other side we have our IT machinery and soft stuff we call IT Infrastruture and applications. That is (perhaps apart from software) quit tangible and we're well able to manage it, especially on element level (e.g. a server, a router or a desktop).
The point is that the business depend on our machinery and soft stuff to excecute their processes. Business point of view and ours are different. They manage business activities and processes. We manage (combined) elements of our infrastructure and applications.
To fill the gap we speak of services, where we try to define "all our stuff working perfectly together so that business can do it's job the way they want" as "service".
So, if we had a good (and mutually accepted and UNDERSTOOD !!) description of a specific service it would be simple to define which business process depends on that service (and to what degree) and which part of the infrastructure and applications directly support that service. It would be simple to define an agreement that descibes the quality of that service and all we had to do is manage the stuff in a way that the quality is garanteed......... In that way you would rather speak af a SQA (service Quality Agreement) than of a SLA.
I think the biggest problem lies in the good description of distinct services in view of the available budgets.
My two cents worth example: Our French president, Mr. Sarkozy, is sometimes called the "omni-president" because he is always everywhere. So his business process of being president of France would need a service called "transportation". If this service is not available he cannot perform his job the way he likes. As there does not yet exist a "beam me up, Scotty" version of this service, the service would rely on hardware such as plains, trains (well.....I don't think so), automobiles and more and more helicopters, humanware such as pilots and drivers and other things like planning, airports, etc and last but not least security!
He (or his staff) should be able to clearly define the requirements of the service and agree on the quality. As long as the price of this service is not in question you can over-dimension the service so that the quality is always OK. The moment budget becomes an issue........... it might become a challenge!