Page History
| Table of Contents |
|---|
Within organizations decisions are made frequently and have an important impact on reaching the organization's organizations 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.automate (parts of) the decision making process.
This chapter discusses how decision management is supported in Blueriq by means of Decision Requirements Graphs.
| Table of Contents |
|---|
Decision Requirements Graph (
...
DRD)
Blueriq adopted the Object Modeling Group (OMG) standard of Decision Model and Notation (DMN) with regards to the Decision Requirements Graph Diagram (DRGDRD).
However, some constructs in Blueriq's DRG differ from the standardThis means that Blueriq generates a DRD at design time in Encore, based on the decisions and sub decisions that have been modeled. Furthermore, Blueriq uses offers a DRG in DRD at design time and a slightly different DRG in at runtime.
For more info on DRG's see Decision Requirements Graph (DRG).DRGs see Decision Requirements Diagram or DRD in Encore
Design time Decision Requirements
...
Diagram
When designing a decision, make use of the Decision Requirements Graph Diagram (DRGDRD), depicted by a scale icon:
.
(for more info on and where to open DRG's see Decision Requirements Graph (DRG))DRGs see Decision Requirements Diagram or DRD in Encore)
Let us say we are modeling a Let's say we're modeling a very simple decision that determines whether someone will receive a discount on some sort of insurance.
Females are eligible for this discount, males are not. The decision requirements graph will probably look something like the one sown shown below.
Use In Encore, use Ctrl-click on the various elements to open them and verify that the discount is modeled correctly.
Although even for simple decisions the DRG DRD is very useful while designing or reviewing, the true strength of the DRG DRD is exemplified when designing or reviewing multi-layered complex decisions. See the example DRG DRD below, that shows the decision that determines an applicant's risk scoreStrategy. At level 1 this decision looks trivial.
When expanded to the next level, it shows that the decision consists of three two separate decisions.
At level 4 the we find that there are in fact twelve many more 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'sDRDs. Shown below is such a DRG DRD for the sub decision Risk score bonus.Bureau call type.
In the examples above, knowledge sources are shown. These knowledge sources appear in a DRD when a specification is linked to a decision (decision table, business rule, attribute with expression, etc.).
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 graphdiagram, but differs mainly with regards to the fact that is it shows all given answers and derived values. See the example below, also about the risk score example.
Expanding sub decisions shows exactly what has been filled in by the user or derived by Blueriq at runtime in a specific session.
Best practices in designing decisions
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.
Some best 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.
| 1 | Main | Ask yourself the question what the main decision is. If you think of more than one answer, split these decisions if possible. |
| 2 | Type | Note that a decision is not bound to be a Boolean. In general, there are three types of decisions:
|
| 3 | Sub | For each identified decision, determine if the decision is 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 calculation where intermediate results are never reused but are created nevertheless, for the sake of understandability. |
| 4 | Circularity | Avoid 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 designing decisions top-down circular references can easily be avoided. |
| 5 | ... |
Constructs of Decision Modeling in Blueriq
text
Attributes
text
Sources
text
Business rules
text
Decision tables
text
Default expressions
text
Data rules
| Excerpt Include | ||||||
|---|---|---|---|---|---|---|
|
More information about the DRG in runtime can be found here: Decision Requirements Graph or DRG in runtime
| Panel | |||||||||
|---|---|---|---|---|---|---|---|---|---|
|
...
Overview
Content Tools