At a Gartner event for Infrastructure & Operations (I&O) professionals earlier this year, the following DevOps-related post was tweeted by Gartner Research Director Ian Head:
At #GartnerIOM Europe over 90% believe that #DevOps is failing to deliver the benefits hoped for. The key question is – Why?
— Ian Head (@heafod) June 6, 2015
Stating that, at this Gartner IOM Europe event, “over 90% believe that DevOps is failing to deliver the benefits hoped for.”
Now I’m not sure of the methodology used to arrive at this statistic or of its statistical reliability. It might only have been a show of hands in a room full of I&O professionals who want to know why their DevOps initiatives are failing, say – but given that Ian is a Gartner Research Director I’m confident that he wouldn’t tweet something that he wouldn’t write about.
In my experience, Gartner analysts are very careful about what they say, or tweet, in public.
It’s also worth considering who the respondents were – if they are I&O professionals, rather than App Dev pros, then they might be too far removed from the DevOps action to see any of the benefits received to date. Plus of course, we shouldn’t overlook the circa 10% that are receiving the benefits they expected from DevOps. These could be the people that are “doing it right,” from whom we can learn.
“The key question is – why?”
My initial reply to Ian’s tweet was “Could it be the usual trio of overselling, misunderstanding, and new IT over people change?” Which I expand on below:
- Overselling – sadly many of us IT professionals never seem to listen to what Public Enemy has to say when it comes to believing the new-technology hype. The overselling, and misselling, might relate to technology, consultancy or advisory services, or even the use of peculiar job titles such as “DevOps Engineer” that we now see touted by recruitment agencies.
- Misunderstanding – while new concepts can be somewhat vague, or even if they are perfectly formed, it’s all too easy for people to hear, and to understand, only what they want to. I’d bet my house that DevOps means many things to many people – but so does ITIL, the IT service management (ITSM) best practice framework formerly known as the IT Infrastructure Library, which has been around since 1989.
- Favoring IT change over people change – most of the believable DevOps “experts” I’ve come across will talk of DevOps as being something akin to “an agile, collaborative approach” to IT delivery; but how many eager IT professionals will invest in overhyped, and potentially underperforming, technology to “do” DevOps? Sadly, I could make another wager here.
IT’s issues with execution anyone? Bueller? Anyone?
An alternative view is that we, in IT, aren’t as great at introducing new things as we should be. It’s a gross generalization, but we have a fairly decent track record in “failing in execution” within IT.
Even if we just look to what we have tried to do in the ITSM arena, and struggled to succeed with:
- Business service management (BSM)
- Configuration management and configuration management databases (CMDBs)
- Self-service and service catalog (although things are thankfully getting so much better)
- Service level management
- Proactive problem management
Plus of course we can’t ignore the fact that most corporate IT organizations use only a third of the 26 ITIL 2011 processes. I know that an adopt-and-adapt approach is meant to be taken with ITIL but there’s still a lot of best practice in the remaining two-thirds of ITIL that would be beneficial to many, if not most, IT organizations.
Then there’s ITSM vs. DevOps
Unless you’ve been on a very long vacation, you’ve probably already heard or read statements such as that:
- ITIL and ITSM can’t work with DevOps
- DevOps will be the death of ITIL
- We should forget about DevOps and instead do NoOps, i.e. that there’s no need for IT operations or ITSM at all
In many ways it’s a clash of speed and control, with some having the opinion that only one can win. In reality they aren’t mutually exclusive – DevOps just needs some serious collaboration involving ITSM pros.
So what should we in ITSM be doing in relation to DevOps?
Firstly we, i.e. us ITSM professionals, need to see the value of DevOps. That it isn’t just something that our App Dev colleagues are playing with, and will probably soon get tired of, in between throwing less-than-perfect code over the fence for us to release.
Secondly, we need to be actively involved. Far too often we hear or read about DevOps as “big DEV and little ops,” i.e. DEVops. The reasons why many ITSM pros don’t seem to be engaged with DevOps is probably a blog in itself.
Thirdly, and this is outside the gift of most ITSMers, we need greater clarity into what DevOps is and isn’t. And a realization that it’s more about people, mindset, and collaboration than it is about buying newfangled DevOps technology, or employing people with sexy job titles, as companies try to cash-in on the latest technology trend.
Finally, we need to share our experiences of ITIL adoption with our App Dev colleagues. Yes they might hate the word, and everything it stands for, but there are important lessons learned – in terms of adoption, failure to execute, and suboptimal outcomes – that a collaborative DevOps initiative can benefit from.
So while we might not know the reasons why DevOps is yet to deliver on its promises for many organizations, surely ITSM professionals need to have a seat – and not just a baby’s high chair – at the DevOps table?
Principal Analyst and Content Director at the ITSM-focused industry analyst firm ITSM.tools. Also an independent IT and IT service management marketing content creator, and a frequent blogger, writer, and presenter on the challenges and opportunities for IT service management professionals.
Previously held positions in IT research and analysis (at IT industry analyst firms Ovum and Forrester and the UK Post Office), IT service management consultancy, enterprise IT service desk and IT service management, IT asset management, innovation and creativity facilitation, project management, finance consultancy, internal audit, and product marketing for a SaaS IT service management technology vendor.