Change Patterns and Change Support Features in Process-Aware Information Systems

Transcription

1 hange Patterns an hange Support eatures in -Aware Information Systems arbara Weber 1,, Stefanie Rinerle 2, an Manfre Reichert 3 1 Quality ngineering Research Group, University of Innsbruck, Austria arbara.weber@uibk.ac.at 2 Inst. atabases an Information Systems, Ulm University, Germany stefanie.rinerle@uni-ulm.e 3 Information Systems Group, University of Twente, The Netherlans m.u.reichert@cs.utwente.nl Abstract. In orer to provie effective support, the introuction of process-aware information systems (PAIS) must not freeze existing business processes. Instea PAIS shoul allow authorize users to flexibly eviate from the preefine processes if require an to evolve business processes in a controlle manner over time. Many software venors promise flexible system solutions for realizing such aaptive PAIS, but are often unable to cope with funamental issues relate to process change (e.g., correctness an robustness). The existence of ifferent process support paraigms an the lack of methos for comparing existing change approaches makes it ifficult for PAIS engineers to choose the aequate technology. In this paper we suggest a set of changes patterns an change support features to foster systematic comparison of existing process management technology with respect to change support. ase on these change patterns an features, we provie an evaluation of selecte systems. 1 Introuction ontemporary information systems (IS) more an more have to be aligne in a process-oriente way. This new generation of IS is often referre to as - Aware IS (PAIS) [1]. In orer to provie effective process support, PAIS shoul capture real-worl processes aequately, i.e., there shoul be no mismatch between the computerize processes an those in reality. In orer to achieve this, the introuction of PAIS must not lea to rigiity an freeze existing business processes. Instea PAIS shoul allow authorize users to flexibly eviate from the preefine processes as require (e.g., to eal with exceptions) an to evolve PAIS implementations over time (e.g., ue to process optimizations or legal changes). Such process changes shoul be enable at a high level of abstraction an without affecting the robustness of the PAIS [2]. The increasing eman for process change support poses new challenges for IS engineers an requires the use of change enabling technologies. ontemporary This work was one uring a postoctoral fellowship at the University of Twente. J. Krogstie, A.L. Opahl, an G. Sinre (s.): AiS 2007, LNS 4495, pp , c Springer-Verlag erlin Heielberg

2 382. Weber, S. Rinerle an M. Reichert PAIS, in combination with service-oriente computing, offer promising perspectives in this context. Many venors promise flexible software solutions for realizing aaptive PAIS, but are often unable to cope with funamental issues relate to process change (e.g., correctness an robustness). This problem is further aggravate by the fact that several competing process support paraigms exist, all trying to tackle the nee for more process flexibility (e.g., aaptive processes [3,4,5] or case hanling [6]). urthermore, there exists no metho for systematically comparing the change frameworks provie by existing process-support technologies. This, in turn, makes it ifficult for PAIS engineers to assess the maturity an change capabilities of those technologies. onsequently, this often leas to wrong ecisions an misinvestments. uring the last years we have stuie processes from ifferent application omains an elaborate the flexibility an change support features of numerous tools an approaches. ase on these experiences, in this paper we suggest a set of changes patterns an change support features to foster the comparison of existing approaches with respect to process change support. hange patterns allow for high-level process aaptations at the process type as well as the process instance level. hange support features ensure that changes are performe in a correct an consistent way, traceability is provie, an changes are facilitate for users. oth change patterns an change support features are funamental to make changes applicable in practice. inally, another contribution of this paper is the evaluation of selecte approaches/systems base on the presente change patterns an change support features. Section 2 summarizes backgroun information neee for the unerstaning of this paper. Section 3 escribes 17 change patterns an Section 4 eals with 6 crucial change support features. ase on this, Section 5 evaluates ifferent approaches from both acaemia an inustry. Section 6 iscusses relate work an Section 7 conclues with a summary. 2 ackgrouns A PAIS is a specific type of information system which allows for the separation of process logic an application coe. At run-time the PAIS orchestrates the processes accoring to their efine logic. Workflow Management Systems (e.g., Staffware [1], APT [3], WASA [5]) an ase-hanling Systems (e.g., lower [1,6]) are typical technologies enabling PAIS. or each business process to be supporte a process type represente by a process schema S has to be efine. In the following, a process schema is represente by a irecte graph, which efines a set of activities the process steps an control connections between them (i.e., the preceence relations between these activities). Activities can either be atomic or contain a sub process (i.e., a reference to a process schema S ) allowing for the hierarchical ecomposition of a process schema. In ig. 1a, for example, process schema consists of six activities: Activity A is followe by activity in the flow of control, whereas an can be processe in parallel. Activities A to are atomic, an activity constitutes a sub process with own process schema S2. ase on a process

3 rom: AiS 2007, LNS 4495 Springer-Verlag erlin Heielberg schema S, at run-time new process instances I 1,...,I n can be create an execute. Regaring process instance I 1 from ig. 1a, for example, activity A is complete an activity is activate (i.e., offere in user worklists). Generally, a large number of process instances might run on a particular process schema. PAIS must be able to cope with change. In general, changes can be triggere an performe at two levels the process type an the process instance level (cf. ig. 1b) [2]. Schema changes at the type level become necessary to eal with the evolving nature of real-worl processes (e.g., to aapt to legal changes). Ahoc changes of single instances are usually performe to eal with exceptions, resulting in an aapte instance-specific process schema. Type (Sub-) Schema S2 Schema Without hange (a) Instance A complete activate Instance Instance I2 Instance I3 hanges at the Instance With hange (b) hanges at the Type A Instance change schema evolution I5 I4 A change propagation I5 I4 ig. 1. ore oncepts 3 hange Patterns In this section we escribe 17 characteristic patterns we ientifie as relevant for control flow changes (cf. ig. 2). Aaptations of other process aspects (e.g., ata or resources) are outsie the scope of this paper. hange patterns reuce the complexity of process change (like esign patterns in software engineering reuce system complexity [7]) an raise the level for expressing changes by proviing abstractions which are above the level of single noe an ege operations. onsequently, ue to their lack of abstraction, low level change primitives (a noe, elete ege, etc.) are not consiere to be change patterns an thus are not covere in this section. As illustrate in ig. 2, we ivie our change patterns into aaptation patterns an patterns for preefine changes. Aaptation patterns allow moifying the schema of a process type (type level) or a process instance (instance level) using high-level change operations. Generally, aaptation patterns can be

4 384. Weber, S. Rinerle an M. Reichert applie to the whole process schema or process instance schema respectively; they o not have to be pre-planne, i.e., the region to which the aaptation pattern is applie can be chosen ynamically. y contrast, for preefine changes, at buil-time, the process engineer efines regions in the process schema where potential changes may be performe uring run-time. or each pattern we provie a name, a brief escription, an illustrating example, a escription of the problem it aresses, a couple of esign choices, remarks regaring its implementation, an a reference to relate patterns. esign hoices allow for parametrization of patterns keeping the number of istinct patterns manageable. esign choices which are not only relevant for particular patterns, but for a whole pattern category, are escribe only once at the category level. Typically, existing approaches only support a subset of the esign choices in the context of a particular pattern. We enote the combination of esign choices supporte by a particular approach as a pattern variant. HANG PATTRNS AAPTATION PATTRNS (AP) Pattern Name Scope Pattern Name Scope AP1: Insert ragment (*) I / T AP8: mbe ragment in Loop I / T AP2: elete ragment I / T AP9: Parallelize ragment I / T AP3: Move ragment I / T AP10: mbe ragment in onitional ranch I / T AP4: Replace ragment I / T AP11: A ontrol epenency I / T AP5: Swap ragment I / T AP12: Remove ontrol epenency I / T AP6: xtract Sub I / T AP13: Upate onition I / T AP7: Inline Sub I / T PATTRNS OR PRIN HANGS (PP) Pattern Name Scope Pattern Name Scope PP1: Late Selection of ragments I / T PP3: Late omposition of ragments I / T PP2: Late Moeling of ragments I / T PP4: Multi-Instance Activity I / T I Instance, T Type (*) A process fragment can either be an atomic activity, an encapsulate sub process or a process (sub) graph ig. 2. hange Patterns Overview 3.1 Aaptation Patterns Aaptation patterns allow to structurally change process schemes. xamples inclue the insertion, eletion an re-orering of activities (cf. ig. 2). ig. 3 escribes general esign choices vali for all aaptation patterns. irst, each aaptation pattern can be applie at the process type or process instance level (cf. ig. 1b). Secon, aaptation patterns can operate on an atomic activity, an encapsulate sub process or a process (sub-)graph (cf. ig. 3). We abstract from this istinction an use the generic concept process fragment instea. Thir, the effects resulting from the use of an aaptation pattern at the instance level can be permanent or temporary. A permanent instance change remains vali until completion of the instance (unless it is unone by a user). y contrast, a temporary instance change is only vali for a certain perio of time (e.g., one loop iteration) (cf. ig. 3).

5 rom: AiS 2007, LNS 4495 Springer-Verlag erlin Heielberg esign hoices for Aaptation Patterns A. What is the scope of the respective pattern? 1. The respective pattern can be applie at the process instance level 2. The respective pattern can be applie at the process type level. Where oes a respective change pattern operate on? (*) 1. On an atomic activity 2. On a sub process 3. On a process sub-graph. What is the valiity perio of the change? 1. The change can be of temporary nature 2. The change can be of permanent nature (*) esign hoice is only vali for AP1-AP10 esign hoice Sub esign hoice Instance I A G Z Atomic Activity Sub Graph Instance I Temporary hange 1st loop iteration 2n loop iteration ig. 3. esign hoices for Aaptation Patterns We escribe four selecte aaptation patterns in more etail. These four patterns allow for the insertion, eletion, movement, an replacement of process fragments in a given process schema. The Insert ragment pattern (cf. ig. 4a) can be use to a process fragments to a process schema. In aition to the general options escribe in ig. 3, one major esign choice for this pattern (esign hoice ) escribes the way the new process fragment is embee in the respective schema. There are systems which only allow to serially insert a fragment between two irectly succeeing activities. y contrast, other systems follow a more general approach allowing the user to insert new fragments between two arbitrary sets of activities [3]. Special cases of the latter variant inclue the insertion of a fragment in parallel to another one or the association of the newly ae fragment with an execution conition (conitional insert). The elete ragment pattern, in turn, can be use to remove a process fragment (cf. ig 4b). No aitional esign choices exist for this pattern. ig. 4b epicts alternative ways in which this pattern can be implemente. The Move ragment pattern (cf. ig. 5a) allows to shift a process fragment from its current position to a new one. Like for the Insert ragment pattern, an aitional esign choice specifies the way the fragment can be embee in the process schema afterwars. Though the Move ragment pattern coul be realize by the combine use of AP1 an AP2 (Insert/elete ragment), we introuce it as separate pattern as it provies a higher level of abstraction to users. The latter also applies when a process fragment has to be replace by another one. This change is capture by the Replace ragment pattern (cf. ig. 5b). We have only escribe the most relevant aaptation patterns. Aitional patterns we ientifie are: swapping of activities (AP5), extraction of a sub process from a process schema (AP6), inclusion of a sub process into a process schema (AP7), embeing of an existing process fragment in a loop (AP8),

6 386. Weber, S. Rinerle an M. Reichert a) Pattern AP1: Insert ragment escription: A process fragment is ae to a process schema. xample: or a particular patient an allergy test has to be ae ue to a rug incompatibility. Problem: In a real worl process a task has to be accomplishe which has not been moele in the process schema so far. esign hoices (in aition to the ones in ig. 3):. How is the aitional process fragment embee in the process schema? 1. is inserte between 2 irectly succeeing activities (serial insert) 2. is inserte between 2 activity sets (insert between noe sets) a) Without aitional conition (parallel insert) b) With aitional conition (conitional insert) If x>0 x>0 A A A A A A else serialinsert parallelinsert conitionalinsert Implementation: The insert aaptation pattern can be realize by transforming the high level insertion operation into a sequence of low level change primitives (e.g., a noe, a control epenency). b) Pattern AP2: elete ragment escription: A process fragment is elete from a process schema. xample: or a particular patient no computer tomography is performe ue to the fact that he has a cariac pacemaker (i.e., the computer tomography activity is elete). Problem: In a real worl process a task has to be skippe or elete. A A Implementation: Several options for implementing the elete pattern exist: (1) The fragment is physically elete (i.e., corresponing activities an control eges are remove from the process schema), (2) the fragment is replace by one or more null activities (i.e., activities without associate activity program) or (3) the fragment is embee in a conitional branch with conition false (i.e., the fragment remains part of the schema, but is not execute). ig. 4. Insert (AP1) an elete (AP2) ragment patterns a) Pattern AP3: Move ragment escription: A process fragment is move from its current position in the process schema to another position. xample: Usually employees are only allowe to book a flight, after getting approval from the manager. or a particular process instance the booking of a flight is exceptionally one in parallel to the approval activity (i.e., the book flight activity is move from its current position to a position parallel to the approval activity). Problem: Preefine orering constraints cannot be completely satisfie for a set of activities. A A esign hoices:. How is the process fragment embee in the process schema? 1. is inserte between 2 irectly succeeing activities (serial move) 2. is inserte between 2 activity sets (move between noe sets) a) Without aitional conition (parallel move) b) With aitional conition (conitional move) Implementation: This aaptation pattern can be implemente base on Pattern AP1 an AP2 (insert / elete process fragment). Relate Patterns: Swap aaptation pattern (AP5) (not etaile in the paper) b) Pattern AP4: Replace ragment escription: A process fragment is replace by another process fragment. xample: Instea of the computer tomography activity, the -ray activity shall be performe for a particular patient. Problem: A process fragment is no longer aequate, but can be replace by another one. A A Implementation: This aaptation pattern can be implemente base on Pattern AP1 an AP2 (insert / elete process fragment). ig. 5. Move (AP3) an Replace (AP4) ragment patterns

7 rom: AiS 2007, LNS 4495 Springer-Verlag erlin Heielberg parallelization of process fragments (AP9), embeing of a process fragment in a conitional branch (AP10), aition of control epenencies (AP11), removal of control epenencies (AP12), an upate of transition conitions (AP13). A escription of these patterns can be foun in [8]. 3.2 Patterns for Preefine hanges The applicability of aaptation patterns is not restricte to a particular process part a priori. y contrast, the following patterns preefine constraints concerning the parts that can be change. At run-time changes are only permitte within these parts. In this category we have ientifie 4 patterns, Late Selection of Proces ragments (PP1), Late Moeling of ragments (PP2), Late omposition of ragments (PP3) an Multi-Instance Activity (PP4) (cf. ig. 6). The Late Selection of ragments pattern (cf. ig. 7) allows to select the implementation for a particular process step at run-time either base on preefine rules or user ecisions. The Late Moeling of ragments pattern (cf. ig. 8a) offers more freeom an allows to moel selecte parts of the process schema at run-time. urthermore the Late omposition of ragments pattern (cf. ig. 8b) enables the on-the fly composition of process fragments (e.g., by ynamically introucing control epenencies between a set of fragments). In case of Multi-Instance Activities the number of instances create for a particular activity is etermine at run-time. We o not consier multi-instance activity patterns in etail as they constitute some of the workflow patterns escribe in [9]. Multi-instance activities enable the creation of a particular process activity uring run-time. The ecision how many activity instances are create can be base either on knowlege available at buil-time or on some run-time knowlege. We o not consier multi-instances of the former kin as change pattern since their use oes not lea to change. or all other types of multi-instance activities the number of instances is etermine base on run-time knowlege which can or cannot be available a-priori to the execution of the multi-instance activity. While in the former case the number of instances can be etermine at some point uring run-time, this is not possible for the latter case. We consier multi-instance activities as change patterns too, since their ynamic creation works like a ynamic schema expansion. 4 hange Support eatures So far, we have introuce a set of change patterns, which can be use to accomplish changes at the process type an/or process instance level. However, simply counting the number of supporte patterns is not sufficient to analyze how well a system can eal with process change. In aition, change support features must be consiere to make change patterns useful in practice (cf. ig. 9). Relevant change support features inclue process schema evolution an version control,

8 388. Weber, S. Rinerle an M. Reichert Type A Pattern PP1 Pr. ragments for Implementation of A Pattern PP2 Instance Z U V S T R How to realize step for process instance? I. THN LS I LS selection base on rules of user ecisions Type A Pattern PP3 A Pattern PP4 Instance A? How shoul the execution of instance procee? ig. 6. Patterns for Preefine hanges (Overview) Pattern PP1: Late Selection of ragments escription: or particular activities the corresponing implementation (activity program or sub process moel) can be selecte uring run-time. At buil time only a placeholer is provie, which is substitute by a concrete implementation uring run-time (cf. ig. 6). xample: or the treatment of a particular patient one of several ifferent sub-processes can be selecte epening on the patient s isease. Problem: There exist ifferent implementations for an activity (incluing sub-processes), but for the selection of the respective implementation run-time information is require. esign hoices: A. How is the selection process one? 1. Automatically base on preefine rules 2. Manually by an authorize user 3. Semi-automatically: options are reuce by applying some preefine rules; user can select among the remaining options. What object can be selecte? 1. Atomic activity 2. Sub process. When oes late selection take place? 1. efore the placeholer activity is enable 2. When enabling the placeholer activity Implementation: y selecting the respective sub process or activity program, a reference to it is ynamically set an the selecte sub-process or activity program is invoke. Relate Patterns: Prerequisite for Pattern Late Moeling of ragment (PP2) ig. 7. Late Selection of ragments (PP1) change correctness, change traceability, access control an change reuse 1.As illustrate in ig. 9 the escribe change support features are not equally important for both process type level an process instance level changes. Version control, for instance, is primarily relevant for changes at the type level, while change reuse is particularly useful at the instance level [10]. 4.1 Schema volution, Version ontrol an Instance Migration In orer to support changes at the process type level, version control for process schemes shoul be supporte (cf. ig. 9). In case of long-running processes, in 1 Again we restrict ourselves to the most relevant change support features. Aitional change support features not covere in this paper are change concurrency control an change visualization.

9 rom: AiS 2007, LNS 4495 Springer-Verlag erlin Heielberg a) Pattern PP2: Late Moeling of ragments escription: Parts of the process schema have not been efine at buil-time, but are moele uring run-time for each process instance (cf. ig. 6). or this purpose, placeholer activities are provie, which are moele an execute uring run-time. The moeling of the placeholer activity must be complete before the moele process fragment can be execute. xample: The exact treatment process of a particular patient is compose out of existing process fragments at run-time. Problem: Not all parts of the process schema can be completely specifie at buil time. esign hoices: A. What are the basic builing blocks for late moeling? 1. All process fragments (incluing activities) from the repository can be chosen 2. A constraint-base subset of the process fragments from the repository can be chosen 3. New activities or process fragments can be efine. What is the egree of freeom regaring late moeling? 1. Same moeling constructs an change patterns can be applie as for moeling at the process type level (*) 2. More restrictions apply for late moeling than for moeling at the process type level. When oes late moeling take place? 1. When a new process instance is create 2. When the placeholer activity is instantiate 3. When a particular state in the process is reache (which must precee the instantiation of the placeholer activity). oes the moeling start from scratch? 1. Late moeling may start with an empty template 2. Late moeling may start with a preefine template which can then be aapte Implementation: After having moele the placeholer activity with the eitor, the fragment is store in the repository an eploye. inally, the process fragment is ynamically invoke as an encapsulate sub-process. The assignment of the respective process fragment to the placeholer activity is one through late bining. Relate Patterns: necessitates Late Selection of ragments (PP1) of the ynamically moifie fragment (*) Which of the aaptation patterns are supporte within the placeholer activity is etermine by the expressiveness of the use moeling language. b) Pattern PP3: Late omposition of ragments escription: At buil time a set of process fragments is efine out of which a concrete process instance can be compose at run time. This can be achieve by ynamically selecting fragments an aing control epenencies on the fly (cf. ig. 6). xample: Several meical examinations can be applie for a particular patient. The exact examinations an the orer in which they are performe are efine for each patient iniviually. Problem: There exist several variants of how process fragments can be compose. In orer to reuce the number of process variants to be specifie by the process engineer uring buil time, process instances are ynamically compose out of fragments. ig. 8. Late Moeling (PP2) an Late omposition of ragments (PP3) hange Support eatures hange Support eature Scope hange Support eature Scope 1: Schema volution, Version ontrol an Instance Migration T 2. y change primitives 3: orrect ehavior of Instances After hange I + T No version control Ol schema is overwritten 4: Traceability & Analysis I + T 1. Running instances are cancele 1. Traceability of changes 2. Running instances remain in the system 2. Annotation of changes Version control 3. hange Mining 3. o-existence of ol/new instances, no instance migration 5: Access ontrol for hanges I+T 4. Uncontrolle migration of all process instances 1. hanges in general can be restricte to authorize users 5. ontrolle migration of compliant process instances 2. Application of single change patterns can be restricte 2: Support for A-hoc hanges I 3. Authorizations can epen on the object to be change 1. y change patterns 6: hange Reuse I T Type, I Instance ig. 9. hange Support eatures aition, controlle migration of alreay running instances, from the ol process schema version to the new one, might be require. In this subsection we escribe ifferent existing options in this context (cf. ig. 10).

10 390. Weber, S. Rinerle an M. Reichert If a PAIS provies no version control feature, either the process esigner can manually create a copy of the process schema (to be change) or this schema is overwritten (cf. ig. 10a). In the latter case running process instances can either be withrawn from the run-time environment or, as illustrate in ig. 10a, they remain associate with the moifie schema. epening on the execution state of the instances an epening on how changes are propagate to instances which have alreay progresse too far, this missing version control can lea to inconsistent states an, in a worst case scenario, to ealocks or other errors [2]. As illustrate in ig. 10a process schema has been moifie by inserting activities an with a ata epenency between them. or instance the change is uncritical, as has not yet entere the change region. However, I2 an I3 woul be both in an inconsistent state afterwars as instance schema an execution history o not match (see [2]). Regaring I2, worst case, ealocks or activity invocations with missing input ata might occur. y contrast, if a PAIS provies explicit version control two support features can be ifferentiate: running process instances remain associate with the ol schema version, while new instances will be create on the new schema version. This approach leas to the co-existence of process instances of ifferent schema versions (cf. ig. 10b). Alternatively a migration of a selecte collection of process instances to the new process schema version is supporte (in a controlle way) (cf. ig. 10c). The first option is shown in ig. 10b where the alreay running instances, I2 an I3 remain associate with schema, while new instances (I4-I5) are create from schema (co-existence of process instances of ifferent schema versions). y contrast, ig. 10c illustrates the controlle migration of process instances. Only those instances are migrate which are compliant 2 with (). All other instances (I2 ani3) remain running accoring to. If instance migration is uncontrolle (as it is not restricte to compliant process instances) this will lea to inconsistencies or errors. Nevertheless, we treat the uncontrolle migration of process instances as a separate esign choice since this functionality can be foun in several existing systems (cf. Section 5). 4.2 Other hange Support eatures Support for A-hoc hanges: In orer to eal with exceptions PAIS must support changes at the process instance level either through high level changes in the form of patterns (cf. Section 3) or through low level primitives. Although changes can be expresse in both ways, change patterns allow to efine changes at a higher level of abstraction making change efinition easier. orrectness of hange: The application of change patterns must not lea to run-time errors (e.g., activity program crashes ue to missing input ata, ealocks, or inconsistencies ue to lost upates or vanishing of instances). 2 A process instance I is compliant with process schema S, if the current execution history of I canbecreatebaseons (for etails see [2]).

11 rom: AiS 2007, LNS 4495 Springer-Verlag erlin Heielberg Schema is overwritten (a) Type Instance Type change overwrites A Instances I2 an I3 are in inconsistent sates I2 I3?? o-existence of process instances of ifferent schema versions (b) Instance Migration (c) Type Instance Type Instance Type change results in a new schema A version A I3 I2 Instances create from ol instances remain with I5 I4 Instances create from Type change results A in a new schema version A I3 I5 I2 an the I4 migration of compliant instance Non-compliant instances ig. 10. Version ontrol ifferent criteria (see [2]) have been introuce to ensure that instances can only be upate to a new schema if they are compliant with it. Traceability an Analysis: To ensure traceability of changes, they have to be logge. or aaptation patterns the applie changes have to be store in a change log as change patterns an/or change primitives. While both options allow for traceability, change mining [11] becomes easier when the change log contains high-level information about the changes as well. Regaring patterns for preefine changes, an execution log is usually sufficient to enable traceability. In aition, logs can be enriche with more semantical information, e.g., about the reasons an context of the changes [10]. inally, change mining allows for the analysis of changes (e.g., to support continuous process improvement) [11]. Access ontrol for hanges: The support of change patterns leas to increase PAIS flexibility. This, in turn, imposes security issues as the PAIS becomes more vulnerable to misuse. Therefore, the application of changes at the process type an the process instance level must be restricte to authorize users. Access control features iffer significantly in their egree of granularity. In the simplest case, changes are restricte to a particular group of people (e.g., to process engineers). More avance access control components allow to efine restrictions at the level of single change patterns (e.g., a certain user is only allowe to insert aitional activities, but not to elete activities). In aition, authorizations can epen on the object to be change, e.g., the process schema. hange Reuse: In the context of a-hoc changes similar eviations (i.e., combination of one or more aaptation patterns) can occur more than once. As

12 392. Weber, S. Rinerle an M. Reichert it requires significant user experience to efine changes from scratch change reuse shoul be supporte. To reuse changes they must be annotate with contextual information (e.g., about the reasons for the eviation) an be memorize by the PAIS. This contextual information can be use for retrieving similar problem situations an therefore ensures that only changes relevant for the current situation are presente to the user [12,10]. Regaring patterns for preefine changes, reuse can be supporte by making historical cases available to the user an by saving frequently re-occurring instances as templates. 5 hange Patterns an hange Support in Practice In this section we evaluate approaches from both acaemia an inustry regaring their support for change patterns as well as change features. or acaemic approaches the evaluation has been mainly base on literature. In cases where it was unclear whether a particular change pattern or change feature is supporte or not, the respective research groups were aitionally contacte. The evaluate acaemic approaches are APT[3], WI [13], Pockets of lexibility [14], Worklets/xlets [4,15], Rlow [12,10], MOV [16], HOON [17], an WASA [5]. In respect to commercial systems only such systems have been consiere for which we have hans on experience as well as a running system installe. This allowe us to test the change patterns an change features. As commercial systems Staffware [1] an lower [6] were consiere. valuation results are summarize in ig. 11. A etaile escription of the evaluate approaches can be foun in [8]. If a change pattern or change support feature is not supporte at all, the respective table entry will be labele with -. Otherwise, it escribes the exact pattern variants as supporte by listing all available esign choices. In case no esign choices exist for a particular change pattern, which is supporte, the respective table entry is simply labele with +. Partial support is labele with. As an example take change pattern PP1 of the Worklet/xlet approach [4,15]. The string A[1,2], [1,2], [2] inicates that esign choices A, an are supporte. urther, it shows for every esign choice the exact options available (e.g., for esign choice A, Options 1 an 2 are supporte). In particular an aaptation pattern will be only consiere as being provie, if the respective system supports the pattern irectly, i.e., base on one high-level change operation. Of course, aaptation patterns can be always expresse by means of a set of basic change primitives (like a noe, elete noe, a ege, etc.). However, this is not the iea behin aaptation patterns. Since process schema changes (at the type level) base on these moification primitives are supporte by almost each process eitor, this is not sufficient to qualify for pattern support. y contrast, the support of high-level change operations allows introucing changes at a higher level of abstraction an consequently hies a lot of the complexity from the user. Therefore changes can be performe in a more efficient an less error prone way. In aition, in orer to qualify as an aaptation pattern the application of the respective change operations must not be restricte to preefine regions in the process.

13 rom: AiS 2007, LNS 4495 Springer-Verlag erlin Heielberg Several of the aaptation patterns (e.g., AP3 or AP4) can be implemente by applying a combination of the more basic patterns AP1, AP2, AP10 an AP11. However, a given approach will only qualify for a particular aaptation pattern, if it supports this pattern irectly (i.e., it offers one respective change operation). Note that missing support for aaptation patterns oes not necessarily mean that no run-time changes can be performe. As long as feature 2 is supporte a-hoc changes to running process instances are possible (for etails see [8]). In general, if a respective approach provies support for preefine change patterns like for instance late moeling of process fragments (PP1) or late selection of process fragments (PP2) the nee for structural changes of the process schema can be ecrease making feature 3 less crucial. The evaluation of selecte approaches shows that there exists no single system which supports all change patterns an features (cf. Table 11). In particular, none of the approaches provies both aaptation patterns an preefine change patterns, which woul allow aressing a much broaer process spectrum. While preefine change patterns allow to reuce the nee for structural changes uring run-time by proviing more flexible moels, aaptation patterns allow for structural changes which cannot be pre-planne. In aition, they make changes more efficient, less complex an less error-prone through proviing high-level change operations. Pattern/ eature APT / Rlow AP1 AP2 AP3 A[1, 2], [1,2,3], [1,2], [1, 2] A[1, 2], [1,2,3], [1,2] A[1, 2], [1,2,3], [1,2], [1, 2] AP4 WI hange Patterns an hange Support Pockets of lexibility Acaemic Worklets / xlets hange Patterns Aaptation Patterns ommercial MOV HOON WASA Staffware lower A[2], [1], [2], [1,2] A[2], [1], [2] A[2], [1], [2] A[2], [1], [2] PP1 PP2 A[1], [2], [1,2] Preplanne hange Patterns A[1,2], [2], [2], [1,2] A[1,2], [1,2], [2] A[1,2], A[1,2], [1,2], [2] [1,2], [2] A[1], [1], [3], [1,2] PP3 PP hange eatures 1 3, 5 3, 5 3 3, 5 3, 4 1, 2, , 2, , 2, 3 1, 3 1, 2, 3 1, 2, 3 1, 3 1, 2, 3 1 1, 2, 3 1, 2, 3 * (*) lower supports Option 2 an 3 of feature 4 only for process instance changes, but not for process type changes ig. 11. hange Patterns an hange Support eatures in Practice

14 394. Weber, S. Rinerle an M. Reichert 6 Relate Work Patterns were first use to escribe solutions to recurring problems by h. Alexaner, who applie patterns to escibe best practices in architecture [18]. Patterns also have a long traition in computer science. Gamma et al. applie the same concepts to software engineering an escribe 23 patterns in [7]. In the area of workflow management, patterns have been introuce for analyzing the expressiveness of process moeling languages (i.e., control flow patterns [9]). In aition, workflow ata patterns [19] escribe ifferent ways for moeling the ata aspect in PAIS an workflow resource patterns [20] escribe how resources can be represente an utilize in workflows. The introuction of workflow patterns has significant impact on the esign of PAIS an has contribute to the systematic evaluation of PAIS an process moeling stanars. However, to evaluate the powerfulness of a PAIS regaring its ability to eal with changes, the existing patterns are important, but not sufficient. In aition, a set of patterns for the aspect of workflow change is neee. urther, the egree to which control flow patterns are supporte provies an inication of how complex the change framework uner evaluation is. In general, the more expressive the process moeling language is (i.e., the more control flow an ata patterns are supporte), the more ifficult an complex changes become. In [21] exception hanling patterns which escribe ifferent ways for coping with exceptions are propose. In contrast to change patterns, exception hanling patterns like Rollback only change the state of a process instance (i.e., its behavior), but not its schema. The patterns escribe in this paper o not only change the observable behavior of a process instance, but aitionally aapt the process structure. or a complete evaluation of flexibility, both change patterns an exception hanling patterns must be evaluate. 7 Summary an Outlook In this paper we propose 17 change patterns (an escribe 8 of them in etail) an 6 change support features, which in combination allow to assess the power of a particular change framework. In aition, we evaluate selecte approaches an systems regaring their ability to eal with process changes. We believe that the introuction of change patterns complements existing workflow patterns an allows for more meaningful evaluations of existing systems an approaches. In combination with workflow patterns the presente change framework will enable (PA)IS engineers to choose process management technologies uture work will inclue change patterns for aspects other than control flow (e.g., ata or resources) an patterns for more avance aaptation policies (e.g., the accompanying aaptation of the ata flow when introucing control flow changes) as well as the evaluation of aitional systems an approaches.

15 rom: AiS 2007, LNS 4495 Springer-Verlag erlin Heielberg Acknowlegements. We woul like to thank S. Shaiq, M. Aams, M. Weske an. Han for their valuable feeback an the many fruitful iscussions, which helpe us to significantly improve this paper. References 1. umas, M., ter Hofstee, A., van er Aalst, W. (es.): Aware Information Systems. Wiley Publishing, hichester (2005) 2. Rinerle, S., Reichert, M., aam, P.: orrectness criteria for ynamic changes in workflow systems a survey. ata an Knowlege ngineering 50, 9 34 (2004) 3. Reichert, M., aam, P.: APT flex supporting ynamic changes of workflows without losing control. JIIS 10, (1998) 4. Aams, M., ter Hofstee, A.H.M., mon,., v..aalst, W.M.: A service-oriente implementation of ynamic flexibility in workflows. In: oopis 06 (2006) 5. Weske, M.: Workflow management systems: ormal founation, conceptual esign, implementation aspects. University of Münster, Germany, Habil Thesis (2000) 6. van er Aalst, W., Weske, M., Grünbauer,.: ase hanling: A new paraigm for business process support. ata an Knowlege ngineering. 53, (2005) 7. Gamma,., Helm, R., Johnson, R., Vlissies, J.: esign Patterns: lements of Reusable Object-Oriente Software. Aison-Wesley, New ork (1995) 8. Weber,., Rinerle, S., Reichert, M.: Ientifying an evaluating change patterns an change support features in process-aware information systems. Technical Report Report No. TR-TIT-07-22, TIT, Univ. of Twente, The Netherlans (2007) 9. van er Aalst, W.M.P., ter Hofstee, A.H.M., Kiepuszewski,., arros, A.P.: Workflow patterns. istribute an Parallel atabases 14, 5 51 (2003) 10. Rinerle, S., Weber,., Reichert, M., Wil, W.: Integrating process learning an process evolution - a semantics base approach. In: PM 2005, pp (2005) 11. Günther,., Rinerle, S., Reichert, M., van er Aalst, W.: hange mining in aaptive process management systems. In: oopis 06, pp (2006) 12. Weber,., Wil, W., reu, R.: Rlow: nabling aaptive workflow management through conversational cbr. In: R 04, Mari, pp (2004) 13. asati,.: Moels, Semantics, an ormal Methos for the esign of Workflows an their xceptions. Ph thesis, Milano (1998) 14. Saiq, S., Saiq, W., Orlowska, M.: A framework for constraint specification an valiation in flexible workflows. Information Systems 30, (2005) 15. Aams,M.,terHofstee,A.H.M.,mon,.,v..Aalst,W.M.:ynamican extensible exception hanling for workflows: A service-oriente implementation. Technical Report PM enter Report PM-07-03, PMcenter.org (2007) 16. Th. Herrmann, A.-W., Scheer, H.W. (es.): Verbesserung von Geschftsprozessen mit flexiblen Workflow-Management-Systemen - Verffentlichungen es orschungsprojektes MOV Physica Verlag, Heielberg (1998) 17. Han,.: Software Infrastructure for onfigurable Workflow Systems. Ph thesis, Univ. of erlin (1997) 18. Alexaner,., Ishikawa, S., Silverstein, M. (es.): A Pattern Language. Oxfor University Press, New ork (1977) 19. Russell, N., ter Hofstee, A., mon,., van er Aalst, W.: Workflow ata patterns. Technical Report IT-TR , Queenslan Univ. of Techn. (2004) 20. Russell, N., ter Hofstee, A., mon,., van er Aalst, W.: Workflow resource patterns. Technical Report WP 127, inhoven Univ. of Technology (2004) 21. Russell, N., van er Aalst, W.M., ter Hofstee, A.H.: xception hanling patterns in process-aware information systems. In: AiS 06 (2006)