Softw Syst Model (2012) 11:319–323DOI 10.1007/s10270-012-0233-4

EXPERT’S VOICE

Workflow patterns put into context

W. M. P. van der Aalst · A. H. M. ter Hofstede

Received: 20 January 2012 / Accepted: 23 January 2012 / Published online: 14 February 2012© The Author(s) 2012. This article is published with open access at Springerlink.com

Abstract In his paper “Approaches to Modeling BusinessProcesses. A Critical Analysis of BPMN, Workflow Pat-terns and YAWL”, Egon Börger criticizes the work of theWorkflow Patterns Initiative in a rather provocative manner.Although the workflow patterns and YAWL are well estab-lished and frequently used, Börger seems to misunderstandthe goals and contributions of the Workflow Patterns Initia-tive. Therefore, we put the workflow patterns and YAWLin their historic context. Moreover, we address some of thecriticism of Börger by pointing out the real purpose of theworkflow patterns and their relationship to formal languages(Petri nets) and real-life WFM/BPM systems.

Keywords Workflow patterns · YAWL · Petri nets ·Business process management

1 Introduction

In [3], Egon Börger states that the patterns by the WorkflowPatterns Initiative are “not well founded”, “badly described”,and “no suitable BPM benchmark”. Moreover, he criticizesthe semantical foundation of YAWL. Börger makes theseclaims in a rather provocative and emotional manner. There-fore, the editors encouraged us to write this rebuttal.

In the remainder, we first sketch the Workflow PatternsInitiative in its historic context. In [3], a substantial number

Communicated by Bernhard Rumpe.

W. M. P. van der Aalst (B) · A. H. M. ter HofstedeEindhoven University of Technology, Eindhoven, The Netherlandse-mail: w.m.p.v.d.aalst@tue.nl

W. M. P. van der Aalst · A. H. M. ter HofstedeQueensland University of Technology, Brisbane, Australiae-mail: a.terhofstede@qut.edu.au

of sentences are quoted from ten of our publications, whichappeared between 2000 and 2011. Many of these quotationsare out of context, e.g., quotations related to specification,analysis, and implementation are muddled up. Therefore,Sect. 2 describes the developments related to the WorkflowPatterns Initiative over the last decade thereby clarifying thepurpose of the patterns and the role of YAWL. In Sect. 3,we argue that patterns need to balance between generalityand precision and should not be viewed as a formal speci-fication of behavioral properties. Patterns should allow formultiple modeling techniques and not impose very specificsemantics, e.g., the well-known design patterns [7] also donot impose the use of Java or any other programming lan-guage. In Sect. 4, we point out the complexity of the variousinteracting workflow perspectives and argue that there is no“Silver Bullet Formalism” that will make everything as sim-ple as suggested in [3]. Finally, in Sect. 5, we acknowledgethe need for empirical validation and discuss our efforts tofind out what is happening in real workflow processes andWFM/BPM tools.

2 History of the workflow patterns

In the mid-nineties, Wil van der Aalst got involved in theSagitta project when he was working as a part-time work-flow consultant for Bakkenist Management Consultants. Thegoal of this project was to realize a workflow system for sup-porting the key processes within the Dutch Customs [18]. Hewas surprised by the way the Workflow Management (WFM)system was selected. Stakeholders had problems describingits desired functionality. For example, they did not distin-guish between—what is called today—the Deferred Choice(Pattern 16) and the Exclusive Choice (Pattern 4). Althoughthe Dutch Customs clearly had many processes that required

123

320 W. M. P. van der Aalst, A. H. M. ter Hofstede

support for the Deferred Choice, they were about to select aWFM system that did not support this at all [18]. This expe-rience and also several similar experiences of the first authorin the second half of the nineties clearly showed the need fordescribing workflow patterns.

However, the real start of the Workflow Patterns Initia-tive was in 1999 when the authors met at CoopIS 1999 inEdinburgh. This resulted in the first paper on the workflowpatterns at the same conference one year later [17]. Initially,the work received little attention, but this changed whenthe http://www.workflowpatterns.com website was launchedand started to attract the attention of people involved in theselection and use of WFM systems. Several reports on thepatterns appeared in Dutch IT journals and these encour-aged vendors to study the workflow patterns more closely. Inparallel, we refined and extended the patterns and started tosystematically evaluate commercial WFM systems [4,5,21].We also evaluated emerging standards such as BPEL4WS,BPML, XLANG, WSFL and WSCI.

Initially, the focus was on control-flow only. This changedin 2004 when Nick Russell joined the Workflow PatternsInitiative. Over time, we added patterns for the other coreperspectives such as the workflow resource patterns [13], theworkflow data patterns [14], and the exception handling pat-terns [12]. Later also patterns related to service interactionand flexibility were added. Whereas the control-flow pat-terns could be used to evaluate a language or notation, forthe other patterns it made more sense to consider them in thecontext of a WFM/BPM system. In 2006, the original set of20 control-flow patterns was revisited with the goal to pro-vide a more precise description of each of the patterns andalso to identify any potential gaps in the original set of pat-terns. As a result the number roughly doubled. In [3], Börgercriticizes the growing number of patterns: “an exponentialgrowth can be observed starting with 20 workflow patternsin 2003 going through 43 WPs in 2006 and reaching a praised126 patterns (obtained by adding patterns for the so-calleddata and resource perspectives) in 2010. No reason is giventhat this growth has a fundamentum in re and a limit.” (note:references in this quote were removed). The reason for thegrowing number of patterns was the expanding scope of theWorkflow Patterns Initiative and our experiences with a widerange of systems and standards. Moreover, as was clearlystated in our publications, we do not claim that WFM sys-tems/languages should support all patterns. Users should firstanalyze which patterns they need and then use this short-listof patterns to select a system.

In parallel with the refinement and extensions of thepatterns, we also started the development of the YAWL lan-guage and system [15,20]. YAWL is inspired by the work-flow patterns and extends Petri nets to facilitate the use ofmore advanced patterns [19]. Börger is very critical aboutthe development of YAWL as a reference implementation of

the workflow patterns. He talks about “an obvious. . .groupinterest” (Section 4.1 in [3]) suggesting that the patterns wereused to promote YAWL. However, Börger misunderstandsthe true intentions of YAWL. The development of YAWLstarted in 2002 and was triggered by frequent discussionswith practitioners that had problems understanding the subtlebut important differences between the various patterns. Somevendors doubted that comprehensive patterns support couldbe achieved (without adding a lot of complexity). They wouldoften ask “How do you do this?” and wanted to see concreteexamples. This instigated the development of YAWL. Theacronym (Yet Another Workflow Language) clearly showsthat YAWL was not intended as a commercial effort trying togain competitive advantage by exploiting the patterns. How-ever, YAWL has had a very positive effect on the WorkflowPatterns Initiative. When implementing YAWL new ques-tions emerged, especially with respect to the interaction ofthe various patterns. The YAWL environment also helped toprovide a proof-of-concept for various innovative researchideas related to workflow flexibility, work distribution, work-list visualization, configurable process models, verification,simulation, and process mining [15]. YAWL is one of themost visible open source WFM systems (see [22] for a pat-terns based analysis of the other main open source WFM sys-tems). YAWL has been downloaded approx. 120,000 timesand the key paper [20] has been cited more than 800 timesaccording to Google Scholar. Overall, we think that YAWLhelped to progress WFM/BPM research and it is unclear whyBörger goes to great lengths to denounce it (in [3] no otherWFM systems are singled out for criticism).

In our view, the workflow patterns have had a very positiveeffect on WFM/BPM research and WFM/BPM products.Today, the patterns are widely used to describe workflowfunctionality in a language/system-independent manner. Inaddition, the patterns are also highly visible. The http://www.workflowpatterns.com website has been one of the most vis-ited websites in the field of BPM averaging more than 300visitors per working day over the last decade. Moreover, [21]is the most cited workflow paper ever (it has more than 2,250citations according to Google Scholar).

3 Balancing between generality and precision

In [3] both the informal descriptions of the workflow pat-terns and the example formalizations using YAWL and CPNTools are criticized. Surprisingly, despite his criticism, EgonBörger has published various papers on formalizing the con-trol-flow patterns in terms of Abstract State Machine (ASMs)[2]. On the one hand, he claims that our informal descriptionsare vague and ambiguous. On the other hand, Börger doesnot like the explanations/formalizations in terms of (colored)Petri nets. In this section, we address these comments.

123

Workflow patterns put into context 321

The notion of patterns as a means of categorizing recurringproblems and solutions in a particular domain is generallyattributed to Christopher Alexander [1]. Later the concept ofpatterns was adopted in software development, resulting inwell-known patterns collections such as the design patternsby the “Gang of Four” [7], the business analysis patterns[6], and the enterprise application integration patterns [8].See http://hillside.net/patterns/patterns-catalog for pointersto other collections. All of these collections have in com-mon that they do not impose a particular language and thatthe description of the pattern is deliberately kept informal.When describing a pattern one needs to resort to concreteexamples, e.g., the design patterns book by the “Gang ofFour” [1] includes many examples using C++ and Smalltalk.However, these examples should not be confused with theactual patterns. We often use Petri nets to explain patterns.However, this does not imply that these Petri nets should beviewed as formal specifications of the pattern. Moreover, asour evaluations show, systems not based on Petri nets canalso support any of the patterns if they provide the desiredfunctionality. It is quite OK to formulate pattern examplesin terms of ASMs, just like they have been formulated invarious process algebras (e.g. in [9]). However, this does nottouch upon the essence of the workflow patterns which arerepresentation independent.

In Section 4.2 of [3], Börger argues that (colored) Petrinets are unsuitable “for the practice of BPM”. As indicatedin [19,20], we agree that Petri nets are unsuitable as a busi-ness process modeling language for end users. (This is thereason for developing more suitable notations like YAWL.)However, ASMs are even less suitable as an end-user lan-guage for modeling processes as they are not graphical andvery different from mainstream languages such as BPMN,UML, EPCs, etc. We do not propose Petri nets as an end-user language. Instead, we use it for:

• Clarification: Petri nets are graphical, well-known, andwidely used. Therefore, it makes sense to illustrate thebasic patterns in terms of small Petri net examples.

• Semantics: YAWL and various workflow functionalities(e.g., work distribution mechanisms) can be formalizedin terms of colored Petri nets. Moreover, using CPN Toolssuch models are directly executable and can be used foranalysis (simulation and state-space exploration).

• Analysis: Petri nets allow for different types of analysis,not only for model checking but also for various linear-algebraic techniques (invariants and the marking equa-tion), Markov analysis, simulation, etc.

Clearly, many properties are undecidable unless rigorousabstractions are used. However, there is a large body ofknowledge on analyzing workflows using Petri nets. A sys-tem such as YAWL provides support for checking soundness

[15], but other techniques in areas such as process mining[16] and simulation [10] have been developed to supportspecific types of analysis relevant for the field of BPM. Suchdedicated techniques do not exist for ASMs. In his paper,Börger refers to work on “Software Product Lines” for solu-tions. However, he is not very clear about this as it is just aside remark in the three page discussion on the “unsuitabil-ity” of Petri nets (cf. Section 4 in [3]).

4 Make things as simple as possible, but not simpler

In [15], we discuss the semantics of YAWL and in the PhDthesis of Nick Russell [11] a formalization of YAWL’s con-trol-flow, data, and resource perspectives is given in terms ofcolored Petri nets. The formal model of YAWL can be exe-cuted using CPN Tools. Börger complains that the CPN Toolsmodel is not shown in [15]. The model is indeed large: 55pages, 480 places, and 138 transitions. However, this modelcovers all three aforementioned perspectives and also theinteractions between these perspectives. It is absurd to thinkthat another formalization technique like ASMs will sud-denly make things simple. The CPN Tools model describesmany essential and complex mechanisms.

Egon Börger seems to advocate a “Silver Bullet Formal-ism” that will make things simple and manageable. Thereis definitely room for improvement. However, making suchclaims without having specified or implemented a WFM sys-tem that is able to support a reasonable number of patternscovering the control-flow, data, and resource perspectives isnot very convincing.

5 Need for empirical validation

In Section 3.1 of [3], Börger writes “In fact, there is no statis-tical underpinning showing how frequently which patternsappear in real-life business processes. Experimental data likethat produced for BPMN constructs in [61] should have beenput in place to validate the pattern selection.” We acknowl-edge the importance of empirical validation. However, theworkflow patterns have been validated. First of all, the pat-terns are based on a detailed analysis of various WFM/BPMsystems. Moreover, practical experiences obtained through amultitude of evaluations resulted in reformulations and fur-ther refinements of the patterns. Systems such as Staffware,WebSphere MQ Workflow, FLOWer, COSA, iPlanet, SAPWorkflow, Filenet, jBPM, OpenWFE, Enhydra Shark, Web-Sphere Integration Developer and Oracle BPEL, and lan-guages/standards such as BPMN, XPDL, BPEL, UML andEPCs have been analyzed using the patterns. Moreover, wehave been interacting with workflow vendors, consultants,end-users and analysts regarding the patterns. Second, welooked at the frequencies of patterns in real-life projects. See

123

322 W. M. P. van der Aalst, A. H. M. ter Hofstede

for example the work done by Kristiaan de Vries and OscarOmmert [4,5]. Under the supervision of the first author theyevaluated five workflow projects conducted by ATOS/Ori-gin to get quantitative data about the frequency of patterns.Each of these projects involved multiple processes for whichthe number of activities ranged from dozens to hundreds. Thesystems Eastman Enterprise Workflow, Staffware, and Dom-ino Workflow were used in these projects. Empirical findingsshowed that in many of ATOS/Origin’s projects workflowdesigners were forced to adapt the process or had to resortto spaghetti-like diagrams or coding because particular pat-terns were not supported by the WFM system. The projectalso showed a positive correlation between the patterns beingused and the patterns that were well supported, e.g., the pro-cesses developed using Staffware had much more parallel-ism than the processes developed using Eastman EnterpriseWorkflow. This example shows that patterns tend to be usedfrequently if they are supported well. This indicates that pro-cess design is influenced by patterns support.

A more elaborate empirical validation of the workflowpatterns is welcome. Moreover, we would also like to referto our work on process mining [16]. In this work, we ana-lyze processes based on event logs, i.e., we discover, monitorand improve real processes (i.e., not assumed processes) byextracting knowledge from event logs readily available intoday’s information systems. Experience obtained by apply-ing process mining in over 100 organizations shows thatprocesses are often much more involved than what peoplewould like to think. Typically, 80% of the process instancescan be described by a rather simple process model. How-ever, to model the remaining 20% more advanced patternsare needed.

Acknowledgments The authors would like to thank all that contrib-uted to the Workflow Patterns Initiative and the development of YAWL.In particular Nick Russell, Nataliya Mulyar, Bartek Kiepuszewski, Ali-stair Barros, Petia Wohed, and Michael Adams.

Open Access This article is distributed under the terms of the CreativeCommons Attribution License which permits any use, distribution, andreproduction in any medium, provided the original author(s) and thesource are credited.

References

1. Alexander, C.: A Pattern Language: Towns, Building and Con-struction. Oxford University Press, Oxford (1977)

2. Börger, E.: Modeling workflow patterns from first principles.In: Parent, C., Schewe, K.D., Storey, V., Thalheim, B. (eds.) Con-ceptual Modeling (ER 2007). Lecture Notes in Computer Science,vol. 4801, pp. 1–20. Springer, Berlin (2007)

3. Börger, E.: Approaches to modeling business processes. a criti-cal analysis of BPMN, workflow patterns and YAWL. Softw. Syst.Model (2012). doi:10.1007/s10270-011-0214-z

4. de Vries, K., Ommert, O.: Advanced workflow patterns in practice(1): experiences based on pension processing (in Dutch). Bus. Pro-cess Mag. 7(6), 15–18 (2001)

5. de Vries, K., Ommert, O.: Advanced workflow patterns in practice(2): experiences based on judicial processes (in Dutch). Bus. Pro-cess Mag. 8(1), 20–23 (2002)

6. Fowler, M.: Analysis Patterns: Reusable Object Models. Addison-Wesley, Reading (1997)

7. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Pat-terns: Elements of Reusable Object-Oriented Software. Profes-sional Computing Series. Addison-Wesley, Reading (1995)

8. Hohpe, G., Woolf, B.: Enterprise Integration Patterns. Addison-Wesley, Reading (2003)

9. Puhlmann, F., Weske, M.: A look around the corner: the Pi-calcu-lus. In: Jensen, K., van der Aalst, W.M.P. (eds.) Transactions onPetri Nets and Other Models of Concurrency II. Lecture Notes inComputer Science, vol. 5460, pp. 64–78. Springer, Berlin (2009)

10. Rozinat, A., Wynn, M., van der Aalst, W.M.P., ter Hofstede,A.H.M., Fidge, C.: Workflow simulation for operational decisionsupport. Data Knowl. Eng. 68(9), 834–850 (2009)

11. Russell, N.: Foundations of Process-Aware Information Systems.PhD thesis, Queensland University of Technology (2007)

12. Russell, N., van der Aalst, W.M.P., ter Hofstede, A.H.M.: Workflowexception patterns. In: Dubois, E., Pohl, K. (eds.) Proceedings ofthe 18th International Conference on Advanced Information Sys-tems Engineering (CAiSE’06). Lecture Notes in Computer Sci-ence, vol. 4001, pp. 288–302. Springer, Berlin (2006)

13. Russell, N., van der Aalst, W.M.P., ter Hofstede, A.H.M., Edmond,D.: Workflow resource patterns: identification, representation andtool support. In: Pastor, O., Falcão e Cunha, J. (eds.) Proceed-ings of the 17th Conference on Advanced Information SystemsEngineering (CAiSE’05). Lecture Notes in Computer Science, vol.3520, pp. 216–232. Springer, Berlin (2005)

14. Russell, N., ter Hofstede, A.H.M., Edmond, D., van der Aalst,W.M.P.: Workflow data patterns: identification, representation andtool support. In: Delcambre, L., Kop, C., Mayr, H.C., Mylopoulos,J., Pastor, O. (eds.) Proceedings of the 24th International Confer-ence on Conceptual Modeling (ER 2005). Lecture Notes in Com-puter Science, vol. 3716, pp. 353–368. Springer, Berlin (2005)

15. ter Hofstede, A.H.M., van der Aalst, W.M.P., Adams, M., Russell,N.: Modern Business Process Automation: YAWL and its SupportEnvironment. Springer, Berlin (2010)

16. van der Aalst, W.M.P.: Process Mining: Discovery, Confor-mance and Enhancement of Business Processes. Springer, Berlin(2011)

17. van der Aalst, W.M.P., Barros, A.P., ter Hofstede, A.H.M.,Kiepuszewski, B.: Advanced workflow patterns. In: Etzion, O.,Scheuermann, P. (eds.) Proceedings of the 7th International Confer-ence on Cooperative Information Systems (CoopIS 2000). LectureNotes in Computer Science, vol. 1901, pp. 18–29. Springer, Berlin(2000)

18. van der Aalst, W.M.P., van Hee, K.M.: Workflow Manage-ment: Models, Methods and Systems (in Dutch). Academic Ser-vice, Schoonhoven (1997)

19. van der Aalst, W.M.P., ter Hofstede, A.H.M.: Workflow pat-terns: on the expressive power of (Petri-net-based) workflow lan-guages. In: Jensen, K. Proceedings of the Fourth Workshop on thePractical Use of Coloured Petri Nets and CPN Tools (CPN 2002).DAIMI, vol. 560, pp. 1–20, Aarhus, University of Aarhus, Aar-hus (2002)

20. van der Aalst, W.M.P., ter Hofstede, A.H.M.: YAWL: Yet AnotherWorkflow Language. Inf. Syst. 30(4), 245–275 (2005)

21. van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszew-ski, B., Barros, A.P.: Workflow patterns. Distrib. Parallel Dat-abases 14(1), 5–51 (2003)

22. Wohed, P., Russell, N.C., ter Hofstede, A.H.M., Andersson, B., vander Aalst, W.M.P.: Patterns-based evaluation of open source BPMsystems: the cases of jBPM, OpenWFE, and Enhydra Shark. Inf.Softw. Technol. 51(8), 1187–1216 (2009)

123

Workflow patterns put into context 323

Author Biographies

W. M. P. van der Aalst isa full Professor of Informa-tion Systems at the TechnischeUniversiteit Eindhoven (TU/e).Currently, he is also an adjunctprofessor at Queensland Univer-sity of Technology (QUT) work-ing within the BPM group there.He is also a member of the RoyalHolland Society of Sciences andHumanities and the Academyof Europe. His research inter-ests include workflow manage-ment, process mining, Petri nets,business process management,

process modeling, and process analysis.

A. H. M. ter Hofstede is a Pro-fessor in the Information Sys-tems School in the Science andEngineering Faculty, Queens-land University of Technology,Brisbane, Australia, and is Headof the Business Process Man-agement Discipline. He is alsoa Professor in the InformationSystems Group at EindhovenUniversity of Technology, Eind-hoven, The Netherlands. Hismain research interests lie inthe area of business processautomation.

123