Computer Economics finds enterprise DevOps is more aspirational than reality

Kurt Marko Profile picture for user kmarko August 5, 2018
Computer Economics shatters the myth that DevOps is mainstream at large enterprise.

enterprise DevOps
Enterprise DevOps

If you pay attention to the media, you'd readily think that DevOps is ubiquitous. But like all new ideas and technologies in IT, DevOps suffers from a form of conceptual schizophrenia characterized by a chasmic disconnect between the vendor hype and corresponding media buzz versus lukewarm IT interest and enterprise adoption.

It seems like the larger and more established the enterprise, the greater the disparity between online excitement and on-premise implementations.

Whether talking about DevOps in practice or the software used to automate its processes, one can easily get the impression from reading press releases, news stories and vendor presentations that every digitally transformed, cloud-savvy, container-loving company worth its salt is fully on board the DevOps train. New research from Computer Economics, shows that nothing could be further from the truth.

Enterprise DevOps still in its infancy

The report titled DevOps Adoption and Best Practices looks at DevOps rates of adoption and maturity of implementation in enterprises across industries. The report summarizes the findings across 132 IT organizations in North America with at least $50 million in revenue. It finds that although about a third of organizations dabble in DevOps, almost none do so formally and consistently across the organization or show any semblance of mastering of DevOps practices. While smaller, less bureaucratic and hence more nimble organizations are somewhat more likely to tackle DevOps, the report finds adoption rates low across the board. (See image at top of this story.)

Before DevOps evangelists cry foul about cherry-picked data from a small sample of IT dinosaurs, it's important to emphasize, as the report does, that most of the survey respondents are from traditional corporate IT organizations, not application developers or entrepreneurs. That is, these organizations likely spend more time in SharePoint than GitHub. As Frank Scavo, CEO Computer Economics told me in an email conversation,

Most corporate IT organizations are miles behind in software development best practices. We think it's because most of them are running packaged software or cloud applications and not doing much in-house development.

Reliance on third-party applications can create complacency on the part of organizations that don't see software development as a core competence, which further leads to ignorance about the latest development methodologies and tools like DevOps. Writes Scavo,

There is so much written about DevOps these days, but not much about the corporate IT angle. There is really a bifurcation in DevOps adoption. It is a way of life among companies that live and die by software. But there is a lack of awareness among most traditional IT departments. They may have heard about it, but they don't see a need themselves.

The result, as the report illustrates, is that in most enterprise organizations where DevOps is used, it's typically in an ad hoc way, without formal and consistent processes, standards and tools.

The survey finds pockets of DevOps adoption, notably in professional services organizations and retailers. The latter are likely responding to Amazon's outsized influence with the realization that software, whether for ordering, logistics or marketing can create competitive differentiation. Regardless of the industry, Scavo believes that any organization developing custom applications should follow their lead,

There are a few that are DevOps leaders, like Target, Walmart, Nordstroms. But those are the exceptions that make the rule.  In any event, where they [IT organizations] are maintaining custom code, they should be practicing agile and deploying using DevOps. This is especially true if those systems are customer-facing or provide a competitive advantage.

From the 'what' to the 'why'

Anemic levels of DevOps adoption by traditional, established enterprises is partly, sometimes entirely, due to ignorance and indifference, but the causes go deeper.

DevOps is like dieting: it requires changes in values, attitudes, processes and habits. Such changes are hard and must be practiced, not bought. They require education and discipline, not a purchase order. DevOps wannabes that think that it's only just a matter of installing some open source automation tools and container software are like dieters hoping that buying a gym membership and diet shakes in January means they'll lose weight by July. It doesn't work that way.

Significant organizational improvements result from things you do, and DevOps requires cultural and organizational change. The products and technology come later, after the hard work of modifying behaviors, attitudes and processes. DevOps aspirants can get a clue about the path ahead of them from Erasmus, who  described the painful process of habitual change as anything but quick and easy,

A nail is driven out by another nail; habit is overcome by habit.

My take

I am thankful that Scavo sheds light on the contrast between DevOps perceptions and enterprise reality. However I do quibble with the way the report conflates DevOps and the related practices of agile development and continuous integration and delivery (CI/CD). For example (emphasis added)

DevOps is a natural extension of agile development into the deployment and operational phases of the system life cycle. Just as agile development builds software in small, iterative build cycles, DevOps applies enhancements as small incremental changes that are committed daily, hourly, or even moment by moment into the production system.

Under DevOps, developers are empowered to build, test, and commit small changes directly into the production environment. New releases are rolled out incrementally as a series of smaller changes that can be implemented much more quickly than under the traditional model.

Let's look at a reasonable definition of DevOps,

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

The emphasis is on reducing the latency between software development and runtime implementation without compromising quality. I contend that there are many instances where these can be accomplished without adopting CI/CD processes, for example using PaaS and/or the infrastructure automation concept known as infrastructure as code (IaC).

While I agree that DevOps is often a natural evolution of agile development and that CI/CD are the methodologies often used in an automated DevOps processes, I don’t think the concepts are inextricably linked, even when looking at the software development side of DevOps. As I wrote earlier this year, many DevOps practitioners make PaaS an integral part of their transformative strategy, however PaaS stacks like Cloud Foundry, Azure PaaS or Google Cloud App Engine are often implemented without a simultaneous change to CI/CD.

A PaaS meets the core DevOps criteria for reducing the development-to-deployment timeline, while offering many other benefits like software quality, security and repeatability while reducing the administrative overhead of software maintenance. DevOps goals are likewise achieved when using IaC automation that can dramatically speed up the deployment, scaling and updating of virtual application resources (VM instances, storage, even databases). These benefits accrue whether one has the type of application that is continually changing or not. Granted, many organization will evolve to continuous and incremental release cycles, but I contend that CI/CD is not a requirement nor an intrinsic aspect of DevOps.

My critique shouldn't overshadow the report's useful information and spot-on recommendations.

I particularly agree with Scavo's conclusion that DevOps shouldn't just be confined to cloud-native applications, but can be useful for legacy systems. Indeed, it is just these type of relatively static, on-premise applications that can benefit from a more nimble development and release cycle without taking on the risks of a CI/CD process.

If more organizations understood that DevOps isn't solely the domain of startups and cloud natives they would find the resulting improvements to deployment processes and interdepartmental communications are broadly applicable to any application and business situation.

Endnote: for more information on DevOps and related technologies like CI/CD, this search will take you to many of my articles on the topic.

A grey colored placeholder image