Business Process Model Patterns Classification

This site has been developed in the context of our work on business process model patterns. Our first core results have been submitted as an article to BISE Journal. In the submission "Business Process Model Patterns: State-of-the art, Research Classification and Taxonomy" we surveyed existing publications on process model patterns, thereby constructing a classification scheme as well as a pattern taxonomy. Some details of the classification scheme and taxonomy can be found below. The pattern publication classification can be found on this site.

This work has been done in the frame of our working group on Semantic Technologies in BPM associated with the EMISA. If you want to propose some other publications for our classification related to process model patterns or if you have any other questions please contact us.

Pattern Classification Scheme

All papers are classified with respect to several criteria. In the following, a description of these criteria is provided. The classification resembles a faceted classification, since multiple properties (facets) with multiple values are captured.

Criteria Description
Publication Title This property captures the title of a publication describing the pattern approach. If no single publication describes the approach, then an artificial title based on relevant publications is given.
This property has values indicating whether patterns have been developed in a scientific context or not.
  • Research: Holds if patterns have been developed in a scientific context.
  • Other: Holds if this was not the case (e.g., if patterns come from an industry).
Method of Creation
This property has values indicating the research methods used in the pattern creation process.
  • Informed Argument: Holds if patterns are elaborated and/or justified by providing sound arguments in reference to established literature, theories or real-world insights, e.g., gained in large industry projects or by applying the patterns. These arguments do not have to be put forward in the frame of any specific research method.
  • Literature Review: Holds if some form of systematic literature assessment such as a structured literature analysis has been conducted to derive patterns. At a minimum, the sources of literature, the search strategy and analysis procedure as well as the derived results have to be described.
  • Case Study: Holds if procedures of established case study research methods have been followed to derive patterns. At a minimum, the case(s) selected should be introduced in sufficient detail and the goals and results of the case analysis should be described.
  • Automatic Mining: Holds if the pattern has been derived using some computerized procedure capable of identifying recurrent pairs of problems and solutions in a large number of previously solved problems.
  • Manual Mining: Holds if the pattern has been derived using a manual procedure capable of identifying recurrent pairs of problems and solutions in a number of previously solved problems.
Year The year of the pattern paper publication.
Category This property dcategorizes patterns in specific topics. To get an overiew of all categories see Pattern Taxonomy.
This property has values indicating which perspectives are addressed by the patterns. For naming the perspective, we follow the ISO standard 19439, which distinguishes four perspectives.
  • Function: Holds if the pattern addresses processes, their inputs and outputs, as well as functionalities and behaviors of an enterprise.
  • Information: Holds if the pattern addresses enterprise information used and obtained during the enterprise operations.
  • Resource: Holds if the pattern addresses enterprise resources needed for carrying out the enterprise operations.
  • Organization: Holds if the pattern addresses the organization, organizational relationships and the decision making responsibilities in an enterprise.
Intended User
This property has values indicating the main addressees of the patterns.
  • Business Analyst: Holds if the pattern addresses people in charge of anal- ysis of an organisation or business domain in order to understand how it works or to help achieving its goals.
  • IT Specialist: Holds if the pattern addresses people in charge with design- ing, operating or maintaining software applications or computer hardware.
  • Researcher: Holds if the pattern addresses people who execute scientific work.
This property has values indicating the level of generalizability of the patterns.
  • Domain-specific: Holds if patterns have been developed for a spe- cific branch of the economy like health-care or banking. In this case, the solution component suggested by a pattern is dependent of this specific area of interest.
  • Generic: Holds if patterns contain solutions to problems that work independently of any specific domain.
Type of Article
In our survey, we found three different types types of papers.
  • Evaluation Research: hose Papers aim to understand the use of a particular (known) technique (in our case: one or more patterns) in practice.
  • Proposal of Solution: Those papers suggest a solution (in our case: by means of one or more patterns) for a given problem.
  • Personal Experience: Those papers describe a personal experience of the author(s) using a particular technique (in our case: description of one or more patterns).
  • Survey: This category includes literature reviews which summarize and categorize existing research literature.
This property has values indicating whether the described patterns are documented in a structured form, using a consistent template for presenting each pattern.
  • None: Holds if patterns are not documented in any structured form.
  • Light: Holds if patterns are documented using some structuring elements (e.g. name, classification, problem, solution, consequences, known uses) that may be proposed by or derived from standard pattern templates.
  • Full: Holds if patterns are documented using an elaborate template that is identical to or closely resembles established pattern templates.
The category Presentation describes the form in which the solution parts of the patterns are described.
  • Textual: Holds if the solution is described as text.
  • Formal: Holds if the solution is described by means of a formal, mathematically well-founded formalism (e.g. Petri nets).
  • Graphical: Holds if the solution is described by means of a diagram (e.g. a BPMN model).
The category Notation applies only for those papers for which the classification in the category Presentation is different from Textual. If a formalism or diagram is used for describing the solution, Notation shows which kind of notation is used for the description.
  • None: Applies if the value for Presentation is only Textual, i.e., no other formalism than text has been used.
  • Existing: Applies if an existing notation or formalism (e.g. BPMN) has been used.
  • Extension: Applies if an existing notation has been extended for the purpose of the pattern description.
  • New: Applies if a new notation has been introduced for the purpose of the pattern description.
Language Dependency
The category Language Dependency describes if the described patterns can only be used in conjunction with a specific language or if they can be used language independently.
  • Yes: Pattern descriptions are classified as Language-Dependent if the solutions are specific to a particular modeling language.
  • No: Not each pattern for which the solution has been described by using a certain modeling language has to be language-dependent. For example, the essence of a solution described using the Event-Driven Process Chain notation can be used when working with BPMN diagrams as well. Hence, such a pattern description would not be classified as language-dependent.
Extent of Documentation Many pattern descriptions do not refer to a single pattern but to a group of patterns. This property indicates whether some or all of the patterns belonging to this group are documented.
  • Partial: Holds if only selected patterns are documented in one or more publications while others are not accessible.
  • Complete: Holds if a complete documentation is available (e.g., in the paper itself, in an appendix of the paper, in a database on the web, or in additional reports referenced in a publication).
Instructions, Guidelines This category describes, if instructions or guidelines regarding the pattern usage are descirbed in the paper.
  • Yes: Holds if the pattern description contains procedures or methodological support such as adaptation mechanisms for applying the proposed patterns.
  • No: Holds if that is not the case.
Tool Support The category Tool Support describes whether the pattern description discusses tool support for working with the patterns.
  • Yes: The value in this category is Yes if a tool has been developed specifically for the purpose of working with the patterns.
  • No: Just alone the fact that a pattern can be applied when using a common modeling tool would not be sufficient; in those cases the value is No.

Pattern Taxonomy

To make it easy for researchers and practicioners to find relevant patterns for their field of interest, we categorizied all publications. The taxonomy below shows all publications for each category. Just click on the category you are interested in, and all relevant publicatins will show up. A decsription of every category is given when the mouse pointer moves over the question mark next to each category. The numbers display the number of publications in each category.

  1. Structure and Behavior
    1. Instantiation and Termination 3
    2. Process Structure and Flow 16
  2. Resource Patterns
    1. Role and Resource Assignment 6
    2. Delegation 1
  3. Data Patterns 4
  4. Orchestration and Choreography Patterns
    1. Communication 5
    2. Negotiation 2
    3. Collaboration 6
  5. Content Patterns
    1. Domain-dependent 4
    2. Domain-independent 4
  6. Quality, Compliance and Risk Patterns
    1. Business Process Compliance 7
    2. Risk and Security 1
    3. Environmental Impact 1
  7. Adaption and Improvement Patterns
    1. Differences and Variability 12
    2. Model Improvement 6
  8. Integration and Conversion Patterns
    1. Model View 4
    2. Model Integration 4
    3. Model Transformation 5
  9. Process Architecture Patterns 1