Essential Business Process Modeling

Yet Another Workflow Language (YAWL)

As part of their work on patterns, the P4 rated 15 vendor offerings (including Staffware, SAP/R3, MQ Workflow, and Lotus Domino Workflow), determining whether each vendor’s product directly supports each pattern, indirectly supports each pattern with sufficient coding, or lacks support for a pattern completely. The results were disheartening: every vendor has spotty pattern coverage, most failing to support (even indirectly) half of the patterns. Even worse, among the vendors there is no conceptual consistency; every product has its own notation and execution semantics.

Motivated by dismal industry support and the absence of a universal theory of workflow, P4 authors van der Aalst and ter Hofstede created a graphical process language called Yet Another Workflow Language, or YAWL, that is rigged to support all 20 P4 patterns. A YAWL process is a Petri net extended with symbols supporting AND, OR, and XOR splits and joins, as well as multiple activity instances. The symbols are shown in Figure 4-30.^[*]

Figure 4-31 depicts the YAWL solution to two multiple instance patterns. In this example, some number of witnesses, at least one but no more than 10, are interviewed for the processing of an insurance claim.^[†]

In Case (a) in Figure 4-31, the number is not known until runtime; in Case (b), the number is not known even at runtime, and in certain cases, might need to be greater than 10! The notation [1,10,inf,fixed] in process_witness_statements in Case (a) means that between 1 and 10 instances of that activity are required and that the number is fixed at runtime; in Case (b), [1,10,inf,var] means between 1 and 10 instance are required and that this number is variable (var).

Figure 4-30. YAWL symbols

Figure 4-31. YAWL examples for Multiple Instance patterns

YAWL is interesting to read about, but it will never claim an actual production success story. First, standards to which current vendors are building, including BPMN and BPEL, are about as expressive as YAWL anyway. (White’s article demonstrates the relative ease of coding the patterns in BPMN and UML activity diagrams.^[*]) Second, there is more to a process language than support for patterns. Adopters care much more about level of difficulty, expressiveness, system integration capabilities, business analyst savvy, and other intangibles than having an out-of-the-box solution for, say, interleaved parallel routing. Analogously, in the object-oriented world, no one has bothered to invent a language whose main purpose is to support all of the Gang of Four patterns; Java, C++, and Smalltalk dominate, even without perfect GoF pattern support.

---

^[*] W. M. P. van der Aalst and A. H. M ter Hofstede, “Workflow Patterns: On The Expressive Power of (Petri-net-based) Workflow Languages,” in K. Jensen (editor), Proceedings of the Fourth Workshop on the Practical Use of Coloured Petri Nets and CPM Tools (CPN 2002), volume 560 of DAIMI, pages 1-20, University of Aarhus, Denmark, August 2002, p. 11.

^[†] Ibid, p. 13.

^[*] Stephen White, “Process Modeling Notations and Workflow Patterns,” BPTrends, March 2004.