Page 154 -

4 Dynamic Workflow 143
Other Approaches

Most workflow systems use their own unique conceptual framework, which is usu-
ally based on programming constructs rather than founded on theories of work
practice. Consequently, since the mid-nineties, much research has been carried out
on issues related to dynamic flexibility and exception handling in workflow manage-
ment systems. Such research was initiated because, generally, commercial workflow
management systems required the model to be fully defined before it could be
instantiated, and that any changes must be incorporated by modifying the model stat-
ically. These typically flat, monolithic, single-schema architectures make it difficult
to fully capture flexible business processes [46,117].
While there have been many proposed and/or implemented approaches to flexi-
bility, this section discusses a sample of the more interesting ones.
An optional component of the Tibco iProcess Suite is the Process Orchestra-
tor [102], which allows for the dynamic allocation of subprocesses at runtime. It
requires a construct called a “dynamic event” to be explicitly modeled that will
execute a number of subprocesses listed in an “array” when execution reaches
that event. Which subprocesses execute depend on predefined data conditionals
matching the current case. The listed subprocesses are statically defined as are the
conditionals. There is no scope for dynamically refining conditionals, nor adding
subprocesses at runtime.
COSA (version 5.4) [66] provides for the definition of external “triggers” or
events that may be used to start a subprocess. All events and subprocesses must
be defined at design time, although models can be modified at runtime (but only for
future instantiations). COSA also allows manual ad-hoc runtime adaptations such
as reordering, skipping, repeating, postponing, or terminating steps. SAP Workflow
(version 6.20) [227] supports conditional branching, where a list of conditions (each
linked to a process branch) is parsed and the first evaluating to true is taken; all
branches are predefined. FLOWer (version 2.1) [45, 191] is described as a “case-
handling” system; the process model (or “plan”) describes only the preferred way
of doing things and a variety of mechanisms are offered to allow users to deviate in
a controlled manner [22].
There have been a number of academic prototypes developed in the last decade
(although activity was greater during the first half); very few have had any impact
on the offerings of commercial systems [174]. Several of the more widely acknowl-
edged are discussed here.
The eFlow system [56] supports flexibility in e-Services by defining compensa-
tion rules for regions, although they are static and cannot be defined separately to the
standard model. The system allows changes to be made to process models, but such
changes introduce the common difficulties of migration, verification, consistency
and state modifications.
ADEPT [118,206] supports modification of a process during execution (i.e., add,
delete, and change the sequence of tasks) both at the model (dynamic evolution)
and at the instance levels (ad-hoc changes). Such changes are made to a traditional
monolithic model and must be achieved via manual intervention, abstracted to a high