In this post, Add Dev Managers John Tran and Dipanjan Ghanti compare DevOps vs. ITIL while offering useful guidance for a successful DevOps transformation.

Introduction

If you work in a large enterprise organization, works such as DevOps and Agile can be met with a certain level of skepticism. These buzz words circulate and influence teams to change their methods but how do you successfully transition an organization which has invested heavily into a structured sequential processes and practices such as ITIL? Rather the question is can ITIL be customized to fit in with DevOps?

On the surface DevOps and ITIL seem to be contradictory practices, with the former being more used in development work and the latter being more used for services/operations. However, if we drill down into their fundamentals you will find that DevOps cannot exist in its entirety without a framework such as ITIL. This article will try to align the similarities between DevOps and ITIL and attempt at defining a road map for organizations to work towards adopting DevOps and maturing the way that they deliver value.

How ITIL can complement DevOps

Looking back at the age-old approach, software development was performed following Software Development Lifecycle (SDLC) and waterfall project management practices. On the operations front, the processes were governed based on ITIL. Through DevOps, development and operations came together under a single banner and in this mix, the waterfall methodology gave way to Agile methodologies. However, there was not enough understanding on how ITIL would come in to the DevOps world. So, at the advent of DevOps many considered that it would mark the end for ITIL. This is plainly noise without any substance. As we know, DevOps is not a framework, it is rather a set of good practices. So, if the processes under DevOps are reorganized it will fit the newer objectives.

The key to success

The ultimate goal is to integrate DevOps practices into your business without disrupting the existing ITIL system. On the surface, the goals of each system are very similar however these two differing paradigms can be very polarizing. Friction can be caused by misunderstanding and or a resistance to change. For example, DevOps practitioners may think that ITIL is too restrictive and tedious; while teams which practice ITIL, sees DevOps as the wild west, with no structure or rules. To be successful we need to implement the processes that embrace both philosophies.

Adoption first steps

Baseline maturity:

Gather a baseline level of maturity of the organization. Take a step back, review and document all the processes which are currently being practiced. Understanding where we started will allow us to better define the next steps and measure success.

Level set, definitions:

Begin by giving all team members a base level of knowledge. Make sure that each team member accepts the transformation and that everyone is working towards the same goals. We want to include all roles, from management, business, development, operations, security, QA, BA, etc.

Adoption and integration:

Using the maturity baseline, we want to identify areas that we need to develop or any gaps in process. These are the areas that we want to prioritize and concentrate on first. Start by looking at the existing process and see where small simple changes can be integrated first. Don’t try to implement DevOps in a big bang. This approach is doomed to fail. The transformation needs to grow organically, and the culture will need time to adapt.

For example, practices such as Continuous Integration and Continuous Delivery may not be right for the organization and do not need to be implemented right off the bat. Start with build and deployment automation, even if these builds are manually triggered. Over time you will refine and improve until the team is mature enough to fully deploy autonomously.

Continuous improvement.

Continuous improvement driven by validated learning is a core tenant of both frameworks. By making decisions based on metrics we can ensure the changes that we implement are a net benefit to the team and to the organization. Over time the maturity will grow and transform into something completely new.

Conclusion

In larger organizations, during high stress, time sensitive deliveries; teams sometimes bypass processes to meet strict deadlines. This is where DevOps gets its bad reputation. In this same situation, the traditional ITIL process may be looked on as a hinderance, not adding any value to the delivery team. In fact, by implementing some of the practices of DevOps into your organization already established processes you can help to accelerate delivery, increase quality and build a stronger and more dynamic team.

The misconception that DevOps is only for small teams and organizations needs to be changed. Large organizations with well established processes can also adopt the principles of DevOps into their processes without completely throwing out what they already have in place. To be successful we need to implement a process that embraces both philosophies. DevOps is widely seen as a replacement for ITIL, but this is not the case. Things are not so binary.