Page History

...

Immediate cause

Image Removed

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.

Image Added

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 maintainable and flexible business models, a quicker time to market and happier customers with regards to maintenance. 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 absolutely 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 will work and can be intertwined at will. So whenever there is an activity that is only applicable when another activity is completed, it can be modeled with flow.

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

...

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. Using this strategy does not interfere with the approach of flow, if applicable.
5. ...

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. The extra layer of attributes, mainly necessary to use the power of the Decision requirements Graph, might be considered as domain model pollution. If a Decision requirements Graph could be generated directly from the precondition, this would result in a much cleaner domain model.
5. ...

...