3.1 Systematic literature review
Understanding a rigorous procedure, SLR provides unbiased studies of the related publications, through the following steps: i) justifying the review background and setting review questions, ii) defining the search protocol of the review, including “specifying data sources” (by reviewing title and abstracts), iii) selecting primary studies based on data inclusion and exclusion criteria, iv) finalizing findings from the primary studies based on appropriate assumptions to ensure aligning with the search protocol (by regarding full text of papers), and v) discussing the validating the search process from various aspects, e.g., highly cited papers, approach most prolific researchers.
We mainly address through SLR two parts of our RQ.1 question in this paper (See Sect.
1) in two separate search questions on: (i) existing BP consolidation approaches, which are supported by merging techniques, and (ii) the extent that consolidation of BP models requires further research based on its stages. With the latter issue, we search for potential improvement lines for BP consolidation methodology. For the SLR purpose, Google Scholar is used. Primary concern in searching scientific resources is to determine the searching queries. The term “consolidation”, as defined in Sect.
1, is related to different keywords in BP management discipline, while it is new in relation to BS management in VOs. In principle, consolidation shares several ideas and concepts with BP management approaches that imply the combination of different BP models into one artifact in a certain procedure. The merge technique is mainly used in BP consolidation procedure to create a merged model [
10].
To develop a merged BP model, various parts of different BP models are indistinguishably combined into a completely new BP model, e.g., in [
13,
14]. Sometimes, a family of BP variants are merged into a so-called configurable merged model [
5], where a BP model could be further customized, e.g., [
10,
15]. Studies have suggested that the closest concepts to consolidation are integration, variability, and merging. However, integration and variability aim at exchanging information and messages without unifying the BPs, whereas our consolidation concerns with finding common parts of the models and resolving differences between them, through merging models. Thus to conduct our search, different grammatical forms of the two words “merge” (i.e., “merging” and “merged”) and “consolidation” (i.e., “consolidate”, “consolidated”, and “consolidating”) are combined with the “business process /service” (or business processes/services) and process model (or Process models).
For each query, we select the first 200 hits of the Google scholar, form 2000 to 2015 and filter them based on the titles. We consider journal papers, conference papers, and book chapters. However, we exclude duplicates as well as less than 5-page papers, and papers without citations. Furthermore, we give particular importance to cited articles and forward-check the papers that cite it, and backward-check the papers in the references thereof up to first 50 hits. During the search, we find out that the concept of “aggregation” (in different grammatical forms, such as “aggregation”, “aggregate”, and “aggregating”) is also related to the consolidation approaches. Besides, workflow is used instead of business process interchangeably. Therefore, we search other queries by considering new key words (i.e., “workflow” and “workflows”). After checking the abstracts of all search results, 86 papers were selected as the results of the primary search.
To verify the preciseness of our primary search, we identified four related literature surveys. First, Ayora et al. [
16], review the variability of BP models in process-aware information systems. The survey considers related concepts to variability management of BP modes such as configuration, merging, and evolution. From [
16] we select the merge supporting our approaches. The other survey is by La Rosa et al. [
17] about business process variability modeling. From this one, we pick the consolidation supporting approaches. Moreover, van der Aalst in [
5] and Dijkman in [
18] introduce some merge-based consolidation approaches. In all cases, our primary search results subsume and extend the findings of all these four surveys, in BP merge aspects. Moreover, we follow the references of these studies, to ensure that nothing is left out. After reading the full text of papers, we identify a list of ten papers, which address the BP consolidation based on merge techniques, constituting the state of the art related to our BS consolidation research. The summarization and data extraction step is performed in two steps including general introduction of finding, and systematic evaluation of consolidation approaches. The evaluation is performed by two first authors, and the results, including disagreements, are further discussed in a conflict resolution meeting.
Table 1
The SLR evaluation summary
| Ex | STL | Block-structured | Sy | N | N | Merging workflows | N | N | C, F | Not fully implemented/Less understandability because of using block-structured languages |
| Ib | STL | EPC | Sy | N | N | Improving process | ± | ± | C, F, I, V | Risk of deadlock occurrence because using AND-join/Not fully implemented |
| Ib | STL | EPC | Sy | N | N | Standardization | ± | ± | C, F, I, V | Lack of scalability to other languages (e.g., BPMN)/Not evaluated empirically |
| Ex | STL | IBM modeler | Sy | N | ± | Standardization | ± | ± | C, I± | Focus is on a tool not a method/Not scalable because of focus on IBM modeling notation/not evaluated empirically |
| Ib, Ir | STL | aEPC | Sy | N | N | Understandability | ± | N | C, I, V | Limited in preserving the correctness/modeling language limitation (EPC) |
| Ex | TS | Block-structured | Sy | N | ± | Minimizing changes | N | N | C, F, I, V | No checking soundness of the merged model/Not include the behaviors of the input model |
| Ib, It, Ir | TS | EPC | Sy | N | N | Configurability | N | N | C, I, V | No framework for supporting the configurable merge |
| Ib, It, Ir | TS | CoSeNets | Sy, Bh | N | N | Configurability | N | ± | C, F, I, V | Not addressed evolution of merged model |
| Ib, It, Ir | TS | EPC, BPMN | Sy, Bh | N | ± | Configurability | N | N | C, F, I, V | Lack of considering end-user opinion/ Not evaluated in a merger context |
| Ex | STL | BPMN, BPEL | Sy, Bh | N | N | Improvement | N | ± | C, F, I | Lack of considering end-user opinion/ not evaluated in a merger context |
[**] | Ib | TS | BPMN | Sy, Bh, AR | Y | N | BS consolidation | Y | Y | C, I±, V | Supporting VO context |
Ten papers present methods, frameworks, or approaches to consolidate BP mode by merging them. Below, a summary of each paper is provided. Note that also each of these papers constitute one row in Table
1.
1.
Regarding two scenarios of organizational merge and BP re-engineering, Sun et al. [
19] introduce a method for merging block-oriented workflows. Given two input process models, first a merged model from their common tasks is built. Then, the variants of input models are added by four categories of merge operations
“sequential”,
“parallel”, “
conditional”, and “
iterative”. In sequential merge of two variants, either one of them is kept or both add to the merged model sequentially. By using AND gateway, two variants are inserted into the merged BP model in parallel situation. To execute one or both variant fragments of the input models based on certain conditional situation, OR gateway is used to connect them to the merged model. The iterative merge of variants occurred when the variants appear in a loop. For instance, based on preceding common tasks, several executions of the variants are needed.
2.
Mendling and Simon [
20] introduce a method for consolidating different views of BP stakeholders. Where, an integrated model is assumed as a database schema and opinions of different stakeholders are added as data to this schema. In this respect, the method first identifies the
semantical relationships between constructs of two given BP models. The relationships could be either
equivalence if two constructs are completely similar, or
sequential if two constructs are modeled based on different views. By using AND-join gateway, the sequential constructs are added to the equivalent constructs. Finally, a set of restructuring rules eliminates some extra gateways. For example, change two subsequent direct AND gateways to one AND gateway.
3.
Gottschalk et al. [
9] present an approach to merge two Even-driven Process Chain (EPC) models by constructing a
function graph. First, the two input EPC models are reduced into their corresponding function graph, where only the functions and logical control flow between each function are reserved. For example, if no connection exists, then just an XOR construct is annotated on the function graph. Then, two function graphs are combined into a merged function graph. Accordingly, an EPC model is extracted from the merged function graph.
4.
To assist modeler for consolidating BP models, Kuster et al. [
13] provide a semiautomated approach in three steps. First, by comparing two given input models, differences between models are identified based on single-entry single-exit approach. Second, these differences are categorized and visualized for modeler in IBM Web-Sphere Business modeler. Finally, resolving differences by modelers preference is done, iteratively.
5.
To alleviate the problem of understandability in complex big configurable merged models, Reijers et al. [
21] propose a method for maintaining and retrieving model variants, during the modeling project in organizations. This approach introduces
aggregate EPC (aEPC), which associate product in addition to existing EPC notation. The products relate the special business context to EPC diagram. The complexity of variability (e.g., conditions for different BP variants) are resolved and kept in the product elements, instead of appearing on the EPC diagram. Since the modelers need single simple and not detailed models that shows similar BPs in an organization, a (mostly manual) approach is introduced for building an aggregated BP model.
6.
Li et al. propose an approach for merging BP variants into a merged model, by regarding
minimum change distances input variants [
22]. The change distance is one of basic change operations, including insert, delete, and move. Accordingly, the total operations to change each BP variant model into merged model should be minimal. The approach is adapted for block-structured languages.
7.
Instead of merging two models at the same time, Derguech and Bhiri propose an approach for merging several variants of BP models [
23]. The approach is tuned for EPC and relies on two preprocessing and post-processing steps for making a configurable merged model. Moreover, the approach considered single-entry single-exit structure to make merged model. Finally, the
consecutive and
trivial gateways such as two succeeded AND gateways are eliminated. The approach is experimented in a logistic case study.
8.
Introduced by Schunselaar et al. [
15], CoSeNets is a tree-like representation of block-oriented BP models, which is used for correcting the merging BP models. The CoSeNets structures of each input model are merged and any required restrictions for further extraction of input models are connected to the merged model.
9.
La Rosa et al. propose an approach for consolidating two graphical BP models by merging them. For this purpose, the following tasks are performed semiautomatically. First,
common regions are matched. Second, the
differences in BP models are appended to common region and produce a configurable merged model. Finally,
entanglements such as circular loops are resolved from the merged model. This approach finds the intersections of the BP models as the potential parts for further reusing in the merge of BP models [
10].
10.
In a model-driven approach, Greth introduces a framework for BP model change management in [
14]. It suggests merge of different versions of BP models, which could be formalized in different modeling notations (e.g., BPMN or EPC). In order to perform a language-independent merge, first an
intermediate representation (IR) of the input model is built. Then, the corresponding elements and differences of IRs are identified and mapped together. Thereafter, the dependencies, equivalences, and conflicts of IRs are analyzed. Finally, the IRs are merged and transformation of IRs to source languages is done.
Ten criteria that are also extracted from the literature [
5,
16,
17] in our SLR, for data extraction purposes, we evaluate the required data through . Each of the 10 papers are then evaluated against these ten criteria. The results show to what extent each paper supports the BP consolidation based on merge. The criteria are as listed and briefly described below.
1C.Preserving process behavior : this criterion refers to the concept if the consolidated models include all the behavior of the input BP models, or if they exclude their behavior. Moreover, the traceability, i.e., finding a process in merged model, and reversibility, i.e., extracting process from the merged model, are considered as the complementary levels of behavior inclusion.
2C.Presuming similar labeling : labeling is an important way of communicating through modeling. However, approaches deal with heterogeneity and homogeneity of labeling differently. We identify whether same labeling is assumed in the approaches or if the approaches are label sensitive.
3C.Depending on special modeling languages: approaches can be either language-dependent or independent. For instance, certain approaches are suitable for graphical languages (e.g., BPMN or EPC), while some consolidate BPs based on an abstract model that is language-independent.
4C.Preserving merged BP model correctness: the merged model is comprised of input models, while during the consolidation process there is a risk of errors occurring in the merged BP model. Accordingly, some approaches consider different levels of correctness, such as syntactical, i.e., concerned with structural consistency of the merged model, for instance by avoiding a disconnected node, or behavioral, i.e., by avoiding anomalies such as deadlocks or livelocks in the merged models and resolving ambiguous patterns such as OR-join.
5C.Considering collaboration in consolidation: the consolidation process is collaboration-intensive in principle. Different stakeholders are involved in BP consolidation, either intra-organizational or inter-organizational. Therefore, the approaches are evaluated for supporting collaboration process. This criteria specifically addresses the need in VOs to establish collaboration in consolidation procedure.
6C.Preserving the evolution concerns: since the approaches need to focus on the entire lifecycle of the merged model, the support for evolution concerns in approaches is evaluated.
7C.Constituting goal of consolidation: the main intention of the consolidation approach is important. Thus, identifying the main aim of consolidation is a significant factor.
8C.Including user preference: this criterion evaluates the extent of automation, in respect to user involvement and interaction in the process.
9C.Introducing step-wise methodology for consolidation: this assesses if a comprehensive method for systematic consolidation is provided.
10C.Supporting depth of research: this general criterion identifies the level of research including conceptualization, formalization, implementation, and validation. The evaluation of each approach, as the answer to the RQ.1 question is summarized in Table
1. Please note that for the comparison purposes, the last row in this table only indicates a ranking of our own approach, latter addressed in Sect.
4) against our SLR criteria, as indicated with [**].
The assessment in Table
1 identifies the missing and challenging areas for further researches. For instance, columns 5C, 6C, 8C, and 9C represent aspects that need special attention in BP consolidation context. Consequently, introducing a collaboration-aware methodology and framework applicable to the VO context is valuable and lacking based on the analysis of results presented in columns 5C and 9C. Whereas, the evolution aspect of the consolidated model or regarding user involvement and preferences in the consolidation BP models through merge are other important subjects for research.
3.2 Stages in BP consolidation: results from SLR
Through the insights reached with our SLR study of the most relevant related research, we have identified the main aspects and steps in need of attention for development of a BP consolidation methodology. Five main stages are identified for this process, including: “devise”, “formalize”, “merge”, “correct”, and “evolve”. We discuss and analyze our findings related to each of these stages in this section. The five stages involved in a BP consolidation methodology development are as follows:
First stage is devising, which focuses on the planning of the aim and method of BP model consolidation process. The aim of BP consolidation is the first and foremost concern, since it specifies the intention behind the consolidation approach. For instance, two organizations in a merger may decide to standardize their BP models according to a specific reference model, while merging their BP models. Besides standardization, BP improvement [
20,
24] and configurable BP reference modeling [
9,
10,
13] are some other well-known aims for consolidation, where the BP reference models represent best practice models that are formalized and address all aspects related to certain business domain [
25].
One primary decision during the devise stage is related to the extent by which the BP models should be merged [
3]. To facilitate making planning decisions for consolidation, two notions of: standardization and harmonization [
24] are introduced in research. Standardization addresses merging of equivalent BP variants into one process model, while harmonization is applied to keep (not consolidate) a rationalized number of multiple equivalent BP models. These approaches in turn yield different methods of managing the BP variants [
16]. Besides deciding on what plans to follow, devise stage also determines how to do the consolidation process by specifying the method of consolidation. The method mainly focuses on practical approaches for accomplishing the consolidation projects, e.g., being collaborative. In two principal scenarios of consolidation, either merger of two organizations, or the consolidation of two variant branches of a company, configuring of the organizational resources and the way they interact together is critical. This is addressed in research on organizational mergers [
26].
Formalizing BP is the
second stage of consolidation process, where the current BPs of an organization is represented by a BP modeling language, e.g., BPMN. The BP formalization has been researched extensively in BP modeling literature [
5]. However, there are approaches in collaborative modeling [
27] which facilitate this stage, but still there is no clear position for collaboration in BP consolidation process (See Table
1. Challenges related to formalizing BP models lie on: modeling at different levels of granularity, using different modeling languages, using synonyms and homonyms in labeling, and applying personal factors. In [
28] BP merge formalization challenges are described and exemplified. While the above challenges are important, in many real-world projects, the main challenge is that formalized BP models do not exist [
10,
18].
Several studies have shown that large process models are more difficult to maintain and comprehend [
25,
29] while being error-prone, hence a large comprehensive model is not necessarily a favorite of modelers.
Third stage of BP consolidation process is
merging the BP models. Our SLR shows that many consolidation approaches in BPM literature, address the (semi-)automated merging of the BP models. However, the merge stage includes three sub-stages. First,
similarity finding is the primary step for merging BP models, i.e., finding equivalent BP models for combining them in the merge stage, which has received specific attention in literature. In [
30] the similarity matching is classified into categories of label matching and BP models semantics matching. Due to different granularity in BP modeling, various labeling patterns, and heterogeneous terminology used in businesses, the similarity matching faces many difficulties and challenges [
31].
The second sub-stage of BP model merge stage is focused on
resolving differences. Following the identification of matched /similar fragments, recognition of differences between the BP models is a main concern in BPM community. Thus, diagnosing differences, which is analyzed and categorized in [
32], is the next step in BP consolidation roadmap. This step distinguishes the consolidation concept from the BP integration. In the integration of BPs, BP models collaboratively exchange information and messages; however, they do not change other partners’ BPs. But in consolidation, planning the needed changes to address identified differences is a concern [
19]. Without automation, it is tedious and time consuming for analysts to decide on differences and recognize common fragments in input BP models [
10].
Combining BP models takes place at the third step of merging stage. Constituting the merged process model out of the input models is another research concern. Merging BP models is addressed in [
9,
10,
13,
14,
20]. However, regarding the two perspectives of simple BP merge, and configurable BP merge, the mentioned approaches constitute the merged BP model generated from the input models of different merger organizations. When it comes to configurable BP merge, the (semi-)automated combining of BPs is very challenging because these approaches are syntactical and rarely represent the interest of business analysts if they are involved in redesigning BPs. Furthermore, the consolidation of all BPs in a configured merged model may result in a large and complex model [
29], not favored by the users [
25]. Moreover, lack of concrete evolving plan for such BP models may cause the merged process to divide it into multiple BP models [
3], and provide more complexity in organizational communications, which again is not favored by users.
Forth stage of BP consolidation process is assuring the
correctness of merged BP models [
33]. During the automated merge of BP models, there is the risk of undesirable constructs to be generated; the so-called anomalies [
5]. These anomalies may be in form of anti-patterns e.g., deadlock constructs [
34], or ambiguous patterns e.g., OR-join constructs [
35]. During the merge process, continuous validation checking is therefore necessary to avoid generation of ambiguous patterns. For instance in [
36], one of the BP modeling guideline is to avoid generation of OR routing gateways, while in configurable BP merged models include typically OR gateways, since the OR gateway subsumes the behaviors of both the X-OR and the AND gateways. The correctness can also consider semantic aspects of BP modeling. For instance, due to the potential of contradictions in applied rules or behavior of the two input BP models from two organizations, there is a feasibility risk of constituting a correct merged BP model, e.g., one university gives priority to specific geographical zone in its admission procedure, while the other one is totally against any such discrimination.
Fifth stage of BP consolidation process is focused on managing the
evolution of merged BP models. During the BP evolution in an organization, the change patterns for achieving the desired evolved BP model are identified and propagated [
37].
In principle, developing a solid methodology that can manage the above-mentioned stages of BP consolidation is a remarkable concern. A few methodologies are introduced that can manage BP model variants and even adapt them through their lifecycle [
16]; however, there is a still a lack of methodology for assuring the consistency of their consolidated BPs through merging their BP models.
3.3 Further SLR findings and analysis
Inputs to the BS consolidation process require being correct. The correctness is not just syntactical, but also behavioral, and otherwise the generated BSs will not properly execute. Therefore, a priority in developing BS consolidation methodology goes to preserving correctness, which is challenging, even due to different features of the BP modeling languages.
For instance, considering that BPMN as the de facto BP modeling language, it is often used for formalization of BPs in their consolidation process. But it is therefore necessary to also include an ambiguity resolution step to the devise stage of BS consolidation methodology. Furthermore, (semi-) automation is needed for it, since manual ambiguity resolution of BPMN models is itself not trivial.
Another issue to point out here is that even the merged models evolve over time. Consequently, the evolving stage of the consolidation methodology shall minimize the needed changes in the model while keeping the consistency of the merged model. These issues, as well as those addressed within the five above stages, constitute the main guidelines for design of our BP consolidation methodology.