Way back in September 2012 I wrote an article about DevOps for Service Talk, the journal of itSMF UK. It was meant to be a wakeup call to my fellow IT service management (ITSM) practitioners, many, if not most, of whom thought that DevOps was just the latest in a long line of fads.
In the article I gave an overview of DevOps and Agile, and challenged the itSMF movement to “take the bull by the horns” and take the lead in engaging with the DevOps community. I said, “If we ignore DevOps and think that it has no relevance to IT service management, then one day very soon, we will hear the cry:
“The King is dead. Long live the King.”
At the 2012 itSMF UK conference that same year, I was astounded to hear people say things like “DevOps will never last”, “it’s only the latest software development methodology,” and worst of all, “IT service management can ignore DevOps.”
4 years later…
Today I’m sorry to have to say to those people that “I was right, you were wrong.”
- DevOps is definitely here to stay. In a recent survey 94% of the respondents in IT, DevOps and the business said that they were engaged in DevOps.
- DevOps is about a lot more than just software development and tools. It encompasses the full lifecycle of IT services, including business analysis, testing, deployment, and operations. The DevOps community is vibrant and growing, continually developing its ideas.
- The itSMF movement didn’t answer my call to engage with DevOps, but individual ITSM practitioners did. Hence ITSM hasn’t ignored DevOps, as witnessed by the growing number of articles, blogs, and presentations on DevOps and ITSM/ITIL.
The King isn’t quite dead yet, but it’s failing fast – as an illustration, the requirement for ITIL and service management skills in the job market has dramatically shrunk whilst the requirement for DevOps and Agile skills has dramatically risen; the number of people taking ITIL qualifications is steadily declining, whilst the number taking DevOps and Agile qualifications is rapidly increasing.
However I’m not gloating, I still care passionately about, and believe in, IT service management. The good news is that so do the thought leaders in DevOps, for example Gene Kim author of “The Phoenix Project”. In 2014 he said:
“…I’ll argue that ITSM (IT service management) skill sets are ever more important in a world where there is an ever quickening pace of change” and “ITSM practitioners are uniquely equipped to help in DevOps initiatives, an create value for the business.”
Note that Gene mentions service management/ITSM skill sets, and ITSM practitioners. Not ITIL processes, or functions. And therein lies the issue.
Resistance to change in service management
Although some in service management have woken up to DevOps, we still need to see a change in how we adapt and apply the practices of ITSM, ITIL, and others that have been our guide and our comfort blanket for so many years.
The reality is that the real IT lifecycle has fundamentally and dramatically changed from the one that was commonplace when the ITSM best practices were established. The days of ‘waterfall’ sequential lifecycle steps against a ‘V’ model, long development cycles, manual test and deployment activities, and fragile applications are going, and in fact have long done for many of today’s successful organizations.
Despite these realities many service management practitioners still want to keep doing things how they’ve always done them. They keep the developers at arms length and put hurdles in place that have to be crossed to put new stuff live. They say things like ‘we are the guardians of live service’, yet have no involvement in specifying what goes into a new release. Sadly many are the first to blame the development community when issues are experienced following a deployment.
These practitioners cling to unwieldy bodies, processes, and artefacts such as ‘change advisory boards’, ‘change evaluation’ and ‘requests for change’. In most cases all these do is to induce delays in putting changes and releases live, and duplicate what has already happened in DevOps. They rarely stop bad stuff going live, but are claimed to ‘add control’. Control over whom? The DevOps culture is one of ownership and empowerment – they feel the pain of a failed release directly.
So why does service management believe it has the right to control DevOps?
The answer is that the historic IT service management best practices are all about control. Controls that were appropriate for waterfall development approaches, for teams that didn’t have skin in the game, for the days of manual application testing and manual code deployment. DevOps has changed all that.
It’s time that ITSM changed too. We have the skills, we have the experience, what we need now is an open mind that is prepared to change. Prepared to make fundamental changes to our processes. Prepared to work as part of the wider DevOps community. Prepared to challenge the sacred cows of our historic best practices, and if beneficial ditch them.
AXELOS have just announced that in early 2017 they will launch a new, free online DevOps training programme. This draws on the combined expertise from DevOps, Agile and IT service management. That’s good news, but ITSM practitioners still need to wake up and smell the coffee.
For years we’ve quoted the mantra ‘adopt and adapt’. Now it’s time to put that mantra into action, otherwise you will hear the cry:
“The King is dead. Long live the King.”
Kevin Holland
With over 20 years of experience in delivering results in the design, management, and improvement of the delivery of IT services, Kevin Holland has in-depth experience in a wide variety of challenging and demanding industry sectors and companies, private and public, large and small.
One Response
Good read and a message with which I am in ‘violent agreement’. Either practitioners take a page from our own hymnals and “adopt and adapt” DevOps concepts within our ITSM practices, or we will find ourselves becoming irrelevant.