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.
When it comes to technical constraints, the reality is that the way the software for product variants is derived should change and the primary transition called for is the shift from customization to configuration. Many companies employ a manual customization process to adjust the generic product software to the specific needs of product variants. When the software was released infrequently, eg once per year, this is an acceptable way of working. However, when employing DevOps, the manual overhead of working in this way goes through the roof as we have to manually customize the latest version of the software every few weeks.
The obvious solution is to adopt a configuration where the generic software contains the superset of all functionality that the space of product variants entails and where this software can be automatically configured to select the specific variants and features that should be part of a specific variant. Although some companies build bespoke, in-house solutions, there are those, such as Pure Systems, that offer tooling that simplifies this process significantly.
One important aspect to realize is that tools such as those by Pure Systems shouldn’t just be used for configuring software, but also for all other assets that need to be configured for each product variant, such as product documentation, requirement specifications, safety documentation, etc. The structured and systematic use of these tools allows for delivering product variants at much lower cost than manual approaches. The consequence may well be that the company decides to offer many more variants than before because the business benefits for each variant outweigh the now significantly reduced cost.
Concluding, the adoption of DevOps often leads to a tendency to reduce product variants. The number of variants should be driven by business considerations and not by technical constraints. Instead, the company should transition from using customization to using configuration and adopting automated tools to manage the creation of all assets related to each variant. This allows for a significant reduction of product variant creation cost and supports DevOps exceedingly well. So, don’t kill product variants indiscriminately but maintain each variant that adds business value!
To get more insights earlier, sign up for my newsletter atjan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
