Epilogue

Abstract

This book presents both the YAWL language and the supporting toolset. YAWL fits well in the transition from workflow management systems focusing on automation of structured processes to Business Process Management (BPM) systems aiming at a more comprehensive support of a wider variety of business processes. The development of YAWL was triggered by limitations of existing software for process automation. Although much has been written about business processes, there is a lack of consensus about how they are best described for the purposes of analysis and subsequent enactment. This has resulted in a plethora of approaches for capturing business processes. Despite an abundance of standardization initiatives, there is no common agreement on the essential concepts. Standardization processes are mainly driven by vested business interests. The large and influential software companies in the BPM area are involved in multiple standardization processes (to keep all options open), but do not wholeheartedly commit to any of them. The inherent complexity of business processes and the question of what fundamental concepts are necessary for business process modeling, enactment, and analysis gave rise to the development of a collection of workflow patterns. These patterns describe process modeling requirements in a language-independent manner. The Workflow Patterns Initiative started in the late nineties when the first set of 20 control-flow patterns were identified. These patterns where inspired by the design patterns for object-oriented design by Gamma et al. and focused on the ordering of tasks in business processes (e.g., parallelism, choice, synchronization, etc). Later this set of patterns was extended to more than 40 patterns. Moreover, driven by the success of the control-flow patterns, also other perspectives were analyzed using a patterns-based approach. This resulted in data patterns (dealing with the passing of information, scoping of variables, etc.), resource patterns (dealing with roles, task allocation, work distribution, delegation, etc.), exception handling patterns (dealing with exceptional situations), flexibility patterns (to make processes more adaptive and adaptable), interaction patterns (formodeling the glue between processes), and so on. All of these patterns resulted in a systematic overview of the possible, and maybe also expected, functionality of an ideal BPM solution. © 2010 Springer-Verlag Berlin Heidelberg.