This chapter discusses typical design considerations when designing and implementing decisions using Blueriq.

Setting a boolean value?

When modeling a decision that is limited to a small number of values (for instance Boolean), there are multiple possibilities to achieve this:

1. Using a constant value and a business rule
2. Using two business rules
3. Using a decision table

Using a constant value and a business rule

Using two business rules

Using a decision table

What to use?

The choice of method is often based on the preference of the business engineer. General recommendations are listed below:

1. Whenever the result depends on multiple input values, it is best to use a decision table.
2. Whenever the result is a calculation, it is best to use a form with a business rule.
3. It is recommended to formally decide which method to use and capture that in an architecture document. A consistent use of a style throughout a project will help the maintainability of a project. There are many roads that lead to Rome, but within one project it is best if all business engineers follow the same road.

Size of a decision table

With multiple inputs or value categories decision table can get very large in size. Decision tables that are too large in size are not easy to oversee and by that to understand. In general you can state that a table should have a maximum of 12 columns. When the number of columns exceeds this number it is advised to split up the table. 

Splitting up a decision table can be done by using sub decisions and sub decisions can be created by adding an extra attribute.

Order in a decision table

When designing a decision table, it is often worth considering in which order the different conditions (rows) should be declared. To illustrate this, see the two semantically equivalent decision tables below.

One might argue that - because of the fact that the decision tables are semantically equivalent - it does not matter if you model the first or second table. However, there are two differences that are worth addressing and should be taken into account when designing decision tables:

1. If the party that uses this decision views its customers mostly by their gender, the first table is preferred. If they view their customers in age categories, the second is preferred.
2. In general the legibility of a decision table improves when the conditions are declared with the number of condition alternatives increasing from top to bottom. So even if the first argument of gender and age categories does not apply, there is a theoretical preference for the first table. This is illustrated below.

Conditions versus attribute values in a decision table

If possible, it is strongly advised to model attributes with their values in stead of conditions about these values. See the two decision tables below.

The bottom decision table uses a condition in stead of attribute values, this is not advised and only to be used when necessary.

Focus on result in stead of completeness

A safe and fairly easy way to approach the design of a decision table is by creating a result alternative for each possible combination. However, this will result in a combinatoric explosion of result alternatives and very large decision tables. When all result alternatives differ, this is the correct approach. Most likely, they will not. In that case, the focus should be on the result alternatives. To illustrate this, see the small example below.

Because of the fact that there are two genders and three age categories, it might not be a big surprise that there are six result alternatives. However, a closer look at these alternatives - with the focus on 10% - reveals two possible design alternatives:

1. All males under 21 receive a 10% discount.

2. All applicants under 18 receive a 10% discount, no matter the gender.

Extreme focus on results

In the example above, there are in fact four discounts: 10%, 20%, 25% and 30%. It is a common mistake that this means that the decision table should have exactly four result alternatives. See the decision table below, which is absolutely not advised:

Decision table or data rule?

text

Attributes and (reusable) expressions

text

Decisions in a process?

text