Page History

...

Immediate cause

Some might day 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.

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 understandable and maintainable business models, a quicker time to market and happier customers with regards to maintenance.

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

...

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

The first 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. 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 argument often heard is that flow has a visualization, namely the flowchart, whereas preconditions do not have such a visualization. This is not correct ...with regards to Blueriq!

So how do we maintain complex preconditions and provide diagrammatic insight? By using the Decision Requirements Graph, 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.

...

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

...

1. When following the strategy as discussed in this article, totally different projects will have the same 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. ...

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. ...

...