My Definition of DevOps

DevOps: A culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system.

Yeah, I know. The world needs another definition of DevOps like I need another (whatever). I heard the term DevOps Engineer one too many times in the past few days and felt like I needed a better way to explain what it is (and isn’t).

I should clarify something that I’ve been asked since first publishing this last year. I’m not saying you should adopt this definition as your own, or your organization’s. I’m totally happy if you do, but that’s not the point of my sharing it. I share this so that you know what I mean when I use the term.

It’s not important that the “industry” agree on a definition. It would be awesome, but it’s not going to happen. It’s important that your organization agree (or at least accept) a shared definition.

So, breaking down my definition…

A culture

You can’t “do” DevOps.

… where people, regardless of title or background …

A lot of people think of DevOps as Developers and Operations. Thought of this way, the term DevOps leaves out of a bunch of groups involved in the process. Trying to add everyone involved to a single term is an exercise in futility, and would be silly even if it wasn’t. Nathan Harvey explained this quite well in his talk “Rugged Enterprise DevSecNetQAGovOps”. (Spoiler alert: If you mix Sugar, Flour, Cocoa, Salt, Baking Soda and a few other things together, you don’t get SugFloCocSalBak, you get a cake.)

It’s about developing and operating a system. They are verbs.

A variety of backgrounds is every bit as important. This is why diversity (in all of its varieties) is so stressed at good DevOps events. If everyone has the same experiences and viewpoints, your chance of creating something with wide appeal is pretty darn low. To say nothing of the fact that it’s just the right thing to do.

All of this as a very long way to say it means the whole team.

… work together to imagine, develop, deploy …

There was a project at ThoughtWorks a little over ten years ago that spurred much of our work on Continuous Delivery. The team developed a Java application on Windows, and when it was “done” they deployed it onto Solaris. It didn’t work.

What if the people who really knew how to run the Solaris systems and would end up being responsible for the application for years to come had been on the team? Better yet, what if they were pairing with the people creating the code? Better even still, what if that whole team was responsible for the application for the rest of its life?

Dev: I’m gonna do it like this
Ops: If you do it that way it will blow up when we try to use NFS on Solaris
Dev: Oh, what if we did it this way?
Ops: That would work, but still could be flaky and result in us both getting paged at 3AM.
Dev: I don’t want to get paged at 3AM, what do you suggest? (slides over pairing keyboard)
Ops: Let’s do it this way.

Months of rework avoided.

Note our fictional alteration of history did not include the Ops person learning advanced Java. It also did not involve the Dev person getting certified on Solaris. It involved a team with a broader knowledge of how the system would be run. (Oh, and as a result the Dev person learned a bit about Solaris and the Ops person learned a bit about Java. Happiness.)

I’m sure you can think of similar interactions between all types of roles.

… and operate a system.

(Note: System is the word I’m least comfortable with in this whole thing. I couldn’t think of a better one sitting here in an airport, but feel free to let me know if you do.)

The key here was actually hinted at in the previous section. If the system goes down at 3AM, the team member on call gets paged. Not the person.

As Amazon CTO Werner Vogels says; “you build it, you run it”.

Added 4 August, 2018 – Platforms play an important part

It’s important to note that with the definition (and the evolution of my understanding of DevOps since originally writing this 18 months ago) I don’t mean to imply that the team creating the system is the only one who controls any part of their infrastructure.

I’m a huge fan of making a platform available to the organization. A proper platform can enable teams to be self reliant while also ensuring important factors such as security and compliance are accounted for.

I was planning on adding another post describing what I mean when I say platform, but my ThoughtWorks colleague Evan Bottcher has already done a much better job than I would on Martin Fowler’s site at

DevOps is definitely not a role.

A job title of “culture where people, regardless of title or background, work together to imagine, develop, deploy and operate a system engineer” would be pretty silly. I believe “DevOps Engineer” is just as bad.

Hire the skills you need to fill out your team. If you need help with automating the deployment of your system, feel free to hire an experienced release engineer, even if they don’t know dockerdockerdocker.

5 thoughts on “My Definition of DevOps

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s