Page 135 -

124 M. Adams
In other work environments, such as those where activities are more creatively
focussed, formal representations may provide merely a contingency around which
ad-hoc tasks can be formulated. Barthelmess et al. state that “In real life, both in
office and scientific lab environments, the enactment of any workcase may deviate
significantly from what was planned/modeled” [41]. Thus, adherence to formal rep-
resentations of task sequences ignores, and may even damage, the informal work
practices that also occur in any set of activities.
In summary, a large group of business processes do not easily map to the rigid
modeling structures provided due to the lack of flexibility inherent in a framework
that, by definition, imposes rigidity. Rather, process models are “system-centric,”
meaning that work processes are forced into the paradigm supplied, rather than the
paradigm reflecting the way work is actually performed. As a result, users are forced
to work outside the system, and/or constantly revise the process model, in order
to successfully complete their activities, thereby negating the perceived efficiency
gains sought by implementing a workflow solution in the first place. Therefore, for a
workflow system to be most effective, it must support dynamic change (i.e., during
execution).

4.2 YAWL and Dynamic Workflow

Human work is complex and is governed by rules often to a much lesser extent
than computerized processing. While some workplaces have strict operating pro-
cedures because of the work they do (e.g., air traffic control), many workplaces
have few prespecified routines, but successfully complete activities by developing
a set of informal tasks that can be flexibly and dynamically combined to solve a
large range of problems. Generally, approaches to workflow flexibility usually rely
on a high-level of runtime user interactivity, which directly impedes the basic aim
of workflow systems (to bring greater efficiencies to work practices) and distracts
users from their primary work procedures into process support activities. Another
common theme is the complex update, modification, and migration issues required
to evolve process models.
The YAWL language supports flexibility through a number of constructs at
design time. Like many other languages, YAWL supports parallel branching, choice,
and iteration natively, which allow for certain paths to be chosen, executed, and
repeated based on conditionals and data values of the instance. In addition (and
unlike most other languages), YAWL also supports advanced constructs such as
multiple-atomic and multiple-composite tasks, where several instances of a task or
subnet can be executed concurrently (and dynamically created), and cancelation
sets, which allow for arbitrary tasks (or sets of tasks), to canceled or removed from
a process instance. Chapter 2 deals with these forms of flexibility in more detail.
The YAWL environment also supports flexibility through its service-oriented
architecture (cf. Chap. 7). This means that dedicated services can be built that lever-
age the power of the YAWL enactment engine to provide flexibility for processes in
various ways.