Changing from ITIL will be like metrication

One of these days the world will replace ITIL, or more likely supersede ITIL, with something better. The IT world is evolving too fast for it not to happen. I’m not thinking here – as most folk do – of the advances in technology. ITIL can manage the Cloud, for example, just as readily as anything else. I’m talking about the advances in the maturity of the IT professions, of our better understanding or organization and process, of the growth of governance and assurance.

ITIL truly and fundamentally sucks at governance and assurance. It only knows how to operate and manage and improve. Improvement such as CSI is a simplistic and purely internal form of governance. And ITIL’s attempts at assurance, such as Information Security, are a source of the greatest mockery of ITIL. It doesn’t really address Risk at all. ITIL has almost no interlocks into the organizational governance and assurance around it.

So I am sure ITIL’s days are numbered.

And I’m sure there are already better tools than ITIL around. There are much better languages than English: easier to learn, to teach, to spell. But it is a little late to suggest to the world that we change: Esperanto proved that. So it is with ITIL... for now.

Of course sooner or later the value of changing outweighs the pain of the switch. Look at the metric system: the only countries in the world that have not officially metricated are Liberia, Burma (Myanmar), and the USA. Which of these is not holding out just because it is barmy?

For the USA, the pain of metrication still exceeds the value. I think that is because of five reasons: (1) imperialism – nobody tells Uncle Sam what to do (2) the not invented here syndrome that kept ITIL out of the USA for a decade or two (3) cussed stubbornness and the deep conservatism of the middle class (4) the poor education of the masses who don’t see the value (5) computerisation and embedded technology makes the change bigger - humans are always more flexible than machines (hence my opposition to CMDB/CMS). Also a contributor was that the USA already had a metric currency, reducing the drivers for change.

Even English isn't necessarily fixed for ever. If I time travelled to 500 years from now I'd be not at all surprised to find the international language is Mandarin.

Moving away from ITIL is a lot less expensive and disruptive than metrication or change of lingua franca, but there are analogies we can draw with any eventual shift to a new framework for IT.

Note I say “framework for IT” not “for ITSM”. The view of ITSM as a way of managing what comes out of the pipes at the IT factory is an out-of-date one. ITIL V3 clearly shows what was always there: ITSM is a perspective on all of the operation of IT, internal and external, all of it seen in the context of what comes out of the pipes: services.

ITIL shows it, with internal areas such as Event, Information Security, Application, Release, Availability, Capacity, Continuity, Configuration and of course Problem.

But ITIL treats all that happens in IT operations as if it were happening in a big factory, with the customer somewhere else and the users somewhere else and the governors in another country. For all the talk of business alignment and transparency, it is a big corrugated metal box with services coming out a pipe.

Business integration needs IT to be part of a bigger organization, with integration into the businesses’ processes and frameworks and organizational structure.

So I am sure ITIL’s days are numbered. One day we will shift to something else.

The analogy with metrication suggests the USA may be the biggest obstruction to change. Wouldn’t it be ironic if the USA ended up being the big defender of ITIL and the last hold-out, given its original attitudes to ITIL.

Comments

looking for a Marketing Mindset

Your comment, "The view of ITSM as a way of managing what comes out of the pipes at the IT factory is an out-of-date one." is interesting....in fact I recently commented on this in a response to a post by Ian;

http://www.itskeptic.org/governance-directives-input-itil#comment-5852

as well as on my blog (although I continue to rant here as well about monitoring and Event Management of course) at:

In Search of a Marketing Mindset: The Right Road to ITSM Excellence

The only ones who really care about the plumbing are the plumbers; everyone else just wants a hot shower in the morning. Think about most ITIL initiatives; are they really led by the business? Is the business involved at all? Do they even have their own business processes documented?

Until the business grabs ITSM by the throat (like the rest of IT), you'll never achieve a marketing mindset. In the meantime, regardless of framework, IT is likely to continue to focus on elegant plumbing while the business takes a cold shower.

The IT service management community loves to talk about "alignment" and "integration" with 'The Business'......but it's amazing how many ITIL initiatives are not only IT-led, but have little to no involvement from the Business at all. In some cases, The Business views IT as responsible for documenting business processes... all the while demanding more.. with less... and much faster.

A savage journey indeed.

John M. Worthington
MyServiceMonitor, LLC

People do care about plumbing

On Sunday evening a water main pipe broke under Helsinki Central Railway Station. Due to unknown reason, someone had drilled a large hole in the concrete that was supposed to stop the water in case of such pipe break and the water cascaded down in the main subway station below. The main subway station will be out of business for several months. Improper Change and Configuration Management, I would say.

Proper infrastructure management is important but in most cases it is invisible or just a nuisance. Everybody hates the water people when they dig up streets to replace old infrastructure with new items. I do not think it is a good idea that Helsinki Water would achieve a marketing mindset. (Actually they tried to start selling Helsinki Water in bottles as our water is better and cleaner than popular bottled water brands. They learned that succes in bottled water is in brand management, not bottle content.)

What I'm trying to say is that ITIL was about infrastructure management. IT infra is not as stable as water mains but in many cases the business has taken over the application development leaving IT people in charge of the supporting infrastructure. It is not so sexy but needs to be done. Running IT service as a business is completely different thing.

Aale

Manage water according to ITIL

Good example Aale! By the way, I've worked a while for the Rotterdam Watercompany in The Netherlands (you wouldn't want their water in bottles!!!).
I discovered that for the management of the water (so their core business) they used processes and approches that could be mapped 1-on-1 to ITIL. Gives me interesting example to use in my ITI trainings

the rest of IT

John I agreew with all your points except one minor one "Until the business grabs ITSM by the throat (like the rest of IT)". I don't think there IS a "rest" of IT. ITSM is IT, it is just a way of seeing it.

I'm sure you agree, I'm just clarifying the point for readers

It ain't a tractor

Oh and while we're being tangential, your post's conversation between Joe and Sam remined me of the Yamaha "It ain't a tractor" radio ad from long ago (warning: use of the "f" word) - still cracks me up, and in a weird way it is relevant.

the service IS the pipe

In your post you asked "IT" coming out of "the pipe," I have no idea what is being discussed. The transaction? The service? Both?
In my mind the pipe delivers transactions. To really thrash the analogy, the service IS the pipe. Users consume transactions which come from the service. To answer your other question, I think Service Delivery is concerned with the production delivery of transactions, not the lifecycle delivery of services. I've a feeling you will shake my complacency but for now I'm clear on both of those.

Service Delivery

You created the pipe so I won't argue that... thanks for clarifying :-)

If someone can point me to a definition of "Service Delivery" that lives in a MECE (Mutually Exclusive, Collectively Exhaustive) neighborhood somewhere I'd be much appreciative.

The term actually does not seem to have an official home in ITIL v3... correct? It's not in the glossaries for either Strat or Transition (I am too impatient to pull out the other 3).

So, all we have to go on is the contents of the v2 SD book: Capacity, SLM, Availability, IT Finance, Continuity... my copy still has a Post It showing the original conception of "Service Catalog..."

I tend to see all of these processes as more about the service's lifecycle, and less about day to day operations. "Proactive" was an adjective I frequently saw applied to v2 SD. I don't think any of them landed in v3 SO, right?

But I am certainly no ITIL expert.

Charles T. Betz
http://www.erp4it.com

delivery phase

proactive problem managemtn certainly disappeared out of V3. they are talking about reintroducing it in ITIL V3.1 but how that fits with the "no new concepts" is a puzzlement. I guess "overlooked" is not the same as "new".

But there is still plenty of proactivity about availability, capacity and continuity.

I think the Service Delivery practices are only about the ...well... delivery phase of a service lifecycle. But yes they are more about the management of the system (the pipe) not the daily execution of the system. The whole service lifecycle is about adding, running and removing pipes.

more on mindsets....

Yes, ITSM is IT....but the conventional view (what comes out of the pipe) is what I see as a manufacturing mindset. Not that this is a bad thing, it's just not enough.

I also agree with Aale Roos to some extent; people DO care about plumbing... but typically only when the toilet backs up.....but Roos, this quote I'd like to explore some:

"IT infra is not as stable as water mains but in many cases the business has taken over the application development leaving IT people in charge of the supporting infrastructure."

I'm not at all convinced that the functional separation of applications from infrastructure is a good thing....the view that we can somehow create a "utility" that we can simply plug applications into (like turning a faucet on) sounds good, but doesn't promote effective end-to-end service design. The notion that there is a single demarcation between infrastructure and applications....this is not reality is it? Aren't there many, many touch points between applications and infrastructure? Does it help to create the perception that this is one, clean d-marc? I don't think so.

From what I've seen, the business whips App Dev so hard to get to market that we take shortcuts (lack of adequate testing, peer review of code, etc.) to say nothing of properly identifying the dependencies between applications and infrastructure....going from 4-5 silos to 2 is not really solving anything. We still seem to fall short of establishing true business-oriented end-to-end service management.

Perhaps we have the wrong audience in ITIL classes....maybe the business folks should be getting foundation certs, and understand that what they really want is accelerated services (not accelerated apps)..... :)

In this case the Good Books are right; IT needs a Marketing Mindset. I just feel they cannot achieve it without full participation from the business and leaving IT to the supporting infrastructure (plumbing) completely misses this point.

Anyway, still enjoying the banter....

John M. Worthington
MyServiceMonitor, LLC

Observation, not a recommendation

Hi John

I want to clarify this: "I'm not at all convinced that the functional separation of applications from infrastructure is a good thing...." I'm not saying it is a good thing but I'm saying that in many cases it is a fact. It can be a bad idea but that does not change the fact.

I'm sure there are organizations that do not have this separation. Personally I have been involved in one project which tried to cover this gap but I do not think it was a major success. When the business has been able to wrestle the control over appplications from IT, they will not give it back. If IT management takes this argument to the top management IT loses and may be outsourced. Outsourcers don't argue, they do what they have been told to do.

Both ISO 20000 and ITIL V3 describe this as one entity and maybe that is the future. In that case we should have business folk in ITIL classes because they are in charge of the Service Lifecyle. In the meantime somebody has to take care of the plumbing.

Aale

Outsourcing

I am interested in your comments around outsourcing, if they don't argue maybe thats what the business wants? maybe they are providing the service that "IT" can't. Is this a case of the customer not being right?

I would be very interested to hear from someone at Amazon, or anyone who has migrated key applications to "the cloud" i assume that these clouds are being managed using ITIL principals, In my estimation the biggest success Amazon has managed is to create a robust billing method, one i think we would all be envious of in our own internal orgs.

just some thoughts.

ITIL and it's Future

The advent of cloud computing will place pressure not only on ITIL but also the very nature of IT. IT is clearly evolving from the IT Factory to managing the supply chain that will deliver Technology enabled business service. Disciplines that are currently not "front of mind" for many ITSM professionals must become paramount including Supplier, Service Level and Financial Management but more important will be understanding the Business Demand which fluctuate and IT will need to \ must be able to rapidly implement not only what we consider change but manage the demand without owning all the assets. Does ITIL cover this, yes more or less, are IT organizations focused on these processes, unfortunately, not so much.

Robert E Stroud
Evangelist Service Management & Governance
CA

Syndicate content