With the updated version of ITIL imminent (the 29 July 2011), I participated in a BrightTalk webinar on “what next for ITIL.”
My views on this are very clear, that we need to “look back before we look forward.” I touched on some of this in a previous blog, 2011: An ITIL Versioning Odyssey, but think it worthwhile to continue to articulate my views in this area.
Let's start with what I consider to be the biggest issue: the gulf between theory and practice with ITIL.
There is no doubt that ITIL can benefit I&O organizations. There are certainly many I&O organizations encouraging, or even forcing, their people to take ITIL training and qualifications: There are at least 1.5 million people with the certification and there is no sign of this slowing down. Not only are trainers busy, so are ITSM consultants and, of course, industry analysts. But, from an industry analyst perspective, there is a lot wrong with ITIL. This is not just how it ballooned in size from ITIL v2 to ITIL v3, but also how it is adopted in the real world.
So what's going wrong?
If you look at existing ITIL v2 adoption, there is a focus on the reactive elements such as incident management, problem management, change management, and maybe even configuration management and service-level management. How many organizations have moved on to the more proactive elements such as availability management, capacity management, IT financial management, and continual service improvement?
My colleague, Glenn O’Donnell, and I (do I sound like the Queen?) have delivered a Forrester report called “Improving The Ops In DevOps” inspired by the long-bemoaned tension between “change-the-business” (dev) and “run-the-business” (ops) IT teams and their activities, and the need for change.
This tension inflicts a detrimental impact on the business. In fact, most organizations suffer this curse, and stereotypes that reflect this animosity abound. Does this sound familiar? Ops people see dev people as sitting in their ivory towers cranking out code all day and wanting to release applications oblivious to real-world constraints; dev sees ops as cog-turners ensuring that the IT infrastructure doesn’t break under the strain of poorly written code. Chances are that your organization is not this bad. But this exaggeration is indicative of the tension between these two IT “tribes” and their opinions of each other. These stereotypes exist because organizational behaviors do exaggerate genuine conflicts, and both parties must act quickly to change.
Getting DevOps right will address many of the issues enterprises consistently have with IT, such as applications failing to meet both functional and nonfunctional requirements, delivery delays, increased costs, and an inflexibility to change. But is DevOps enough to save I&O from extinction?