Original article published here as part of the Vendavo Extensibility Series.

This is the first in a series of articles surrounding software customization and the perils of venturing down treacherous paths. It is a meaty subject for sure. Our objective is to focus on the software side of customization, essentially designing better products that enable these kinds of things without incurring the oppressive downsides of traditional approaches.

In an ideal world, there is no customization. Some of our readers may be in violent disagreement right now. And perhaps they should be. However, it raises an important question that requires closer examination — what exactly do we mean by customization?

The semantics are critical. Many enterprise software companies serve industries with large customers and complex business processes that require some degree of customization.

If you ask five people to define software customization, you will almost certainly receive five different answers. The underlying motives of customization are grounded in the reality that enterprises practice their business processes in different ways. Hence, the need for software to adapt is mission critical to success.

Adaptability is the operative word. If you purchase a piece of software, it needs to adapt to your environment in ways that are unique to you. Customizing software is one means of adaptability, but adaptability does not necessarily imply customization. There are other ways of solving the adaptability problem, such as configuration and extension.

The term customization deserves a concrete definition. Rather than explaining through the lens of a software practitioner, let’s use an analogy that resonates with virtually everyone — vehicles.

If you purchase a vehicle online, you have an opportunity to customize the final product. Even though we use the term customize in this context, what you’re actually doing is configuring the vehicle by making a finite set of decisions with a finite set of choices. These choices are very intentional on the part of the designers and considered well in advance. In contrast, the designers will not allow you to make arbitrary modifications of the internal workings, such as the engine, transmission, or computers. Doing so would introduce all sorts of quality control challenges and operational complexities.

Let’s continue with the vehicle analogy to explain another kind of customization. After purchasing the vehicle, you drop by the local bicycle shop to extend the utility of the vehicle by mounting a rack on the top rails. Even though a third-party produced the bicycle rack, by conforming to a rail specification published by the vehicle designers, it happens to fit nice and snug. This means you can shop among many third-party suppliers to find the rack that is right for you.

We briefly mentioned two forms of customization — configuration and extension. Let’s look at them more closely in the context of software.

Configuration → A finite set of choices that control the behavior of the software.

The software is fully aware of the choices and will modify its behavior based on the configuration. In principle, all configuration combinations can be tested and verified during development.

Examples:

• Choose small, medium, or large icons
• White labeling
• Approval workflows

Extension → A specific behavior of the software with an infinite set of choices.

The behavior at an abstract level is known to the software, but the implementation itself is unknown. The implementation is supplied by a party other than the software designers. Done properly, the software architecture imposes tight constraints that preserve the integrity of the core.

Examples:

• Domain-specific languages
• Bring your own AI model
• Exit points and service provider interfaces

In the next article, we’ll talk about another type of customization that happens more often than not, an insidious type that leads to all sorts of unfortunate tradeoffs.