You are here

Driving DevOps: Where should the leadership begin?

public://pictures/Tony-Bradley-Editor-in-Chief-TechSpective.net_.jpg
Tony Bradley, Editor-in-Chief, TechSpective.net

DevOps is no longer a niche or fringe concept. It has achieved mainstream status and businesses of all shapes and sizes are adopting DevOps tools and principles. DevOps involves various teams and individuals working together toward a common goal, but someone has to lead the effort. Is there a specific role that should own DevOps, or does it not matter who drives the DevOps initiative?

DevOps done right

What's the "right" way to approach DevOps? Should it be a decision by upper management that's pushed down throughout the organization or a grassroots movement from the trenches that strives for support from upper management? Is there even a "right" way?

Gene Kim, coauthor of The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win and the upcoming DevOps Cookbook, joined Mike Kavis earlier this year on a Cloud Technology Partners podcast. The two discussed what works and what doesn't in DevOps and touched briefly on the topic of who should lead DevOps initiatives.

Kim noted that he sees a number of large, complex organizations doing miraculous things with DevOps. Organizations such as Disney, GE, Raytheon, and Capital One—businesses that have to deal with significantly more complexity and overcome entrenched silos and internal politics—are managing to achieve DevOps success on par with DevOps "unicorns" like Netflix and Facebook. 

 

It takes a village

The reality is that companies—especially larger enterprises—aren't embracing or implementing DevOps across the board. It's generally a scenario where one department or team is implementing DevOps tools and principles, and the company adapts one value stream at a time.

One assumption that's often made is that a majority of the DevOps success stories should come from greenfield projects—brand new companies or projects that can simply start from scratch and hit the ground running with a DevOps mindset. Kim, however, says that what he has seen is that about two-thirds of the success stories come from brownfield customers—businesses dealing with legacy hardware and software and existing processes.

So who's leading the DevOps movement for these organizations? Kim notes that of the 50 or so speakers at the DevOps Days conference, the top job title was director of operations, followed by chief architect, and then director of development. What's interesting is that the order was reversed for the session attendees, with most being directors of development, followed by chief architects, and then directors of operations.

What does that mean? It implies that the early adopters of DevOps were driven primarily by operations leaders—which is why those individuals have already risen to the level of speaking at events and sharing their DevOps experiences. The current push for DevOps, on the other hand, seems to be coming from the developer side of the house, as evidenced by the attendee demographics.

In general, it seems that operations isn't driving DevOps fast enough, so developers are taking the initiative to make it happen. The lesson for operations, according to Kim, is to either get involved with leading the effort or risk becoming irrelevant.

Andi Mann, chief technology advocate at Splunk, spoke about his view of where DevOps leadership should come from in an interview with ActiveState while he was still with CA Technologies. "Originally it started in small firms from the ground up. It was operators and developers who sort of got together, talked about what they could do to improve, collaborated more...And I think there's still a lot of that going on," Mann explained.

He continued, "What I see with my customers at the traditional larger enterprise though, is sometimes devs and ops are very, very separated, larger teams, not as easy to establish that communication themselves, more management, more command and control structure. Devs and ops can do some stuff. They can improve their own workflows, they can start to work, I mean they can certainly call each other up and get the communication and collaboration happening. But in a larger enterprise especially, to make substantial change, I believe you've got to get that top-level support. You can drive it from the bottom, but at some point you're going to hit a ceiling, and you've got to get executive and managerial support."

It's all about the culture

We can all agree about the benefits of DevOps from a broad, organizational perspective: better teamwork across development, testing, deployment, and operations teams; faster time to delivery for customers; greater agility and flexibility. But, for the teams and individuals involved, it can be hard to embrace DevOps objectively, as opposed to viewing it through the filter of their own specialized discipline.

The problem is that each department has its own perspective of the "right" way to do things or what the top priorities are, and that can lead to conflicts. For example, can a DevOps initiative be led effectively by someone from QA without a "test-centric" agenda creeping into the process? Possibly. It helps if everyone is conscious of the bias they bring to the table, though, and everyone can communicate openly.

All teams need to be equal partners and collaborate on an even playing field in order for a DevOps initiative to be successful. DevOps can be driven as a grassroots movement from the bottom or as a management directive from the top. Regardless of how DevOps starts or where it's being driven from, the secret to long term success is buy-in and support from the leadership at the top of the organization.

There are many tools and principles related to DevOps, but the foundation on which DevOps is built is a change in the traditional corporate culture. The idea that roles and responsibilities are strictly segregated by corporate silos is anathema to DevOps. At the core of DevOps is the notion that everyone should cooperate and collaborate toward a common goal and that everyone is responsible for the success of the project. That's a different cultural mindset than most businesses are used to.

The shift is on

Kim addresses this challenge in his discussion with Kavis. He talks about the difficulty of doing something innovative or disruptive within an organization that is built around simply doing things the way they've always been done. It isn't easy to fight the inertia of entrenched corporate processes and procedures to effect change and try to shift the IT culture.

No matter where the spark for DevOps starts or which role drives the effort, what's important is that all parties embrace the concept that everyone involved is accountable for the outcome, and that with that responsibility comes the freedom and empowerment to do something about it.