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

Setting a binary value

When modeling a decision that is limited to two 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

Constant value combined with business rule

Two business rules

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, company or product 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 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 the attribute values. Because of legibility it is advised to only use this strategy 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 of attribute values. However, this will result in a combinatoric explosion of condition 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 in stead of the combination of attribute values. 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. If party, company or product that uses this decision actually talks about "males under 21", this is a good approach.

2. All applicants under 18 receive a 10% discount, no matter the gender. If party, company or product that uses this decision actually talks about "anyone under 18", this is a good approach.

Extreme focus on results

It is not a best practice that each decision tables must always contain exactly one result attribute for each possible value. It could be a good starting point in design, but it should not be the ultimate goal to establish one result attribute for each possible value.To illustrate this, the example above has been redesigned to match the before named strategy. In the example above, there are only four discounts: 10%, 20%, 25% and 30%. The decision table holding a result attribute for each value will look like the one below, which in this particular case is not as legible as the two (green) decision tables above:

Expressions in the left column of a decision table

It is possible to use an expression in the left column of a decision table. For instance a count on instances that results in a number that is evaluated.

This possibility in Blueriq offers the business engineer extensive options to create a model. The problem is that especially large expressions are not very legible for easily readable by business users. The Blueriq platform offers two options for not using a large expression.

Option 1: Using a support attribute

Option 2: Using a reusable expression

Decision table or data rule?

text

Attributes and (reusable) expressions

text

Decisions in a process?

text