DevOps is building a ton of momentum in the industry and for good reason. It has a lot of power to make a huge impact on organizations and people and because of that, more and more organizations are going through DevOps transformations.

Despite all of this momentum, I’ve had a lot of people ask me, “What is DevOps?” Truth be told, I’ve asked that same question to a lot of people, too. DevOps is enigmatic in that this simple question has a surprisingly complicated answer. Different groups of people have a different familiarity and understanding of DevOps so you run the risk of giving the wrong definition to the wrong group. In one case, the definition you provide might have people looking at you like a nut job or zealot. In another case, people might scoff at you because “you just don’t get it.” ScriptRock has a great post on the problem with defining DevOps. Read the comments, too, because they’re enlightening.

Here are some of the definitions I’ve heard and read.

From the 2014 State of DevOps Report by Nicole Forsgren Velasquez, Gene Kim, Puppet Labs, and Jez Humble:

“DevOps, a movement of people who care about developing and operating reliable, secure, high performance systems at scale, has always — intentionally — lacked a definition or manifesto.”

From Wikipedia:

“DevOps (a portmanteau of “development” and “operations”) is a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation and measurement between software developers and Information Technology (IT) professionals.” (When was the last time you heard the term “portmanteau” used in conversation?)

From Andrew Storms’ blog post on DevOps.com:

“While a widely agreed upon definition of DevOps is still up for grabs, its safe to say that DevOps is generally inclusive of a few core tools and principles. First, DevOps promotes a culture of cooperation and sharing among different groups in an organization. Second, DevOps promotes the use of heavy automation, decreasing time to market and agile development.”

And finally, from kindred spirit Greg Elin at Gitmachines:

“DevOps describes a mindset and set of practices organizations adopt when they decide they are going to apply the tested practices of operations management and supply chain management to software system development and operations. The primary benefit is the instrumentation of the performance of the supply chain for developing deploying value via software and connecting the performance of that software supply chain to key value metrics of the business, such as conversion rates.”

At the risk of offending or confusing someone (or everyone), here’s my working definition of DevOps that attempts to blend what I’ve heard and read into something comprehensible and useful.

“DevOps is a movement to create a mindset that encourages collaboration among people with different skills and experience within an organization to build high quality working software and deliver it into production quickly and frequently to help their organization win.”

Terrific. One more ingredient to add to the DevOps definition stew.

Here’s a thought. Maybe we shouldn’t be talking so much about what DevOps is in favor of talking about why we should care about DevOps.

Almost everyone in the DevOps community knows The Phoenix Project is required reading for understanding what DevOps is all about. You feel Parts Unlimited go through the transformation and by the end of the book, you want what they had. And if the “heart” argument doesn’t work, let me give you some facts for your “head” from that 2014 State of DevOps Report and a presentation on it from the Velocity conference.

High-performing IT organizations (i.e., those that have gone through a DevOps transformation) enjoy these results:

• 30 times more frequent deployments.
• 8,000 times faster lead times than their peers.
• Twice the change success rate.
• 12 times faster mean time to recovery (MTTR).
• Twice as likely to exceed profitability, market share, and productivity goals.
• 50% higher market cap growth over three years (where the data were available).

I don’t care how you define DevOps if those are the kind of results I can get from it. So let’s stop debating “what” DevOps is and start talking more about the “why” of DevOps.