The true scope of service management and ITIL
Service management is IT. It is a way of describing how to do IT - all of it. When it comes to the scope of service management in general and ITIL in particular, the IT Skeptic has had a change of mind. In the past I accused ITIL V3 of having aspirations beyond its station, of trying to take on areas where it has no business going, such as strategy, applications and security. I don't think so any more: now I just think ITIL did it half-heartedly, too anaemically to be taken seriously by areas of IT outside of IT Operations. But Service Management definitely should go there.
I am much enjoying the columns (blogs) on the newly revised ITSM Portal. If you think the IT Skeptic is rough on ITIL V3 and Castle ITIL, you should read Aale Roos on Can OGC fix the fatal flaws of ITIL V3?. I'm with Aale on all the flaws except one. Aale says
The third fatal flaw is the attempt to rule the world. I have been arguing this with the IT Skeptic, who is a great fan of CobiT and argues that ITIL should cover the same area. We should remember that ITIL stands for IT Infrastructure Library. ITIL was designed for a limited audience of IT infrastructure managers and it has been a great success there...
it is now quite common to separate the roles of Information Management and IT Services. The CIO is in charge of IT architecture and application development. IT Services manages the infrastructure and sells their services to the CIO.
Here I take a different view, as he points out. I say service management (SM) is not something that happens in one department of IT (or any industry). SM is an approach, a philosophy, a perspective. We approach IT in terms of the services eminating from it instead of from the perspective of all the cogs and wheels inside it.
The first, most visible, outer layer of IT are the customer-facing and user-facing functions (I don't want to call them "processes", that is too limiting. There are roles and practices and RACI and tools and all sorts of other stuff wrapped up in each division or area or... function). Customer facing functions include demand and portfolio and SLAs and SL reporting. User-facing functions include catalogue and service desk and request.
Then behind (from a service perspective) these outward-facing functions are the internal ones that deliver to them: procurement, projects, solutions, development, change, test, evaluate, release, availability, capacity, continuity, event, operations, security, incident, problem, ...
And behind those are the functions that provide policing and support: governance, strategy, financial, HR, training, architecture, audit, asset, configuration...
All of these functions can be seen and designed and structured and interlocked from a SM perspective. They are all part of SM. SM is just the (currently-)best and most widely accepted way of thinking about doing ICT. You can't divide IT into SM and not-SM; that is nonsensical.
I like the analogy of serrvice as a pipe discharging water. All the customer and user see is the tap and the water. In SM we manage the pumps and reservoirs and mains pipes and purifiers in terms of the water delivered. What is meant by "SM and not-SM" is more "visible from the end of the pipe" and "not visible from the end of the pipe". But when managing from a water point of view the pumps and pipes are just as important. SM is about how we think about IT, not what we think about.
So I'm (now) all for ITIL expanding scope. ITIL has a right to manage applications and security just as much as change and servers. Unfortunately ITIL V3 did it half-heartedly. It stayed completely out of other areas it should have covered, such as project management and HR and training.
I have been advocating COBIT because it has a wider scope, almost complete. Once it goes to a similar depth as ITIL, which I hope it will in COBIT 5, then I see it displacing ITIL as the first choice framework of the industry. In fact I think it should be the first choice now, with ITIL seen as a secondary work that puts flesh on the COBIT bones as required.
Sorry Aale: ITIL should indeed have tried to rule the world. It just failed at it.
Made in New Zealand 
Comments
"...now I just think ITIL
"...now I just think ITIL did it half-heartedly, too anaemically to be taken seriously by areas of IT outside of IT Operations. But Service Management definitely should go there." and "ITIL should indeed have tried to rule the world. It just failed at it."
Right on! I've always been left wanting(needing) more out of ITIL to really make it work. As if it was teasing me by taking me just far enough to see what could be done but coming up short in a few critical areas when the rubber hit the road and I had to see something alllll the way through to the finish(ie in terms of implementation and CPI). Organizational change comes to mind.
Now, do I hold out hope for some comprehensive, all-encompassing framework(whether ITIL v4+ or COBIT 5) to come down from the heavens? or do I continue juggling and integrating bits and pieces from best-of-breeds(ITIL/COBIT for ITSM, PMBOK/PRINCE2 for PM, any number of Leadership frameworks for HR, etc.)? Is segmentation and/or incompleteness inevitable(for whatever reasons -- scope too large, changes to rapid, vendor self-interest, ignorance, etc.)?
Russ
Seattle, WA
http://www.twitter.com/russhatfield
50 frameworks
On the topic of ITSM Portal columnists, see Geoff Harmer on frameworks (Geoff is a regular comment contributor here as "Deaf Llama")
Mapping the frameworks / Staggering through misc thoughts
One of the things I like about CobiT is how it maps to existing frameworks. It lets you leverage your existing skills and knowledge; and shows you where gaps exist. Better yet, by the mappings you know where to go to fill the gap in.
In my opinion, The ITIL challenge is an absence of these mappings. Sir Isacc Newton said he was standing on the shoulders of giants when he was recognized for his achievements. The ITIL books don't always seem to recognize either the source of the concept, or that alternatives, frameworks or other approaches exist.
For example, IMO a key flaw I see is a total lack of the The OSI, or Open System Interconnection model. This is a framework that defines the IT protocols in seven layers. ITIL seems to be focused on the bottom three layers. One would think that a lifecycle model would mention this somewhere. Its a fundamental principle used in designing applications, infrastructure and networks. When doing implementation, security and improvement work, its critical to identify gaps where metrics or controls are absent throughout the model.
Parallel thought, in my experience, the successful implementations using ITIL (and IT Service Management) are the ones where the organization embraces the philosophy expressed in the library. Call it end to end, holistic view, IT Services, SAAS, etc... the core paradigm shift is to think about delivery from the end user / customer perspective. One of the key messages lost in the murk is that ITIL brings the discipline and science of business to IT professionals. It makes these rules understandable to technical people. It is not that IT needs to be the business; it is that IT needs to consider the business impact (End user experience) of their implemented procedures, processes and policies, IT Technology and any changes they plan to make.
ITIL helps IS and IT professionals get their heads up out of the muck of daily work and think in broader terms. The challenge is to make this transition as painless as possible. Back to CobiT and ITIL... ITIL helps imagine a new paradigm, CobiT helps existing professionals identify where their skills fit into the broader picture. It even provides a map of how what they use links into this new service oriented culture and approach.