The Fallacy of Configurability
Configurability is an often highly desired architectural property in IT solutions. I argue that obsession with configurability leads to brittle, bug-prone, and convoluted designs which achieve the opposite of what this property suggests.
God forbid that you design, code (or buy?) a solution that is not configurable. And by configurable, I don’t mean that you can specify the hostname and credentials of its underlying database. I mean, highly configurable. HIGHLY CONFIGURABLE! (In case I wasn’t loud enough). Nothing is hard coded. Everything can be changed!
Isn’t this a brilliant idea? I can configure my CRM to be my ERP, or maybe I can configure Adobe Photoshop to become Apple GarageBand? How come no one has ever thought about making all applications configurable? No; this isn’t sarcasm nor cynicism. Your gut can tell you that graphics and music are two fundamentally different domains, and that it would be ridiculous to take the configurability property to such an extreme. But how do you draw the line?
See, configurability is not even necessarily a synonym of flexibility. Let’s first take a look at how this property means different things to different people.
Configurable = No Need For Recompilation
“You don’t have to touch the code to change the application!” shouts Jimmy the salesman. But I ask Jimmy: “What’s wrong with touching the code?". Jimmy looks down at me and replies: “You don’t need to recompile the application to make it behave the way you want!".
In this case, Jimmy’s case is that recompilation is something to be avoided like the plague; but recompilation is simply a process applicable to specific languages like C++ or Java. The issue of recompilation as a “burdensome” process has already been solved, at least in three different ways, without the need for this configurability snakeoil.
- By embedding a scripting engine (Lua, Groovy, etc.)
- By unburdening the recompilation process (and deployment!) using a CI/CD pipeline, so that it can be done hundreds of times a day by simply committing the code change, just like Amazon, Netflix, and the likes do.
Configurable = No Need For Developers
Jimmy clarifies that his company’s application is actually written in Ruby (an interpreted language) and what he meant is that no developers are required to change the application. So I ask, “Who do you need then?", to which he smiles and says: “Just someone to configure simple business rules!".
Oh, I get it, it is business rules, it is not “code”. I then ask Jimmy, “Can the business people submit their business rules in a Word document?". Jimmy chuckles and explains: “Business rules is a simple language in which you only express the business logic without touching the application”.
“So business rules are like code then?", I ask
Jimmy becomes defensive: “No! It is not code because it is just rules rather than code. There’s no need for developers! Isn’t that clear?”
Just three questions, Jimmy:
- “Do the business rules have a specific syntax, which if not respected, would result in the application’s malfunction?”
- “Could the business rules, while syntactically correct, result in logical issues, leading to the application’s malfunction?”
- “Could you change the rules straight in production, bypassing all QA processes associated with traditional code-wise development?”
Jimmy is speechless, and after meditating for a handful of seconds, he insists again, “The point is that you don’t need developers”.
Configurable = No Need for IT People
Jimmy is not a bad person. At this point we go for a coffee. He grabs a frappuccino. I grab an oat milk latte. Jimmy confesses that he touted “business rules” just to impress me but that in reality, most customers use a web admin screen in which they can define the application’s behaviour (and rules) using dropdown menus.
I ask Jimmy, “How do other customers test that a business flow defined with his application is defect free?”
Jimmy’s eyes light up: “I’m glad you asked. Our most recent customer, a large insurer, was quite happy with tools such as SoapUI and Selenium”.
Thank God for no IT people.
Configurable = Your Own Business Entities and Data
Jimmy has admitted that some IT involvement is required given that it is an IT solution after all. So he switches the conversation to the topic of data. He argues that I can bring any business entities and data that I want into the application: “It is completely configurable. Any entity, any data, any attribute, you can define it and import it!".
I have a demo version of the application. I log onto its SQL database, and I find a table structure as follows:
1ENTITIES 2-------- 3Entity_Id : Int (PK) 4Name : String 5 6ATTRIBUTES 7---------- 8Entity_Id : ENTITIES.Entity_Id (FK) 9Attribute_Name : String 10Attribute_Value : String
I explain to Jimmy that while the application can store arbitrary sets of data, complex search queries would incur a full table scan (they would be slow), and that I would not feel comfortable using his application as a master data source or system of record.
Jimmy’s eyes lights up again; he takes my objection like something he has solved before:
“No need to worry, a challenger Telecoms customer of ours had plenty of success by combining our application with ElasticSearch”.
ElasticSearch is an external indexing solution. Thank God for simplified IT solutions.
Configurable = Unlimited Flexibility
I don’t want to give Jimmy a hard time anymore. What we secretly (or explicitly) want from an application (as buyers) is for it to be as malleable as possible. We do have some vague notion as to what the boundaries for such a desired flexibility should be but, when the notion of unlimited flexibility is taken to an extreme, we end up with a general purpose database behind some authentication wall. Solutions such as Django or Ruby on Rails are exactly the crystallization of this vision.
I have a litmus test to determine whether the “configurability” property of an application stops being beneficial, and starts becoming a liability:
“Business-wise configurability should not be taken to an extreme where misconfiguration could compromise the application’s integrity, availability, or impact the customer’s experience.”
A telltale sign of moronic configurability is the presence of unit tests or functional tests to verify specific journeys or use cases defined using configuration (I’m abstracting away from whether this is achieved through business rules, a visual interface, and so on). Why is this such a significant anti-pattern? Isn’t QA always a good thing? In theory yes, but we need to look into this from a first principles perspective.
Computers understand bit patterns. Whether such bit patterns are generated using an assembler, C++, or a Java application that has loaded business rules is immaterial. If a business person, through so-called “configuration”, can alter said bit patterns, to the point that an application’s behaviour cannot longer be trusted, then the business person has effectively become a developer. At this point, someone like Jimmy the salesman could argue, “But business rules are much easier than Java!".
So if the point of giving a “business rules” (or other configurability gimmick such as visual BPMN) environment to the business people is that they don’t need to learn Java, but then Java developers (or IT folk) are required to verify said business rules as though they were “proper” code, then we have multiple issues:
- Lead-time: The initial USP of “no code, just configuration!” breaks down in the sense that it doesn’t help optimise lead time. We still have IT experts right in the middle of our critical path
- Automation (connected to lead-time): Modern code quality is achieved through a number of software engineering approaches to save time (using annotations to specify constraints, applying enumerated types, etc.). The idea that every line of code necessitates a unit test is obsolete.
- Expression power and tooling: Most configuration-based environments operate within the confines of a vendor-provided tool where advanced syntactical features and a rich IDE experience is lacking.
- Quality (connected to Tooling): Without linters, static code analysers, and a battery of quality tooling that is available for full-fledged programming languages, configuration-grade “code” is likely to be of low quality and high convolution.
- And last but not least, business configuration that cannot be trusted means that the abstraction has failed to accomplish its goal!
|Bad Configurability||Good Configurability|
|It may crash the application||It only changes pure business behaviour|
|Changes cannot be trusted and require QA||Changes can be made live by the business community|
|It is a way to compensate for the lack of DevOps||It is to separate concerns (core application vs customisation)|
|It extends development effort to the business community||It provides a safe, can’t shoot-in-the-foot business experience|
|Expressive power is driven by the configurability tooling paradigm||Expressive power represents the bounds of flexibility available within the chosen business domain|