DevOps is everywhere! The growth and mindshare of the movement is remarkable. But if you care deeply about DevOps, you might agree with me when I say that although its moment has “arrived,” DevOps is in serious trouble. The movement is fragmented and weakly defined, and is being usurped by those who care more about short-term opportunities than the long-term viability of DevOps.
They are the ninety-nine percent, and nobody cares
How bad could it be? Travel back in time. It is mid-November 2011, and Occupy Wall Street is occupying the headlines. One of the major reasons is that the protestors are targeting shipping ports on the West Coast, causing shutdowns and even violence. As things are getting out of hand, parts of the movement start condemning these actions as counter-productive, hurting the 99% instead of the intended 1%. Spokespeople for the movement are quoted in the media as saying the instigators “don’t represent the movement.”
Why did the Occupy movement become a footnote in history so fast? There were several reasons: there was no cohesive agreement on its identity, values, goals, and mission; in an effort to be unlike “them,” the OWS proponents avoided anything that looked like centralized leadership; and it seemed to be entirely negative, advocating nothing to replace what it wanted to remove.
I believe a similar thing is happening to DevOps right now, for many of the same reasons. Let’s talk about some of these problems.
Messaging and positioning
Messaging and positioning are vital when you’re trying to promote something, because without them, nobody will understand what you’re doing, why, and why they should care. DevOps has a messaging and positioning problem, and it hurts the movement. Positioning a product or service can be done several ways, but a standard one that’s worked well for me on several occasions is filling in the blanks of the following template:
For (target customer)
Who (statement of need or opportunity)
The (product) is a (product category)
That (statement of benefit or compelling reason to buy)
Unlike (primary competitive alternative)
It is (statement of differentiation)
This is not a statement of facts, it’s a statement of how you want a target audience to perceive you. You can probably fill in the template quickly for any number of products, trends, and audiences: the iPad, texting, Breaking Bad, Spotify. Now try replacing the parenthesized phrases for DevOps. If you are like me, you’ll find it difficult, especially when you get to the last line.
DevOps can be forgotten as quickly as it arose
What’s unique about DevOps?
The last line of the positioning statement is about differentiation, and it’s foundational. Messaging and positioning isn’t enough. You also need something unique and compelling to message and position — something others can’t say.
What does DevOps offer that’s unique? This is likely to be a real struggle, no matter what you think of DevOps.
- Breaking down silos? Read some of Patrick Lencioni’s books.
- Continuous learning, creating learning organizations? Pick up a copy of Peter Senge’s The Fifth Discipline.
- Aligning IT with business objectives? This is covered by a lot of management gurus, like Peter Drucker.
- Reducing variability in processes? Read The Goal, or learn about Six Sigma.
And on and on it goes. This is a vitally important question: is DevOps just old wine in a new skin? What, exactly, does it advance over previous practices? I am unable to find anything in anyone’s definition of DevOps that isn’t a restatement of an established idea or practice. I think this is a serious challenge. It means that DevOps can be forgotten as quickly as it arose — perhaps replaced by another movement that’s similar but has stronger messaging, positioning, and unique value propositions.
The echo chambers
For a movement that talks about breaking down silos, DevOps can be pretty cliquey.
If you’re selling a “DevOps tool,” for example, there’s a passionate community of people who object that DevOps isn’t tools, isn’t purchasable, isn’t something you can take off the shelf and unwrap. Of course, there are companies who are looking for just that, others who are selling it to them, and the results are quite good by some accounts. But sometimes people seem unwilling to listen to DevOps success stories when they disagree with how DevOps is presented in the story.
Similarly, those who say that enterprises need to do DevOps differently from smaller organizations might be trying to sell an exclusive “enterprise” flavor of DevOps. This is an old trick for management consultants — brand your process/framework/methodology. Boy, does this get some hackles up fast! But why should it? It’s just using messaging and positioning to create a unique value proposition, or the perception of one — something the objectors have not succeeded in doing themselves.
Of course, those who care most are often those with the most at stake. For example, if DevOps is defined as “developers understanding and caring about the impact of their code in production,” it isn’t surprising that the people who are responsible for production systems are happy with the outcome, and sometimes the developers are not as interested. It makes a difference for the sysadmin’s life, but not necessarily for the developer’s. When a sysadmin rails against a developer’s “wrong” ideas about DevOps, therefore, it can be a turn-off. Likewise, a very senior person with lots of experience in formal practices can get irritated when they’re criticized by a younger person who’s never even heard of those disciplines.
My experience is that this all adds up to create echo chambers — groups of people who insist on particular meanings for DevOps, and get strident when others hold different views.
I can understand why people fear the reversal of a cultural shift that’s benefited them. But I think it’s important to understand that the rise of factions was predictable and unavoidable, due to the lack of definition and agreement about what that change was in the first place, and why it was a good thing. This might be a good thing, because it might show how to solve these problems.
Where to go from here
Hopefully I’ve convinced you there’s a problem. Nobody agrees on what DevOps means — except within its echo chambers. The name is vague. The tenets are unoriginal. There’s no cohesive leadership or central personality who can address these problems, so it’s a free-for-all, with companies and individuals using it in obviously self-serving ways. That’s why I say DevOps has an identity crisis.
I’d suggest that, as contrary to DevOps as this might sound, we really need messaging and positioning that we can stand behind. And then we need to be public about it. As one of the characters in the popular DevOps book The Phoenix Project said, “messiahs are good, but scripture is better.” This means that some people need to assert themselves: “We are the ones who created DevOps, our definition is authoritative, and we’ve signed our names to the manifesto. If you want it to be something else, call it by a different name.”
The problem, though, is that DevOps’s only manifesto is “no manifestos.” But nature abhors a vacuum, and without a manifesto, everyone’s going to supply their own. This is clearly what has happened: the Four Pillars, the Three Ways, and so on. There are literally dozens of definitions of DevOps, depending on whom you ask. In The Phoenix Project, there are even references to The DevOps Cookbook, a definition in the form of a book that doesn’t exist!
What can it hurt to create at least a simple website that we all agree represents the core of the DevOps philosophy?
Is it time to rethink the “no manifestos” mandate? What can it hurt to create at least a simple website that we all agree represents the core of the DevOps philosophy? Something worthy of being the first reference from the Wikipedia article, in place of the hodgepodge of bits and pieces referenced there today? You have to start somewhere.
For my part, although I have expressed some concerns and reservations here, I enjoy the conversations and company of people who are interested in DevOps of many flavors. I try to adhere to the philosophy of “take what you like and leave the rest.” This works for me, but I do wish for a more tangible wheel to which I can put my shoulder. I hope that this article is a step toward that in some way, and I look forward to many more conversations online, in-person, and at events such as DevOpsDays, Velocity, and O’Reilly’s upcoming Software Architecture Conference.
Many thanks to various people at O’Reilly, Dave Zwieback, Nathen Harvey, Bridget Kromhout, Mandi Walls, and Anna Navatsyk for helping with this article directly, and numerous others for helping indirectly.
Editor’s note: This is part of our ongoing exploration of the meaning of DevOps and how community plays a crucial role in its definition.
Cropped R + L illustration CC BY-SA 2.0 Libby Levi for opensource.com