In defense of ITILista

Apparently ITIL people are obstructing the Cloud. Once again the poor techno-geeks' creative brilliance is stifled by unnecessary process.

Recently my friend Rodrigo - leading service catalogue entrepreneur, and lately a tambourine-playing Cloud believer - said in his blog:

I don't want to imply that one is better than the other, rather to point out that these are two cultures that need each other, but may not be articulating their concerns and objectives in ways that each can listen and help.

For example, the cloud requires automation of process and policies to speed provisioning of services. Which is why they get annoyed by the ITILISTA focus on manual process...

Finally, ITIL lack of focus on automation, getting rid of process steps and rigid definitions completely disables people building clouds from bringing in their objectives, tools, language to the table.

Take change management. Please.

ITIL prescribes a cumbersome process, very manual, with meetings, etc. In the cloud, we are looking for self-service, instant delivery of computing resource. Should that go through change management?

In defence of we ITILista, let me say:

- we aren't anti-automation, or dismissive of automation. Process-geeks understand that you have to fix the process before you automate it, else you'll be accelerating backwards. Automation makes bad process faster. Automation is one of the later stages of refinement once you have something worth automating.

- similarly, Change isn't cumbersome. It is about mitigating risk. I don't understand why we would want to drop risk controls. Once you refine your risk mitigation to the point that pre-approval is an acceptable risk, then change gets out of the way (it's called standard change). Absolutely, the Cloud mavens need to convince the Change gatekeepers that automated change is an acceptable risk. Why not?

In both cases it is a question of maturity making automation possible. Until you get to that maturity level, automation is a technical fix to a non-technical problem: bad process.

Likewise outsourcing. Every wise head in the industry says fix it BEFORE you outsource it.

Cloud is a double whammy: outsourced automation. If you aren't ready to do it then don't. If you are ready, then ITIL won't get in the way - it will help.


Can't we all just get along?

Why is it in America everything has to be at one extreme or the other?

You are either a Democrat or Republican.
You are either a Terrorist or a Patriot.
You are either a Clouderati or an ITILista.

I have to agree with Skep, partially because he is on a different continent, but mostly because he's right!

Rodrigo, you experienced the worst part of ITIL. This idea that one must hit every step and dot every i before moving on to the next step. People who create process for sake of producing process and making themselves seem indispensable while doing so. These people will always exist and they use ITIL as a blueprint and excuse for doing so. This isn't unique to ITIL either. CMMi, COBIT, ISO xxxx, none of them are bad on their own. It's the damage you can inflict in their name that makes people run screaming when they hear another four letter acronym attached to the word process.

Skep summed it up in his first statement: "we aren't anti-automation, or dismissive of automation. Process-geeks understand that you have to fix the process before you automate it, else you'll be accelerating backwards. Automation makes bad process faster. Automation is one of the later stages of refinement once you have something worth automating."

Why does it take longer? One can assume that the process in place now about to be automated, outsourced, or both, has room for improvement. Automation does not improve a process, it only makes it faster. Outsourcing a process does not improve a process, it only makes it cheaper. So, a cloud implementation of a process without reviewing its' merits or benefits will allow you to do it cheaper and faster, but the customer will see no improvement. Cheaper and faster benefits the IT department, not the user. It should not take 12-18 months to improve a process. If it takes longer than 3 months (1 financial quarter). You are doing it wrong.

Rodrigo, your original article had a comparison chart of ITIL and Cloud. You categorized, ITIL as being focused on customers and Cloud being focused on infrastructure. I think this clearly makes ITIL the winner, as infrastructure is meaningless if does not meet the needs of the customer.

ITIL results in cloud implementation. Cloud is a natural outcome of ITIL. The two need one another and are not mutually exclusive.

Where do I get some of what you are on?


You know those people who have no filter when they speak. Yeah, I'm one of those, so please take my comments as constructive and with a twisted sense of humor.

Please tell me you have other context to these two statements:
Automation does not improve a process, it only makes it faster.
Outsourcing a process does not improve a process, it only makes it cheaper.

If these are truly ideas and principles that you are believing and tangibly benefiting from without sort of context, then please, please share whatever you are eating, drinking or popping.

Automation comment: I can not even think of one situation where we instituted some sort of automation that did not improve the process. I'll go back 20years to when we used to Ping servers automatically to check availability. The most simplest example I can think of. This revolutionized the way we structured, responded to, and reported within the availability management process. And in fact did not make the availability management process faster, it actually slowed it down, because now our capabilities were greater.

Outsourcing comment: Again here this is just insane. When I outsourced my data center in 2000, my costs doubled. However, I not only improved my processes, I actually got some I never had before, (Security, Capacity, Event). The outsourcer (Exodus at the time) had the people and desire to invest in the processes. They took on the low level responsibility and thus allowed me to invest more time and energy into SLM, which was hurting as my internal and external service sponsors were note being services.

Lastly, I just have to say this comment is also something I can not get my head around "ITIL results in cloud implementation. Cloud is a natural outcome of ITIL."
What? How?

Cloud is where you buy a service not assets. To that end I think Internal Cloud is the stupidest thing I ever heard of,unless of course you are EMC and you use your assets to provision services internally and externally. Cloud services do not need anything form IT to exist. In fact IT as a silo'd bunch of control freaks are the biggest danger to positive business outcomes and benefits that cloud services could provide.

So with my soap boxing complete, I would really have expected Rodrigo to write something on this topic.
How can ITIL help business outcomes that are dependent on cloud services?

Here those with in the business who are using ITIL guidance can look to earlier stage processes to align the actions required to manage the performance of the cloud provider, and help translate to the business the risks and benefits the cloud services are providing. In this way, the associates using ITIL processes are acting as advocates for business outcomes.

Note I didn't say IT People using ITIL, nor did I say IT servicing the customer.

The reality is ITIL, and other guidance in the IT industry makes IT separate from "the business", and calls them their "Customer". Thus, they think of themselves as a "vendor" and "cloud providers" are naturally "Competitors".

We (IT people) need to stop viewing ourselves as separate... then we can all truly get along.


Automation, cricket bats, invisible technology, archeology

An admission - I was one of the pioneers of turning the lights out between 1985 and 1995 - yup I was an accidental turncoat, I truly believed that designing automation systems and core engines for the products that now seem old hat would protect the jobs of individuals and allow for the growth in processing we all expected. It would enhance the value users saw in IT (although as I was reminded recently it was IS or MIS). It would also put in place a process (procedure - insert any word you wish here I tire of arguing) that was established, standardized, and formally agreed, as the new true north for the activities it performed and dragged along like mum with 4 kids through the candy counter.

But - we can only automate what we understand and have agreed works as we need it to. Enter ITIL stage left - to guide us all through how to perform certain activities - PROPERLY. Now, ITIL does speak to automation, it does recognize it, but I think we all understand that unfortunately, as some expected, you cannot automate what is in ITIL - it would run like a v8 car with three cylinders missing - a bit lumpy. As for Cloud - its not new - I speak to us sort of being in and around another Version 3 - the Cloud. From way back I recall the initial wave of ITILers, the ITIL Marines, coming ashore and shouting "adopt and adapt".

What did they mean? Adopt ITIL into the blueprint you have developed for a system (read holistic) for managing the provision of information system services. Then adapt what ITIL says to fit your needs. Herein lies the rub. There is no common definition of what represents a 'service management system'. ITIL V2 was close with its two Delivery and Support components, but these were abandoned by ITIL V3, and the lifecycle we have been given is written from the inside-out. Is there anyone out there who can walk the wall with me and explain how a request flows through the entire 4 (5?) books.

And why do process maturity models END with customer alignment?

Customers have always wanted what the cloud promises. ITSM once promised the same. I wrote to this on my blog here a while back "Every Cloud has an ITSM Silver Lining". The friction between cloudsters and itil evangelists seems grounded in inside-out thinking. It is easily referred by taking the customer position. As a customer I don't care. If its cheaper, easier to administer, provides a better service and affordable (not necessarily cheaper) - count me in like any provider. If it helps me get what I need done, done in a timely and cheaper (secure, risk free etc) manner - count me in as a customer.

Remember, IT stands for "invisible technology". You put technology, IT, and that includes cloud and ITIL, between me and the result I want and I'll take a cricket bat to it and you. Cloud is being positioned as an enabler and accelerator of results. It is deftly positioned at senior management levels as a countermeasure to the economic perfect storm. ITIL is being clumsily positioned by some as a must do and frankly a boat anchor. It sounds complex because it is. Why do I need to build a CMDB when a Cloud vendor can do it for me as part of managing my applications, products and services? How do you build a service catalog without customer involvement to design the interaction and moments of truth?

Cloud folks should continue to do what they are doing - its a fantastic disruptor for ITSM and ITIL initiatives. It brings reason to the table.

ITIL folks need to get back to basics - hug a customer every day and read the ruddy books as they were originally intended to be used (I have been chatting with Majid, the primary author of the Service Strategy book, at length about outside-in, inside-out, outcomes and lumpy bits). Its all there in principle, sort of, minus customer experience management and about 125 important key terms and concepts. It is poorly phrased and even more poorly read and understood. But I put that down to the authors being on an archeological dig for what service management really was, and should be. - oh oh flashback to my ITSM/ITIL Viagra article...

Think customer. Think customer first, and reasons for cloud or ITIL, and whether they support the concept of "invisible technology", or are candidates for batting practice - become so, so clear. Both are contributors to the customer value equation...

Do other departments really talk like this?


You make a great point, and one I see all too often with professionals who have only lived their careers in IT. That in trying to solve problems they focus on IT's ability to solve the problem. When trying to provide outcomes, they focus on IT's ability to provide the outcome. For my company I am both CIO and CMO. As such I attend lots of webinars and networking events with Marketing Executives. Well guess what, CMO's talk about business alignment and customers, can you believe it? OK, I guess not that shocking... Why, because we expect Marketing to be thinking about the business. Here is also what they talk about, Service Strategy, Service Delivery, Integrated process, metrics, transparency, workflow, request management... sounding familiar?

Yes, the marketing executive of today is a true service provide and recognizes they are a key engagement stakeholder in business outcomes. They don't ask permission to think about the customer, they see their responsibility is to drive the customer experience to the highest level of satisfaction.

So here is my questions to every ITSM professional. What single activity does the CIO speak of that can clearly be mapped to the customer experience?

Every CMO and marketing person can clearly answer this question, and it has nothing to do with Marketing or Technology.
Answer: BRAND MANAGEMENT Creating affinity and trust to the services provided. How many IT organizations have that as a mission and plan?


not process? ignore risk?

Smart decision-making and some true accountability will enable the cloud, and it will be enduring if the true business value is there.

Some process discipline will save you time in the long run:
* follow a process to manage services for for value (is a virtual server through the cloud good balance of price/performance/risk)
* construct a business case with a real ROI that someone is going to be held accountable for (will the $ costs offset the $ benefits (and the quality is right))
* put an actionable service catalog in place that meets demand (eg: eg: ability to buy a virtual server through the cloud)
* pre-approve some types of changes (eg: buy a virtual server through the cloud)
* charge the business a fair and reasonable price for that virtual server (but try to limit consumption and waste of an all you can eat buffet)

Also, clearly Rodrigo hasn't taken the CSI book into account. Sure, it is something that most people make a complete meal of, but it's been in manufacturing for decades, CSI recommendations often focus on "automation, getting rid of process steps".

But we need to check that we're not being really efficient at building lead lifejackets, or else you might as well go back to the dot.con days and claim that world hunger will be fixed (and your stock price should go up) because it has a .com after it or has an i in front of it. Or in this case "via the cloud".

You should never EVER outsource accountability for good business decisions (and managing risk). Used with some common sense, ITIL is just something in the kit bag to reduce the likelihood of making a dud business decision.


Strange thing life is.

I am and always will be your friend (Spock to Kirk)

Rodrigo used to be an ITILista, or at least he played one on TV, with his catalog books, publishing with Pink Elephant and perennial booth at all the ITSM North America Shows.

Lately he has been cloud washed and I miss and want my ITIL friend back.

It's strange because many folks look at me and think, oh that "social media", sorry kids, I am only the social media guy because that is how you met me, I am and always will be the Service Desk Guru, ITSM High Priest, etc.

I am afraid that Rodrigo might fall into this cult of personality where people only know him as "CLOUDRIGO"

Don't forget people he was and always will be mister service catalog, even though you can't really see that through the haze these days.


wind up

Knowing your musical talent Rodrigo i got all excited that maybe you'd sung a response! You could have been competition for Rambling Sid Realitsm! Never mind I enjoyed Solomon Burke (new to me), and we'd never give up on you dude, just winding you up :)

Syndicate content