What Is DevOps?

It seems that everyone in IT these days is talking about DevOps. From conferences to articles and books, the term DevOps has taken the IT world by storm. The buzz is understandable, as many IT groups are looking for a way out of the morass of delayed projects, questionable quality and missed deliveries in which they often find themselves.

It's clear that DevOps has the potential to address the many challenges that IT faces. Organizations that have embraced DevOps - including companies such as Etsy, Netflix, Target, Walmart, Amazon and Facebook ¹ - have shown that DevOps principles can lead to competitive differentiation by enabling teams to deliver higher quality software, faster. As a result, it's not a stretch to say that DevOps is becoming the industry standard for software development.

With all this excitement, though, comes a sneaking suspicion that not everyone is talking about the same thing when they talk about DevOps. This suspicion is reinforced by CTOs who claim they are "doing" DevOps or vendors selling tools that magically enable you to "do" DevOps. It can be helpful to reconcile the many interpretations of DevOps that muddy the water and potentially inhibit adoption.

Since the earliest days of DevOps, debates about what DevOps is have existed. Fortunately, over the past few years, there appears to be a growing consensus.

So What Is DevOps, Really?

To clearly understand what DevOps is, it helps to understand what DevOps is not. DevOps is not a methodology or process, nor is it a single tool or technology. In fact, DevOps cannot even be tightly defined as being strictly about development and operations, though its foundations are clearly there. And, although many of the organizations well-known for their success with DevOps are Software as a Service (SaaS) companies, DevOps is certainly not only for SaaS applications. Lastly, DevOps is most definitely not something you "do."

Recent consensus on what DevOps is centered on the idea that DevOps is primarily about culture. The DevOps culture is based on a set of principles an organization initially aspires and ultimately adheres to. Organizations that have adopted this culture value collaboration, experimentation, and learning. In a DevOps culture, all participants in the software delivery lifecycle (not just development and operations) align around a shared goal: the rapid delivery of stable, high-quality software from concept to customer. Since DevOps is a cultural thing, technically it does not require automation. However, automation of software development, testing, and deployment through continuous delivery is widely recognized as a key enabler of DevOps. Automation enables organizations to deliver software more quickly while ensuring operations can have confidence in what is being deployed, and customers get the quality, security, and stability they require.

The DevOps Trinity

A lens for viewing DevOps culture in a simplified form focuses on DevOps as being about gaining alignment between all software development lifecycle participants on three planes - people, process, and tools - or what we can think of as the DevOps trinity.

In practice, misunderstandings on what DevOps is or shortcuts taken in a rush to implement DevOps often result in an organization attempting a DevOps transformation without considering all three components of the trinity. Failure to respect all components almost always leads to failure and unmet expectations.

For example, consider an organization that dismisses cultural change as a requirement. Seeking to accelerate the delivery of higher quality software, this team approaches DevOps as a tools and technology challenge. The organization makes a significant investment in automated tools for testing but neglects to institute a cultural focus on quality first. Without the cultural focus on quality, teams go through the motions but don't actively take steps to ensure quality constantly and consistently. Important aspects of quality include setting effective quality goals, implementing the appropriate levels of automation or collaborating across silos to correct problems early and quickly. Without a focus on these aspects of quality, an organization is unlikely to see improvements in quality or reductions in defects. Instead, they find they can deliver more quickly, but at the cost of decreased quality and more firefighting when defects inevitably arise.

Conversely, an organization fully committed to cultural change but unwilling or unable to adopt agile methods and automated tools will find that the cultural change is simply too difficult to sustain in practice; with manual steps, a heavyweight process, and ill-fitting, cumbersome legacy tools still in place, the expectations for faster delivery go unmet and the transformation is eventually abandoned as a failed initiative.

Framing DevOps

So far we've talked about DevOps in terms of a culture based on certain principles and in terms of the trinity of people, process, and tools. The truth is that there are several models for defining and describing DevOps, and all of them can lead to a deeper, fuller understanding as well as a smoother DevOps implementation. One good example is the Three Ways of DevOps described by Gene Kim and his co-authors in their insightful book The Phoenix Project. Of course, these ways - systems thinking, amplification of feedback loops and a culture of continual experimentation and learning - overlap significantly with the principles outlined earlier. Another good example is the CAMS model, which overlaps similarly with its focus on culture, automation, management, and sharing.

Returning to the idea of the trinity, there is one more way to frame DevOps that resonates with many in IT. In this framework, the software development lifecycle is viewed as having upstream (development) and downstream (operations) halves. The two halves are part of the same software delivery process but in many non-DevOps IT organizations these halves are highly disconnected (Figure 1).

Upstream, the development culture usually prioritizes speed and innovation, whereas downstream the operations culture is tasked with a focus on maintaining quality, stability, and uptime. Upstream, development uses point tools to define and build software using agile methods. Downstream, enterprise class tools are the norm for managing the test, release, deployment, and operation of the software. Downstream meetings are much more likely to be filled with talk of Information Technology Infrastructure Library (ITIL) and Project Management Body of Knowledge (PMBOK) than Kanban and the latest scrum. DevOps is about connecting these worlds and eliminating the chasm that exists between the upstream and the downstream.

A Look at the "How" of DevOps

With a better understanding of what the DevOps state looks like, the next question for an organization is, "How do we get there?" It's a deep question about which numerous full-length articles and entire books have been written. The steps needed to change a culture are not easily summarized and much depends on the organization making the transition. There are however, a few steps any organization can take to begin paving the way. You cannot "do" DevOps, but you can, to start with, do agile development with continuous integration (CI) upstream. Similarly, you can do continuous delivery (CD) downstream. Success with CI and CD depends heavily on automation, because automation not only saves time but it also reduces defects, increases consistency and enables self-service. By automating CI and CD and encouraging open communication and collaboration, organizations begin to span the chasm that separates the upstream from the downstream and establish the foundation for a DevOps transformation.

Often, discussions on the how of DevOps are too narrowly focused on the technical core of what happens from the time developers commit code to the time software is deployed to a server. But in reality, it's just as important to ensure the customer's needs are understood. And from there, to have a plan to define a solution, a plan to deliver it and a plan to support it once it moves into operation. The entire feedback loop spans more than just Dev and Ops, and that is why it's important to recognize that DevOps extends from concept to customer.

Keep in mind that the benefits of a DevOps transition do not suddenly appear one day, once an organization has achieved a particular state. Rather the benefits accumulate as the transition gathers momentum. As it grows stronger and more consistent, an organization's ability to deliver better software faster becomes a competitive differentiator, enabling the organization to innovate, eliminate waste and respond rapidly to market needs.

¹ 10 companies killing it at DevOps, TechBeacon, September 25, 2015, http://techbeacon.com/10-companies-killing-it-devops.