A workflow pattern is a specialized form of design pattern as defined in the area of software engineering or business process engineering. Workflow patterns refer specifically to recurrent problems and proven solutions related to the development of workflow applications in particular, and more broadly, process-oriented applications. Concept Workflow patterns are concepts of economised development. Their usage should follow strategies of simplifying maintenance and reducing modelling work. Workflow is performed in real time. The mechanisms of control must support the typical pace of work. Design patterns must delay execution of workflow. Aggregation Workflow patterns may usually be aggregated as chains and the conditions for starting and terminating must be explicitly defined. Application Workflow patterns can be applied in various context, hence the conditions for use must be explicitly defined and shown in order to prevent misinterpretation. Van der Aalst classification A well-known collection of workflow patterns is that proposed by Wil van der Aalst et al. (2003) in their paper Workflow Patterns. with earlier versions published in 2000–02. This collection of patterns focuses on one specific aspect of process-oriented application development, namely the description of control flow dependencies between activities in a workflow/process. These patterns are divided into the following categories: Basic Control Patterns Sequence - execute two or more activities in sequence Parallel Split - execute two or more activities in any order or in parallel Synchronize - synchronize two or more activities that may execute in any order or in parallel; do not proceed with the execution of subsequent activities until all preceding activities have completed; also known as barrier synchronization. Exclusive Choice - choose one execution path from many alternatives based on data that is available when the execution of the process reaches the exclusive choice Simple Merge - wait for one among a set of activities to complete before proceeding; it is assumed that only one of these activities will be executed; typically, these activities are on different paths stemming from an exclusive choice or a deferred choice (see below) Terminate - terminate execution of activities upon defined event or status change Advanced Branching and Synchronization Patterns Multiple Choice - choose several execution paths from many alternatives Conditional Choice - choose one execution path from many alternatives according to discriminated status conditions Synchronizing Merge - merge many execution paths; synchronize if many paths are taken; do the same as for a simple merge if only one execution