ITIL V3 Business Service Catalogue and Technical Service Catalogue are different views of the same services
It seems Technical Service Catalogue is often misunderstood to mean a catalogue of different services from those in the Business Service Catalogue. It's not. It is a different view of the same services. ITIL SD 4.1.4 sadly refers to "supporting services, shared services" within the TSC which I think contributes to the confusion, but diagram 4.3 makes it clear - the services are the same in both, just the perspective and detail differ because of the different audiences: internal and external.
Processes, functions and composite CIs or "systems" are not services. They are the detail needed behind each service in the TSC.
Technical Service Catalogue and Business Service Catalogue are the two faces of one coin.
Made in New Zealand 
Comments
Agree, but I think it's also
Agree, but I think it's also too easy to conclude that one should have Configuration Items as the 'next layer' underneath the Service Catalogue. With SOA, it obviously makes sense to have a definition of some of the lower layer services, and the only obviously place is either in the CMDB or as another Catalogue wedged between the Business Service Catalogue and the CMDB. Once having thought that through, does it seem right to conclude that the Business Service Catalogue is just one (the top) layer of an n-layer structure? I.e. it's the top-layer of a CMDB. My business only has the top layer, we have no true CMDB currently, it's less important.
SOA "services" are CIs
We've discussed this elsewhere on this blog: just because two things are called a "service" doesn't mean they are the same thing. In fact, what ITIL defines as a service and what SOA defines as a service are utterly different.
SOA is about APIs between software. it has nothing to do with the exchange of value and risk between human business entities. (Or if it does, that is because it is an enabling technology to a "real" ITSM service defined elsewhere)
SOA "services" are CIs. [Stuart Rance pointed out that ALL services are CIs. Touche. What I meant of course is that SOA "services" are not services in the CMDB, they are subsidiary components of services, and well down the stack at that.]
Yes, the service catalog has at least two views
A third one is the requestable view.
The confusion or difficulty with this concept is that many people are working on flat Microsoft Word documents -- how do you do different views to a word document?
Or how do you uses a technical service as a component of a business service if it's all flat?
:) yet another technical fix to a non-technical problem
yes I agree ITIL omits the third view.
I strongly recommend against clients treating technical services as components of business services. then they are NOT different views of the same thing and it entirely destroys "line of sight" to the customer for those working with the "technical service".
My experience is that service definitions are quite static enough that Word documents work just fine. Sorry but I think technical solutions are overkill :) yet another technical fix to a non-technical problem: getting the mappings is the easy bit, getting customer understanding and agreement is harder and a Word document is infinitely easier to use as a discussion tool than some online app.
CMDB is so last decade, now it's Service Catalogue as the product du jour
A rose by any other name
I'm sure vendors have railroaded us into routinely misusing the term service catalogue.
When someone uses the term to me I still have images of a customer and IT manager skipping together through the long grass on one of those impossibly long summer days that you only see in....sales catalogues. If I want to know what service I'm actually getting I'll look at the SLA. And if I want to order a PC, as opposed to knowing the service levels for ordering a PC, I'll use an on line request management tool
From CMDB to Catalog Madness....
So, we're on to Catalog Madness as a replacement of CMDB madness... the Guidance also states, "Some organizations only maintain either a Business Service Catalogue or a Technical Service Catalogue. The preferred situation adopted by the more mature organizations maintains both aspects within a single Service Catalog,.."
I honestly have not seen too much of this. Mostly what I see is more bottoms-up service definition, similar to the way we (tried) to build CMDBs. You could also view this as Inside-Out thinking on the part of IT. Even the new 'standard', SPACL, seems to reference the Technical aspects of the Catalog. (see Lost in SPACL: The Customer is (still) King) This leads me to believe we're (IT) still stuck in an Inside-Out, bottoms-up mentality.
Top-down service definition starts with understanding business processes, and it is not uncommon for businesses to define processes the same way IT does....from a functional, internal perspective. If we believe in the CMDB, Service Catalog, et al as good concepts for understanding and documenting critical dependency data then we should start at the top of the food chain --- the External Customers of the business.
Of course, I'm not suggesting that The Business has always done a good job of this either, which is why I like to suggest that your ITIL© Road Map include a Lane for the Business..... Even with the new Version 3 'heart' of ITIL© (the Service Catalog), a lack of documented business processes often results in a Technical Catalog of Services and automated Request Fulfillment improvements. This mirrors IT's view of the world and continues what is a bottoms-up approach to service definition.....and the Good Book says, Design Top Down ----- Implement Bottom Up.
For me, if the heart of ITIL© and IT Service Management is the CMDB/CMS or even the Service Catalog, service monitoring is its soul.....been bloggin' about this for some time now (see the Fear & Loathing blog) as I track the Savage Journey to ITSM Excellence.
Unfortunately, most monitoring products & projects are as silo-ed as many ITSM initiatives, and so the Savage Journey continues...
In any event, designing from the top down should remind us that before we get into the nooks and crannies of our 'end-to-end' services we'd better understand what 'end-to-end' really means. This requires Outside-In thinking by both IT and the Business. We (IT and the Business) are not supporting two different services ---- there is only one....
and it starts and ends with your External Customers.
John M. Worthington
MyServiceMonitor, LLC
Interesting...
If I read between the lines correctly, it sounds as if the Service Catalog (and CMDB, natch) will always be sub-optimized, unless there is a mature BPM existing in the business that focuses on customer facing processes. I can see that. How much more valuable would the Service Catalog be if the services it describes were linked to those outward facing processes? I'd say lots.
It is similar to something I have seen around Service Continuity Management as well. The business' processes are so ill defined they can not tell IT which are their most critical!
DaveT
A service catalog for every audience....
Pleeeeeze!!!
I agree with John here. The current service catalog push is destined for failure - from a customer perspective - soon to be replaced by Business Service Management, or some other artifact. What ever happened to the CMDB Federation? My eyes bleed with frustration. Process, capability, best practice, technology and even service led service management initiatives are 'inside-out', they lack the customer view (see latest blog here - Is inside-out thinking threatening your ITSM initiative?).
Remember what happened to the buggy whip industry... ?
Why can't we get this straight.... The only reason many IT organizations exist, is to provide service to their users, they are CUSTOMERS. The service catalog is a marketing and communication tool. Its no different from the Victoria Secret catalog I see arrive every time my wife buys something from them, carefully tailored to pitch similar, or seasonal items. The better the marketing based understanding of the customer, and their desired results, and that leads to their value proposition, the less effort to market, close a sale, and of course less provisional costs.
If we looked at what is all around us - the non-IT universe - there are heaps of lessons to be learned. I started a post on this a while ago on linkedin - please join in... its entitled 'The Great Service Catalog Myths
In brief, its ok to have a catalog facing every customer if need be, but sense says someone is going to profile you and put you deliberately in a (target) audience. Its ok to have a technical, business and okeykokey 2000 catalog if you want.
Just put it on a portal, or provide an access point the customer prefers. Be prepared to start with individual requests and please involve both the customer and a marketeer. You will save so much time, effort, and investments in technology.
Is anyone worried that the vendors have to get together as a consortium to figure out what to do?