Do we overcook services? ITIL out of line

It seems to me that the technoid's obsession with over-analysing and chasing perfection - what I call ETF: Excessive Technical Fastidiousness - is often applied to the definition of services.

I've not done the rigorous analysis but I suspect ITIL is actually inconsistent between books in what it regards as a service. In particular Service Design wants to treat the underlying IT systems as "supporting services".

Let's keep it simple. A service is paid for by a customer(s) and consumed by users. There is no such thing as a service that is "invisible to the customer" (SD 4.1.4, p62). There is no such thing as a "network service". Service Design is way out of line. A service has an SLA. An underlying supporting system has an OLA. Don't call the underlying stuff services: you confuse everyone, and you give the geeks an excuse to focus on their own little world and ignore the customer-facing services that matter.

If we stick to customer-facing services, and use the concept of service packages (Service Strategy, and if necessary have multiple catalogues for different market spaces (customer groups), then we ought to be able to avoid hierarchies of services except in the most complex of organisations. Service Design says "to avoid confusion it may be a good idea to define a hierarchy of services" (also p62). That's a crap idea. Aim for a flat list of services, bundled into packages where relevant (I suspect the SD authors had not read SS - they don't mention service packages).

If you have more than a few dozen services you are out of control. Customers and users won't read them all; you won't maintain them all; staff won't use them all for classification (e.g. service desk)

Let's avoid making these huge complex structures that only alienate customers and perpetuate the impenetrability of IT speak.


IT business does not use ITIL

IT services as a business is a mature market. The big players have been there for ten years or more and newcomers have been able to capture only small niches. Back in late 1980's the IT service company I was working for was taken over by business people. The geeks did not like the idea that the CEO came outside, he had a PhD in business but no IT background. Then years later the company had grown tenfold without hearing about ITIL.

In 2003 they started studying ITIL, not to learn how to manage the business better but to learn how to manage the geeks in the basement and how to run the business with less incidents. It is hilarious idea that their top management would start to study ITIL Strategy or Service Design to learn how to design the services or how to run the business but if they did it I'm sure their competition would be very happy.

If we are talking about IT business services to customers, then you need to forget what ITIL says. Marketing and sales decide what are the services to be sold in the next years and they have no role in ITIL. Infrastructure people provide the services required.

For internal IT ITIL service design has a bit more meaning. As they are not in the market, they need to think what are the services they provide.

In both cases the real role of ITIL service design is to explain to the employees how their work is related to the services the organization wants to provide. There must be a meaningful connection between the technical stuff and services. The model I have been using before I had heard about ITIL is a matrix of services. One side are the end user services and the other side the technical services. The matrix explains which technical services are needed to produce the end user services. The matrix is not something to be shown to the customers. The geeks must understand that they all work in customer service, that incidents must be fixed quickly, problems solved permanently and that un-authorized change is a crime.


and Merry Xmas to all from very white Helsinki, -9 C and snowing. From my window I see firs with their branches weighed down by loads of snow.

The Geeks in the basement


You've finally revealed one of the best kept secrets of ITIL: In the majority of cases implementation is driven by the need "to learn how to manage the geeks in the basement and how to run the business with less incidents"

90% of the time the fancy strategy talk is just a way to disguise this basic requirement without alienating the workforce. That's why ITIL is really about cultural change.


nice holiday rant.....

Sticking to (externally) customer-facing services sounds good to me, and I'm not going to get wound up about 'service' or 'system' either. Frankly I don't care what you call it; business-driven technology management is the end game.

I'm ok with a Technical Service Catalog that views IT as its market, who (in theory) can pick and choose services to build solutions (services) to customers. I think more often than not it simply avoids the fundamental problem of alignment.

It's the Business Service Catalog that (should) rule, but from what I've seen in many cases the business is as functionally silo-ed as IT is. Frequently business processes are functionally defined in (painstaking) detail or not at all. Get IT involved and the problem gets worse by encouraging inside-out thinking (and more process detail). I'm all for outside-in and lean thinking --- the customer (should be) king!

However you slide and dice the new heart of ITIL (Service Catalog), without an understanding of how business processes serve external customers you may not be headed in the right direction. I favor the Customer Expectation Management Method for this reason.

In a recent rant I said, "If the heart of ITIL© and IT Service Management is the CMDB/CMS or even the Service Catalog, intelligent service monitoring is its soul. You cannot measure without monitoring, and the essence of CSI is effective measurement."

Knowing what to measure, and obviously defining services is a pre-requisite and this should ideally start with Level 1 business processes (those that encompass the total customer experience). So I'm not suggesting we tear out the 'heart' of ITIL©, in fact correctly defining services goes to the heart of the matter (the external customer) if done correctly.

However, once you've succeeded in doing this, mapping these business processes to underlying infrastructure --- where the volatility and volume of measurement data grows exponentially --- is demanding service monitoring intelligence. The Service Catalog will not align IT with the business by itself.

This is (ever so slowly) gaining traction; a services-based approach to improvement, monitoring intelligence and (someday) business processes that are designed with an outside-in perspective.

All the best to Skep and friends for a Happy & Healthy New Year!

John M. Worthington
MyServiceMonitor, LLC

Good points


Some very good points in there. Can I just build on one thing though? Often the difference between the IT perspective and the business perspective is that the business have an emotional (for want of a better word) view of their services. To borrow terminology from elsewhere the business are the pigs and IT the chickens. Attempts to systemize the business view, whether by a service catalogue or a monitoring framework, will fail to achieve alignment if the emotional element is not catered for.



I disagree. I like the concept of supporting services. Very much.

IT delivers service products to customers. Fine.

But, any business worth a da** knows the content and costs of each and every constituent product or service it takes to deliver its products.

Businesses that don't regularly evaluate their costs versus selectively outsourcing similar services that can be acquired outside the organization is wasting organization money. And failing at their duty of being good stewards of corporate resources.

The reality of IT services is that that they are, like prime contractors in any business, assembling sub-services to create the service they offer to their customers. Each sub group is quite similar to a Professional Services Firm or a service group.

If IT hopes to ever gain "alignment" with their customers (perenially the #1 issue, but never achieved) and CIOs hope to gain entree into the inner circle of management then they must KNOW their costs and demonstrate how they are managing things.

Bundling all the costs into one giant pool does not allow for this kind of granular management. And, it doesn't allow for understanding such things as advisability of moving to cloud, virtual machine management, etc.

Supporting services are expenses to the prime service or, perhaps, to other supporting services. Being able to show the value of managing those services to the customer is important to legitimacy and good relationship management.

The "trust me" thing won't work for much longer. Vendors with external services SaaS, IaaS, etc. are marketing directly to IT's customers. HP and IBM have whole business units to market to the business and cut IT out of the deal.

Get busy managing your supporting services so your customers can understand your value. Or get busy planning retirement or a new career.

Cary King
Minerva Enterprises
Managing Partner

data modeler about to call "time out"

I think everyone would agree that the components of the service should be well understood.

The debate is whether the signifier "service" should be treated recursively, or privileged as a root node only. This gets into questions of shared discourse and channels of interaction as much as anything.

The discussion could go on for many beers with no consensus. Does it add value?

Charles T. Betz

reserve the word "service"

this discussion adds value if it improves the quality of service catalogues presented to customers, and improves gthe attitude of IT geeks towards what they are supposed to be there for.

Charles, you said exactly what i was going to say in reply to Cary, but allow me to say it in English :)

I never for a moment suggested we should not decompose services for our own purposes internally, including understanding and allocating costs. Where did I say that? All i said was don't call the supporting pieces "services" and don't expose them to customers (and try to keep the customer service structure flat). I'm concerned about perceptions and attitudes here not theory.

in reality, in practice, the word "service" is unavoidable when talking about third party providers. but you have a "system" and they provide an outsource service to you (NOT to your customer) for that system. the word "service" should only be used in the downward-and-outward-facing context of talking about external service providers. internally and as a component of the services YOU provide it is not a service, it is a system.

if we at least try to reserve the word "service" for delivering value to our customers we focus our organisation on what they are supposed to be there for, we reduce confusion, and we simplify. Otherwise the reductio ad absurdum is that every practice/activity/procedure in the organisation is a service provided by someone to someone else.

When is a service a system?

So, when IBM delivers it to you that is a component of one of your services they will call it a service and you call it a system?

They're not providing a service because it is not directly to your customer?

When someone fixes your car, it is a system? Not a service?

It seems to me that every service is a service.

Why would we want to make up construct like this?

To a manufacturer a part is a part - whether they sell it or buy it.

A product is different from a part, I suppose. Just as a service product would be different from a service.

Cary King

Well, I like the car

Well, I like the car example. Let's say this car is a taxi. It's owner (the taxi driver) provides services to his customers. Let's call this: "transport services".

If the taxi is out of order the taxi driver brings it to the garage to have it repaired. Let's call this: "repair services".

Perhaps the taxi driver is a poor guy who could not afford to buy a taxi so he leases it. Let's call this: "financing service"

So we see lots of services but each to different customers. The person that gets transported in the taxi does not care about al these other services that were needed to enable the taxi driver to drive him form A to B.

We could call this a hierarchy but in my eyes this is no more or less that "good old man" Porter's value chain.

I agree that IT customers should not be confronted with too many different services. All the IT customer wants is a working tool to enable him to do business. He wants to agree terms and conditions to assure him he can indeed do this business. So basically he does not want a SLA, he wants a BLA (Business Level Agreement). Why not give him what he's asking for?

the real service

I understand the value chain (value network is the trendy concept - Porter is so last millennium) and the resulting chain of services. My point is that within the taxi company we want the staff to concentrate on only one set of services: the services to the customers. So the garage provides the repair process or function or call it anything but a service.

Inside the taxi company we also have a mechanic. For pity's sake don't let him call what he does a maintenance "supporting service" because then he can narrow his worldview to just his little "service" and forget the real customer and the real service of which he is one bit.

Exactly the point...

BUT... if in fact you have not one but fifteen mechanics, and you are beginning to question whether you have the right stuff to manage them in house, one of the first things you might do would be encourage more of a service interface around them... essential if you want to eventually outsource.

For value nets vs. chains, see Harmon

Charles T. Betz

apropos links

here... and here.

I continue to question, what is the relationship between application and service? offering a subscription to the primary enterprise ERP system would seem to be a highly visible and sensible "service" offering... while offering a generic "hosting" service much less so... yet too much service catalog discussion ends with the hosting service. Or am I missing something?

Charles T. Betz

Will SPACL solve the catalog dilemma?

Whats your take on the SPACL initiative? I've a few questions and I plan to engage at the site. Do we really want vendors to specify the requirements of a service portfolio and service catalog solution? I'm open on this but do worry that requirements live in the realm of a customer - not a provider.... I am also intrigued as to how others can become members of the 'consortium'.

A major part of me thinks its a healthy initiative but it rather grates that organizations such as the itSMF have not been doing this (as they should have done with the CMDB) - and included it in conference proceedings.....

Just started to review things but first impressions are that it is well put together, but.... the opening definition in the white paper rather smacks of ITIL..... which is disappointing as ITIL is pretty closed minded on all this and still learning. Product Management has the answers.

IMHO a service catalog describes offerings (which are an operational capability but.... we need to maintain a customer/prospect view here) as part of the offer contract provide a service model must support. It is a designed and managed by a team with MARKETING skills and authorized by the equivalent of a product manager....

The content and scope of a catalog should be designed to speak to the requirements of a specific target market (market space). Please note - the paperwork is copyright the SPACL Consortium - what happens to good idea and comment sfrom joe public?

I feel a blog coming on..


Now, you are way out of the line

Hey skeptic, I'm skeptic about your opinion now.
Hierarchic services? Why not, the life is hierarchic. I believe in service like it is defined in Lean: a service is a simple transaction between the Provider and the Consumer (P->C) one-by-one, in the required quantity and quality. "Underlying supporting systems" are services, too but the Consumer is not the ultimate customer, rather another IT function, acting as a Provider in another service (maybe facing the ultimate customer). As the ultimate IT customer is just a Provider of other service or services, like HR or GL in a corporate hierarchy. You shouldn't afraid of the complicate hierarchy of services, because it is just a graph of very simple elementary service relations.

customer-centric customer-friendly

I bet my hierarchal structures are more complex than your hierarchal structures. I'm not afraid. I'm trying to think of the customer first. You should try it - it is what ITSM is supposed to all be about.

Don't expose hierarchal structures to customers in the Catalogue - many don't think in the same complex and analytical way most IT people do.

Don't define recursive service structures with hidden internal services: you only give It staff the excuse to not think in terms of the service delivered to the customer.

Both are arguments that come from the first principle of customer-centric customer-friendly services. I don't think I'm out of line: I'm trying to get us back in line

Its the service request stupid...

Hi Skep - now I am not accusing you or anyone else of being stupid its just a hark back to the infamous Clinton one liner about the economy.... This service discussion is all mambo pambo gobbledygook. What is a service? Its a transaction - yup but whats it made up from?

As a reader of the USMBOK I suspect you've been influenced a tad here by some of the concepts that I penned calling on the product management origins of the definition of a service. Its a type of good. Inside the service box are capabilities, features, functionality - you know what I mean. These enable customers to do things they want to do to achieve their desired results - typically in exchange for something - like air, water, food and $.

What customers do is perform activities - work, which in effect submits a 'request for service' to IT systems - sometimes its serviced invisibly by the 'service transaction engine (one or more application transaction processors)' and sometimes it bubbles to the surface as a request that needs manual intervention.

Services are deliberate bundles of service requests. They are bundled and unbundled based upon market conditions and product management decisions. Again - I need to refer you to the USMBOK for more information on all this. Yup - blatant plug but its good stuff.

Services can be defined as belonging to families or hierarchies, but generally thats a decision related to how cost and/or revenue is counted. Subsets of functionality can be offered as separate services - sure, but they need not be defined in a hierarchy.

What I read out there about 'services' in the ITSM/ITIL realm is generally missing the point and theoretical guesswork - dragging IT organizations into strategies that will likely fail. Oh by the way - its quite ok to have an SLA that speaks only to one service request - there I said it... They'll be dragging me up before some panel of experts soon to punish me for saying such a thing - thats my Galileo syndrome kicking in...

Syndicate content