2015-23-February-Question.jpg
Everyone is trying to define DevOps. Whether it's a three page white paper or an annotated diagram/model, this is perilous territory as the most vibrant thing in the DevOps movement is its lack of a singular definition (i.e., a litmus test). Instead of asking "What is DevOps?" maybe we should be asking "How do you DevOps?"

Let's Start at the Beginning

I spent a few hours with an old friend who leads a geographically dispersed team that maintains an application stack in the medical industry. He had not heard of DevOps, but was intimately familiar with the downward spiral of irrational expectations that has plagued IT shops for the last 25 years.

He was perplexed by an article he read on the topic and looking for something to put it in perspective. "What is it? I don't see any specifics," he said. We struggled for a bit and then I returned to the concept of the theory of constraints.

The theory of constraints, a management philosophy first articulated by Eliyahu M. Goldratt in his 1984 book "The Goal," suggests that all systems have constrained throughput and that unless a system improvement is made at the tightest constraint, the improvement is not an improvement at all, rather, it is an illusion.

It's simple to visualize. Any throughput improvement before the tightest constraint will increase backup at the constraint and any improvement after the tightest constraint can't improve throughput because it will create a void. 

2015-23-February-Bottleneck.jpg

All's Well Doesn't Always End Well

Explaining this analogy is where the light begins to come on. Once you understand the theory, the consequences become so obvious to the IT professional who is fluent in systems, that both fear and relief crop up. Fear for the consequences that at first glance seem to be inevitable and relief because you can identify a reason as to why things are the way they are.

Every shop will argue where the tightest constraint is, but the typical top three (in chronological order) are: business decisions, QA and deployment. Given that the agile methodology has become mainstream and agile's basic goal is to loosen the constraint at the "work intake" part of the system, without any loosening at the QA and deployment stages, what do you think will happen? Whatever happens, it won't be pretty.

DevOps is designed to loosen constraints downstream from the business decisions where agile is focused. This is where it gets hairy, because the set of DevOps tactics is neither finite nor limited to technology systems.

The mix of artisan culture, automation zealotry and metric obsession leaves many people struggling to concisely define the movement and answer the question "What is DevOps?" After some time I grew to appreciate the value in not being able to explicitly define it -- because now, DevOps is what you and your enterprise make of it.

A Little Bit of Mystery Can Be A Good Thing

If your enterprise cherishes ultra fast performance and a slew of metric laden dashboards, that qualifies. If your startup is populated by full stack engineers who automate each and every configuration set, that passes muster. If your department strives to build an artisan culture into its software engineering and operational disciplines, then you are in the club.

My team has a multidimensional approach to DevOps and it's not meant to be a measuring stick to stand next to your approach. We are all dancing to the music we hear within the hallways of our enterprises. We are unique and that is good. This is why DevOps is a vibrant movement embraced by the masses of IT professionals, each in their own unique way and without a rule book. This is also why there a dialogue continues within the community on the topic of whether or not "DevOps" is appropriate to use in people's titles.

In the midst of all the undefinable goodness, Gene Kim and his merry band of collaborators are putting the last round of edits into the anticipated follow-up to "The Phoenix Project." The soon to be released "DevOps Cookbook" is chock full of pathways and dimensions that any team can use to start their own journey. While the book has a beginning, middle and end, it isn't an instruction manual with a fixed starting point. It's up to you, the individual, to find your preferred starting place. It may be daunting, but I challenge you to name the last truly inspiring thing you have been a part of that wasn't just a tiny bit scary.

So I ask again and I hope you post your answer in the comments: "How do you DevOps?"