ITSM and DevOps, don't settle for relevant, drive value!

There have been many articles and discussions posted over recent months and years about the ongoing relevance of ITSM when DevOps is the new norm. Many of the articles have been written and posted by people with a vested interest in the ongoing importance of ITSM, and almost without exception - the call to arms for the ITSM community is automation, automation, automation!

After hearing this mantra, the overwhelming urge is to go and restructure and automate Change Management processes.  In my opinion, this misses the point of DevOps entirely, and only serves to;

a) Diminish the Change Management process; and

b) Still annoy and slow down the DevOps team by making them engage with a manual (if less time-consuming) process.

So is ITSM still relevant?

The simple answer is, it is only relevant if it adds value to the DevOps process. There are in fact many ways that ITSM achieve this, many of them do (of course) include automation, but few of them involve Change Management;

1) Focus on MTTR - one of the principles of DevOps (or at least Facebook) is "fail fast". Incident Management and reducing Mean time to Repair (MTTR) is something every organization who has implemented ITIL has done. So why not use it to help DevOps. What if we stopped trying to reduce the number of Incidents (and accept the numbers will grow), and put the focus on fixing them quickly. 

The first step is to automate the triage of Incidents and route them directly to the DevOps team. Then, what-if we automatically knew (from the CMDB and Change records) who was responsible for the relevant change that caused the incident, and route it directly to that person/group.  There is absolutely no reason why a customer reported Incident couldn’t be resolved within minutes of it being reported, by a fix implemented by the DevOps team.

2) Change the Definition of an Incident. ITSM has been focused for years on defining an Incident as the interruption to a standard service. But - increasingly organizations view usability or requests for new features as just as important as service disruption, especially if it can drive corporate advantage. ITSM can add value to DevOps by providing a great pathway for Customers to provide direct feedback to DevOps teams as they already have the infrastructure, people and portals to do this. What a way for ITSM to bring something useful to the DevOps table!

3) CMDB - DevOps is where the CDMB finally comes into its own. Change processes should be able to automatically assess the impact of a particular change based on the individual container being changed by the DevOps team. Based on this impact, the relevant test scripts should be run and change should be automatically approved by determining: the impact of the container change, the successful execution of the relevant automated test scripts and the impact of the change prior to deployment. To put this into a practical example, if a supermarket is making a change to their weekly retail specials, and the change is logically separated from the shopping cart functionality - there is no practical need to re-test the shopping cart!

In the above scenario, automation, CMDB and change management are key - but rather than automating a specific process, ITSM is automating the handoff between the processes and leveraging the knowledge that a powerful ITSM solution can provide.

4) Automation between processes. As the above scenario shows, ITSM automation is absolutely essential to providing value to DevOps processes, but the focus needs to not only be on individual processes, but the transition between one process to another, which historically has always been manual, cumbersome and susceptible to error. There are a myriad of scenarios in which this type of automation can be leveraged, from seamless transition from Change to Release, providing Customer Satisfaction scores directly to DevOps teams, further driving down MTTR by leveraging the details within the CMDB, the list goes on.

At Cherwell software, I'm constantly working with organizations that are finding new ways to use the Cherwell codeless platform to drive innovation in this space. The challenge I often have, is many of my customers are already delivering value for their DevOps teams with the Cherwell technology, without any input from the team at all! I'm looking forward to discovering more ways ITSM will not just settle for being relevant in the future, but become key to an optimum DevOps environment.