Dynamic Business Process Management based on Process Change Patterns

Transcription

1 2007 International Conference on Convergence Information Technology Dynamic Business Process Management based on Process Change Patterns Dongsoo Kim 1, Minsoo Kim 2, Hoontae Kim 3 1 Department of Industrial and Information System Engineering, Soongsil University, 511 Sangdo-Dong, Dongjak-Gu, Seoul, Korea dskim@ssu.ac.kr 2 Department of Systems Management Engineering, Pukyong National University, San 100, Yongdang-dong, Nam-gu, Busan, Korea minsky@pknu.ac.kr 3 Department of Industrial & Systems Engineering, Daejin University San 11-1, Sundan-dong, Poch'on-si, Kyonggi-do, , Korea hoontae@daejin.ac.kr Abstract In order to provide life cycle support of business process management, a framework for managing process improvement and dynamic process changes is required. In this paper, we propose a new approach to managing business process changes in dynamic business environment based on business process change patterns. We identify and categorize business process change patterns that occur recurrently based on workflow patterns. Several issues on managing process versions are discussed and a new version management method for managing process changes more flexibly based on the process change patterns is explained in detail. In order to maximize the flexibility in executing various process versions we propose a mechanism for abstract process execution with runtime encapsulation of a business process in dynamic business environment. In addition, we propose a useful mechanism to support dynamic process version selection with process promotion and demotion to support abstract process execution. This paper contributes to managing various business process changes efficiently and enhances the flexibility of BPM system. 1. Introduction BPM (Business Process Management) systems are used to support the efficient execution and effective management of business processes in a variety of application domains. BPM is defined as follows: Supporting business processes using methods, techniques, and software to design, enact, control, and analyze operational processes involving humans, organizations, applications, documents and other sources of information [2]. When compared with classical definitions of WFM (Workflow Management) BPM provides a broader set of functionalities and support of the whole process life-cycle [2][3]. Aalst et al. provided the relationship between WFM and BPM based on the BPM lifecycle concept [2]. Thus, a lot of BPM researchers and solution vendors are addressing the importance of the life cycle support of business processes. The BPM lifecycle includes the whole phases in supporting business process management. It is composed of several stages such process design, process execution, and process control. Although, there are a variety of definitions on the composition of BPM lifecycle [2][11][12], all of them include process analysis and improvement stage. That is to say, BPM life cycle management emphasizes not only defining and executing business processes, but also improving business processes after analyzing the results of process execution. This means that a framework for managing process improvement and dynamic process changes is urgently required in order to provide lifecycle support of BPM system. In general, business process improvement involves modification of an existing process and deploying and executing the changed process. Although it is important to support managing business process changes, not much attention or research on this issue has been given. In this paper, we propose a framework /07 $ IEEE DOI /ICCIT

2 for supporting business process improvement and managing business process changes based on the process change patterns in dynamic environment. We identify frequently occurring business process change patterns based on workflow patterns which were proposed by Workflow Patterns initiative led by Aalst and Hoffstede [1]. The process change patterns are classified into three types: activity split/change type, activity extend/delete type, and activity merge/change type. Based on the concept of process change patterns, we propose a scheme for managing process changes in dynamic business environment using BPM systems. Traditional version management methods which have been originally devised for version management of software or XML documents do not fit well for managing business process changes because of the specific requirements of the BPM domain, which will be discussed in detail in Section 4. Therefore, we propose a new method for managing various process versions in a more dynamical and flexible way. The rest of the paper is organized as follows; in the next section we review pattern based approach to BPM and suggest the concept of process change pattern. Then, three types of business process change patterns are proposed and a process designer supporting these change patterns is presented in Section 3. A new version management method based on the process change patterns is described in Section 4. Section 5 concludes this research. 2. Pattern based approach to BPM The concept of pattern has been used frequently in software engineering and other areas. Riehle, D. and Züllighoven, H. (1995) define pattern as the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts [14]. Aalst et al. proposed 20 workflow patterns for modeling business processes. The patterns are classified as Basic Control-Flow Patterns, Advanced Branching and Synchronization Patterns, Structural Patterns, Multiple Instance Patterns [1]. Recently, they added 23 patterns to the original 20 patterns which results in 43 control patterns [17]. Business process improvement is a systematic approach to help organizations to archive significant changes in the way they do business [16]. Foster, F. (2006) describes business process improvement pattern as an attempt to describe successful solutions to model operational business process improvement steps [8]. He defines a business process improvement pattern as an abstract form of a recurring instance of a process modification step used in a business process improvement activity. Foster explain his business process improvement pattern framework using performance indicators such as time, quality, cost, and flexibility, and he suggested dimension of process improvement such as process, organization, data, and object. He defined about 50 business process improvement patterns based on these four dimensions. Table 1 illustrates representative patterns he provided in his article. Table 1. Business process improvement patterns Improvement types Description A single process step can be added or eliminated in a business process. A resource instance can be added to or removed from a business process. An IT system can be added to or eliminated from a business process. An instance of an object can be added to or eliminated from the input or output of a business process. Aalst and Jablonski use the term change for both dealing with unexpected events, and handling modifications of the process model because of changing conditions [3]. We suggest that the term process change rather than process improvement. There are two types of process change, which include change for improvement and change for adaptation. A business process can be modified due to the results of process improvement efforts. But also a business process can be modified due to the change in business environment such as official announcement of a new regulation. In order to incorporate all kinds of the business processes modifications including process improvement and process change for the adaptation to a changing environment, we propose a concept of 1155

3 business process change pattern. The business process change patterns described in this paper has been devised based on the workflow patterns suggested by Aalst et al [1]. 3. Business process change patterns Workflow patterns provided by Aalst et al. seek to enumerate all of the possible business process modeling patterns. We define business process change patterns as transformation pattern between an existing process model (P) and the changed version (P ) of the process model. We identify frequently occurring business process change patterns, which are listed in Table 2. The process change patterns are classified into three types: activity split/change type, activity extend/delete type, and activity merge/change type. Table 2. List of business process change patterns Classification Pattern Name - Sequential Split Pattern - And Split Pattern Activity - XOR Split Pattern Split/Change - OR Split Pattern - N-out-of-M OR Split Pattern Activity Merge/Change Activity Extend/Delete - Activity Content Change Pattern - Activity Change Propagation Pattern - Activity Position Adjustment Pattern - Activity Parallelization Pattern - Activity De-Parallelization Pattern - Sequential Merge Pattern - AND Merge Pattern - Activity Delete/Detour Pattern - Activity Sequential Insert/Propagation Pattern - Activity Parallel Insert Pattern - Activity Replace/Detour Pattern Split Pattern, XOR Split Pattern, OR Split Pattern, and N-out-of-M OR Split Pattern Figure 1 illustrates a very simple process change pattern named Sequential Split Pattern. In this change pattern, a single activity A is decomposed into a series of activities A1, A2, and A3 that are linked sequentially. This type of change pattern can occur due to a variety of reasons and we can see this change pattern frequently with other split type change patterns such as And Split Pattern, OR Split Pattern and so on. A complex activity can be decomposed into several relatively simple and manageable activities using this pattern. Figure 1. Sequential Split Pattern In N-out-of-M OR Split Pattern, a single activity A is split into multiple activities using And routing nodes (AND-Split and n-synchronizing-merge) or x- Multi-Choice routing nodes (x-multi-choice-split and n-synchronizing-merge). More than n activities out of m activities should be finished to execute the next activity. Upper diagram in Figure 2 shows activity A is split into multiple activities A 1, A 2 and A m that are to be executed in parallel. And if n activities out of A 1, A 2 and A m are finished, the next activity can start. Lower diagram shows x-multi- Choice-Split and n-synchronizing-merge which incorporate A 1, A 2 and A m. x-multi-choice- Split node means x activities out of A 1, A 2 and A m should start in parallel. In this case x is greater than or equal to n and smaller than or equal to m. In the following sections, we describe each type of process change in detail and illustrate only several representative change patterns due to the space limitation. 3.1 Activity Split/Change Activity Split/Change type means process change patterns where an existing activity of a business process is split or decomposed into multiple activities. This type include Sequential Split Pattern, And Figure 2. N-out-of-M OR Split Pattern 3.2 Activity Merge/Change While change patterns of Activity Split/Change type involves change from a simple process structure to a more complex structure, business process change patterns of Activity Merge/Change type do not involve any complication of a process structure. This 1156

4 change type include Activity Content Change Pattern, Activity Change Propagation Pattern, Activity Position Adjustment Pattern, Activity Parallelization Pattern, Activity De-Parallelization Pattern, Sequential Merge Pattern, and AND Merge Pattern Figure 3 illustrates Activity Parallelization Pattern that involves a parallelization of sequential activities. This change pattern is frequently used to reduce the execution time of a business process by executing sequential activities simultaneously. Figure 3. Activity Parallelization Pattern Figure 4 illustrates Activity De-Parallelization Pattern where activities enclosed with parallel routing nodes such as AND-Split/Merge, XOR-Split/Merge and so on are re-defined as sequential activities. For example, in diagram (a) of Figure 4 AND parallel activity A and B are changed to sequential activities (B C, or C B). In diagram (b), 2 activities out of 3 activities enclosed with XOR-Split and XOR-Merge are de-parallelized. is not used temporally then it can remain in the changed process model by including an XOR Dummy activity for the purpose of activity reuse of B in the future (refer to diagram (b)). Figure 5. Activity Delete/Detour Pattern Figure 6 shows several example changes of Parallel Activity Insert Pattern. In this figure, a sequential process model composed of A, B, and C can be changed to a new process model which has parallel routing nodes. Between various split nodes and merge nodes a new activity D is inserted (refer to diagram (a), (b), and (c)). Diagram (d) illustrates that a new activity D is inserted to the existing process model that has AND routing nodes. Figure 4. Activity De-Parallelization Pattern 3.3 Activity Extend/Delete Activity Extend/Delete type means change patterns that add a new activity to the existing activities in order to reflect new business logic or delete some activities due to the change in business logic. This type includes Activity Delete/Detour Pattern, Sequential Activity Insert/Propagation Pattern, Parallel Activity Insert Pattern, and Activity Replace/Detour Pattern. Figure 5 illustrates Activity Delete/Detour Pattern which is a very simple and basic change pattern. Activities that are valid no longer should be removed from a business process model. In the figure, activity B is deleted (refer to diagram (a)). If the activity B Figure 6. Parallel Activity Insert Pattern 3.4 Process designer supporting change patterns We have developed a process designer supporting process change patterns as an Eclipse plug-in. We extended the BPEL (Business Process Execution Language) project [19] that support WS-BPEL (Web Services Business Process Execution Language). WS- BPEL or BPEL is a vendor-neutral specification being developed by OASIS [13]. We provide templates for supporting the process change patterns listed in Table

5 new version management mechanism based on the process change patterns. 4.1 Version management of a business process A version is a changed state of a specific target or concept from an existing state or condition. The term version management, frequently used in computer software area, means a methodology for dealing with changes systematically as time goes by [9]. A version model is usually defined as a version graph as shown in Figure 9 [4]. V 1 (p) revision V 2 (p) revision revision V 3 (p) variant V 4 (p) Figure 7. Process change by AND Split pattern Figure 7 illustrates how a process model can be changed using our process designer. In this example, an activity named invokeloanassessor need to be composed two AND parallel activities invokeassetassessor and invokepotentialassessor. Users can easily apply the change pattern (in this example, AND Split pattern) with the help of a wizard function (refer to Figure 8) provided by the process designer without re-designing the changed process model manually. Figure 8. Process redesign using a wizard function 4. Version management based on process change patterns To support process change in BPM system, an efficient mechanism for controlling business process versions is required. In this section, we discuss several issues on process version management and propose a Figure 9. Process version graph There are two types of versions; revision and variant [7]. A revision is a newly created version by amending an existing version. In Figure 9, V 2 (p) is a revision to V 1 (p). A variant relation is made when two or more versions are derived from an existing version. The two versions V 3 (p) and V 4 (p), generated from V 2 (p), have a variant relation. Traditional version management methods have been devised to manage software versions. There are two kinds of software version management methods; Source Safe method and CVS (Concurrent Versions System or Concurrent Versioning System) [9][5]. Source Safe uses a "lock-modify-unlock" model that is also called check-out and check-in model. CVS is an edit and merge kind of source control system. Therefore, it is not required to check out files before working on. Recently, as XML documents are becoming used in various areas, there have been several studies on version management of XML documents. Traditional text line focused version management methods include SCCS (Source Code Control System) and RCS (Revision Control System) [15][18]. These methods are not efficient for object-oriented structured documents [6]. Chien et al. propose UBCC (Usefulness-Based Copy Control) as an efficient method for managing structured XML documents. Existing version management methods used to manage process versions in BPM domain are heavily dependent on traditional version management mechanism such as check-out and check-in, and delta approach. The most frequently used version 1158

6 management method for dealing with process versions is check-out and check-in model. This method stores entire process model in order to create a new version of a process model, which is not efficient in perspective of storage space. In order to avoid this kind of problem the delta approach is often used. The delta means change operation to an existing process model. Traditional version management methods do not perform efficiently when managing business process changes due to the following reasons listed in Table 3, which necessitates a proper version management method for BPM system in dynamic environment. Table 3. Issues on process version management Problem Description - Existing process version management methods mainly rely on software version management methods or XML Detection document version management method. and - Semantically not meaningful changes creation such as adding comments may generate of a new a new process version. version - Therefore, a new version creation using semantics of process models is necessary. How to deploy when multiple versions coexist? New version execution control Providing templates supporting process change patterns Abstract process execution - Multiple process versions can co-exist at the time of process execution. - Which version should be deployed? - Deciding which version is to be selected and executed is required. - Monitoring and controlling multiple versions from the same process model is necessary. - Without human users interaction business process can be initiated due to the occurrence of external events. - If there are multiple versions, rules for selecting a proper process version should be established prior to process execution. - Generally a process library is provided to support designing the whole process model. - However, small-sized templates targeting a part of a process model is more useful in supporting process improvement and change. - Templates supporting process change patterns are necessary and also delta approach to dealing with changes is required. - If we manage process versions based on the process change patterns, abstract and flexible process execution can be provided. 4.2 Abstract execution of a business process We propose a new method for managing process versions based on process change patterns. The new flexible version management method is based on the run-time encapsulation of a business process model proposed by Kim et al [10]. The run-time encapsulation of a business process model, extended from nested process model, separates lower level subprocesses from an upper level process and supports dynamic and flexible process management. When process versions are controlled based on the change patterns, abstract and flexible process execution is possible. If there are multiple versions of a process, which version should be selected and executed? Traditional BPM systems usually select one of the versions prior to process execution. However, there are many cases where the proper version of a process cannot be determined in advance. For example, in case of clinical workflows in hospitals, successive activities of an initial diagnosis activity are usually determined and executed dynamically according to the result of the diagnosis activity. Figure 10 illustrates abstract execution of multiple versions of a business process. In this figure v2 version is created by applying a business process change pattern named Activity Parallelization Pattern to an existing process version v1. The first part of the two process versions are the same, so we call this part common execution block. And the second part of each version is different from each other. It is possible to execute common execution block without determining the version of the process model, that is, the selection of a process version to be executed can be deferred until the end of common execution block, when a proper version is determined according to the execution results of the common execution block. Abstract execution of a business process enhances the flexibility of BPM system and also enables efficient resource allocation in dynamic business environment combined with process promotion and demotion which is explained in Section

7 Common execution block Activity Parallelization Pattern Figure 10. Abstract process execution 4.3 Flexible execution of process versions Usually a process change involves a modification of a set of related activities. We call a set of related activities modified by a single conceptual change factor pattern block. In Figure 11 changed process model (a) has a connected pattern block after applying change pattern Activity Position Adjustment Pattern. On the contrary, changed process model (b) has two disconnected pattern blocks. However, theses two blocks constitute a logically single pattern block. process version until the end of the first common execution block. When it encounters any activity or routing node in pattern area, a proper version of a process should be determined. We propose a useful mechanism to support dynamic process version selection. Let s consider a situation where a process instance is executed within pattern area, and it is necessary to change the version of the process instance. The possibility of successful process execution and the flexibility of BPMS can be increased by supporting dynamic process version selection which requires activity rollback and compensation. The execution status of a process instance being executed within pattern area can be rolled back before the start of the pattern area using activity rollback and compensation. That is to say the activities within pattern area are rolled back and should be restated. And then the version of the process instance to be executed should be determined. Here, according to the selected version the process instance can be promoted or demoted. A process instance is promoted if a later version of a process model is selected and executed (process promotion). On the contrary, a process instance is demoted if a previous version of a process model is selected and executed (process demotion). It is expected that a BPM system supporting process promotion and demotion combined with abstract process execution enhances the flexibility of process execution and enables dynamic process management. 5. Conclusions before change Figure 11. Pattern block after change By defining pattern blocks as shown in Figure 12, we can express all the changes applied to an existing process model as a combination of pattern blocks. Figure 12. Combination of pattern blocks In this paper we call the combination of pattern blocks pattern area, which contains all of the changed part of an original process model. Outside of pattern area is composed of the original unchanged activities and routing nodes and we call this area common execution block as shown in Figure 10. BPM solution can execute a process instance without deciding a Lifecycle support of BPM solutions is becoming more and more important. In order to achieve the goals of BPM implementation it is required to support process analysis and improvement, which necessitates a framework for managing business process changes in dynamic environment. In this paper, we have presented a new approach to managing business process changes in dynamic business environment based on business process change patterns. We have addressed a concept of business process change and propose a variety of process change patterns based on Aalst s workflow patterns. We identified the 16 business change patterns and classify them into three types. Activity Split/Change type includes process change patterns where the existing activity of a business process is split or changed. Activity Merge/Change Type is contrary to Activity Split/Change Type. Finally, Activity Extend/Delete Type includes change patterns that add a new activity or delete some activities due to the change in business logic. Also, we have designed and developed a process designer supporting the process change patterns. 1160

8 We have reviewed several issues on managing process versions and proposed a new version management method for managing process changes more flexibly based on the business process change patterns. To maximize the flexibility in executing various process versions we propose a mechanism for abstract process execution with run-time encapsulation of business processes in dynamic environment. Also, we propose process promotion and demotion to support abstract process execution. We expect that our new approach to managing business process changes can contributes to efficient and effective management of business process changes for organizations adopting BPM system. They can manage their various business process changes more flexibly in dynamic business environment. A BPM system that supports abstract process execution with process promotion and demotion enhances the flexibility of process execution and enables dynamic process management. Acknowledgments This research was supported by Seoul R&BD Program. References [1] van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P., (2003), "Workflow Patterns", Distributed and parallel databases : an international journal, Vol. 14, No. 1, pp [2] van der Aalst, W.M.P., ter Hofstede, A.H.M., Weske, M., (2003), Business Process Management: A Survey, In W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske, editors, International Conference on Business Process Management (BPM 2003), LNCS 2678, pp [3] van der Aalst, W.M.P., Jablonski, S., (2000), Dealing with workflow change: identification of issues and solutions, International Journal of Computer Systems Science & Engineering, Vol. 15, No. 5, pp [4] Bae, H., et al., (2004), Document configuration control processes captured in a workflow, Computers in Industry,Vol. 53, No. 2, pp [5] Cederqvist, P., et al., Version Management with CVS, Available at [6] Chien, S-Y., Tsotras V. J., Zaniolo, C., (2001), Version Management of XML Documents, WebDB 2000, LNCS 1997, pp [7] Conradi, R., Westfechtel, B., (1998), Version models for software configuration management, ACM Computing Survey, Vol. 30, No. 2, pp [8] Forster, F., (2006), Toward a Business Process Improvement Pattern Framework, BPTrends. [9] Katz, R.H., (1990), Toward a unified framework for version modeling in engineering database, ACM Computing Surveys Vol. 22, No. 4, pp [10] Kim, Y., Kang, S.-H., Kim, D., Bae, J., Ju, K.-J., (2000) WW-flow: A Web-based Workflow Management System with Run-time Encapsulation, IEEE Internet Computing, Vol. 4, No. 3, pp [11] Klückmann, J., (2007), On the way to SOA - Business processes as a guideline, ARIS Expert Paper. [12] Netjes, M., Reijers, H.A., van der Aalst, W.M.P., (2006), FileNet s BPM life-cycle support, BPM Center Report BPM-06-07, BPMcenter.org. [13] OASIS, (2007) Web Services Business Process Execution Language Version 2.0, OASIS Standard, Available at OS.pdf. [14] Riehle, D., Züllighoven, H., (1996), Understanding and Using Patterns in Software Development, Theory and Practice of Object Systems, Vol. 2, No. 1, pp [15] Rochkind, M. J., (1975), The Source Code Control System, IEEE Transactions on Software Engineering, Vol. 1, No. 4, pp [16] Rosemann, M. (2001), Business Process Lifecycle Management, Brisbane: Queensland University of Technology. [17] Russell, N., ter Hofstede, A.H.M., van der Aalst, W.M.P., Mulyar, N., (2006), Workflow Control-Flow Patterns: A Revised View, BPM Center Report BPM [18] Tichy, W. F., (1985), RCS - A System for Version Control, Software Practice and Experience, Vol. 15, pp [19]