Olegas Vasilecas, Diana Kalibatiene and Dejan Lavbič. 2016. Rule- and context-based dynamic business process modelling and simulation, Journal of Systems and Software (JSS), 122, pp. 1 - 15.

Abstract

The traditional approach used to implement a business process (BP) in today’s information systems (IS) no longer covers the actual needs of the dynamically changing business. Therefore, a necessity for a new approach of dynamic business process (DBP) modelling and simulation has arisen. To date, existing approaches to DBP modelling and simulation have been incomplete, i.e. they lack theory or a case study or both. Furthermore, there is no commonly accepted definition of BDP. Current BP modelling tools are suitable almost solely for the modelling and simulation of a static BP that strictly prescribes which activities, and in which sequence, to execute. Usually, a DBP is not defined strictly at the beginning of its execution, and it changes under new conditions at runtime. In our paper, we propose six requirements of DBP and an approach for rule- and context-based DBP modelling and simulation. The approach is based on changing BP rules, BP actions and their sequences at process instance runtime, according to the new business system context. Based on the proposed approach, a reference architecture and prototype of a DBP simulation tool were developed. Modelling and simulation were carried out using this prototype, and the case study shows correspondence to the needs of dynamically changing business, as well as possibilities for modelling and simulating DBP.

Keywords

Dynamic business process, Business rules, Context, Simulation, Business process modelling

1 Introduction

Nowadays business processes (BPs) are dynamic by nature and affected by a dynamically changing environment. Examples of such dynamic changes of environment include regulatory adaptations (e.g. change in raw material prices), market evolution (e.g. stock price change), changes in customer behaviour (e.g. rapid change in customer needs), process improvement, policy shifts and exceptions.

Traditional approaches used to model, simulate and implement BP no longer cover the actual needs of business, which should be more dynamic in order to be able to compete. There is thus a necessity to conduct research in the field of DBP modelling, simulation and their automation in information systems (IS), and to propose new solutions that correspond to a dynamic business’s needs. Moreover, a business needs tools which support such DBP and allow it to find answers for the question of what-if.

Consequently, these business needs can be transformed into the requirements for research as follows:

  • proposing a DBP modelling approach,
  • proposing a DBP simulation approach,
  • proposing an architecture and implementing it into a BP simulation engine.

Existing approaches to DBP modelling and simulation are incomplete because they are lacking in theory and in terms of implementation. Furthermore, there is no commonly accepted definition of DBP. Current BP modelling and simulation tools are suitable for modelling and simulation of a static BP that strictly predicts which activities, and in which sequence, to execute (e.g. Simprocess or ARIS 9.7). In the best case, today’s tools and proposed methods allow for changing BP by executing different configurations of the BP, as in (Xiao et al. 2011), or using templates for modifying BP activity sequences, as in (Eijndhoven, Iacob, and Ponisio 2008). This means that the majority of existing tools and approaches require strict specification of a BP, and unexpected sequences of BP activities cannot be included during a BP execution. Therefore, modelling and simulation of a dynamically changing BP, e.g. dynamic processes, is a topical, relevant and challenging task.

As advocated in a number of papers, e.g. in (Mejia Bernal et al. 2010; Hermosillo, Seinturier, and Duchien 2010a; Milanovic, Gasevic, and Rocha 2011), business rules are applicable for ensuring the dynamicity of BP.

The main opportunities of using business rules to ensure dynamicity of BP lie in the following: each activity in a process is selected according to the defined conditions at BP runtime; choice of activity content; and representing the changing DBP context. However, as presented in the works related to this paper, there is no complete approach or tool for rule- and context-based DBP modelling and simulation – i.e. none of the analysed tools (IBM Websphere (v.7.0 2014)1, Simprocess (v 2015)2, Simul83, AccuProcess4 and ARIS 9.75), which are widely used for BP modelling and simulation, supports changing business rules during the simulation of DBP. Some approaches, like (Hermosillo, Seinturier, and Duchien 2010b), describe BP dynamicity using BP pointcuts, where adaptations can be made, or changes of BP are available in new instances of the BP, but not at the same instance, like in (Xiao et al. 2011).

In our paper, we propose an approach for rule- and context-based DBP modelling and simulation. We define DBP as a process with a not-fixed sequence of activities, i.e. activities for execution in the BP are selected according to the rule conditions and changing context of the environment. Moreover, activities can be changed at the same BP instance runtime. We propose an approach for changing a sequence of BP activities, their content, rules for selecting activities in DBP and the context of a DBP at process runtime. Based on the proposed approach, the reference architecture and a prototype of a DBP simulation tool was developed. A case study was carried out using this prototype, and it shows correspondence between the obtained results and needs of the dynamically changing business, as well as possibilities for DBP modelling and simulating.

The balance of this paper is organized as follows. Section 2 presents related works on DBP. Section 3 presents our proposed requirements of rule- and context-based DBP. Section 4 describes our approach for rule- and context-based DBP modelling and simulation and reference architecture for the rule- and context-based DBP modelling and simulation system (DRBPSimul). Section 5 presents a case study of an ordering system. Section 6 presents results and discussion. Finally, Section 7 concludes the paper.

3 Requirements for a rule- and context-based DBP

According to the related works, we propose requirements for a DBP. To start, we present the definition of the context used in the requirements:

  1. Context refers to internal context and external context.
  2. An external context is a set of variables and context rules (i.e. business rules which define some policy of the environment) defining a particular state of the environment.
  3. An internal context is a current state of system resources.
  4. An internal context change is a change to a current state of system resources.
  5. An external context change is a change to a current state of environment, like a change of variables describing environment or context rules.

The list of our proposed requirements for a DBP is as follows:

  1. A DBP should not have a predefined sequence of activities.
    1. Every subsequent activity should be selected according to predefined rules and a context. Therefore, every subsequent BP instance may differ from the previous instance of the same BP.
    2. If there is no activity for further execution at a DBP runtime, it should be possible to do the following:
      1. to terminate the execution of a DBP instance;
      2. to define a new activity and concerning rules for a DBP instance execution.

Activities in DBP are selected according to the external and internal context and rules, i.e. DBP have no predefined sequence of activities. The advantage of implementing this requirement is that we increase dynamicity of a process. For example, in e-health process activities are selected according to the user’s context, which describes user’s health state. When a user’s context changes, like blood pressure or temperature, necessary activities, like drug supply, should be selected for execution immediately. Moreover, in many cases, it is difficult or impossible to predict all possible changes of a context and predefine possible sequences of activities. Contrary to DBP, static processes have predefined sequence of activities and could be adopted only in predefined places of a process instance, like variation points.

  1. Context-based dynamicity:
    1. It should be possible to define an external and internal context.
    2. A DBP should react to the change in a context.

As presented in Section 2.2, external context is expressed through variables and rules. Internal context describes state of system resources. A DBP should react to the changes of a context. The advantage of implementing this requirement is that at process instance runtime context can change and process should be adopted to those changes immediately at process instance runtime.

  1. Rule-based dynamicity:
    1. It should be possible to define new business rules and to change or delete existing business rules at BP runtime.
    2. A DBP should react to the changes in business rules at process instance runtime.
    3. Every next activity in a DBP should be selected according to the predefined business rules.

Activities in DBP are selected according to the predefined rules. However, if it is necessary, additional rules can be defined or existing rules can be changed at process instance runtime. The advantage of implementing this requirement is that at instance runtime rules, expressing constraints of application domain, laws, etc., could change and, according to this requirement, it should be possible to implement those changes at process instance runtime.

  1. Any role involved in DBP execution should support DBP instance change, i.e. change of activities or their sequence, according to the context and rules at runtime with possibly low latency.

According to this requirement, a DBP implementing system should react to changes immediately after those changes comes in force. Moreover, any role, involved in DBP execution, should support any process instance changes. The advantage of implementing this requirement is that the change of a context or business rules influences selection of the next activity immediately after a change comes in force at process instance runtime. Implementation of this requirement allows rising a process dynamicity. Otherwise, if we implement changes during next process instance, a process becomes static. The majority of analysed approaches (see Sections 2 and 6) do not meet this requirement.

  1. Before selecting the next activity, the historical data of instances execution of the same DBP should be analysed and the selected next activity should not cause execution of an unacceptable sequence of activities, regarding to early gained experience.
    1. The historical data of each DBP instance execution should be stored in a log file.
    2. It should be possible to define executed instances of a DBP as a “good practice” and a “bad practice”.
    3. It should be possible to select a suitable instance, labelled as a “good practice”, from the historical data for repeated execution.
    4. Time, cost, etc. values should be calculated and stored for each executed DBP instance.
    5. Instances named “bad instance”" should not be executed.

This requirement describes that before executing any DBP instance, a historical data of this DBP should be analysed. The analysis of historical data allows determining so called “good” and “bad” instances of the same process. A “good instance” means the one that requires minimum resources, is completed within an optimal to this process period and the goal of the process is reached. A “bad instance” means that it utilise too many resources for its execution and/or do not reach a goal. Therefore, such instance is unacceptable. Moreover, during historical data analysis, it can be found what conditions, i.e. state of current context, leads to such “bad instances”. This analysis is necessary to prevent execution of “bad instances” and to propose suitable alternative sequence of activities for execution.

  1. A DBP execution and selection of the next activity at DBP runtime should be based on goal-oriented approach.

In our paper, a goal-oriented approach means that we are focusing on achieving some state of the system, but not on the way of how to achieve some state of the system. Therefore, we implement goal through rules, which together with check, if we approaching to a goal or not, are used to select each next activity and/or define new activity for execution. Advantage of implementing this requirement is that we achieve more dynamicity and strong goal-orientation of BP.

We argue that a BP, which meets all presented requirements, is a DBP. Implementing all six requirements provides more freedom in BP modelling. However, this freedom can be constrained by adding business rules, which depend on the requirements of application domain. Moreover, the advantage of the implementing the proposed requirements is that it allows DBP being a goal-oriented.

4 A rule- and context-based DBP modelling and simulation approach

According to the DBP requirements defined in the previous section, we propose an approach for rule- and context-based DBP modelling and simulation. The approach is based on the fact that at BP runtime it is possible to change rules, BP actions and their sequence, depending on the new business system context.

The main idea of the approach is presented in Figure 4.1. The DBP simulation approach consists of these steps:

  1. The historical data of the same BP, e.g. already executed instances of the same BP, are analysed. This activity is useful for distinguishing successful and unsuccessful BP simulation instances and using them for the current instance simulation.
  2. The context of the DBP simulation is analysed.
  3. According to the context, the set of rules are chosen for further selection of BP activities.
  4. According to the rules, an activity is selected for execution. Here we may have three cases, as follows:
    1. one activity – in this case the selected activity is executed and we go to the first step;
    2. several activities – in this case the activity with greater priority is executed and we go to the first step; and
    3. no activities – in this case the process is finished or we have to define a new or select another activity for execution.
An approach for rule- and context-based DBP simulation

Figure 4.1: An approach for rule- and context-based DBP simulation

Moreover, an activity uses resources during its execution. For more about resources see (Vasilecas et al. 2015).

In accordance with the proposed rule- and context-based DBP simulation approach, a system architecture – DRBPSimul – was developed. It is presented in Figure 4.2.

The architecture of the rule- and context-based DBP modelling and simulation system (DRBPSimul)

Figure 4.2: The architecture of the rule- and context-based DBP modelling and simulation system (DRBPSimul)

The proposed architecture (Figure 4.2) consists of these components:

  • Simulation Interface is responsible for the collaboration of the user with the Simulation engine;
  • Simulation engine is responsible for the simulation execution. It works as described in the model presented in Figure 4.1. The Simulation engine consists of these components:
    • The Activity engine, which is responsible for the processing of the selected activities;
    • The Rule engine, which is responsible for the checking of the selected rules that correspond to the existing context. The Activity engine uses the Rule engine to select the activities for execution;
    • The Context engine, which is responsible for the context analysis and definition of the process instance context. The Rule engine uses the Context engine to determine which rules correspond to the existing context and should thus be used for the selection of the activities for future execution;
    • The Results analyser, which is used to analyse historical data of the executed BP instances. The activity engine uses the Results analyser to check if the selected activity for the execution causes execution of a not-acceptable sequence of activities.
  • Storages (Rule base, Activities storage, Context storage, Historical data storage and Resources) are responsible for storage of rules, activities, context, historical data and resources used for simulation execution and results analysis. Storages handle the persistence factors of entities (e.g., rules, activities, context, historical data and resources) by providing an interface to create, delete, and obtain entities and their templates for new entities by reference or query.
  • Manager (Resources Manager, Rules Manager and Activities Manager) – responsible for managing (i.e. creating, deleting and getting entities their templates for new entities by reference or query) of entities through Management Interface.
  • External context is a sensor used by Context storage to determine an external context for process instance simulation.
  • Resources are resources used for the execution of BP. This component is used to determine an internal context state and save it in Context storage. Moreover, Resources are used by the Activity engine to process selected activities. For more about resources see (Kalibatiene, Vasilecas, and Rusinaite 2015; Vasilecas et al. 2015).

Before the simulation, Manager (see Figure 4.2) should load activities, rules and resources into Storages and allocate resources to activities. When the loading is over, an Analyst or Business user can start the simulation process. The simulation process is managed through Simulation Interface. E.g., the simulation process can be started, stopped, continued and modified. The simulation process is executed and managed by Simulation engine, which gets commands from Simulation Interface. When Simulation engine gets a message from the interface to start a simulation process, it sends a message to Context Engine and Rule Engine to check existing context and to determine which rules correspond to it and should be used for the selection of the activities for future execution. After the corresponding rules are determined, Simulation engine sends a message to Activity Engine to choose an activity according to the rules. Moreover, Activity Engine uses Results Analyser to analyse the Historical data of the same DBP. When activity is selected, it is executed by Activity Engine. After executing a selected activity, Activity Engine sends results of an activity execution to Simulation engine, which in turn repeats the process from determining current context and selecting next activity for the execution.

The proposed architecture belongs to the reference level, i.e. it is independent of the implementation solutions, which could be used to implement it. For example, a service-oriented approach (SOA) may be used for the implementation of the architecture, like in (Hermosillo 2012; Marrella and Mecella 2011; Xiao et al. 2011; Berkane, Seinturier, and Boufaida 2012); the authors use a SOA for rules execution. This does not mean that other ways of implementing DBP are neglected.

5 A case study of rule- and context-based DBP simulation

The proposed rule- and context-based DBP simulation approach was realised using Microsoft technologies: Visual Studio 201216, C#17 and .NET platform 4.518. Windows Presentation Foundation19 components were used to develop the user interface. Microsoft technologies were used because the university where the prototype of the system was developed has licenses for those Microsoft products. An implementation, named DRBPSimul, and an experiment were developed in Information Systems Research Laboratory20.

An ordering system was used in this case study for demonstrating the rule- and context-based DBP simulation tool. A simulation example is presented in Figure 5.1.

A simulation example of ordering process

Figure 5.1: A simulation example of ordering process

The description of Figure 5.1 is presented as follows:

  1. The first column on the left presents the list of events, which were detected and processed during the simulation. In the presented case, the event “Receive an order” and its triggered process are presented in Figure 5.1.

  2. The second column on the left presents the graph of the simulated process instance. The activities presented in yellow are those executed in this process instance simulation; those in grey are activities which are not executed in this process instance simulation but which were simulated earlier in previous process instances; those in green are activities that have just been simulated. As can be seen from Figure 5.1, the presentation of a graph depends on the executed activities. If all simulated instances are the same, we will have a sequential chain of activities. However, if simulated instances differ, we will have a graph that is coloured differently than the one presented in Figure 5.1.

  3. The third column on the left presents the process context and its change during execution of activities. The process context can change after execution of each activity. The simulation log is located below the process context.

  4. The fourth column on the left presents simulation “Watch points”.

It is possible to change rules and context during the simulation. Rules could be changed through the Activities tab at the Body placeholder, as presented in Figure 5.2. After changing a rule, we can continue a simulation of a BP instance.

Example of changing the rules

Figure 5.2: Example of changing the rules

The proposed conceptual architecture presented in Figure 4.2 is now partially realised as follows:

  • Simulation Interface, Activity Engine, Rule Engine, Rule base, Activities storages and Manager are realised;
  • Context Engine, Context Storage and Resources are realised partially;
  • Results Analyser and Historical data storage are least realized.

6 Main results and discussion

During our research, we obtained the following results.

The analysis of the related works, including our research conducted on BP modelling and simulation, allows us to formulate a theoretical background of a dynamic business process (DBP), as well as to propose an extended definition and to specify requirements of the rule- and context-based DBP.

Based on the proposed DBP requirements, an approach for rule- and context-based DBP modelling and simulation is presented. The main idea of the approach is that during the simulation of the same BP instance a rule set and a context can be changed. Those changes can be observed within the same BP instance immediately after changes come into force, e.g. activities and their sequence can be changed at runtime. Consequently, DBP has no predefined sequence of activities, i.e. each subsequent activity for execution is selected after observing an existing context and rules. Moreover, new activities can be created and existing activities can be modified at DBP runtime.

To implement the proposed approach, a reference architecture for rule- and context-based DBP modelling and simulation tool was developed. The architecture presents the main components and their relationships, which are necessary to support the proposed approach. Our contribution is this: unlike in the majority of the analysed research, our proposed architecture is not domain-specific. Moreover, components and their relationships are organized in such a way as to support rule- and context-based DBP modelling and simulation. Additional components, such as Results analyser linked to Historical data storage, are also included into the architecture in order to add intelligent functionality to the approach.

The proposed architecture was implemented into the rule- and context-based DBP modelling and simulation prototype, and an experiment on ordering system business processes was carried out. An experiment shows that instances for the same BP differ in appearance of specific activities when a different context and rules are applied (see Figure 5.1). Moreover, we can observe the dynamicity of a BP.

The comparison of the proposed approach with the other analysed approaches according to the proposed requirements (see Section 3) is presented in Table 6.1. The first column lists the 11 approaches considered, including our proposed approach. Each approach is identified by a sequance number and a reference to the publication/s as follows:

  • A1 = CEVICHE, (Hermosillo, Seinturier, and Duchien 2010b; Hermosillo, Seinturier, and Duchien 2010a), where implementation includes some examples of code,
  • A2, (Eijndhoven, Iacob, and Ponisio 2008), where implementation includes prototype and case study with some examples of code,
  • A3, (Bui et al. 2013), where implementation includes prototype with test cases from the homecare domain,
  • A4, (Yao et al. 2012), where implementation includes prototype, print screens, from on-boarding customers to IT outsourcing,
  • A5, (Döhring, Zimmermann, and Godehardt 2010), where implementation includes prototype and print screens,
  • A6 = PROVOP, (Hallerbach, Bauer, and Reichert 2008b; Hallerbach, Bauer, and Reichert 2008c; Hallerbach, Bauer, and Reichert 2008a; Hallerbach, Bauer, and Reichert 2010), where implementation includes prototype and print screens from automotive and healthcare industries,
  • A7 = DYPROTO, (Wörzberger and Heer 2011; Heer, Briem, and Woerzberger 2009), where implementation includes prototype, without examples,
  • A8 = RoDP, (Hu, Wu, and Chen 2013), where implementation includes example with Mathlab simulation experiment,
  • A9 = BPFAMA (Boukhebouze et al. 2011), where implementation includes prototype, print screens and example of purchase order,
  • A10, (Mejia Bernal et al. 2010), where implementation includes case study with examples,
  • A11 = Our proposed approach, where implementation includes prototype and print screens.

The other columns indicate the requirements and to what extent the given approach covers each requirement.

Table 6.1: Comparison of the eleven approaches on rule- and context-based DBP modelling and simulation
Approach
R1
R2
R3
R4
R5
R6
R2.1 R2.2 R3.1 R3.2 R3.3 R5.1 R5.2 R5.3 R5.4 R5.5
A1 No Yes, external, if defined in CEP. Does not detailed Yes/No Yes/No, in CEP No No, only when adaptation situation arises Yes No No No No Yes No
A2 No No No Yes/No Nothind said Yes Yes No No No No Yes No
A3 No Yes, external\(^{\text{B}}\) Yes Yes/No Nothind said Yes Yes Yes No No No Yes No
A4 No Yes, external\(^{\text{B}}\) Yes Yes/No Nothind said Yes Yes Yes No Yes No Yes Yes
A5 No Yes\(^{\text{C}}\) Yes Yes/No Nothind said Yes Yes No No No No Yes No
A6 No Yes\(^{\text{C}}\) Yes Yes/No Nothind said Yes Yes Yes Yes Yes/No No Yes Yes/No
A7 No No No Yes/No Nothind said Yes Yes No No No No Yes No
A8 No Yes, internal. Does not detailed Yes Yes/No Nothind said Yes Yes No No No No Yes No
A9 No No No Yes/No Nothind said Yes Yes Yes Yes/No, diagnostic phase No No Yes No
A10 No Yes, internal Yes Yes/No Nothind said Yes Yes No No No No Yes No
A11 Yes Yes, both Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes

\(^{\text{B}}\) The authors Bui et al. (2013), Yao et al. (2012) identify user-context, which can be described by a set of variables characterizing the user’s needs (i.e. time of taking medications, blood pressure, etc. in (Bui et al. 2013)). We make a presumption that it is an external context, since the most variables belongs on concrete situation (i.e. a user).

\(^{\text{C}}\) The authors Döhring, Zimmermann, and Godehardt (2010), Hallerbach, Bauer, and Reichert (2008b), Hallerbach, Bauer, and Reichert (2008c), Hallerbach, Bauer, and Reichert (2008a), Hallerbach, Bauer, and Reichert (2010) define context by context variables, and context rules are applied to define the behaviour of the process in concrete situations. They do not clearly exclude what type of context (internal or external) is defined. In most cases, it is the user’s needs. Therefore, we make a presumption that it is an external context, since most variables pertain to a concrete situation (i.e. a user).

Reviewing column-by-column, we can observe these results: the analysed approaches (except for our proposed approach) deal with the initial BP model, where sequence of process activities can be changed only in variation points according to the predefined rules.

Regarding the context, the majority of authors describe one type of context, i.e. external or internal, since, in the authors’ analysed cases, it suffices to have one type of context - though not all authors specify how to define context. The common description of a context, also used by Bui et al. (2013) and Yao et al. (2012), consists of variables and rules.

All the analysed approaches deal with rules, and their application differs. For example, in (Hermosillo, Seinturier, and Duchien 2010a; Hermosillo, Seinturier, and Duchien 2010b) the authors use rules to define complex events. The authors of the analysed approaches consider the definition of new rules, or changing or deleting existing rules, before process simulation (see R3.1 in Table 6.1). Nothing, however, is said about the possibility of changing rules at runtime and about how to react to those changes (see R3.2 in Table 6.1). Moreover, since the basic ideas of the approaches vary, the analysed approaches differ in terms of how each subsequent activity is executed in accordance with the defined rules (see R3.3 in Table 6.1). For example, in (Eijndhoven, Iacob, and Ponisio 2008) only variable segments of a process can be changed according to predefined rules. Such a view limits the degree of dynamicity of a process.

The analysis of the approaches according to process modification at runtime (see R4 in Table 6.1) shows that all approaches meet this requirement. However, authors do not show clearly how to implement this requirement.

As can be seen from Table 6.1, historical data is used only in a few approaches, like in (Yao et al. 2012), PROVOP and (Boukhebouze et al. 2011). But the usage of historical data is weak. The advantage of selecting “good practice” and “bad practice” (see R5 in Table 6.1) is not used in the analysed approaches.

Regarding the implementation, the analysis shows that the biggest part of the approaches is implemented as examples or case studies, like in (Mejia Bernal et al. 2010; Hermosillo, Seinturier, and Duchien 2010b; Hermosillo, Seinturier, and Duchien 2010a) or an automation of the proposed approach at some level, like in (Eijndhoven, Iacob, and Ponisio 2008). In half of the analysed studies, the authors present a small piece of code and some diagrams or examples from which it is difficult or impossible to determine the level of implementation of the approaches. Therefore, it is not clear which part of the method/approach is implemented. Though authors like Bui et al. (2013), Yao et al. (2012), Döhring, Zimmermann, and Godehardt (2010), PROVOP and Boukhebouze et al. (2011) present prototypes and some print screens that enhance the proposed approaches, no author presents a process simulation.

From the presented results, it can be summarized that the main difference between our proposed approach and those analysed is that ours is goal-oriented. In such a process, every next activity for execution is selected according to the context (variables and rules describing context) and business rules. The analysed approaches deal with an initial process model, which can be changed at variation points according to the new user’s needs. The main contribution of our proposed approach is that we ensure dynamicity of a process and allow implementing goal-oriented approach. Contrary, other approaches are based on an initial process model that limits the dynamicity and BP can be changed only in predefined places in a process – e.g. variation points, like in (Eijndhoven, Iacob, and Ponisio 2008; Bui et al. 2013) or pointcuts, like in (Hermosillo, Seinturier, and Duchien 2010b; Hermosillo, Seinturier, and Duchien 2010a).

Moreover, in our approach, during the process simulation, we can change rules and react to the changing of context at runtime – something that is not supported in all the analysed approaches.

Our proposed approach meets all defined requirements, unlike other approaches, which meet only a particular set of requirements. This can be explained by the fact that other studies aim to solve slightly different types of domain-specific problems – that is, the majority of approaches are targeted at meeting the requirements of particular application domains. In contrast, our approach is general and is not dependent on a specific domain.

Implementing all six requirements provides more freedom in changing the BP than is possible in the analysed approaches. However, this freedom can be constrained by rules. Our developed prototype and obtained results show that the proposed method is implementable. Moreover, as can be seen in Figure 5.1, for a BP with the same goal different sets of activities occur when different rules are applied when different contexts appear.

Below we try to explain each requirement in term of our presented case study.

  1. Implementation of the first requirement can be seen in Figure 5.1. Our process has no predefined sequence of activities. Each activity is selected according to the context and rules. It can be seen that different instances of the same process has different sequence of activities.

  2. Implementation of the second requirement can be seen in Figure 5.1 column three (Process Context). In this case, we are working with internal context, i.e. resources.

  3. Implementation of the third requirement can be seen in Figure 5.2, where we present a window with rules, which can be changed during paused BP simulation.

  4. The forth requirement is implemented manually, when it is necessary to implement changes, like a rule change, we manually pause the simulation, change the rule and continue the simulation of the same instance.

  5. The fifth requirement is implemented by adding rules, which prevent execution of “bad instances”.

  6. The sixth requirement (goal-orientation) is implemented through defined rules, which example can be seen in Figure 5.2.

7 Conclusions and future works

This analysis of the concept of a dynamic business process (DBP) shows that there is no commonly accepted DBP definition and neither is there a complete approach or tool for DBP modelling and simulation. Current BP modelling and simulation tools are mainly suitable for modelling and simulating a static BP which strictly predicts activities and the sequence of their execution. Today’s tools and proposed methods allow us, at best, to change BP by presenting several different instances of the changed BP or presenting templates for BP execution. This means that the majority of existing tools and approaches require strict BP specification of and that an unexpected sequence of BP activities cannot be executed.

In this paper, we proposed a new approach for rule- and context-based DBP modelling and simulation. Our main contribution is that we have proposed the requirements for a DBP and according to those requirements developed a model for rule- and context-based goal-oriented DBP modelling and simulation. The main idea of the approach is that during the simulation of the same BP instance, rules and a context can be changed and those changes influence selection of the next activity for execution. Thus, activities and their sequence will be changed within the same instance immediately after rules and context changes come into force at runtime. Consequently, the DBP has no strict activities and their sequence, i.e. each subsequent activity for execution, is selected after observing an existing context and rules regarding to the defined goal.

According to the proposed approach, an architecture for rule- and context-based DBP modelling and simulation is put forth. This architecture was implemented into a prototype and the case study shows correspondence to the needs of the dynamically changing business, as well as possibilities for modelling and simulating DBP.

The topics for future research are as follows:

  1. Refining and improving a set of requirements.
    1. Improving an implementation of a goal-oriented approach in DBP simulation.
    2. A requirement, that a DBP should meet requirements of a regular BP, should be analysed in more details and implemented. This type of requirements concerns with correctness and consistency of a DBP. Now, this kind of requirements is implemented manually. For example, Analyst is responsible for process correctness, since, he defines necessary rules and should ensure that deadlocks not arise.

  2. Historical data of simulations should be saved in the historical data storage and appropriate algorithms should be created and used to automate analysis of the stored historical data. During historical data analysis, conditions, i.e. state of current context, which lead to “bad instances” should be found.

  3. Improving the developed prototype and making its detailed description.

  4. Simulating parallel DBP with shared resources.

References

Aalst, W. M. P. van der, M. Pesic, and H. Schonenberg. 2009. “Declarative Workflows: Balancing Between Flexibility and Support.” Computer Science - Research and Development 23 (2): 99–113. doi:10.1007/s00450-009-0057-9.

Adams, Michael. 2010. “Dynamic Workflow.” In Modern Business Process Automation, 123–45. Springer, Berlin, Heidelberg. doi:10.1007/978-3-642-03121-2_4.

Alférez, G. H., V. Pelechano, R. Mazo, C. Salinesi, and D. Diaz. 2014. “Dynamic Adaptation of Service Compositions with Variability Models.” Journal of Systems and Software 91 (May): 24–47. doi:10.1016/j.jss.2013.06.034.

Bastinos Šaša, Ana, and Dejan Lavbič. 2015. “SPARQL-Based Framework for Semantically-Based Event Processing.” In Proceedings of the 25th International Conference on Information Modelling and Knowledge Bases (EJC 2015), 282–96. Maribor, Slovenia.

Berkane, M.L., L. Seinturier, and M. Boufaida. 2012. “A Pattern-Based Architecture for Dynamically Adapting Business Processes.” The Fourth International Conferences on Pervasive Patterns and Applications (PATTERNS 2012), 29–35.

Bizagi. 2016. “Understanding Ad Hoc Processes.” http://help.bizagi.com/bpm-suite/en/index.html?understanding_ad_hoc_processes.htm.

Blaze Software. 1999. “Blaze Advisor.” Technical White Paper, version 2.5. http://condor.depaul.edu/jtullis/documents/Blaze_Advisor_Tech.pdf.

Boukhebouze, M., Y. Amghar, A.-N. Benharkat, and Z. Maamar. 2011. “A Rule-Based Approach to Model and Verify Flexible Business Processes.” International Journal of Business Process Integration and Management 5 (4): 287–307. doi:10.1504/IJBPIM.2011.043389.

Bui, Duc Viet, Maria Eugenia Iacob, Marten van Sinderen, and Alireza Zarghami. 2013. “Achieving Flexible Process Interoperability in the Homecare Domain Through Aspect-Oriented Service Composition.” In Enterprise Interoperability, 50–64. Lecture Notes in Business Information Processing. Springer, Berlin, Heidelberg. doi:10.1007/978-3-642-36796-0_6.

Chandy, K. Mani, and W. Roy Schulte. 2009. Event Processing: Designing IT Systems for Agile Companies. 1 edition. New York: McGraw-Hill Education.

Charfi, A., B. Schmeling, A. Heizenreder, and M. Mezini. 2006. “Reliable, Secure, and Transacted Web Service Compositions with AO4BPEL.” In 2006 European Conference on Web Services (ECOWS’06), 23–34. doi:10.1109/ECOWS.2006.32.

Charfi, Anis, and Mira Mezini. 2004. “Aspect-Oriented Web Service Composition with AO4BPEL.” In Proceedings of European Conference on Web Services (ECOWS 2004), 3250:168–82.

Chiu, Dickson, Qing Li, and Kamalakar Karlapalem. 2000. “A Logical Framework for Exception Handling in ADOME Workflow Management System.” In Advanced Information Systems Engineering, 110–25. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg. doi:10.1007/3-540-45140-4_9.

Coutaz, Joëlle, James L. Crowley, Simon Dobson, and David Garlan. 2005. “Context Is Key.” Communications of ACM 48 (3): 49–53. doi:10.1145/1047671.1047703.

Döhring, M., B. Zimmermann, and E. Godehardt. 2010. “Extended Workflow Flexibility Using Rule-Based Adaptation Patterns with Eventing Semantics.” In, 1:195–200.

Döhring, Markus, and Birgit Zimmermann. 2011. “vBPMN: Event-Aware Workflow Variants by Weaving BPMN2 and Business Rules.” In Enterprise, Business-Process and Information Systems Modeling, 332–41. Lecture Notes in Business Information Processing. Springer, Berlin, Heidelberg. doi:10.1007/978-3-642-21759-3_24.

Dustdar, Schahram, Thomas Hoffmann, and Wil van der Aalst. 2005. “Mining of Ad-Hoc Business Processes with TeamLog.” Data & Knowledge Engineering 55 (2): 129–58. doi:10.1016/j.datak.2005.02.002.

Eijndhoven, T. v, M. E. Iacob, and M. L. Ponisio. 2008. “Achieving Business Process Flexibility with Business Rules.” In 2008 12th International IEEE Enterprise Distributed Object Computing Conference, 95–104. doi:10.1109/EDOC.2008.23.

Geebelen, K., E. Kulikowski, E. Truyen, and W. Joosen. 2010. “A MVC Framework for Policy-Based Adaptation of Workflow Processes: A Case Study on Confidentiality.” In 2010 IEEE International Conference on Web Services, 401–8. doi:10.1109/ICWS.2010.81.

Gong, Yiwei, and Marijn Janssen. 2012. “From Policy Implementation to Business Process Management: Principles for Creating Flexibility and Agility.” Government Information Quarterly, Government Information Networks, 29 (January): S61–S71. doi:10.1016/j.giq.2011.08.004.

Göser, Kevin, Martin Jurisch, Hilmar Acker, Ulrich Kreher, Markus Lauer, Stefanie Rinderle-Ma, Manfred Reichert, and Peter Dadam. 2007. “Next-Generation Process Management with ADEPT2.” In BPM’07 Demo Proceedings, 3–6. CEUR-WS.org Workshop Proceedings. CEUR-WS. http://dbis.eprints.uni-ulm.de/89/.

Hagen, C., and G. Alonso. 2000. “Exception Handling in Workflow Management Systems.” IEEE Transactions on Software Engineering 26 (10): 943–58. doi:10.1109/32.879818.

Hallerbach, Alena, Thomas Bauer, and Manfred Reichert. 2008a. “Context-Based Configuration of Process Variants.” In 3rd International Workshop on Technologies for Context-Aware Business Process Management (TCoB 2008), 31–40. http://dbis.eprints.uni-ulm.de/199/.

———. 2008b. “Managing Process Variants in the Process Lifecycle.” In 10th Int’l Conf. on Enterprise Information Systems (ICEIS’08), 154–61. http://dbis.eprints.uni-ulm.de/193/.

———. 2008c. “Issues in Modeling Process Variants with Provop.” In Business Process Management Workshops, 56–67. Lecture Notes in Business Information Processing. Springer, Berlin, Heidelberg. doi:10.1007/978-3-642-00328-8_6.

———. 2010. “Capturing Variability in Business Process Models: The Provop Approach.” Journal of Software Maintenance and Evolution-Research and Practice 22 (6-7): 519–46. doi:10.1002/smr.491.

Heer, Thomas, Christoph Briem, and Rene Woerzberger. 2009. “Workflows in Dynamic Development Processes.” In Business Process Management Workshops, edited by D. Ardagna, M. Mecella, and J. Yang, 17:266–77.

Hermosillo, Gabriel. 2012. “Towards Creating Context-Aware Dynamically-Adaptable Business Processes Using Complex Event Processing - Semantic Scholar.” PhD Thesis, Lille: Université des Sciences et Technologie de Lille.

Hermosillo, Gabriel, L. Seinturier, and L. Duchien. 2010a. “Using Complex Event Processing for Dynamic Business Process Adaptation.” In 2010 IEEE International Conference on Services Computing, 466–73. doi:10.1109/SCC.2010.48.

Hermosillo, Gabriel, Lionel Seinturier, and Laurence Duchien. 2010b. “Creating Context-Adaptive Business Processes.” In Service-Oriented Computing - Icsoc 2010, Proceedings, edited by P. P. Maglio, M. Weske, J. Yang, and M. Fantinato, 6470:228–42.

Hildebrandt, Thomas T., and Raghava Rao Mukkamala. 2011. “Declarative Event-Based Workflow as Distributed Dynamic Condition Response Graphs.” In Electronic Proceedings in Theoretical Computer Science, 69:59–73. doi:10.4204/EPTCS.69.5.

Hofstede, Artur H. M, Will M. P. Aalst, Michael Adams, and Nick Rusell. 2010. Modern Business Process Automation: YAWL and Its Support Environment. Berlin, Heidelberg: Springer. https://link.springer.com/book/10.1007%2F978-3-642-03121-2.

Hu, Guangchang, Budan Wu, and Junliang Chen. 2013. “Dynamic Adaptation of Business Process Based on Context Changes: A Rule-Oriented Approach.” In Service-Oriented Computing – ICSOC 2013 Workshops, 492–504. Lecture Notes in Computer Science. Springer, Cham. doi:10.1007/978-3-319-06859-6_43.

Kalibatiene, D., O. Vasilecas, and T. Rusinaite. 2015. “Implementing a Rule-Based Dynamic Business Process Modelling and Simulation.” In 2015 Open Conference of Electrical, Electronic and Information Sciences (eStream), 1–4. doi:10.1109/eStream.2015.7119486.

Kwan, M. M., and P. R. Balasubramanian. 1997. “Dynamic Workflow Management: A Framework for Modeling Workflows.” In Proceedings of the Thirtieth Hawaii International Conference on System Sciences, 4:367–76 vol.4. doi:10.1109/HICSS.1997.663409.

Laznik, Jurij, and Matjaž Branko Jurič. 2013. “Context Aware Exception Handling in Business Process Execution Language.” Information and Software Technology 55 (10): 1751–66. doi:10.1016/j.infsof.2013.04.001.

Li, S., X.D. Shao, Z.H. Zhang, and J. Chang. 2012. “Dynamic Workflow Modeling Based on Product Structure Tree.” Applied Mathematics and Information Sciences 6 (3): 751–57.

Marrella, Andrea, and Massimo Mecella. 2011. “Continuous Planning for Solving Business Process Adaptivity.” In Enterprise, Business-Process and Information Systems Modeling, 118–32. Lecture Notes in Business Information Processing. Springer, Berlin, Heidelberg. doi:10.1007/978-3-642-21759-3_9.

Mejia Bernal, Jose F., Paolo Falcarin, Maurizio Morisio, and Jia Dai. 2010. “Dynamic Context-Aware Business Process: A Rule-Based Approach Supported by Pattern Identification.” In Proceedings of the 2010 ACM Symposium on Applied Computing, 470–74. SAC ’10. New York, NY, USA: ACM. doi:10.1145/1774088.1774186.

Milani, Fredrik, Marlon Dumas, Naved Ahmed, and Raimundas Matulevičius. 2016. “Modelling Families of Business Process Variants: A Decomposition Driven Method.” Information Systems 56 (March): 55–72. doi:10.1016/j.is.2015.09.003.

Milanovic, M., D. Gasevic, and L. Rocha. 2011. “Modeling Flexible Business Processes with Business Rule Patterns.” In 2011 IEEE 15th International Enterprise Distributed Object Computing Conference, 65–74. doi:10.1109/EDOC.2011.25.

Muehlen, Michael zur. 2004. Workflow-Based Process Controlling. Foundation, Design, and Application of Workflow-Driven Process Information Systems. Berlin: Logos Verlag.

Müller, Robert, Ulrike Greiner, and Erhard Rahm. 2004. “AgentWork: A Workflow System Supporting Rule-Based Workflow Adaptation.” Data & Knowledge Engineering 51 (2): 223–56. doi:10.1016/j.datak.2004.03.010.

Nunes, V. T., C. M. L. Werner, and F. M. Santoro. 2011. “Dynamic Process Adaptation: A Context-Aware Approach.” In Proceedings of the 2011 15th International Conference on Computer Supported Cooperative Work in Design (CSCWD), 97–104. doi:10.1109/CSCWD.2011.5960061.

Pesic, M., and W. M. P. van der Aalst. 2006. “A Declarative Approach for Flexible Business Processes Management.” In Business Process Management Workshops, 169–80. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg. doi:10.1007/11837862_18.

Pourshahid, A., D. Amyot, A. Shamsaei, G. Mussbacher, and M. Weiss. 2012. “A Systematic Review and Assessment of Aspect-Oriented Methods Applied to Business Process Adaptation.” Journal of Software 7 (8): 1816–26. doi:10.4304/jsw.7.8.1816-1826.

Pucher, Max J. 2010. “Agile-, AdHoc-, Dynamic-, Social-, or Adaptive BPM.” Welcome to the Real (IT) World! https://isismjpucher.wordpress.com/2010/03/30/dynamic-vs-adaptive-bpm/.

Rao, Jinghai, Peep Küngas, and Mihhail Matskin. 2006. “Composition of Semantic Web Services Using Linear Logic Theorem Proving.” Information Systems, The Semantic Web and Web Services, 31 (4): 340–60. doi:10.1016/j.is.2005.02.005.

Rosemann, M., and J. Recker. 2006. “Context-Aware Process Design: Exploring the Extrinsic Drivers for Process Flexibility.” In, 236:149–58.

Sadiq, Shazia W., Olivera Marjanovic, and Maria E. Orlowska. 2000. “Managing Change and Time in Dynamic Workflow Processes.” International Journal of Cooperative Information Systems 09 (01n02): 93–116. doi:10.1142/S0218843000000077.

Saidani, Oumaima, and Selmin Nurcan. 2007. “Towards Context Aware Business Process Modelling - Semantic Scholar.” In Workshop on Business Process Modeling, Development, and Support (BPMDS’07).

Šaša, Ana, and Olegas Vasilecas. 2011. “Ontology-Based Support for Complex Events.” Elektronika Ir Elektrotechnika, no. 7: 83–88.

Traverso, Paolo, and Marco Pistore. 2004. “Automated Composition of Semantic Web Services into Executable Processes.” In The Semantic Web – ISWC 2004, 380–94. Lecture Notes in Computer Science. Springer, Berlin, Heidelberg. doi:10.1007/978-3-540-30475-3_27.

Valença, G., C. Alves, V. Alves, and N. Niu. 2013. “A Systematic Mapping Study on Business Process Variability.” International Journal of Computer Science & Information Technology 5 (1): 1–21.

Vasilecas, O., D. Kalibatiene, A. Rima, I. Birzniece, and P. Rudzajs. 2015. “A Resource Model for the Rule-Based Dynamic Business Process Modelling and Simulation.” In 29th Annual European Simulation and Modelling Conference 2015, ESM 2015, 36–41.

Weber, Barbara, Manfred Reichert, Stefanie Rinderle-Ma, and Werner Wild. 2009. “Providing Integrated Life Cycle Support in Process-Aware Information Systems.” International Journal of Cooperative Information Systems 18 (01): 115–65. doi:10.1142/S0218843009001999.

Weske, M. 2001. “Formal Foundation and Conceptual Design of Dynamic Adaptations in a Workflow Management System.” In Proceedings of the 34th Annual Hawaii International Conference on System Sciences, 10 pp. doi:10.1109/HICSS.2001.927082.

Wörzberger, R., and T. Heer. 2011. “DYPROTO - Tools for Dynamic Business Processes.” International Journal of Business Process Integration and Management 5 (4): 324–43. doi:10.1504/IJBPIM.2011.043391.

Xiao, Z., D. Cao, C. You, and H. Mei. 2011. “Towards a Constraint-Based Framework for Dynamic Business Process Adaptation.” In 2011 IEEE International Conference on Services Computing, 685–92. doi:10.1109/SCC.2011.95.

Yao, W., S. Basu, J. Li, and B. Stephenson. 2012. “Modeling and Configuration of Process Variants for on-Boarding Customers to IT Outsourcing.” In 2012 IEEE Ninth International Conference on Services Computing, 415–22. doi:10.1109/SCC.2012.32.

  1. http://www-03.ibm.com/software/products/en/modeler-advanced.↩

  2. http://simprocess.com↩

  3. http://www.simul8.com↩

  4. http://bpmgeek.com/accuprocess-business-process-modeler↩

  5. http://www.softwareag.com/corporate/products/new_releases/aris9/more_capabilities/default.asp↩

  6. http://en.wikipedia.org/wiki/Dynamic_business_process_management↩

  7. http://www.gartner.com/it-glossary/dynamic-business-process-management-bpm↩

  8. http://whatis.techtarget.com/definition/dynamic-BPM-business-process-management↩

  9. As defined by Muehlen (2004), a workflow is a specific representation of a process which is designed in such a way that the formal coordination mechanisms between activities, applications, and process participants can be controlled by an information system, by the so-called workflow management system - i.e. a workflow is a formal, or implementation-specific, representation of a BP.↩

  10. Case-based reasoning (CBR) is the way of solving new problems based on the solutions of similar past problems: users are supported to adapt processes by taking into account how previously similar events have been managed (Marrella and Mecella 2011).↩

  11. http://www.drools.org/↩

  12. http://openl-tablets.sourceforge.net/↩

  13. http://openrules.com/↩

  14. http://www-01.ibm.com/software/integration/business-rule-management/jrules-family/↩

  15. http://www.fico.com/en/products/fico-blaze-advisor-decision-rules-management-system↩

  16. https://www.visualstudio.com/↩

  17. https://code.msdn.microsoft.com/site/search?f%5B0%5D.Type=ProgrammingLanguage& f%5B0%5D.Value=C%23&f%5B0%5D.Text=C%23↩

  18. https://www.microsoft.com/en-us/download/details.aspx?id=30653↩

  19. https://msdn.microsoft.com/en-us/library/aa970268%28v=vs.110%29.aspx↩

  20. Information Systems Research Laboratory, Institute of Applied Computer Science, Faculty of Fundamental Sciences, Vilnius Gediminas Technical University, http://fm.vgtu.lt/faculties/departments/institute-of-applied-computer-science/departaments/information-systems-research-laboratory/73139↩