The corruption of DevOps

Source- ciodive.com

Enterprise technology has a long history of asking for the easy answer. Process people and technology people commingle, with underlying divisions creating tangible opposition.

Business stakeholders ask for more than technologists think reasonable, and dusty layers of backend technology leaves IT always asking for more resources, more people, funding and tools.

Compounding the issue is the disconnect between those that develop and operate business technology. Once all the business requirements are met, developers unleash software on operations, leaving deployment and execution to someone else.

Chaos ensues.

But a new way of doing work has become popular, highlighting the need for cultural change in technology to match transformation efforts. Rather than having disjointed technology deployments, development and operations could align in DevOps. Through the methodology, stakeholders are tied to a single project and those creating software are also responsible for its deployment.

DevOps rode a real wave about four to five years ago, around the time “The Phoenix Project” came out, according to Nigel Kersten, VP of ecosystem engineering at Puppet, in an interview with CIO Dive.

Industry moved beyond early adopters and into the mainstream, which is where a struggle adopting the DevOps culture emerged.

“The thing I’m seeing over and over again is [companies are] adopting the tooling but not the process changes or the cultural changes” of DevOps, Kersten said.

A hesitancy to invoke real organizational change to implement DevOps has created an underlying reliance on the vendor landscape. Though DevOps originated as a methodology grounded in grassroots adoption, scale became a roadblock. This created a craving for tools to ease and facilitate adoption, ignoring the integral people and process tenants along the way.

“DevOps has been bastardized now from what it started as,” said T.J. Randall, VP of customer success at XebiaLabs, in an interview with CIO Dive. The initial, “cool little concept” centered on how to get two stark sides of the enterprise puzzle — development and operations — to work closer together.

Early DevOps deployments focused on iterative, agile adoption. Companies were willing to try something else if early efforts did not work. Now, most customers ask for the same thing: “Just tell us what the right way to do this is,” Randall said.

At XebiaLabs, Randall is responsible for post-sales and getting DevOps to work in practice. Customers express eagerness for templates and tools, but pay less attention to the required cultural changes.

People are so “thirsty” to understand how to do DevOps for real, they’re skipping steps, he said.

Rather than experimenting and iterating, customers ask for answers in an attempt to avoid mistakes. But following a predetermined roadmap does little to solve underlying cultural hangups.

The problem is, there’s no silver bullet, said Jez Humble, co-founder and CTO of DevOps Research and Assessment LLC (DORA), in an email to CIO Dive. “You can’t just buy tools or implement methodologies; you have to do the hard work of process improvement and capability development and learn what will work for your organization.”

Vendors to the rescue

Suppliers have taken up the DevOps calling, offering solutions that ensure the streamlined approach to development practices is easily adopted.

There is a vast ecosystem of DevOps-oriented vendors, covering the breadth of the development stack, including:

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

The DevOps market, however, undervalues the movement. And the authenticity of some rebranded tools calls into question a product’s effectiveness.

“A lot of people rebadged existing software development tools and often existing tools that were called ‘Agile’ five years earlier and they just threw DevOps on the title,” said Kersten.

Take Azure DevOps, for example, which last week rebranded Microsoft’s Visual Studio Team Services offering for a more developer-centric era.

Once the inevitable vendor wave happened, “we saw a lot of people who weren’t interested in the commercial side of DevOps start to back away somewhat in disgust,” Kersten said.

As movements become mainstream, it is difficult to preserve the underlying philosophy. By the time concepts get into an executive’s office, inherent meaning often becomes watered down. Just as vendors can augment DevOps meaning, so too can companies looking to adopt it.

There’s always a risk terms will lose their meaning as they become hyped, said Jeff Olson, vice president and chief data officer at the College Board, in an interview with CIO Dive. That is seen when organizations create DevOps departments or rename operations departments “DevOps.”

If you are creating a DevOps department, you might not be practicing DevOps, Olson said. “It’s possible to embrace the trapping of something without embracing the essence of it.”

The essence of DevOps is teams developing code also operate it. Any separation of people who write the code from people who operate it creates a “moral hazard” for the people writing the code because “they don’t feel the pain associated with any problem that they may introduce,” Olson said.

Like many other organizations, The College Board, which runs the high school advanced placement exams and the SATs, has worked to migrate its monolithic applications to the cloud and rearchitect software in a simpler way.

A key tenant of that migration was employing DevOps to tie teams to both the development and operation of an application.

The College Board tasked early “beachhead” teams with adopting its core principles, which included DevOps. Each success helped propel further adoption and helped coax widespread change to how technology work is done.

Top down change

Enterprise attention toward digital transformation has helped stoke the DevOps flame. Appetite for change regularly comes from leadership rather than disgruntled employees who are unsatisfied with a lack of technology efficiency.

This top-down view allows executives to have a slightly rosier outlook of DevOps implementation; executives don’t always have visibility over cross-department divisions that are difficult to overcome in development.

The C-suite, reliant on upward communication, often sees “filtered and sanitized” results in terms of adoption and are not cognizant of the “bottlenecks and broken processes that are stalling progress,” according to the 2018 State of DevOps report from Puppet and Splunk.

Of companies that have undergone a medium DevOps transformation — which accounted for 80% of Puppet’s 3,000 respondents — one-third have a strong DevOps culture across a single team, with fewer reporting a strong culture across a single or multiple departments.

And only 19% of those with high evolution have DevOps applied across multiple departments.

DevOps adoption can also come from inside an organization as a more grassroots movement. What often emerges are “pockets of success where individuals or teams have worked out how to adopt these practices and within their own sphere of influence and domain, they’ve been able to achieve really great things,” Kersten said. “Everyone knows who those teams are.”

Creating successful DevOps case studies is not the issue within an organization. But every group sees their challenges as unique, and viewing another groups’ success is more likely to spark feelings of resentment than flashes of inspiration. Some technology challenges just seem too great to overcome.

That’s because enterprise leaders are facing a great technological burden. With DevOps, you’re “never ever starting from zero,” said Prashant Kelker, partner and lead digital strategy and solutions, EMEA at ISG, in an interview with CIO Dive.

It is easy for companies and vendors to praise DevOps in greenfield discussions, where users can start from scratch to build a new way of doing development.

According to Kersten, the initial birth of the DevOps movement had two-pronged early-adoption: One side of the movement came from people working at web scale companies — like Google, Twitter and Facebook — where software teams and operational staff tended to have reasonable development chops. The other stemmed from small startups who had a chance to build an architecture from the ground up.

The reality is most DevOps projects now, following the first wave of early-adoption and into more mainstream examples, is brownfield.

“Everybody says culture eats DevOps strategy for breakfast. I think architecture will eat strategy for breakfast,” said Kelker. “You simply can’t undo 30 years of legacy.”

The struggle has increased the vendor role in DevOps implementation. “DevOps sounds more and more like it’s a responsibility” and “less about process, less about culture,” said Kelker.

The pull toward adoption, however, comes from the results.

Elite DevOps performers have multiple deployments per day and can deploy on-demand, according to a recent report from DORA.

It takes those same performers less than an hour to go from code commit to running code in production. By comparison, low performers require between one and six months. Medium performers need at least a week.

Protests about how hard it is to change culture aside, companies have to do something to keep up with the technology curve. Legacy culture and technology stacks have to evolve in tandem. Those that fail to modernize face irrelevance.

The real fear with DevOps is it will morph into a tired movement as its predecessors have. And without cohesion across units, DevOps adoptions remain stagnant with resources wasted.

The answer is getting stakeholders across the business involved. If developers are the sole drivers of DevOps, it is easy for companies to end up with efforts 99% based on tools, said Randall, with the assumption that rest of the organization will figure out how to implement.