Variability and DevOps

Many companies that I work with are in the process of adopting continuous deployment of software – or DevOps. As part of that process, the notion of product variability comes up frequently because there often are multiple product variants out in the field. The software for each variant used to be created in a mostly manual process. As a consequence, most companies do not see a reasonable way to adopt DevOps with that many product variants requiring frequent software updates. This often results in significant pressure within the organization to start reducing the number of variants drastically in order to alleviate the DevOps challenge.

In my experience, reducing the number of product variants indiscriminately isn’t the right way forward. The number of variants shouldn’t be driven by technical limitations or constraints, but rather by business considerations. We should offer those variants for which the variation can provably be monetized. If there are business reasons to maintain a variant as the value that it represents outweighs the cost of maintaining it, obviously this variant should not be removed. The reality in many companies, of course, is that the product variant space has often evolved over a long period of time and it may well be the case that many variants are outdated and should be removed. However, once again, this should be driven by business considerations and not by technical constraints.