The Alienation of DevOps: When Methodology Degrades into a Tool Label

Editor's note: This article was originally published in September. Because of its everyday relevance, we are bringing it back from the archives.

The enterprise technology field has always had a tradition of seeking simple answers. The deep divisions between process people and technical people often form real opposition when they mix.

Business stakeholders often make demands that exceed what technical staff reasonably expect, while layers of legacy backend technology keep IT departments constantly asking for more resources, staff, funding, and tools.

What complicates the problem further is the disconnect between developers and operations staff. Once all business requirements are met, developers hand the software over to operations, leaving deployment and execution to others.

Chaos follows.

However, a new way of working has become increasingly popular, highlighting the need for cultural change in technology to match transformation efforts. Instead of keeping technology deployments separate, development and operations can align in DevOps. Through this methodology, stakeholders are tied to a single project, and those who create the software are also responsible for its deployment.

According to Nigel Kersten, vice president of ecosystem engineering at Puppet, speaking with CIO Dive, DevOps saw a real wave of interest about four or five years ago, coinciding with the release of The Phoenix Project.

The industry has moved beyond the early adopter stage into the mainstream, and it is in this process that the struggle to adopt DevOps culture has surfaced.

"What I repeatedly see is that companies adopt the tools but not the process or cultural changes of DevOps," Kersten said.

The hesitation to implement real organizational change to land DevOps has fostered a potential dependence on the vendor ecosystem. Although DevOps was originally a methodology rooted in grassroots adoption, scaling became an obstacle. This created a demand for tools to simplify and facilitate adoption, while overlooking the indispensable people and process principles.

"DevOps has now been twisted beyond recognition, far from what it originally was," T.J. Randall, vice president of customer success at XebiaLabs, told CIO Dive. The original "cool little concept" focused on how to bring the two diametrically opposed sides of the enterprise puzzle—development and operations—into closer collaboration.

Early DevOps deployments focused on iterative, agile adoption. If initial efforts did not yield results, companies were willing to try other approaches. Now, most customers ask the same question: "Just tell us the right way to do it," Randall said.

At XebiaLabs, Randall handles post-sales matters and making DevOps actually work in practice. Customers show a keen desire for templates and tools, but pay little attention to the cultural changes required.

He said people are so "eager" to learn how to actually practice DevOps that they skip steps.

Instead of trying and iterating, customers directly ask for answers, trying to avoid mistakes. But following a preset roadmap does little to address deep cultural issues.

The problem is that there is no silver bullet, Jez Humble, co-founder and CTO of DevOps Research and Assessment (DORA), said in an email to CIO Dive. "You can't just buy tools or implement a methodology; you have to put in the hard work to improve processes, develop capabilities, and figure out what works for your organization."

The vendor "salvation"

Vendors have taken up the DevOps banner, offering various solutions to ensure that simplified paths for development practices are easy to adopt.

A vast vendor ecosystem has formed around DevOps, covering every aspect of the development technology stack, including:

• Leading cloud service providers, such as Amazon Web Services, Microsoft, and Google Cloud, have woven DevOps capabilities into their services.
• Collaboration platforms from providers like Atlassian and Slack, used to streamline development operations and real-time communication.
• Other vendors focus on continuous integration/continuous delivery (CI/CD) and DevOps automation aspects, such as Puppet and XebiaLabs.
• Analytics-driven tools from vendors like Splunk and Sumo Logic, used to monitor IT performance.

However, the DevOps market underestimates the essence of this movement. The authenticity of some repackaged tools also raises doubts about their effectiveness.

"Many people put new labels on existing software development tools, often existing tools that were called 'agile' five years ago, and they just add DevOps to the title," Kersten said.

Take Azure DevOps, for example, which last week renamed Microsoft's Visual Studio Team Services product to fit a more developer-centric era.

When the inevitable vendor wave hit, "we saw many people who were not interested in the commercial side of DevOps start to retreat with disgust," Kersten said.

When a movement goes mainstream, it becomes difficult to preserve its underlying philosophy. By the time the concept reaches the executive office, its inherent meaning has often been diluted. Just as vendors can distort the meaning of DevOps, companies trying to adopt it can do the same.

As the term gets hyped, its meaning always risks being lost, Jeff Olson, vice president and chief data officer at the College Board, told CIO Dive. This phenomenon is visible when organizations create DevOps departments or rename operations departments to "DevOps."

If you are creating a DevOps department, you may not be practicing DevOps, Olson said. "It is entirely possible to embrace the appearance of something without embracing its essence."

The essence of DevOps is that the team that develops the code also operates it. Any practice that separates the people who write code from those who operate it creates a "moral hazard" for the code writers, because "they do not feel the pain of any problems they might introduce," Olson said.

Like many other organizations, the College Board, which administers Advanced Placement exams and the SAT, has committed to migrating its monolithic applications to the cloud and rearchitecting software in simpler ways.

A key principle of that migration was using DevOps to bind teams to both the development and operation of applications.

The College Board assigned early "beachhead" teams to adopt its core principles, including DevOps. Each success drove further adoption and helped guide a broad transformation in how technology works.

Top-down change

Corporate focus on digital transformation has fueled the DevOps fire. The willingness to change usually comes from leadership, not from ordinary employees who are dissatisfied with technical inefficiency.

This top-down perspective gives executives a slightly more optimistic view of DevOps implementation; executives do not always see the insurmountable cross-departmental divisions in development.

The C-suite relies on upward communication and often sees "filtered and beautified" adoption results, while being unaware of "bottlenecks and broken processes that hinder progress," according to the 2018 State of DevOps Report co-published by Puppet and Splunk.

Among companies that have undergone a moderate DevOps transformation—which accounts for 80% of Puppet's 3,000 respondents—one-third have a strong DevOps culture within a single team, while the report shows lower percentages with strong culture within one or multiple departments.

And among companies at high evolution levels, only 19% have applied DevOps to multiple departments.

DevOps adoption can also come from within the organization as a more grassroots movement. Often there are "isolated points of success, where individuals or teams have figured out how to adopt these practices and achieved truly remarkable results within their own sphere of influence and scope," Kersten said. "Everyone knows who those teams are."

Creating successful DevOps cases within an organization is not difficult. But every team thinks its challenges are unique, and seeing other teams' success is more likely to breed resentment than inspiration. Some technical challenges seem insurmountable.

That is because enterprise leaders are burdened with significant technical debt. With DevOps, you "can never start from scratch," Prashant Kelker, partner and EMEA digital strategy and solutions lead at ISG, told CIO Dive.

In greenfield discussions, companies and vendors can easily praise DevOps because users can build a brand-new development approach from scratch.

According to Kersten, the DevOps movement originally had two early adoption forces: one from people working at hyperscale internet companies—like Google, Twitter, and Facebook—where software teams and operations staff often had considerable development capabilities. The other stemmed from small startups that had the opportunity to build architecture from scratch.

The reality is that, after the first wave of early adoption and moving into more mainstream cases, most DevOps projects today are brownfield in nature.

"Everyone says culture eats DevOps strategy for breakfast. I think architecture eats strategy for breakfast," Kelker said. "You cannot erase 30 years of legacy."

This struggle intensifies the vendor role in DevOps implementation. "DevOps increasingly sounds like a responsibility," and "increasingly less about process, less about culture," Kelker said.

However, the force driving adoption comes from results.

Elite DevOps performers deploy multiple times per day and can deploy on demand, according to a recent DORA report.

The same performers take less than an hour from code commit to running in production. In contrast, low performers take one to six months. Medium performers take at least a week.

Putting aside complaints about how hard it is to change culture, companies must act to keep up with the technology curve. Legacy culture and technology stacks must evolve in tandem. Those that fail to modernize will face obsolescence.

The real concern about DevOps is that it will evolve into an exhausting movement like its predecessors. And if there is a lack of cohesion among units, DevOps adoption will stall and resources will be wasted.

The answer lies in getting stakeholders from all business sides involved. If developers are the only driving force behind DevOps, companies can easily end up with 99% tool-based efforts, Randall said, assuming the rest of the organization will figure out how to implement it on its own.