DevOps is Disintegrating… But Maybe That’s OK

Note: originally appeared in TechBeacon.

DevOps is disintegrating. Such a claim may sound absurd if you search Google for the term, glance at the program of any IT Ops-related conference, check out all of the DevOps resources out there, or listen to the buzz in daily Scrum meetings across the industry.

But you need to understand what I mean by the word “disintegrate.” I’m not talking about what happens when you blow something up or the slow process of some ancient object turning to dust. DevOps certainly isn’t disintegrating in either of those ways. Rather, its disintegration goes back to the roots of the word: “to reduce to fragments, or parts; to break up or destroy the cohesion of an object.”

DevOps is disintegrating… but not like this, exactly…

Everyone Has a Different Definition

One of the ongoing critiques of the DevOps movement is that the DevOps community steadfastly refuses to agree upon a definition or mimic Agile’s adoption of a manifesto describing its values. Baron Schwartz lamented this lack of a structured definition (and sometimes a visceral reaction against any definition) back in January of 2015. Those concerns may be coming home to roost.

Today, when someone says “DevOps,” the context isn’t anchored in anything, so it’s difficult to tell through what framework that person is seeing DevOps.

For some, DevOps is a handy vehicle for selling software. Automation and other tooling that are critical in an IT operations context is foundational to DevOps, but many use that fact to their advantage, rebranding decade-old application lifecycle management or deployment tools as “DevOps-ready.” Even newer-generation configuration management and orchestration tools have deep contextual roots in DevOps. And don’t even get me started on the number of DevOps-istas claiming that Git is required to “do DevOps right.”

For some, DevOps is a way of selling their ideas on culture: to explore all the soft, fuzzy, human interactions that lie just beyond the technology. But now “DevOps as culture” is being used to sell organizational cultures in the form of process improvement. Indeed, the ITIL community has realized that there might just be something to this DevOps thing and has begun incorporating it into its canon.

The Agile with a capital “A” community has realized that it had better pay attention to DevOps, lest those Scrum meetings and Kanban boards get rebranded as DevOps meetings to discuss DevOps boards. And the Lean/Six Sigma crowd reminds us that it’s all about Deming (and thus, we would do well to join them in just skipping ahead to what Deming professed). Today, there’s even a DevOps Practitioner certification.

For still others, DevOps represents a unique moment in time to fix the tech world’s diversity problem. There is no denying that the IT and software development industries have a diversity problem; the statistics are, in a word, abysmal. Some consider DevOps and its themes of empathy and inclusivity as one of the best vehicles for making life better for women, people of color, and LGBTQ software and operations engineers. So to them, the creation and curation of physical and virtual spaces that focus on solving these problems takes the driver’s seat, with culture sitting up front, and everything else piled into the back seat. DevOps provides the highway upon which to drive forward these conversations.

Finally, some just use DevOps to describe the indescribable. In 2009, John Allspaw and Paul Hammond presented “10 Deploys Per Day,” describing what was at that time the nearly unthinkable level of cooperation at Flickr. It’s become one of the seminal DevOps presentations, and yet “DevOps,” as a word, doesn’t appear in their slide deck or presentation.

Similarly, many of the DevOps unicorns of today, from Netflix to Target, don’t use the term internally. For them, the organizational environments they’ve created to experiment with new practices and tools just represent new ways of working; it’s the external community that tacks the term “DevOps” onto these successful examples of experimentation and learning.

To be clear, none of these lenses is better than any of the others, nor are any of the motivations. But because they describe such different facets and goals, it’s no wonder that many are still so confused after repeatedly asking, “Yeah, but just tell me: What is DevOps?”

And as resources and sponsorships have flowed to support these different constituencies’ framings, the incentive to maintain cohesion within the DevOps community, as opposed to doubling down on your own framing, is reduced. This leaves DevOps, conceptually, in a state of active disintegration, despite (and, because of) its popularity. It’s a popularity that lacks a definition or any document to declare its own shared values.

In effect, DevOps is becoming distractingly dissonant.

What You Can Do About It

So what does DevOps’ disintegration mean for you? Should you just ignore DevOps? Probably not. But here’s what you should do:

  • Pay attention to your silos and streams. One of the most astute observations about DevOps that I’ve read is that the vast majority of its problems continue to stem from the structures and incentives (both explicit and implicit) within organizations and a lack of understanding of the organizations’ own software delivery value streams. Understanding these, and working to align them more with desired outcomes, is still the best activity you can pursue that will pay dividends.
  • Stop asking what DevOps is. No, really. Just stop. Accept the reality that asking ten people that question will net you fifteen answers. The definition doesn’t matter. The behavioral patterns between people, teams, computers, and subsystems, however, will continue to matter, and many of those patterns have been documented at length. Read up on them; experiment with them; tweak them to your own context and environment. But beware of formulaic recipes and one-size-fits-all solutions and advice. That is, unless you want a wholesale repeat of the agile experience, where most of us followed the processes without ever understanding why we were doing so, only to wonder why we never got the advertised results.

To quote one of my favorite television series “You can’t take a picture of this. It’s already gone.” DevOps as we knew it, if we ever really knew it, is indeed already gone.

But that’s okay, because that vacuum forces us to face head on what’s really important: the unique complexities of our own team and our own company’s tooling, diversity, incentives, empathy, and culture.

And there’s one that thing DevOps has unarguably shown us: You should be constantly engaged in that process, no matter what you call it.