Labeling DevOps Hurts the Movement

If you label me, you negate me.” –Kierkegaard or Dick Van Patten

INo Labels posted a rather inflammatory tweet last week (shocking, I know) that attacked the concept of “Enterprise DevOps.” For those of you that don’t know there has been a movement, led mainly by traditional enterprise software vendors, to define a unique branch of DevOps that focuses solely on specific challenges that Enterprise IT shops face in their journey to a DevOps operating model. The theory being that traditional DevOps ideas won’t work in Enterprise IT, and there must be Enterprise specific ideas for DevOps.

This tweet gained a few favorites and retweets, but it also ruffled feathers. The most boisterous response was from a Benjamin Wotton. Now I have never met Benjamin in person that I can recall, nor had we ever before interacted online. Benjamin’s problem with my tweet was that he uses the term “Enterprise DevOps” all the time, and that he is proud of it. He also pointed out that his definition encapsulates the fact that DevOps in the enterprise is more complex & multifaceted. That I can agree with, and I pointed out Rob Cummings’ idea, that DevOps in the enterprise just requires more patience, which in my mind takes into account that Enterprises are more complex and multifaceted.

But that is not the tweet exchange that interests me the most. Patrick Debois responded in the middle of this exchange and made a compelling point by questioning whether I was being inclusive. To me that equaled the Godfather of DevOps putting a horse head in my bed.

After I thought about this, the whole idea of “Enterprise DevOps” actually creates an exclusive environment that the DevOps community fights hard against. “Enterprise DevOps” creates an environment that says Enterprises can’t learn from “Standard DevOps”, and reinforces this idea that enterprises can’t learn anything from non-enterprises (web only shops, startups, “webscale” companies, etc).

But this is completely wrong. Netflix was often accused of being a unicorn; this mythical creature that no organization could become. As the industry has progressed, Netflix has instead become more and more a model of success that Enterprises try to emulate. I have worked with major banks, retailers, software shops, and more that all seek to emulate some aspect of the Netflix model. While they all don’t seek to become a unicorn, some seek to have a horn, some seek to have magical blood, and some seek to crap rainbows.

The fact of the matter is there is no one true DevOps. There are operating models that we might seek to emulate, but every organization’s needs are different and approaches require tailoring to the current needs and maturity of the organization. This is as true for the 1 person shop as it is for the 10,000 person shop. Cookie-cutter Enterprise IT operations has always been a pipe dream being sold by those who sell really expensive software and professional services contracts. It won’t happen with ITIL, Business Service Management, DevOps, or any other buzzword of the day.

The idea of DevOps is about listening. It’s about listening to those that are smaller than us; it’s about listening to those that are larger than us. It’s about having an open mind that someone (internal or external) might actually have an idea that can help us, and having the flexibility in our organization to rapidly experiment with that idea.

As Andrew Shafer is fond of saying, “We get the DevOps we deserve.” If you choose to ignore the advice of others, if you think you can learn nothing from the smaller shops and only rely on “Enterprise DevOps™” advice, you miss out on a world of opportunity and ideas that could help you improve. In the end you’ll have your DevOps: the one you deserve.