In every business model constants are used. Such constants have a distinct and often commonly recognized name, a justification in law or legislation and a single value that rarely changes. The constant will probably only change because of change in law or legislation.
Typical examples of constants are
- The age of adolescence
- The maximum amount of savings
- The percentage of tax due in scale 1
- The percentage of the lower value added tariff
- etc.
There are several ways to organize those constants in a business model.They will be discussed below.
Entity Constants
One way of organizing constant values is combining them in a singleton entity. Of course the attributes of this entity do not share any commonality, except for the fact that they are constants. Business engineers that uphold strict rules of elegant modeling might frown upon such an entity, whereas the more pragmatic business engineers favor one particular space in the business model where all constants are stored and managed.
 |
|---|
Scattered attributes, set by a decision table
Another way of organizing constant values is setting them in one single decision table, while the constants themselves are declared wherever the business engineer thinks they belong. This scenario can also be used when using a one entity to store all constants together. The default value of these constants is left out, but one (or perhaps even more) decision table sets the values.
 |
|---|
Reusable expressions
Perhaps the most intuitive way of organizing constant values is setting them in reusable expressions. The main reason many business engineers favor this option is that some constants do not belong to an entity. Reusable expressions - used in this manner - are "orphaned" single-valued-attributes; they have the most in common with actual constants.
 |
|---|
One might argue in favor of using any of the three scenarios discussed here. Other scenarios may be possible as well. There is one con that the three scenarios mentioned here have in common: It is not possible to add a justification for each constant. After all, default values do not have justifications, neither do reusable expressions. Decision tables can have a justification, but only for the complete set of derived attributes. If justification per constant is necessary, a decision table for each constant is the only option.
Back to main chapter Design considerations
Overview
Content Tools