Page History

Table of contents

Immediate cause

There is a trend among business process modeling, where modeling with preconditions is taking precedence over modeling flow. When the business requirements grow, classic BPM flowcharts become less and less readable, until they finally burst overflow (no pun intended) with complexity. Maintenance on such complex flowcharts will become difficult and eventually maybe even impossible.

Using independent ad hoc tasks that have preconditions that state when such a task may be executed and when it must be executed, will result in far better readable understandable and maintainable business models, a quicker time to market and happier customers.

...

Business process modelers that have a lot of experience using classic BPM might argue that this shift in modeling has a downside. This downside has to do with the fact that preconditions might become complex and therefore not understandable. This is arguably true, since complexity of the business will not magically disappear when using preconditions in stead of flow. However, the complexity of preconditions is maintainable even at a very large scale, the complexity of flow will - at one point or another - grow beyond repair. A second argument often heard is that flow has a visualization, namely the flowchart, whereas preconditions do not have such a visualization. This is not correct...

So how do we maintain complex preconditions and provide diagrammatic insight? By using the power of Decision Requirements GraphsGraph, a diagram that is available within in Blueriq 9.3 an and onwards and is based on the Decision Model and Notation (DMN) standard by the Object Modeing Modeling Group (OMG). Shown below is an example of such a graph that depicts the decision regarding maximum income for a certain benefit.

For more information about the Decision Requirements Graph see Decision Requirements Graph.

Step-by-step guide

In order to use We will provide a step-by-step guide on how to make optimal use of the the power of the DRG in Decision Requirements Graph when modeling preconditions, follow these steps:. When following these steps conditions used in preconditions and in necessity (required) will be much easier to understand and maintain.

1. Attributes for tasks

Create 1. Create an entity for each ad hoc task with two attributes: Task, with the attribute <TaskName>.MayBePerformed and Taskif applicable <TaskName>.MustBePerformed.
It Of course it is also possible to create a combination-entity with attributes for multiple tasks, this is subject to the Business Engineer's taste or agreed architectural (project) guidelines.

2. Preconditions on tasks

Create a precondition (and possible conditional requirement) that uses the attributes mentioned before. The structure will always be the same: the precondition will be <TaskName>.MayBePerformed.
In the example below we have two very fictional ad hoc tasks, Approve travel request and Ask for additional information. We now focus on the precondition Approve travel request may be performed.

3. Logic for attribute

Use any logic element to infer when the task may and/or must be performed. Below a decision table is sketched that states when the task ApproveTravelRequest may be performed.
Note that the column on the right might be considered redundant, since the attribute also has a default value False.

4. Inspect with Decision Requirements Graph

Use the Decision Requirements Graph to inspect the logic underneath the derived attribute. Note that you can generate this This Decision Requirements Graph can be generated from the logic element or from the attribute itself, in both cases by clicking the scale icon Image Added.
Unfortunately the Decision Requirements Graph cannot be generated not from the precondition in the task, since the precondition is an expression and not necessarily a decision (derived attribute).

...

Pros 

1. When following the strategy as discussed in this article, many different project will have the same structure.

...

...