Page History

Table of contents

Immediate cause

Image Removed

There Some might say that 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 overflow (no pun intended) with complexity. Maintenance on such complex flowcharts will become difficult and eventually impossible. Shown below are some examples of flows that are used to demonstrate this complexity.

Image Added

Image Added

Using independent ad-hoc tasks that have preconditions that state when such a task may be executed performed and when it must be executedperformed, will result in far better understandable maintainable and maintainable flexible business models, a quicker time to market and happier customerslower maintenance costs. Furthermore, precondition based tasks will result in a more flexible application, since tasks are only available and/or required when necessary. From a Blueriq-point-of-view, it is not mandatory to use preconditions and ad-hoc tasks exclusively, nor is it mandatory to use flow exclusively. One of the unique aspects of Blueriq is that both approaches are available and can be intertwined to get the best of both worlds. So whenever there is an activity that may only be performed when another activity is completed, it can be modeled with flow.

Using ad-hoc tasks and preconditions requires a shift in business process modeling. In stead Instead of thinking about a task and possible next tasks, the business process modeler needs to figure out when a task is applicable (may be performed) and necessary (must be performed).

Complexity and traceability

Business process modelers that have a lot of experience using classic BPM(N) might argue that this shift in modeling has two downsides.

The first a downside. This downside has to do with the fact that preconditions might become complex and therefore not understandable. This is arguably true, since because complexity of the business will not magically disappear when using preconditions in stead instead of flow. However, the complexity of preconditions is remains maintainable even at a very large scale, because they are defined for just the scope of each task. The complexity of flow will can - at one point or another - grow beyond repair. A second argument out of control. Flows become more complex when the scale increases, with more arrows, duplicated activities and decisions used for the sake of control. When using tasks with preconditions, the number of tasks grows with an increasing scale, not the complexity of the tasks.

A second downside often heard is that flow has a visualization, namely the flowchart, whereas preconditions do not have such a visualization. This is not correct...article shows how this downside can easily be overcome using standard Blueriq elements.

So how do we maintain complex preconditions and provide diagrammatic insightstill oversee the dependencies between tasks? By using the Decision Requirements Graph to provide insight. The Decision Requirements Graph , is a diagram that is available in Blueriq 9.3 and onwards and is based on the Decision Model and Notation (DMN) standard by the Object 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

We will provide a step-by-step guide on how to make optimal effectively use of the the power of the Decision Requirements Graph when modeling preconditions of ad-hoc tasks. When following these steps for conditions used in preconditions and in necessity to state when a task may be performed (precondition) and when it must be performed (required), it will be much easier to understand and maintain thse ad-hoc tasks.

1.

...

Entities and attributes for tasks

Create an entity for each ad-hoc taskTask, with the attribute <TaskName>.MayBePerformed and if applicable <TaskName>.MustBePerformed.
Of course it is also possible to create a single combination-entity with attributes for multiple a may-be-performed-attribute and a must-be-performed-attribute for all tasks, this is subject to the Business Engineer's taste or agreed architectural (project) guidelines. In this document we use an entity for each task.

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 ApproveTravelRequest and AskAdditionalInformation. We now focus on the precondition Approve travel request ApproveTravelRequest 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.

Image RemovedImage Added

4. Inspect with Decision Requirements Graph

Use the Decision Requirements Graph to inspect the logic underneath the derived attribute. This Decision Requirements Graph can be generated from the logic element or from the attribute itself, in both cases by clicking the scale icon .
Unfortunately Currently, the Decision Requirements Graph cannot be generated not from the precondition in of the task directly, since  as the precondition is an expression and not necessarily a decision (derived attribute).

Image RemovedImage Added

Pros 

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

...

1. projects will contain a uniform and recognizable structure.
2. Maintenance on projects becomes easier, since it is always clear where to start inspecting existing preconditions.
3. Complexity is not scattered over decisions, processes, tasks and flow but it is concentrated in the area where it belongs, namely logic.
4. Using this strategy does not interfere with the approach of flow, if applicable.

Cons

1. Tasks are modeled in a process module, but the majority of logic elements that infer when these tasks may and/or must be performed are probably modeled in interaction modules. This means that entity and attribute duplication and data mappings are necessary.
2. When a task has a very simple precondition, the strategy described here is quite excessive.
3. Whenever a task is used more than once, with different preconditions, extra attributes have to be declared. This could result in a lot of extra entities and attributes. 
4. Since Blueriq currently cannot generate a Decision Requirements Graph directly from the precondition, an extra layer of (non-functional) entities and attributes is required to enjoy the benefits of the Decision Requirements Graph

...