Stop Customizing Your System! Configure It Instead!

Image credit: pixabay

Although mass-market companies have figured this out long ago, companies offering their software-intensive systems to a smaller group of powerful customers are often under significant pressure to customize their systems for individual customers.

There are at least three reasons why customizing your system for each individual customer used to be a good idea. First, when closing the initial deal with the customer, the sales process typically requires a back and forth in terms of concessions and pricing. Offering customization of the software can be an effective mechanism to maintain pricing levels while giving the customer something that makes her or him feel special and unique.

Second, the customization itself often needs to be conducted by the company selling the system and is, of course, not free. Especially in situations where the company is organized in a central organization and market companies, providing the customization is a very effective approach for market companies to generate revenue.

Third, whenever there is a need to update the software in the system, the market company will need to repeat the customization for the new version of the software. In that sense, customization is a gift that keeps on giving from a revenue perspective.

When stepping back, it is obvious that from a narrow, short-term perspective, customization may make a lot of sense, but from a broader, long-term perspective it is a bad idea. Although this has been true in almost all cases over the years, more recently, the adoption of continuous deployment makes it even more important to stop customizing. Again at least three reasons why we should stop customizing.

First, it doesn’t make sense from a financial perspective. In most companies, customization monetized through a markup on the salary cost of the engineers doing the work. Even if you manage to have a 100% margin, the revenue driven by these engineers pales in comparison to product R&D. In a company with an R&D budget that is 5% of the company’s revenue, it means that every € spent in R&D has to result in 20€ of revenue for the company. Even if it may look good on paper to sell the engineer hours for a factor 2 of the cost, it is much less valuable than investments in product R&D.

Second, customization severely complicates continuous deployment as it requires the customization to be repeated for every release of the software. In most cases, this is prohibitively expensive for your company and your customers, resulting in a situation where customer will do everything they can to avoid upgrading their software. This, in turn, results in you being required to maintain many releases of the software, sometimes ranging over a decade or more.

Third, as I described in last week’s blog post, R&D needs to shift from focusing on efficiency to focusing on effectiveness. That requires continuous deployment and a constant flow of data from the systems in the field to determine that the system as well as features are generating the value for customers. Realizing this fast feedback loop is impossible when every customer has a unique customization of the system.

Instead of customization, we need to adopt configuration. This requires us to architect the system in such a way that features that are used by some customers, though not all, are configuration items in the system. Customer unique functionality should be built at the other end of a stable product interface, so that the product can evolve continuously while the customer unique functionality can stay the same and work against the stable interface.

Concluding, if you customize your products and systems for each customer, it is time to stop this practice. Instead, re-architect your systems to provide the main points of variation as configuration settings and introduce a stable interface for customer unique functionality (the true customer-specific customization). Failing to do so keeps you stuck in the old ways of working, which simply is not competitive in the long run. You need continuous deployment and a quantitative data channel back from your systems in the field in order to maximize the effectiveness of your R&D.