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?
The Nebula appliance announced today jumps right into this space and provides a standardized hardware configuration for OpenStack implementations. It offers scaled-out compute power based on commoditized x86 CPUs and standardizes a configuration of switches and other components to glue a large number of these CPUs together. The new VC-backed startup will thus compete head to head with EMC’s Vblock and Microsoft’s Azure appliance; neither of these are based on open source, and the latter isn’t really on the market yet.
But Nebula is more than just a hardware deliverable. Its mission is to transparently standardize the cloud hardware stack. Basically, it’s nothing more than the complex specification Microsoft worked out with its hardware partners (Dell, Fujitsu, and HP) to deliver the Azure appliance to local cloud providers and large-scale private clouds. However, Nebula’s openness is the differentiator; it reminds me a bit of IBM’s approach around the original personal computer back in the 1970s. Sure, it enabled hardware competitors to produce compatible PCs — but it also brought mass adoption of the PC, outperforming Apple over four decades.
If Nebula delivers a compelling price point, it has an appealing approach that could gain significant share in the growing cloud hardware market. If the new company aims to spur a revolution similar to that of the PC, its founders need to tweak their strategy soon:
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?