In this section, the structure of business process models is investigated, and
an initial soundness criterion is introduced. While the considerations in this
section hold for process models represented in any of the process orchestration
languages introduced above, this section uses Petri nets, in most cases,
workflow nets, to represent these structural errors. The reasons are not only of
historical nature—workflow nets were the first approach for which soundness
was investigated—but also practical: the formal foundation of workflow nets
allows to formally specify and reason about soundness properties.
The type of structural error discussed in this section can be characterized
by dangling transitions or places, i.e., transitions without input places or output
places. Petri net with dangling places and transitions.
Notice that this Petri net is not a workflow net, since there are multiple places
without incoming edges and not all nodes, for instance, t5, are on a path from
i to o.
When a token enters the Petri net in place i, transition t1 is enabled. Note
that there is no way that t4 can ever be enabled. When t2 fires, t5 and t3
are enabled. When t3 terminates, the output place o is reached, signalling
the completion of the case. However, at this point in time, t5 could still be
running! As a consequence, the token at the output place o does not signal the
completion of the case. These types of errors are ruled out by the definition
of workflow nets.
This example motivates the development of correctness criteria for process
models to prevent the modelling errors discussed. The simplest correctness criterion uses the structure of business process models. It is inspired by the
definition of workflow nets and takes advantage of the definition of workflow
Definition 6.1 A process model is structurally sound if the following conditions
• There is exactly one initial node, which is the only node without any
• There is exactly one final node, which is the only node without any outgoing
• Each node in the process model is on a path from the initial node to the
Structural soundness also goes well with the definition of business process
models, which states that business process models consist of related activities.
Structural soundness makes this relationship concrete by defining that each
activity is embedded in the context of the process and that no activities are
independent of other activities of the same business process.
Many business process languages enforce structural soundness, for instance,
event-driven process chains and business process diagrams expressed
in the Business Process Modeling Notation. However, the process designer has
the freedom to use these process languages to design process models that are