Does the emergence of DevOps mean the end of ITIL?

I recently blogged on on the acceleration of the adoption of DevOps which is becoming a more frequent topic of discussion in the ITSM and ITIL worlds as we look to become more agile and accelerate our implementation cadence. Many believe that DevOps or “NoOps,” as some call it, is simply a movement to remove the rigor and structure of ITIL. I’m sure this may have crossed the minds of the initial founders of ITIL for a micro second, but it’s not the purpose of DevOps. And DevOps doesn’t necessarily mean the end of ITIL, but it may change the ground rules somewhat.

The popularity of DevOps goes hand in hand with the growth in Agile development methodologies. DevOps is extremely complementary to Agile. It extends and completes the continuous integration and release process across the testing and pre-production environment into the operational realm. This gives development complete transparency, from the approval of the work request to production. A key advantage is that code is promoted as soon as it’s developed. Since deployments don’t pile up, complexity and risk of failure is minimized. The smaller the change, should it fail, the more likely the area of impact is known and can be resolved or backed out and service restored.

DevOps does require cultural change, including organizational change and the removal of the age-old boundaries between Operations and Development. It is not about removing rigor or returning to times of IT being consistently unavailable. In fact, DevOps should increase rigor and structure, typically within the automation of the process from idea to production. One of the advantages of this is that the majority of us cope with small incremental change; this usually removes the requirement to “re-educate” ourselves. For the developer, the smaller “contained” nature of the change means that should a problem occur, the nature of the issue is known and it can be resolved or removed from the production environment.

So while DevOps doesn’t necessarily mean the death of ITIL, it does signal a sea of change in how IT operates and will require you to review your ITIL change and release management processes at a minimum. As you review your processes look to see if they are too structured and inflexible and check to see that your change requirements are not too rigid and structured. If it takes too long for a change to migrate to production, the line of business will likely seek new alternatives and you could be looking for a new role.

So my guidance to you is that you need to remove those rose colored glasses and take a look at DevOps and see if it is appropriate for your environment and if so how can you blend it into your effective and efficient delivery of IT enabled business. Remember it is the business that pays the bills!

The following two tabs change content below.

Robert Stroud

Vice President Strategy & Innovation IT Business Management at CA Technologies
Robert Stroud is vice president of innovation and strategy for IT Business Management at CA Technologies. Rob is dedicated to the development of industry trends, strategy and communication of industry best practices. Rob is a strong advocate for the governance, security, risk and assurance communities working closely with the community to author, develop and communicate standards and best practices. Rob also advises organizations on their implementations to ensure they drive maximum business value from their investments in IT-enabled business governance. Following a four-year term as an ISACA International vice president, Rob served on the ISACA Strategic Advisory Council, and is currently serving as ISACA ISO Liaison sub-committee. Earlier, Rob served on the itSMF International Board as Treasurer and Director Audit, Standards and Compliance, the itSMF ISO liaisons to multiple working groups and spent multiple years on the board of the itSMF USA. An accomplished author and blogger, Rob is widely recognized for perspectives on industry trends. He also has contributed to multiple standards publications including COBIT 4.0, 4.1 and COBIT 5, Guidance for Basel II and several ISO standards. Rob served as an active member of the ITIL Update Project Board for ITIL 2011 and in various roles in the development of ITIL v3 including the Advisory Group, mentor and reviewer. Prior to joining CA Technologies, Rob spent more than 15 years in the finance industry successfully managing multiple initiatives in both IT and retail banking sectors related to security, service management and process governance. Follow Rob on Twitter: @RobertEStroud

This article has 4 comments

  1. I have certainly seen organisations where Change Management is used to limit change, rather than facilitate the controlled (and safe) introduction of change. These organisations often see the business engaging with IT vendors outside of the control of the IT organisation, effectively bypassing IT to get to the speed of change they require; and ending up with a lot less control…

    The best IT organisations are able to promote business requirements quickly without the introduction of too much risk. The only thing I would say with regard to DevOps, is that just like ITIL you can take it too far. Complex, integrated, changes with large risk could quickly become part of the same “agile” approach, and the level of testing and control can be minimised inappropriately. Organisations need not have a “one size fits all” approach to change control, and those items where movement to production can occur under a DevOps mind-set is absolutely the right way to go in some circumstances.

  2. I agree, it doesn’t, but as you said, it will require some adaptation. Which is fine, because the aim of ITIL is to facilitate the work, the process should never be the goal!
    In my view it will indeed put a bigger focus on Release Management. And the Change Management process will most likely shift from what it is in ITIL2/3 back to implementation control. Because the lifecycle of decision, design, development and test will be controlled by the Product owner and the DevOps team thru the Product backlog.
    In my opinion this also eliminates the need for a separate Problem Management process. When you have something to fix, put it on the backlog. If it’s important enough, it will get prioritized so that it can be included in the next Sprint. Why bother with a Problem record and Know Errors (other than to assist with Incident resolution) and an Error Correction Plan?
    Incident management is here to stay, because that really has proven its usefulness to all parties, including Dev.
    There will problably be implications for the other processes as well, but I haven’t got a clear picture of those yet. What’s your view on the future of the strategic processes? (Service design)

  3. What’s in DevOps that is not already addressed by ITIL. To me, it is just another “framework” or whatever you want to call it getting into the market, etc… begging to get attention…another buzz word for that matter. The issues that DevOps recognizes have been already addressed by ITIL. But this is just to say that ITIL is only a library it is not a framework. Different people understand it different. So you wouldnt find any one org. doing ITIL in the same way. Therefore, it is not one size fits all. People try to make ITIL as one size fits all and hence all the differences.

    I think people need to understand and follow only one methodology and stop trying to come up with other stuff just for creating another buzz word in the main stream. Try to understand and stop reinventing the wheels… this is wastage of time for everyone!!

    An ITIL® practitioner | MALC (Managing Across Lifecycle)

  4. This is also a cultural divide: DevOps is more prevalent in companies with OpenStack,AWS, Google Compute style deployment versus a classinc incumbent (read: Enterprises) well versed in ITIL and running NOC.Cloud Operations like the one I did at Cisco. I had benefit of creating a DevOps group at part of the Cloud Operations team and I can now say that briding the gap did take some internal selling and evangelizing. I do tend to agree that ITIL framework has enough meat to factor a DevOps framework.

Leave a Reply