Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

When creating a business model in Blueriq, one must always aim to model decisions that can be easily understood by the business. To verify whether the level of complexity of th decisions is acceptable, a DRG can be generated at any time in the design process. This DRG is then used to visualize the decision and its sub decisions and by that give insight to a business engineer and for instance an analyst on how this particular decision is made.

A Some best practice practices when designing decisions is given below. It is not to be used as "the one and only way" but should be treated as a possible means to create understandable decisions.

1Main

Ask yourself the question what the main decision is. If you think of more than one answer, split these decisions if possible.
For instance, if you main decision is "the amount and duration of a child care benefit" or "the fee for a small building permit" you are are actually modeling two decisions. Design them seperately separately and reuse attributes that accomodate accommodate both decisions.

2TypeNote that a decision is not bound to be a Boolean. In general, there are three types of decisions:
  • Boolean decision (you are eligible for benefit X),
  • Classification (you will receive category 'medium' for benefit X) or
  • Calculation result (you will receive € 100,- per year for benefit X).
3SubFor each identified decision, determine if the decision is preferrably preferably built up in meaningful sub decisions. These sub decisions could be reusable decisions - in fact reusable decisions will most likely be sub decisions - but not every sub decision has to be a reusable decision.
Think of a complex calcutaion calculation where intermediate results are never reused but are created nevertheless, for the sake of understandability.
4CircularityAvoid circularity. When decision A depends on the outcome of decision B and decision B needs the result of decision A as input, you're in trouble! When desiging designing decisions top-down circular references can easliy easily be avoided.
5 ...

Design time Decision Requirements Graph

...

When expanded to the next level,it shows that the decision consists of three separate decisions.

At level 4 the decision looks like thiswe find that there are in fact twelve decisions in play:

It is possible to completely expand all decisions, knowledge models, input data and sources in one single graph, but this will most likely result in a diagram that is not usable for any type of audience. Therefore it is advised to expand sub decisions in separate DRG's. Shown below is such a DRG for the sub decision Risk score bonus.

...

Runtime Decision Requirements Graph

Although OMG´s standard DMN does not contain any specifications for it, Blueriq also uses a runtime decision requirements graph. This graph resembles the design time decision requirements graph, but differs mainly with regards to the fact that is shows all given answers and derived values. See the example below, also about the risk score example.

<plaatje>text

Constructs of the Decision Requirements Graph

text

Decisions

text

Business knowledge models

text

Input data

text

Knowledge source

Decision requirements graphs consist of four different constructs, each using its own shape.
For more info on DRG's see Decision Requirements Graph (DRG)

 

 text

Constructs of Decision Modeling in Blueriq

...