You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »

Within organizations decisions are made frequently and have an important impact on reaching the organization's goals. Decisions are made using logic, even if that is not always obvious. There are many organizations that have automated their operational decision making using software. Blueriq is a platform that is often used to make decisions.

Therefore, Blueriq adopted OMG's standard of Decision Model and Notation (DMN) with regards to the Decision Requirements Graph (DRG). However, some constructs in Blueriq's DRG differ from the standard. Furthermore, Blueriq uses a DRG in designtime and a slightly different DRG in runtime.

Best practices in designing decisions

When creating a business model in Blueriq, one must always aim to model decisions that can be easliy 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 best practice 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.

1 Main

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" you are modeling two decisions. Design them seperately and reuse attributes that accomodate both decisions.

2 TypeNote that a decision can be
  • a Boolean decision (you are eligible for benefit X),
  • a classification (you will receive category 'medium' for benefit X) or
  • a calculation result (you will receive € 100,- per year for benefit X).
3 SubFor each identified decision, determine if the decision is preferrably 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 where intermediate results are never reused but are created nevertheless, for the sake of understandability.
4 CircularityAvoid 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 decisions top-down circular references can easliy be avoided.
5  ...

Designtime Decision Requirements Graph

text

Runtime Decision Requirements Graph

text

Constructs of the Decision Requirements Graph

text

Decisions

text

Business knowledge models

text

Input data

text

Knowledge source

text

Constructs of Decision Modeling in Blueriq

text

Attributes

text

Sources

text

Business rules

text

Decision tables

text

Default expressions

text

Data rules

text

  • No labels