Change Patterns and Change Support Features

Companies increasingly adopt process-aware information systems (PAISs), which offer promising perspectives for more flexible enterprise computing. The emergence of different process support paradigms and the lack of methods for comparing existing approaches enabling PAIS changes have made the selection of adequate process management technology difficult. This paper suggests a set of 18 change patterns (consisting of 14 adaptation patterns and 4 decision deferral patterns) and 7 change support features to foster the systematic comparison of existing process management technology in respect to process change support. While the proposed patterns are all based on empirical evidence from several large case studies, the suggested change support features constitute typical functionalities provided by flexible PAISs. Based on the proposed change patterns and features, we conducted a detailed analysis and evaluation of selected approaches from both academia and industry. This work not only facilitates the selection of technologies for realizing flexible PAISs, but can also be used as a reference for implementing flexible PAISs.

Change Patterns

All these change patterns constitute solutions for realizing commonly occuring changes in PAISs. We divide the change patterns into two major categories: adaptation patterns and decision deferral patterns (also denoted as patterns for changes in prede ned regions). Thereby, adaptation patterns support structural process adaptations, whereas decision deferral patterns allow for built-in flexibility and are especially suited to deal with rather loosely structured business processes.

Adaptation Patterns

When having a closer look at existing PAISs or process modeling tools there are two different approaches for accomplishing structural adaptations of a process model: change primitives and high-level change operations (also denoted as adaptation patterns).

Structural model adaptations can be based on a complete set of change primitives, which directly operate on single elements of a process model. Examples include add node, remove node, add edge, and remove edge. Following this approach, the definition of a particular process model adaptation (e.g., to delete an activity or to add a new one) usually requires the application of a number of change primitives. Specifying structural model adaptations at this low level of abstraction, however, is both complex and error-prone. When applying a single change primitive, in general, soundness of the resulting process model (e.g., proper completion, no dead activities) as well as data flow correctness cannot be guaranteed by construction. Instead, respective properties have to be explicitly checked after applying the desired set of change primitives.

As an alternative, structural adaptations of a process model can be based on high-level change operations, e.g., to move an activity or an entire process fragment within a process model. Usually, respective change operations abstract from the concrete process model transformations to be conducted. Instead of specifying a set of change primitives, the user applies one or more high-level change operations to realize the desired process model adaptation. Existing approaches often associate pre- and post-conditions with the high-level change operations in order to be able to guarantee model correctness after each applied adaptation, i.e., to ensure correctness by construction. This is especially  important when ad-hoc changes shall be defined by end-users or — even more challenging — be automatically introduced by software agents during run-time. While change primitives can be applied to numerous process modeling languages relying on different process meta models, the application of high-level chnage operations often imposes structural restrictions (e.g., block structure) on the process model to be adapted in order to realize the aforementioned correctness guarantees.

Process adaptation patterns constitute abstractions of high-level change operations which are independent of concrete implementations as can be found in existing approaches. They enable users to structurally modify process models at high levels of abstraction, e.g., by adding, deleting or moving activities. Further, adaptation patterns can be applied at both the process type and the process instance level.

Adaptation patterns AP1 and AP2 allow for the insertion (AP1) and deletion (AP2) of process fragments in a given process model. Moving and replacing fragments is supported by adaptation patterns AP3 (Move Process Fragment), AP4 (Replace Process Fragment), AP5 (Swap Process Fragment), and AP14 (Copy Process Fragment). Adaptation patterns AP6 and AP7 allow for adding or removing levels of hierarchy. The extraction of a sub-process schema from a process model is  supported by AP6, whereas the inclusion of a sub-process into a process model is supported by AP7. Patterns AP8–AP12 support adaptations of control dependencies: embedding an existing process fragment in a loop (AP8), parallelizing a process fragment (AP9), embedding an existing process fragment in a conditional branch (AP10), and adding or removing control dependencies (AP11, AP12). Finally, AP13 (update condition) enables changes of transition conditions.

Decision Deferral Patterns

Traditional workflow management systems off er little flexibility and require to completely prede ne a business process in advance, thus employing a strictly plan-driven approach separating modeling and execution entirely. Decision deferral patterns, in turn, allow for better dealing with uncertainty by deferring decisions regarding the exact controlfl flow to run-time. Instead of requiring a process model to be fully speci ed prior to execution, parts of the model can remain unspeci ed relaxing the strict separation between built-time and run-time. In contrast to adaptation patterns, whose application is not restricted a priori to a particular process part, decision deferral patterns defi ne constraints concerning the parts of a process schema that can be changed or expanded. In this category we have identi fied 4 patterns: Late Selection (PP1), Late Modeling (PP2) and Late Composition of Process Fragments (PP3) and Multi-Instance Activity (PP4). These four patterns diff er regarding the parts that can remain unspecifi ed resulting in a di erent degree of freedom during run-time.

Change Support Features

Change patterns can be used to accomplish changes at the process type or process instance level. However, simply looking at the supported patterns and counting their number is not suffcient to analyze how well a system can deal with process change. In addition, change support features must be considered to make change patterns useful in practice. Relevant change support features include Schema Evolution, Version Control and Instance Migration (F1), Support for Instance-Speci c Changes (F2), Correctness of Change (F3), Traceability and Analysis of Changes (F4), Access Control for Changes (F5), Change Reuse (F6), and Change Concurrency Control (F7).


  • B. Weber, M. Reichert and S. Rinderle-Ma: Change Patterns and Change Support Features – Enhancing Flexibility in Process-Aware Information Systems. Data and Knowledge Engineering 66(3):438–466, 2008  
  • B. Weber, S. Rinderle and M. Reichert: Change Patterns and Change Support Features in Process-Aware Information Systems. In: Proc. CAiSE ’07, pp. 574–588, 2007.