“If you label me, you negate me.” –Kierkegaard or Dick Van Patten
I
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.
The Goat Farm 
It seems your final point is once again directed at Enterprises. It implies that Enterprises need to be willing to listen to smaller shops in order to have a more well-rounded view of implementing DevOps practices. So why not tell smaller shops that they can also learn from Enterprises as well? Is the point that smaller shops can always do it so much better than Enterprises? If the post was an attempt of mea culpa it seems a backhanded one at that.
Smaller shops tend to have a legacy of being able to achieve things faster, mainly because the red tape and legacy isn’t there. The disadvantage is that they often don’t have the resources that larger shops have.
Listening is often a two way street, you are right on there. But I’ve heard stories of and have witnessed first hand interactions where people are shut down, talked over, and ignored because they aren’t “Enterprise”.
Thanks for the comment.
If you don’t know anything about laundry detergent and you want to make sure no one will be mad at you for ruining your girlfriend’s jeans, you’ll buy the stuff that says: “specifically designed for women’s jeans!”. If you fail, you can always point at the label and claim you bought the right stuff and followed instructions to the letter.
Even if you *do* know for a fact that a cheaper generic detergent is identical to the “special” stuff, it might still be wiser to buy the “right” product: you don’t always get to explain yourself to those who pass judgement and you create an opportunity for your opponents to discredit your actions.
In the Enterprise, this is far more common than in smaller shops and this is one of the reasons why many prefer a “Real Enterprise Solution” from a “Real Enterprise Vendor”. These vendors usually don’t mind long meetings, lots of paper work and late payments as well 🙂
Very interesting argument and you’ve left me torn.
In very real ways, an enterprise is no different than a small company. It’s just a bunch of people working together to try and solve some problems that people are willing to pay to have solved. The core lessons of DevOps are no different – a culture of teamwork, cross-functional teams / cooperation, a bias towards automating stuff, etc.
What is different is the scale and often the scale of the problem. As an obvious example, fostering cross-silo cooperation is simply easier when the person you need to cooperate with is on the other side of the room rather than on the other side of the building. Or on the other side of the building rather than on the other side of the world.
I tend to prefer saying “DevOps in the Enterprise” rather than “Enterprise DevOps” but flagging a conversation as specifically about the challenges you have in bigger companies is useful. It tells someone from a small shop not to waste their time, and someone from a larger shop that we’re going to be talking about their particular challenges.
I hope it doesn’t imply that enterprises have nothing to learn from small shops. My audience would be surprised early in the conversation. Many of the examples I would provide would reference stories from smaller shops that show what is possible, and then move to a “but you’re huge, regulated, traditionally slow. How are you going to be more like the little guy?” The little guy is extraordinarily relevant as folks in technical fields almost take it for granted that the little guy can kill the big guy. The big guy needs to get faster and more effective to avoid getting disrupted to death.
I suspect that getting an organization with several tens of thousands of techies to grok DevOps is going to require different methods than getting a single 2-pizza team to grok it. The experience Agile has had would suggest that, and provides some lessons (if not clear answers).
Pingback: Contino | Why Rejecting ‘Enterprise DevOps’ Hurts The Movement - Contino