So it seems my Clouderati vs. ITILista has a response from my friend TheITSkeptic. He has a post in defense of the ITILista that you should read. Here's an excerpt.
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?
Frankly, in a normal world, it's hard to argue with Skep. He makes a lot of sense.
But the world is not normal and people nor logical. Change is happening.
I coined the phrase "ITILista" to provoke the process-obsessed, lack of customer-centric, literal-interpreting and yes, techno-phobic people that I've run into my last few years in the ITSM world. It's dismissive, because I've seen this people create projects that drag and drag producing very little value - arranging the decks of the Titanic while Rome burns, to mix my metaphor.
Despite ITIL being about IT, I see a willfull disregard for technology-led change in a small, but vocal part of the ITSM community -- usually some consultants -- who often don't have technology or tool skills.
But Cloud computing a storm that will re-make IT organizations. It is here and doesn't need our permission to come into our lives. Like the internet before, it's re-making some industries and creating collateral damage in others. This one affects the very future of IT departments.
And yes, ITSM people will have an important role to play but only if if they learn the language of the cloud and the technology of the cloud. Those who don't, will not have a job in IT - something I see happening already.
Take Skep's second point. That whole conversation about "having to convince Change gatekeepers," drives people crazy. It's absolutely the worst worst worst way to engage in this conversation.
You know what dev and qa people are doing when they confront that? They go and use a public cloud! And they do it with the blessing of the business. They are aligned! They get projects done. Oh, there are and will be issues, but so what? In this economy getting stuff done now matters.
Meanwhile the ITSM people don't have any visibility and are out of the loop, and then out of a job. Much of the desire for providing private clouds comes from the realization of this trend. It's eiher IT provides the service with convenience, agility, customer self-service and control, or the customer has a choice.
So it's important to understand cloud automation,
- Understanding how provisioning works, vmotion, drs, layer 2 networking, are super important to make risk assesments.
- Understanding how Service Profiles in Unified Computing are making provisioning more responsive and safer allows us to make better decisions about workload management.
- Understanding how cloud bursting allows us to move capex to opex and capacity management are important, but it's not appropriate to every workload.
I can keep on going, but if these three bullets did not make sense.. that's the point. There's a language and understanding chasm between clouderati and ITIListas.
And there are a lot more cloud-people than ITIL people. Just Vmworld alone had 17,000 people attend; ITSMf (where I'm speaking next week), will have between 1,500-2,000 people. No contest when it comes to who owns the dominant language. So it's incumbent on ITSM people to learn the technology of the cloud in order to bring their relevant experience.
The clouderati for the most part won't bother with ITIL.
Heck, one of them told me yesterday I tried to understand ITIL. Had one of my guys explain it for a day. I just gave up. Didn't seem relevant. Waste of time. I am not making this up. Fair or unfair. Smart or stupid. It is what it is.
Here's another example about the chasm between clouderati and ITILista. In our LinkedIn community, over the years there's still arguments over whether you need a tool for a service catalog (and one in which Rob and I agree). In the cloud / virtualization space, it's just accepted and it's part of the architecture of every cloud. No argument; let's just get on with the project.
It boggles my mind that in 2010, there are more people talking service catalog, demonstrating service catalog tools, and implementing them at a cloud show than there are at ITMSF Fusion.
I'm not anti ITIL;I'm just saying that technology, automation have to be part of the skill set in 2010.
I do worry about my ITSM reader's future job prospects. The world is changing and there will be fewer jobs in IT. Those that remain will need to know cloud. That's the message.
I appreciate Skep taking on this topic and giving me the opportunity to more fully rant. :)
What do you think?
Nice post, Rodrigo. I am anti-ITIL because it's not about IT and it's not a library.
We need something better...
Posted by: twitter.com/stevie_chambers | Friday, September 17, 2010 at 02:04 AM
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.
Posted by: Dsalamack | Friday, September 17, 2010 at 08:14 AM
Oh please, not the old "all the old rules are gone" argument again. I thought e-commerce, dot.bomb, hedge funds and US real estate would have got that out of our language by now.
Cloud will fail. There will be disasters. Companies will crash and possibly the economy will crash, all because Cloud Cowboys ignored basic professional principles of business conduct, especially risk control. Most of all it will be because they thought they could apply a technical solution to a non-technical problem: the poor processes and culture that make them see risk management as an obstacle instead of a safety mechanism.
Posted by: The IT Skeptic | Sunday, September 19, 2010 at 04:06 PM