Truth be told, there are dozens of different frameworks in existence and all have their unique perspectives on how a project is managed and executed. Frameworks such as Agile, ITIL, lean, cobit, six sigma and many others were built on an ideology of following a path defined by best practices.

With DevOps, two of those frameworks, Agile and ITIL, have become the basis for arguments on how to do DevOps correctly. Yet, until recently those frameworks were very different in the paths offered to bring about project success. With the announcement of ITIL V4, things have changed a little: ITIL is becoming a little more like Agile, adding to the confusion of what path makes the most sense in the world of DevOps.

A Quick Glance Backwards

The foundations of DevOps were built upon the ruins of non-iterative application release cycles. Or look at it this way: DevOps is all about not taking a plunge over the waterfall. While those observations are little more than metaphors for something that rings true, DevOps has brought a new paradigm to software development and deployment. A new paradigm that comes with its own recommended practices.

Yet, current DevOps practices—or let’s call them rules—can come up short in the modern enterprise, meaning that other management best practices—such as those illustrated in the Agile and ITIL methodologies—are borrowed to drive DevOps further forward. That said, the common DevOps ideology is built around a few foundational practices that define the framework of DevOps. The primary goal here is to bring application development and operations together as a functional team. Some of the generic best practices include:

 
• Implement collaboration and teamwork tools to improve communications as well as improving the ability to share knowledge, ideas and automatically document interactions. Simply put, incorporating teamwork with an audit trail goes a long way toward bringing order to DevOps.

 

• Incorporate tools to capture requests. One of the most important capabilities delivered from DevOps is the ability to adapt to change. Traditional application development frameworks are usually based on waterfall processes, where everything is defined at the outset and then an application is eventually delivered. Waterfall ideologies offer no leeway to adapt to change in the middle of a development cycle. DevOps eschews those limitations by incorporating the understanding that change is constant. However, requests for changes must be recorded, tracked and reported upon.

 

• Adopt a framework ideology that can match workloads to team capacity. In other words, team leaders and managers need to have a clear view of what work is in progress and the context of that work as it applies to a team’s abilities.

 

• Use systems to log metrics on automated and manual processes, which will give insight into productivity, as well as identifying where improvements can made.

 

• Implement test automation. The idea here is to automate the testing of code using test data in a sandbox environment. Code that passes the tests can be forwarded further along the DevOps process, while code that fails is automatically returned to developers for correction.

 

• Use a continuous feedback system in which a chain of communications can be established to keep developers and operators informed of the status of any issues, as well as change requests and the progress of any code through the framework.

 

While the above best practices are simplified representations of a full DevOps framework, they do establish that DevOps relies heavily on collaboration and iterative processes to support the ideology of continuous development and deployment. Now, comparing the DevOps ideology to what constitutes either Agile software development practices or the ITIL Framework brings up some additional questions and establishes that Agile and ITIL may very well have different goals. A more simple way of looking at it is to think of Agile as a set of practices to provide faster software delivery, while ITIL is a framework squarely focused on processes and not practices.

The Path Becomes Muddy

Therein lies the real dilemma of establishing a path to DevOps using either Agile or ITIL ideologies. ITIL is designed from the perspective of the governance of IT service management and establishes a framework that supports continuous measurement and should deliver improvement of the quality of IT services. Agile is a set of processes designed for software development that meets the needs of customers and cross functional teams.

Interestingly, Agile and ITIL prove to be complimentary in the world of DevOps, where ITIL can be used to ensure quality and value while Agile brings forth a continuous stream of improvements in applications. Ultimately, with the arrival of ITIL V4, Agile and ITIL will become more aligned with each other and offer benefits to DevOps.

Featured eBook

Cloud computing is everywhere—with IT infrastructures of all kinds and sizes extending into private and public clouds. For most organizations, a single cloud isn’t enough. That’s why it’s important to understand how multicloud can benefit your business. This eBook examines how multicloud helps meet various goals, including achieving greater flexibility, …

Read More