Resolving issues with configuration keys that are conflicting or mutually exclusive

What's the problem?

You use configuration keys to determine which features to switch on or off in the application. The settings of the configuration keys affect all company accounts in the application.

If configuration keys are used in a way where configuration keys are also used to control how a feature works, problems will arise if two or more configuration keys try to make the same feature work in different ways.

The problem is a fact in environments where several or all country/region configuration keys are switched on. Environments like that could be test environments or it could be a customer installation running a multi country/region setup with company accounts placed in different countries or regions, e.g. company DAT is a German company and company ITA is an Italian company.
How do you in such a setup control if a certain feature should run in the German way or the Italian way only by looking a configuration keys? You can't!

A line in a requirement or design specification, like “If configuration key X is switched on the feature should do the calculation like so and so, if configuration key Y is switched on the calculation should be like so and so, otherwise the calculation should be like so and so”, should alarm you.

What's the solution?

There must be a clear distinction between switching a feature on or off and controlling how the feature works. Configuration keys are only on/off switches.

This is an example of the distinction that must be made:
Cash discount is a feature that can be switched on or off.
How cash discount is calculated (e.g. before or after tax) must be controlled by parameters.
Let's try and elaborate on this example:
We  have an application with company account situated in two countries or regions: X and Y.
Let's assume that calculating cash discount before tax is only legal in country/region X and the system does the calculation in this way if the country/region configuration keys for X are switched on.

Now if I switch on the country/region keys for both countries, the system will calculate cash discounts in a way that's illegal in country or region Y. 
Therefore I must now make the distinction between having the feature available and doing the calculation in different ways.

I do that by adding a parameter to the financial parameters of the system: "Calculate cash discount before tax?". This parameter I connect to the country/region configuration key for X, so it's only applicable and visible if this configuration key is turned on.
In company X I can now check this parameter and calculate cash discount before tax. In company Y I leave the parameter unchecked and the system calculates cash discount after tax.

The approach gives a little more work in regards to setting up the parameters, but it effectively allows you to have the same feature perform in different ways.

Why am I rambling about this?

Well, I have seen several examples where configuration keys were used to control how a feature works, I've seen the conflicts and I've seen the ugly errors you get as a result ... and I've had to clean up the mess on several occasions.

This posting is provided "AS IS" with no warranties, and confers no rights.

Skip to main content