As companies seek to adopt continuous practices, one of the claims I run into a lot is that customers don’t want DevOps. This argument is often used as a way to cut off the discussion as we obviously shouldn’t do what customers don’t want. Instead, we should keep things as they are as customers are happy and we shouldn’t rock the boat.
The first few times I heard this, I took it at face value as the person presenting the argument clearly had met some customer who had said exactly that. At some point, however, I started to get a bit suspicious. The pattern seemed to be that the individual claiming customers didn’t want DevOps seemed to have the most to gain by not changing things internally.
What I can’t figure out is why anyone would say no to getting a better and improved solution. Assuming we continuously prioritize building functionality that makes our offering better for our customers and users, why would they say no to getting access to this functionality? This was the question I was unable to resolve in my head.
It seems obvious to me that if we’re building functionality that’s valuable for customers and users and they still say that they don’t want it, something is going on that needs to be better understood. In my experience, there are three arguments why customers say no to upgrades and DevOps: quality concerns, deployment cost and compatibility issues.
First, although many companies claim that they have good quality in their offerings, the fact is that quality is a real concern in many contexts. If an upgrade or DevOps deployment has a reasonable chance of causing issues, many customers refuse to move to the next version as the risk is perceived to be higher than the value of new functionality.
Interestingly, DevOps requires a higher quality level than traditionally deployed software but implicitly also helps companies achieve that by exposing all quality issues continuously. Running into an issue once or twice a year may cause us to ignore it and use a workaround. Running into the same issue every two weeks or even more often will ensure that it gets prioritized and fixed.
Second, many R&D organizations tend to focus on the functionality inside the product and ignore all the surrounding issues such as difficulty of installation and deployment. If deploying a new version of the software is painful and effort-consuming, customers will ask to reduce the release frequency or simply ignore new versions as the cost of deploying them is higher than the perceived benefits of the update.
The obvious implication is that deployment should be seamless and not require any effort from the customer. In fact, if at all possible, deploying new software versions without any customer involvement, assuming the customer accepts this and there are no legal constraints, is of course preferable as it ensures that all customers always are on the latest version of the software. Achieving this state, however, may require some significant R&D effort to get the offering to the point architecturally and quality-wise that deployment can be performed this way.
Third, no system is an island and customers tend to build integrations between our offering and other systems to maximize automation, ensure consistency or provide seamless access. Any new software version that breaks the integration with other systems will automatically be rejected by customers as the cost of upgrading and fixing the integrations will almost certainly outweigh the provided benefits.
Addressing this concern requires architectural work where the offering exposes stable interfaces that don’t change, or rather change infrequently. That allows the deployment of new software versions without causing issues for customers. Crafting these interfaces tends to be challenging as it requires a careful balance between providing sufficiently powerful access for customers to build the integrations they need while limiting the exposure of functionality that’s likely to change frequently.
With all the challenges associated with adopting DevOps, many companies fail to acknowledge the benefits. I’ve met quite a few companies that live in a versioning hell where the number of versions out in the field at customers can be staggering. And each customer can contact the company with issues in their specific version that they want fixed while refusing to upgrade to any version that doesn’t have these concerns. Although this is less of an issue in industry than it was perhaps a decade ago, in the process of adopting DevOps, it’s quite easy to end up again in the same place as the number of released versions goes up quite significantly.
Although arguments that customers don’t want DevOps can be quite convincing, it’s important to understand the underlying concerns. Nobody says no to an improved offering unless there are quality concerns, upgrade cost issues or compatibility problems. This means that adopting DevOps requires increasing the quality of the software, simplifying deployment and carefully crafting stable interfaces that customers can use for their integrations. Failing to do so can easily result in a versioning hell where R&D spends all its resources on maintaining a plethora of versions deployed at customers in the field. And that kills any ability to build new differentiating functionality. To end with a quote from Gene Kim: “One of the inherent challenges of initiatives such as DevOps transformations is that they’re inevitably in conflict with ongoing business operations.” In that lies much of the root of resistance against DevOps.
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
