Home > CA Community > Service Management

CA Community





This Blog

Service Management

The importance of Service Management from building a strategy to applying best practices with ITIL is paramount in realizing real world, practical implementations. Learn how you can go from strategy to implementation

Does the emergence of DevOps mean the end of ITIL?

Published: January 14 2013, 10:45 AM
by Robert Stroud

I recently blogged on ServiceVirtualization.com 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!

Share this post:  

 

By: Robert Stroud
Robert Stroud is vice president of innovation and strategy for Service and Portfolio 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...
Read More..

4 people have left comments:

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.

Posted by: Steve Green | January 14, 2013 5:53 PM

Pingback from  Does the emergence of DevOps mean the end of ITIL? - Service Management - CA Technologies | DevOps in the Enterprise | Scoop.it

Posted by: Does the emergence of DevOps mean the end of ITIL? - Service Management - CA Technologies | DevOps in the Enterprise | Scoop.it | January 14, 2013 8:36 PM

Pingback from  Fresh Links Sundae from David Lowe of Actionable ITSM | Actionable ITSM

Posted by: Fresh Links Sundae from David Lowe of Actionable ITSM | Actionable ITSM | January 20, 2013 9:27 AM

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)

Posted by: Jan-Joost Bouwman | January 31, 2013 11:17 AM

Leave a Comment

* An asterisk indicates a required field

* :  

:

* :  

  Submit