What Is the Definition of DevOps?

Everywhere you turn these days, you hear the term "DevOps." At first blush, DevOps may seem like a pretty straightforward concept. After all, isn't the word itself just a combination of "Dev" and "Ops"?

Well, yes. But let's delve into that a bit more...

At its heart, just like the word itself, DevOps is about bringing together historically separate functional areas. It involves "bridging the gap" — or "removing silos between" — software development ("Dev") and IT operations ("Ops") teams, often with the goal of being able to release software faster, and with greater stability.

But since its introduction about a decade ago, DevOps has become an umbrella buzzword of sorts for any and every trend in the software development + IT operations space. It's understandable, really, because DevOps is still evolving, encompasses so many areas, and is adapted and adopted based on an organization's specific business objectives, priorities, and existing knowledge base.

By the end of this article, we'll seek to provide our own principle-based definition of what DevOps is, but before we can do so, it's helpful to discuss what DevOps is NOT, dispelling some of the common misconceptions around DevOps.

What DevOps is NOT

People (A Role, Team, or Re-Org)

Merely experimenting with personnel changes and/or team structure is not in and of itself DevOps.
Some common attempts at implementing DevOps with a people focus include:

• Hiring DevOps engineers so that you can check the "Doing DevOps" box
• Creating a third silo between Dev and Ops, and calling it the DevOps team
• "Tearing down the wall" literally (through team co-location) or figuratively (via organizational changes) to remove silos between software development and IT Operations teams

Organizations that treat DevOps as something that can be accomplished through a re-org or hiring effort are only looking at one piece of the DevOps puzzle. Team structure and roles are secondary to the underlying cooperative practices at work.

The Agile Admin's popular blog post, "What is DevOps?" puts forth the following definition of DevOps, which is rooted in that concept of cooperation:

"DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support."

Process (or Lack Thereof)

You can't talk about DevOps without mentioning process. Many may actually think of DevOps as a complete departure from process — or perhaps just a departure from what historically have been the visible by-products of a process-minded organization, such as documentation- and review-heavy "gates" built into the software development lifecycle (SDLC).

In an interview with Computer Business Review, Sonatype's own CTO, Brian Fox, stated that he believes process (and the culture built around it) is often the biggest hurdle for organizations seeking to adopt a DevOps mindset:

"What we see in the market is that our customer's greatest challenge today is often the cultural change required to get all of the process owners to think outside the legacy process box they find themselves in."

For example, a couple of the key movements that inspired DevOps — Agile software development and Continuous Delivery — are indeed departures from that increasingly dated Waterfall model of software development, but they do not actually throw process to the wind, as some might think.

Instead, they reimagine process, using methods like Scrum to facilitate team communication and flow of work, and implementing CI/CD automated processes and tooling to continuously integrate code changes and deploy applications to production on-demand. What feels like a departure from process is merely the continual refining of a process to reduce the reliance on manual efforts and time spent creating documentation to enable asynchronous cross-team collaboration, instead of doing it face-to-face, every day.

Tools

Google "What is DevOps?" and you'll also quickly find that most technology companies that deliver automated tooling (Infrastructure-as-Code, microservices, containerization, cloud services, etc.) in the DevOps space present their own definitions of DevOps with a focus on their contributions to the market. For example:

• Amazon's take is (not surprisingly) rooted deeply in their cloud-based Infrastructure-as-a-Service offerings.
• GitLab's take is all about driving a common toolset to optimize collaboration between development and operations.
• Microsoft's take also speaks to a lot of the areas (Infrastructure as Code, Microservices, and Monitoring) in which they deliver solutions.
• New Relic's take is centered on monitoring and measurement.

These examples are useful, but underscore our assertion that DevOps still means different things to different people (or organizations). DevOps is interpreted and implemented differently, depending on the organization and its core values and competencies. Tools that enable IT automation are a key aspect of making DevOps work in practice, but if the underlying principles and processes aren't a part of the equation, tools alone won't bring your organization to the desired high-performing outcomes.

The Agile Admin cautions practitioners against merely taking a tools-focused DevOps approach:

"DevOps is also not simply implementing a set of tools. One reason why I feel that a more commonly accepted definition of DevOps is needed is that having various confusing and poorly structured definitions increases the risk that people will pass by the "theory" and implement the processes or tools of DevOps without the principles in mind, which is definitely an antipattern. Automation is just the exercise of power, and unwise automation can do as much damage as wise automation can bring benefit."

What DevOps IS

DevOps is not any one of the items listed above (People, Process, and/or Tools), but it's often confused as one or more of the three cobbled together. They are all important parts of an organization's adoption of DevOps, but won't do the job on their own.

So what is DevOps exactly?

When in doubt, start with Wikipedia. Just kidding. (Sort of.)

The Wikipedia entry for DevOps, is really quite telling:

"DevOps is a set of software development practices that combines software development (Dev) and information technology operations (Ops) to shorten the systems development life cycle while delivering features, fixes, and updates frequently in close alignment with business objectives."

That's actually a pretty good outcome-focused definition, but what's most interesting about the Wikipedia entry is that the next section quickly admits its sources still need verification, and that there is no one standard, agreed upon definition of the term:

"Academics and practitioners have not developed a unique definition for the term 'DevOps'."

So we'll have to keep digging.

A Set of Principles

The closest thing we have to an agreement between academics and practitioners in defining DevOps is chronicled in The DevOps Handbook, written by some of the movement's thought leaders and pioneers. Their definition is rooted in the theoretical and historical underpinnings of DevOps, as well as the principles upon which it is built. But although the definition is certainly comprehensive, it may not be the most memorable simply because of its length:

"DevOps is the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream. DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others. Other valuable contexts that DevOps draws from include high-trust management cultures, servant leadership, and organizational change management. The result is world-class reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability through the technology value stream, including Product Management, Development, QA, IT Operations, and Infosec."

The key takeaway from this definition is really understanding the depth and breadth of the bodies of work that inform DevOps, with its focus being applying these trusted principles to quickly achieve desired outcomes within the technology value stream.

(We'll discuss these principles in greater detail in a later article.)

A Culture (of Learning and Continuous Improvement)

When you consider all of the aspects of DevOps mentioned up to this point (People, Process, Tools, and Principles), you're 80% "there" in understanding what DevOps encompasses.

But the remaining 20% can really make or break a DevOps approach within an organization, because without it, the important "fail fast, learn, and try again" mantra won't feel safe or be obtainable in reality.

Several keywords within The DevOps Handbook definition above deserve further emphasis and commentary to round out our definition:

• Learning organizations
• Safety culture
• High-trust management cultures
• Servant leadership

In Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations, the authors discuss the need for a generative culture (a term coined by Westrum), which focuses on the mission and optimizing the flow of information across teams, rather than a pathological, command-and-control, power-centered mindset:

"...in organizations with a generative culture, people collaborate more effectively and there is a higher level of trust both across the organization and up and down the hierarchy."

A generative organizational culture devoted to this type of continuous learning and improvement also provides an important distinction in their approach to DevOps adoption, as Steve Mezak noted:

"It's reasonable to describe DevOps as a journey, or perhaps an aspiration, rather than defined destination. DevOps, like lean manufacturing, seeks continuous improvement, seeking higher output, greater efficiencies and even continuous deployment. Automated tools that support DevOps continue to evolve."

When you build the People, Process, and Tools on top of foundational DevOps Principles and a Culture committed to Learning and Continuous Improvement, you're well on your way to understanding DevOps from a holistic perspective.

Therefore, the definition of DevOps we propose is the following:

"DevOps is a discipline rooted in collaboration and communication, made possible by removing perceived barriers between teams and building trust in a culture of learning and continuous improvement, and drawing from proven technical and management practices that work toward a common goal of shortening software delivery cycles and improving the stability of deployments."

Sources:
Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by Nicole Forsgren PhD, Jez Humble, and Gene Kim

DevOps entry, Wikipedia

Five Questions with...Sonatype CTO Brian Fox by Ed Targett

The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations by Gene Kim, Jez Humble, Patrick DeBois, & John Willis

The Origin of DevOps: What's in a Name? by Steve Mezak

What is DevOps? The Agile Admin blog