Living In A DevOps World (Part 1: Recognition)

DevOps.com.
DevOps has evolved into a conceptual and working model for more effective software implementation. However, there are differences of opinion on the real-world value of any approach to date.  This includes the question of the best way to implement a real-world DevOps environment. This two-part article will focus on what an agile DevOps approach is meant and not meant to address.
DevOps sits at the nexus of three essential business technology functions: software development, quality assurance and operations. A short and concise definition of DevOps proposed in 2015 seems as appropriate as any:

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into regular production while ensuring high quality.

The definition was suggested in the book, “DevOps: A Software Architect’s Perspective,” and the authors have hit upon the essence of the practice. The key, of course, is how to put that concept into practice.
The first step on the journey to effective DevOps is the recognition that the concept is the result of the rise of the Lean and Agile software development methodologies. Those methodologies, among other things, emphasize the following:

DevOps in Practice

Something had to be invented to adhere to the principles above; that something was DevOps.  Over time, an effective practice should address any number of business technology pain points. The following short list of those pain points and their respective solutions should prove instructive.

System Downtime

System outages are inevitable as long as systems are designed, tested and implemented—even with increased automation—by imperfect beings. DevOps changes the focus from trying to create applications that never fail to designing systems that can recover quickly.  This decreases aggregate systems outage time over the life cycle of any application or system.

Stagnation

This was a staple of traditional systems development and is most closely associated with the waterfall methodology for systems development. After requirements were created, the development team would be locked away for weeks, months or even years before emerging with “fully” working software.  This software inevitably no longer satisfied rapidly evolving business requirements. DevOps fits hand-in-glove with the Agile practice of short windows of incremental changes instead of long release cycles, providing value to customers as quickly as possible.

Team Conflict

Having been borne from the cultural combination of Agile and Lean, DevOps has taken on the problem of functional silos that are often erected between development, operations and the business customers. It follows the methodological approaches of collaboration and teamwork first to understand what others know and to leverage the best of it to solve business problems more rapidly. There is also a cultural bent toward experimentation, continual learning and constant improvement. This leads to blameless post-mortems, where collaborative discussion replace finger pointing and blame.

Knowledge Silos

Functional silos have led to compartmentalized knowledge. If the old game was that knowledge is power, the new game in the DevOps world is that knowledge is freely exchanged as an enabler to solving business problems. DevOps addresses the problem of information being lost in translation between the development and operations functions by eliminating the functional barricades and making knowledge sharing the highest form of collaboration.

Inefficiency

Waiting for things to happen used to be a standard operating procedure in the pre-DevOps world. Project plans were created and managed to account for the time it takes for new code to be moved into a testing, quality or even production environment. This was a momentum killer for projects and at times a morale killer for developers waiting to see what changes they might need to make to their code.
The combined Agile and DevOps approach rewrites the traditional approach to code migration, smoothing and eliminating wait times.  Projects can flow more seamlessly from start to finish. This also keeps business resources—testers, approvers, etc.—more engaged as a result of a constant flow of new functions and features to test and use.  There is a financial aspect to this as well. Reducing speed to market with new functionality, reducing or eliminating idle hands—be they technical or business—and delighting customers with a steady stream of enhancements and features all go directly to an organization’s top and bottom lines.
That, after all, is in many ways what the DevOps approach is all about. All of these critical areas become the means to accomplish it. Part two of this article will focus on some more of the benefits of a DevOps approach, and how to achieve them.]]>