Page 24 -

1 Introduction 9
with other types of systems, generally described as process-aware information sys-
tems, did not occur until the mid to late nineties. Although there are technological
considerations involved, the lack of a commonly accepted foundation for the speci-
fication of executable business processes played a major role in the slow progression
of workflow to broad adoption. This resulted in a plethora of approaches, where con-
cepts with similar names could have significant semantic differences. The Workflow
Management Coalition (WfMC) failed to provide a standard that was (1) sufficiently
precise, and (2) sufficiently expressive. As part of its definition of “interface 1,” it
provided natural language definitions of a number of commonly occurring workflow
concepts. These definitions led to a situation where vendors could legitimately claim
to abide by the WfMC standard, even though their interpretation of these concepts
was fundamentally different and could lead to the same workflow model being exe-
cuted in different ways. In addition, the concepts that were described by the WfMC
captured only simple control-flow dependencies. This meant that workflow migra-
tion was not only hampered by different interpretations of similarly named concepts,
but also by the fact that some concepts were supported in one environment but did
not have a counterpart in another.
These were the circumstances that gave rise to the Workflow Patterns Initiative in
the second half of 1999. The original founders recognized that there was a need to
distill the essential features of the many workflow management systems that existed.
This would allow an unbiased comparison of different approaches to the specifica-
tion of executable business processes and provide the basis for the adaptation and
refinement of existing techniques as well as supporting the development of new
approaches.
The approach chosen focussed on identifying the constructs required for the
specification of control-flow dependencies between tasks. The ability to explic-
itly capture tasks and their chronological dependencies is an essential capability
of workflow management systems. Initially, 13 commercial workflow management
systems and two research prototypes were examined with respect to the constructs
they offered for control-flow specification. This resulted in a collection of 20
control-flow patterns. Following the book by Gamma et al., which provided patterns
for object-oriented design, patterns have become a popular way of identifying recur-
ring problems and corresponding solutions in various areas of computer science.
The Workflow Patterns consisted of a description of desired control-flow function-
ality, problems with realizing this functionality and implementation approaches.
Workflow management systems were rated on a three point scale against these pat-
terns; the highest score was given where there was direct support for a pattern, while
the intermediate score indicated there were some restrictions in terms of direct pat-
tern support. The lowest score did not mean that the pattern could not be realized
from a theoretical point of view, as scripting languages are all Turing-complete,
but simply that the system involved did not provide direct support. Therefore, the
patterns are not concerned with expressive power but with suitability, a notion that
refers to the alignment between a modeling language and a problem domain.
Over time, the patterns-based evaluations were extended to business process
modeling languages (e.g., UML Activity Diagrams, BPMN), standards for web