1 Introduction

Flexibility is always a multifaceted concept, and it can be defined in different ways depending on the considered discipline, or the nature of a research activity (Alter 2004). When a specific domain is considered an holistic view is then necessary (Kanfer et al. 2000). In particular within the Business Process Management (BPM) domain flexibility asks to take into account different aspects from several existing disciplines including organizational science, information science, computer science, and sociology (Weske 2007). In this paper we underline the role of Business Process (BP) flexibility to support the operational level of an organization. In particular our interest is on technological and methodological issues related to BP flexibility, whereas managerial issues, while certainly relevant, are outside the scope of this paper.

In the following we refer to flexibility as the ability of an organization to deal with both foreseen and unforeseen changes, and in consideration of the impact they can have on the BPs regulating the activities of the organization (Schonenberg et al. 2008). Therefore flexibility can be seen as the ability to properly manage the coordination between organizational aspects, technical environments, and their changes. Process-Aware Information SystemFootnote 1 (PAIS) evolved to support such an ability (Reichert and Weber 2012). A “flexible” organization is then able to accommodate its BPs, and supporting IT infrastrtucture, to reach planned objectives, even when some working condition changes, e.g. different skill levels of the workers due to relocation of personnel, incompleteness of available information, etc. This is particularly true when the complexity of the organization increases, see for instance (Beeson et al. 2002). In such cases organizations have to codify their “way of working” since their complexity generally does not permit an informal approach to carry on “day to day” activities in an effective way (Melão and Pidd 2000). Such codification can be possible adopting notations and languages for Business Process modeling. As any other artifact a BP model, and its flexible version, needs to be properly handled during its whole life-cycle (Weske 2007).

Many solutions have been proposed in literature to support BP flexibility. As illustrated in detail in the next sections approaches can differentiate both with respect to the used instruments (mechanisms and languages), and in reference to their applicability to real scenarios. The amount of literature on the topic, and the heterogeneity of the proposed solutions, makes difficult to compare and classify the proposed approaches. Existing surveys on the topic do not completely fulfill this objective (Ayora et al. 2015; Valenca et al. 2013; La Rosa et al. 2013; Mechrez and Reinhartz-berger 2014; Murguzur et al. 2014b; Lang 2012; dos Santos Rocha and Fantinato 2013) (see Section 7).

This paper reports the results of a Systematic Literature Review (SLR) on BP flexibility with a special focus on software systems related aspects, with a particular emphasis on research works in academic literature. Given the specific context we use the following taxonomy (Reichert and Weber 2012):

  • Variability is the ability of deriving different variants from the same BP;

  • Adaptation is the ability to temporarily deviate the flow during the execution of a BP;

  • Looseness is the ability to execute a BP considering a specification in which aspects related to the decisions affecting the control flow are not fully defined or undefined;

  • Evolution is the ability to permanently modify a BP affecting all future BP enactments.

To minimize the risks of getting results biased by our personal preferences and previous knowledge we decided to conduct the survey according to the Kitchenham’s guidelines reported in Kitchenham (2007).

The paper is organized as follow. Section 2 shows the methodology we applied, while Section 3 reports about the research questions and the search protocol we adopted. Successively Section 4 describes the application of the protocol and it gives an overview on the obtained results that are successively detailed in Section 5. Then Section 6 contains a discussion on the results. Related works are presented in Section 7, and finally Section 8 provides some conclusive remarks.

2 Methodology

A SLR aims to present a fair evaluation of a research topic by using a trustworthy, rigorous, and auditable methodology. This paper refers to the methodology proposed by Kitchenham (2007), that has been conceived with a particular emphasis on SLR conducted within the software engineering domain. Nevertheless we consider it also suitable to get a credible evaluation of the research works under the topic of BP flexibility.

Kitchenham’s methodology is structured according to the following three steps, that have to be performed one after the other.

  • Planning the SLR - This phase aims at understanding needs and objectives for the review. To do that a set of research questions have to be defined and the review protocol (the strategy of work) must be established.

  • Conducting the SLR - This phase aims at defining a search strategy to select the wider set of relevant research works. The search is done according to the protocol defined in the planning phase, and it can be applied both in an automatic and manual way. As soon as the search has been concluded relevant research works are included or excluded from the review. This refinement step is quite critical since it can strongly impact on the goodness of the results (Wohlin 2014; Hassler et al. 2014). To guarantee the quality of the results it is important to apply quality checks on the included research works, so to avoid results biased by works that cannot be considered solid. Finally, for each selected research work data extraction is performed and classified according to its relevant characteristics.

  • Reporting the SLR - This phase aims at effectively communicating the results illustrating the answer to the research questions.

3 Planning the systematic literature review

In this section we present the planning step of this SLR. First, we introduce research questions and then we show the research protocol.

3.1 Research questions

The research questions we defined have been established by the need of discovering the state of the art in reference to relevant BP flexibility studies. The research questions we defined have been established by the need of discovering the state of the art in reference to relevant BP flexibility studies. The questions resulted from a set of brainstorming sessions carried on by the authors. The results of these sessions have been successively submitted for validation to three colleagues with more than 10 experience in BP management and related consultancy activities, and working with us within the EU project Learn PAd.Footnote 2 The feedbacks from experts were reconsidered by authors in a successive meeting to consolidate the final version of the questions.

  • RQ1. What raises the need for BP flexibility?This question aims at clarifying the motivations behind the need for BP flexibility solutions.

  • RQ2. Which phases of the BP life-cycle need to support flexibility?This question aims at understanding how flexibility impacts on the different BP life-cycle phases. In particular wants to distinguish solutions that consider flexibility as a design time or a run-time aspect.

  • RQ3. Which are the instruments used to express and support BP flexibility?This question aims at understanding how existing instruments handle BP flexibility. In particular it is important to refine it into two sub-questions.

    • RQ3.1 Which are the languages used and extended to express BP flexibility?This sub-question aims at identifying which languages/notations are used to model flexible BP, and how they are used in practice.

    • RQ3.2 Which are the mechanisms introduced to support BP flexibility?This sub-question aims at identifying which concrete mechanisms are used to enable flexible BP, and how to use them in practice.

  • RQ4. Are there any validation of BP flexibility instruments?This question aims at reporting on the state of the art regarding conducted real experiences (i.e. empirical experiments and/or industrial studies), that permitted to validate used languages and mechanisms.

3.2 Developing the systematic literature review protocol

This section provides details on the search query and the criteria used to include or exclude research works from the survey. As said the applied protocol has been defined according to Kitchenham suggestions (Kitchenham 2007).

To retrieve relevant research works we performed an automatic search on the main computer science digital libraries (Brereton et al. 2007). In particular included digital libraries are: IEEExplorer,Footnote 3 ACM Digital Library,Footnote 4 Citeseerx Library,Footnote 5 Scopus Science Direct,Footnote 6 SpringerLinkFootnote 7 and Institute for Scientific Information (ISI) Thompson Reuters Web Of Science.Footnote 8 We used a carefully planned search query that considered relevant as fields the title and the abstract of a research work. The definition of the query has been based on consolidated recommendations as reported in Brereton et al. (2007) and Zhang et al. (2011). At the beginning the query included keywords derived from the proposed research questions (RQ1 - RQ4) combined through the logical connectors AND and OR. Then the query was updated according to the experience of the authors in order to capture frequently occurring words in titles and abstracts of the relevant papers. Then we also included generic terms mainly used in the realm of software engineering like “dynamic”,Footnote 9 “self-adaptation”Footnote 10 and “context awareness”.Footnote 11 Finally we also included in the query text a specific BP modeling language such as “BPMN”. This is motivated by the fact that, even though the SLR objective is to perform a search covering the whole topic of BP flexibility, with special focus on software systems related aspects, its inclusions can bring positive effects for the reasons listed in the following (Recker 2010; Chinosi and Trombetta 2012): (i) the language is the result of a standardization path; (ii) the language is widely accepted method for documenting BP; and (iii) the language is the most used one due to its intuitive graphical notation, that permits to create a bridge closing the gap between BP design and implementation. The resulting search query is shown in Table 1.

Table 1 Search String
Full size table

As part of the protocol implementation the set of inclusion/exclusion criteria have been specified and reported in Table 2, they permit to guarantee that only relevant papers are selected. In particular we define two criteria for paper inclusion. Criterion I.1 aims at considering only primary studies, i.e. research works proposing novel solutions and not reviewing available literature. In particular in the following the term “research work” is used only for primary studies. Criterion I.2 refers to the time frame in particular we consider only research works published after 2000. This choice intended to include the periods of time considered by the other surveys on similar topics, as reported in Table 13. The choice is related to the fact that the first conference devoted to the management of BP flexibility took place in that year. Clearly the lack of a specific conference for a topic does not mean per-se that the topic was not studied before. Nevertheless we believe that the maturity of a topic is also related to the availability of places in which relevant issues are discussed.

Table 2 Selection criteria
Full size table

Two criteria for paper exclusion have been also defined. Criterion E.1 guarantees that research works considering software systems aspects related to BPM solutions are considered relevant for our work. Indeed several undesired research works resulted from the search activity. These works included the search terms but they were not related to the topic under study, for instance papers related to Neural Network or Artificial Intelligence were excluded thanks to this criterion. Finally, criterion E.2 asks to exclude papers not written in English.

4 Conducting the systematic literature review

In this section we describe how we performed the research protocol, therefore we introduce details related to the research works identification and selection activities and than we report the categories used to classify the research works.

4.1 Identification and selection of the research papers

The final result from the applied search protocol has been the identification of 164 relevant research works. Figure 1 reports the selection steps we applied. The automatic search permitted to initially identify 1333 research works. From this initial set we deleted the duplicates due to their availability in more than one digital library. Surprisingly just 12 % of the initially identified research works (160) were duplicates, their removal from the initial set resulted in 1173 unique research works. Table 3 shows the number of duplicates considering each possible couple of digital libraries. It is worth noting that SpringerLink provides unique research works that are not found in the other digital libraries and 73 % of the research works provided by ScienceDirect (57 research works) are also provided by ISI Thompson Reuters Web Of Science. Moreover just 4 research works resulted to be indexed by 3 different digital libraries. No research work was returned by more than three digital libraries. The last step asked to read all the papers in the set to decide with respect to the inclusion and exclusion criteria. Most of the time consisted in the reading of the paper abstract, introduction and conclusion, in particular to understand if the selected paper was really related to BPM. Indeed the exclusion Criterion E.1 was the main factor that reduced the cardinality of the set of relevant papers from 1173 to 164.

Fig. 1
figure 1

Research works selection steps

Full size image
Table 3 Research works duplication in two digital libraries
Full size table

Immediately after we carried on a further analysis step on the selected research works. In particular, we first made a validation based on the snowballing search method (Jalali and Wohlin 2012). This method asks to check the reference list of the identified research works looking for possible relevant studies not considered so far by the process. This permitted to check if there were relevant research works we did not identified during the automatic search. This step required to read few more paper abstracts but we have not identified further relevant works to be included in the relevant set.

We also did a quality evaluation, and to this end we identified the relevant criteria for our topic from those developed by Dybå and Dingsøyr (2008). In particular the considered questions are:

  1. 1.

    Is the paper based on research (or is it merely a lessons learned report based on experts opinions)?

  2. 2.

    Is there a clear statement of the aims of the research?

  3. 3.

    Is there an adequate description of the context in which the research was carried out?

  4. 4.

    Was the research design appropriate to address the aims of the research?

  5. 5.

    Was the data collected in a way that addressed the aims of the research?

  6. 6.

    Was the data analysis sufficiently rigorous?

  7. 7.

    Is there a clear statement of findings?

When applicable, all the 164 research works answered positively to the considered questions we considered. To apply the quality check to each work a reader and a reviewer were identified among the authors. The first one read the paper and provided a report for the quality assessment, while the reviewer checked after reading if he/she was in line with the report. All disagreements were solved through discussion. The same strategy of quality assessment was applied in the step of data extraction and synthesis for the research work classification.

4.2 Data extraction and synthesis

The objective of the data extraction and synthesis step is to design a suitable form to record and collect the relevant information obtained from the reading of the selected research works. The formFootnote 12 includes a common set of general fields such as title, publication year, publication venue and publication type (conference, workshop, journal or other). We also included some multiple choice fields for the research questions RQ1, RQ2, RQ3.1 and RQ3.2. We included an empty text box for RQ4, since its results cannot be classified a priori, and a multiple choice field to classify the paper according to the flexibility taxonomy. Finally, an empty text box for possible notes is included. General fields and multiple choice items are summarized in Table 4.

Table 4 Attributes for data extraction
Full size table

Attributes included as options in the multiple choice questions RQ1, RQ2, RQ3.1 and RQ3.2, were selected after a content analysis step. The characterization of the research works, according to emergent relevant attributes, required to apply an iterative approach that permitted to refine our findings after having considered each paper at least 3 times.

In order to answer the research question RQ1 - What raises the need for BP flexibility? - we selected the following six attributes.

  • Exceptions. In this class we include research works that consider flexibility driven by anomalous events. Taking into account all the admitted scenarios at design time is not always possible, therefore the occurrence of exceptions can lead the BPs into an unstable or insecure state where users do not know how to conclude it. As a result the proper management of the exception introduce flexibility. For instance, if a machine performing an activity breaks an exit strategy to continue the production is needed.

  • Technology Evolution. In this class we include research works considering flexibility driven by changes in the supporting hardware or software infrastructure. For instance, a mailing system can be substituted by a cloud-based application where mail, calendar and documents management are all integrated in a single application.

  • New Working Methods. In this class we include research works considering flexibility driven by changes in the organizational strategy in term of activities performed to reach a goal. Organizations can change the BP even though they maintain the same goal. For instance let’s suppose that a car manufacturer aims to produce a specific car according to a fixed product line. In this case, as soon as a new kind of paint is introduced some new activities regarding painting preparation could be needed.

  • Changes in the Target Goals. In this class we include research works considering flexibility driven by changes in the organizational strategy in term of goals that have to be reached. For instance let’s suppose that the organization aims at producing more goods, such as a manufactures would like to increase the car production of 10 %. In this case, a car manufacture can introduce a new approch permitting to install the wheels in parallel with the drive shaft.

  • Changes in the Laws. In this class we include research works considering flexibility driven by changes in a regulation framework (law, decrees, and legislation). For instance, it can happen that a new law introduces novel requirements for privacy management (i.e. encryption of personal data during mail exchange).

  • Saving. In this class we include research works considering flexibility driven by economical reasons. This means that BP flexibility can be due to the need to save money or time in the provision of services and products. For instance, a company can change its suppliers to spend less.

In order to answer the research question RQ2 - Which phases of the BP life cycle need to support flexibility? - we selected the following four attributes that are a slightly revised version of the phases of BP life cycle proposed by Weske (2007).

  • Design/Modeling. The design/modeling phase aims at producing BP models suitable for being successively used by the other phases. In this class we include research works providing notations and languages to represent flexible BPs.

  • Analysis. The analysis phase aims at detecting BP syntactic, structural and behavioral issues. In this class we include research works supporting correctness and compliance check for flexible BPs. It can be carried on via informal (i.e. workshops or focus group) and/or formal approaches (i.e. model checking).

  • Enactment/Execution. The enactment/execution phase aims at starting, executing and supporting running BPs. In this class we include research works providing mechanisms to manage flexibility at run-time.

  • Monitoring/Improvement. The monitoring/improvement phase aims at collecting functional traces and non-functional measures from the BP execution. In this class we include rese arch works discussing about how to log information and how to activate mining and reasoning techniques for BP improvement.

In order to answer the research question RQ3 - Which are the instruments used to express and to support BP flexibility? - we consider two set of attributes, one for each sub-question. The attributes for the sub-question RQ3.1 - Which are the languages used and extended to express BP flexibility? - were defined considering modeling languages used in the selected research works. We use the basic version of the language as attribute to classify the research works that also consider extensions and derivations of the same language.

  • Language Independence. In this class we include research works considering flexibility notion that does not depend from any language/notation.

  • BPMN. In this class we include research works considering BPMN (OMG 2011) and related extensions and derivations. This is a semi-formal notation for BP modeling defined by the Object Management Group.

  • BPEL. In this class we include research works considering BPEL (OASIS 2007) and related extensions and derivations. This is an executable language for web services modeling and execution defined by Organization for the Advancement of Structured Information Standards. BPEL is one of the most used executable modeling language in Service Oriented Architecture context with reference to their enactment and execution.

  • UML. In this class we include research works considering UML (OMG 2007) and related extensions and derivations. This is a standardized, general-purpose modeling language released by the Object Management Group. UML is the most used graphical language for the design of complex software systems. UML provides a specific diagram, named Activity Diagram, that can be fruitfully used in the domain of BP modeling.

  • Petri-Net. In this class we include research works considering Petri-Net (Hack 1976) and related extensions and derivations. Petri-Net is a mathematical modeling language for the description of distributed, concurrent, and asynchronous systems. The notation is used to represent BP models due to its ability to support formal analysis. In this class we also include language inspired by Petri-Net such as YAWL and related extensions.

  • Process Algebra. In this class we include research works considering process algebras (Bergstra and Klop 1984). This is a set of mathematically rigorous languages with well defined syntactic and semantics enabling formal analysis.

  • Declarative Model. In this class we include research works considering declarative language and related extensions. This is a set of mathematically rigorous languages. In most of the case they are based on formal logic definition. In most of the case it is used to define BP constraints concerning accepted behaviors.

  • EPC. In this class we include research works considering event-driven process chain (EPC) (Mendling 2008) and related extensions and derivations. An EPC model defines an ordered graph of events and functions. The EPC method was developed within the framework of Architecture of Integrated Information Systems in the early 1990s.

The attributes for the sub-question RQ3.2 - Which are the mechanisms introduced to support BP flexibility? - were defined considering mechanisms used in the selected research works.

  • Process Family. In this class we include research works proposing or related to mechanisms supported by configurable model. This is a generic model eliminating model redundancies by representing the commonalities of different process variants only once. BP variants supported by the configurable model are commonly referred as a family of BPs.

  • Business Rule. In this class we include research works proposing or related to mechanisms supported by rules. This is an atomic unit of business logic that affects cross-cuts application components and can be susceptible to changes due to constraints, derivations or reactions imposed by external conditions that can be satisfied or not by the BP.

  • Event Management. In this class we include research works proposing or related to mechanisms supporting the capability of a BP to observe events (i.e. error, exceptions and unexpected behaviors) and to react changing the normal activity flow.

  • Case Based. In this class we include research works proposing or related to mechanisms supporting the management of flexibility case by case. Each running instance is driven according to a specific scenario. This is applied in case the BP is loosely defined and it has to reach pre-defined objectives.

  • Edit BP. In this class we include research works proposing or related to mechanisms supporting design-time or run-time changes via operations like insert, delete, link and replace.

  • Pattern. In this class we include research works proposing or related to mechanisms supporting a set of BP elements commonly reusable from the structural point of view. In such a case on the base of predefined patterns the BP can be adapted in a imperative way.

  • Modularity. In this class we include research works proposing or related to mechanisms supporting the design of BP using pre-defined modules that are reusable from the behavioral point of view. Modules refer both to BP objectives and contexts. New modules can be designed and than added to the BP.

5 Results of the systematic literature review

In this section we present the results of the SLR indicating.Footnote 13 At first we report some general information on the collected data, and then considering the research questions listed in Section 3 we discuss: (i) emerging needs for BP flexibility, (ii) the flexibility impact on BP life-cycle, (iii) instruments (language and mechanisms) used to express and to support BP flexibility, and (iv) available case studies on the real usage of flexible BP languages and mechanism.

5.1 General remarks on collected works and data

The first analysis step we carried on the collected research works permitted to highlight interesting aspects on general trends with respect to the considered topic. In Fig. 2 can be observed that from 2000 the number of research works in the set regularly increases till 2012, than it seams that the interest on the topic started to slightly decreases. On the other hands data for the last two years could be affectd by the updating time of digital libraries.

Fig. 2
figure 2

Papers distribution by publication year

Full size image

In particular around 45 % of the research works have been published in the last 5 years. Indeed, since we run the search in July 2015 this percentage could have been even bigger considering that at the time of search some of the research works published (or under publication) in 2014/2015 could be not indexed by the digital libraries, yet. The trend somehow confirm the increasing relevance of the topic.

With reference to the venue type for the selected publications we observe that 64 % papers (104 research works) were published in conferences, 11 % (18 research works) in workshops, 24 % (39 research works) in journals, and only 1 % (2 research works) refers to the other categories (i.e. white paper and technical report). More in detail, as reported in Table 5, we observe that the research works have been published in 102 different events (conferences and workshops) and journals and most of these venues/journals published only one research work. From the data emerges then that does not exist a venue specifically devoted to BP flexibility. Figure 3 reports conferences, workshops and journals where at least 4 research works, among the ones included in our SRL, have been published. Somehow this data indicate the “communities” (reseraches and PC members) that considered the topic interesting. The International conference on Service Computing (IEEE SCC) is the most recurring conference, where 7 % of selected research works (11) have been published. Equally recurrent are, the international conference on Advance Information Systems Engineering (CAISE), the Business Process Management conference, and the Enterprise Computing Conference (EDOC). Each of these conferences account for 3 % of selected research works (5). With reference to journals the Information Systems JournalFootnote 14 is the most recurring one. It published 4 % of the research works (7) included in the SLR. Then it is followed by Data & Knowledge Engineering journalFootnote 15 that has published 2 % of the selected research works (4).

Fig. 3
figure 3

Papers distribution by main events or journals

Full size image
Table 5 Summary of papers by publication type and by publication year
Full size table

5.2 Why and when BP flexibility is needed

The research question RQ1 intends to clarify which are the needs that generally lead to the definition of solutions for flexibility management. We found that only 43 % of the selected research works (70) explicitly mention the reasons behind flexibility. Figure 4 and Table 6 summarize these results, taking into account that some research work mention more than one needs. In particular the introduction of new working methods is the main cause for 28 the research works, while the need to manage exceptions accounts for 26 research works. Changes in the laws is another important factor that accounts for 10 research works, while technology evolution is considered by 9 of the selected research works. Successively saving is the motivation mentioned in 5 of research works, as well as it is the case for changes in the targeted goals. Finally 8 research works just generically state that flexibility has positive effects on the organization, without providing precise needs.

Fig. 4
figure 4

Papers distribution by the needs for BP flexibility (RQ1)

Full size image
Table 6 Papers distribution by the needs for BP flexibility (RQ1)
Full size table

5.3 BP life-cycle and flexibility

The research question RQ2 considers the phases on the BP life-cycle in order to clarify which are the ones possibly impacted by flexibility aspects. We found that 99 % of the selected research works (163) explicitly mention the BP life-cycle to contextualize their work. Figure 5 and Table 7 summarize these results. In detail, phases are considered by the identified research works according to the following data: enactment/execution phase (61 %, 100 research works), design/modeling phase (50 %, 81 research works), analysis phase (12 %, 19 research works), and monitoring/improvement phase (6 %, 10 research works). There are also many research works facing more than one phase, and most of them (31 research works) combine the design/modeling and the enactment/execution phases.

Fig. 5
figure 5

Papers distribution by BPM life cycle (RQ2)

Full size image
Table 7 Papers distribution by BPM life cycle (RQ2)
Full size table

The impact of BP flexibility in the enactment/execution phase has been quite investigated. There are several scenarios where flexibility is not known a priori and it has to be managed during the execution of the BP. In those scenarios flexibility can be observed as an emergent behavior.

Design/modeling flexible BP attracts a wide research interest. The most representative attempt refers to the possibility to use a configurable BP model where a huge set of BP variants are encapsulated in a single model. This successively asks for individualization/selection step in order to derive a specific BP model.

The Analysis phase is also strongly affected by flexibility. Different techniques can be used and have been proposed to check soundness for BP model, which is the most recurrent property. Issue typically observed in the analysis of BP model (i.e. state explosion problem) are generally exacerbated by flexibility.

Finally, the impact of flexibility on the monitoring/improvement phase is not much investigated by the identified works. In particular it is generally reported as an add-on of the enactment/execution phase.

5.4 Languages and mechanisms for BP flexibility

5.4.1 Languages to express flexibile BP

The research question RQ3.1 wants to clarify which are the languages/notation used to express BP flexibility. We found that 49 % of the selected research works (81) explicitly refer to the used notations. Figure 6 and Table 8 summarize these results. In details we observed the following data: BPMN (28 %, 23 research works), BPEL (20 %, 16 research works), Petri-Nets (11 %, 9 research works), declarative models (11 %, 9 research works), process algebra (7 %, 6 research works), EPC (7 %, 6 research works), language independence (5 %, 4 research works) and UML (4 %, 3 research works). It is worth noting that few research works (7 %, 6 research works - Other category in the figure) present languages not used by any one else.

Fig. 6
figure 6

Papers distribution by modelling languages (RQ3.1)

Full size image
Table 8 Papers distribution by modelling languages (RQ3.1)
Full size table

BP flexibility is mainly expressed defining an extended version of BPMN 2.0. This can be done introducing variation points in which a specific behaviors can be manually or automatically inserted, updated or deleted (Sarnikar and Zhao 2008). Other interesting research works suggest to mix rule based approaches with BPMN. In particular rule-based BPMN (rBPMN) proposes an integration of BPMN with the REWERSE Rule Markup Language (Milanovic et al. 2011; Milanovic and Gasevic 2009).

BPEL is also extended in some research works. As an example we cite VxBPEL that incorporate variability into service-based systems (Koning et al. 2009). In other research works variation is related to the management of unpredictable events in relation to exception handling mechanisms (Laznik and Juric 2013).

Petri-Nets are also used to express and support flexible BP. As an example we report the self-adapting recovery net (Hamadi et al. 2008), where the formalism is used to specify BP exceptional behavior dynamically adapting Petri-Net at run-time to handle exceptions. Colored Petri-Nets have been also considered to model configurable process models (Gottschalk et al. 2008).

Declarative models are also used in modeling without explicitly specifying all the possible behavior. As an example, “Declare” supports the realization of different configurations of a BP declaring the allowed behaviors using a graphical notation associated to a variant of linear temporal logic (Schunselaar et al. 2012). Another contribution is “ConDec” that is again an approach based on temporal logic (Pesic and Aalst 2006).

Several papers extend EPC in order to include elements to express flexibility mainly at design time. For instance, the Configurable EPC language (C-EPC) was designed to model configurable process models for which standard EPC models can be extracted by a configuration step (Rosemann and van der Aalst 2007; Mendling et al. 2006; Recker et al. 2006).

In the area of process algebras the most representative example is CAptLang (Bucchiarone et al. 2013). This is a language to model context-aware and adaptable BPs. Its main feature is the capability to handle at run-time extraordinary or improbable situations.

Few research works support flexibility using approaches that can be applied independently from the reference language (Golani and Gal 2005; Frece and Juric 2012). In this category the work of Frece and Juric is particularly relevant (Frece and Juric 2012).

Finally, in the “other” category we introduced modeling languages that are not used by others and that cannot be categorized in one of the previous group (e.g. this is the case of the Common Variability Language or the integration between WFM and CCBR) (Ayora et al. 2012a; Weber and Wild 2005).

5.4.2 Mechanisms to support flexible BP

The research question RQ3.2 intends to clarify the mechanisms used to support BP flexibility. We found that 67 % of the selected research works (110) explicitly mention them, and in some case they consider more than one mechanism (5). Figure 7 and Table 9 summarize these results. In details we observe the following data: business rule (32 %, 35 research works), process families (19 %, 21 research works), edit BP (14 %, 15 research works), pattern (9 %, 10 research works), case based (8 %, 7 research works), event management (5 %, 6 research works), and modularity (4 %, 4 research works). It is worth noting that some research work (14 %, 15 research works - Other category) presents approaches used only once.

Fig. 7
figure 7

Papers distribution by mechanisms (RQ3.2)

Full size image
Table 9 Papers distribution by mechanisms (RQ3.2)
Full size table

Several research works show that business rules (also called policies or constraints) can be used in order to derive new versions of a BP or to adapt them. These rules ask for changes when certain conditions are true. For instance, many research works support flexibility using Event Condition Action (ECA) rules (Gong et al. 2009; van Eijndhoven et al. 2008). An ECA based approach can show the following advantages: (i) it can be expressed in a natural or formal language, (ii) it is easy to adapt, (iii) it can be managed in a single as well as distributed scenario. Nevertheless ECA rules can also have some practical limits when they do not reflect the procedural way of thinking familiar to the people in the organization (Bry et al. 2006). Another contribution focus on the integration of BP model with a rule-based approach such as the Rule Markup Language (R2ML) (Milanovic and Gasevic 2009), where the integration has been done at the levels of both graphical syntax and meta-models (Milanovic et al. 2011).

The creation of a family of processes is a widely investigated approach. This is inspired by Software Product Line (SPL) engineering where developers need to express variability in software systems (Pohl et al. 2005). Among the others feature models are often used to express BPs variability (Ognjanovic et al. 2012; Cognini et al. 2014). Process Families can be also associated to decision mechanisms to manage all the decision points during BP modeling (Boffoli et al. 2012b). Process Families are not only related to design time, and they are can also be used at runtime to deal with unknown situations (Reichel et al. 2010).

Few research works suggest to edit directly BP models (i.e. inserting or deleting tasks) in a manual or automatic way. The complexity to manage flexibility can be resolved directly by users that take decisions regarding all the possible changes. In this area a relevant approach is ADEPT (Dadam and Reichert 2009) that permits to users to perform ad-hoc modifications of running BPs. The approach provides an end user interface for ad-hoc changes.

It is worth mentioning that in some case flexibility is implemented using patterns. Patterns are associated to actions (skip, insert, abort) that are able to solve recurring modeling situations. They can be applied both during design/modeling and enactment/execution phases. Patterns represent a bounded set of variants that the BP can implement. Some generic patterns such as skip segment, insert-element-in-parallel, abort-try-resolve, etc. have been defined and validated to support flexibility in BP modeled using BPMN 2.0 notation (Döhring et al. 2011).

There are also few research works (5, 5 %) that combine more than one approach. For instance, an approach that is based on Pattern and at the same time provides the possibility to edit a BP at run-time is proposed in Zhao and Liu (2013).

5.5 Available case studies on BP flexibility

The research question RQ4 intends to highlight real experiences used to validate instruments supporting flexible BP. In the literature we can observe a general lack of real case studies. Most of the research works present toy examples without introducing an in-depth requirements analysis to justify flexibility. In particular we found only 4 realistic scenarios that are briefly summarized in the following. Table 10 shows how these scenarios answer the proposed research questions.

Table 10 Validation scenarios
Full size table

Among the most significant scenarios we can cite the car logistic (Bucchiarone et al. 2011b; Bucchiarone et al. 2012; Raik et al. 2012), that refers to the seaport of Bremen (Germany) where many cars need to be delivered from the manufacturers to the dealers. Each car has different features such as for example brand and model. The scenario presents several different cases in which adaptation is needed (for instance in case a car is damaged during the travel it will have to be repaired before the delivery). In the considered scenario flexibility is driven by exceptions. The already cited CAptLang language (Section 5.4) is used to model the adaptable BP. In the case study flexibility is considered both at design/modeling and enactment/execution phases.

Another interesting scenario is given by the British Telecom company, that in Jennings et al. (2000) illustrates a system to quote network installations. The case presents a BP that allows strategic changes during the course of negotiation with a customers. In particular, with reference to a negotiation process as soon as a customer contacts the sales department the identity of the customer is verified, and his/her requirements are elicited. Quotation is than provided in a personalized manner. The authors of this work take advantage of the already cited ADEPT tool (Section 5.4) to provide alternative execution paths at run-time on the base of the users requirements.

The ADEPT approach has been also used and validated in a clinical scenario reported in Dadam and Reichert (2009). In this case the workflow activities in a hospital are studied, analyzed and documented. This study shows that BPs for managing clinical activities cannot much constrained since deviations from standard procedures constitute a quite general case. Flexibility is considered during the execution/enactment phase giving the possibility to the user to edit the BP model. The approach is also extended to support variant analysis.

Finally, an interesting scenario is the warehouse management (Marconi et al. 2009). This is a workflow management system that aims to organize the movement of goods (i.e. shipping, receiving, put-away goods) within a warehouse. Physical and logical objects characterize the warehouse management. Examples of physical objects are the doors that represent the locations where the goods arrive or leave the warehouse. Logical objects are the staging areas where goods are temporarily placed. Warehouse management requires the execution of complex procedures considering logical and physical objects to deal with several different logistics situations. Flexibility in this case is supported by an extended version of BPEL. In their work the authors introduce abstract and concrete set of activities, where abstract activities are not executed, and are used to partially specify the control flow model at design-time. Concrete activities are executable activities and are selected to substitute the abstract one at run time. Both design/modeling and enactment/execution phases are considered by the case study.

6 Discussion

In this section we discuss the relationships among languages, mechanisms, and the BP life-cycle, and we cluster the selected research works according to the flexibility taxonomy introduced in Section 1. Finally, the main issues which seem to need further investigations are discussed.

6.1 Relationships among languages, mechanisms, and BPM life-cycle phases

To better understand the relations among the languages, mechanisms and the different phases of BP life-cycle we put together results from research questions RQ2, RQ3.1 and RQ3.2.

In particular with respect the relations between languages and phases, as shown in Fig. 8, the following considerations hold. In the design/modeling phase the most used language is BPMN. Clearly this data is partially biased by the presence of the string “BPMN” in the search string. Nevertheless the data tell us that while works using other notations tend to decrease, the number of hits in the literature related to BPMN as modeling notation is definitively increasing from 2006. This fact somehow confirms that the standard is affirming itself within the research community, and that probably the usage of this notation increases the possibility of having a real impact for forthcoming research works. Nevertheless with respect to the the design/modeling phase a relevant role is also played by EPC for which a quite constant trend has been observed. Somehow this is not surprisingly since this notation is supported by some important industrial players working on process aware information systems.

Fig. 8
figure 8

Languages used in the different BPM life-cycle

Full size image

With respect to the analysis of BP models the quite general approach is to map the notations mentioned above, used at an high level of abstraction to define models, to languages having a precise semantics, and for which analysis tools are already available. In this case we observe that the most common approach is to use Petri Nets or Declarative models. It is worth to note that we did not find any research work trying to directly define a precise semantics for the most commonly used modeling notation. Indeed this would make the analysis phase more reliable, since no mapping is defined, and more easily the tracing of possibly identified issues with respect to the defined model.

In the enactment/execution phase the most investigated language is BPEL. This fact seems influenced by the possibility to directly use execution engines for the language permitting to directly involve web services within an BP enactment. In this case the notation and the engines are usually extended to enable run-time variation.

Finally, the monitoring/improvement phase is not so much investigated with regards to flexibility and no relevant trends can be observed in terms of used languages/notations.

Successively we put together the results of RQ2 and RQ3.2 to identify the mechanisms that are mostly used to support flexible BP in each phase of the BP life-cycle, see Fig. 9. In particular for the design/modeling phase we observe that the most common approach is to introduce in the already available languages/notations mechanisms to support the definition of business rules or the definition of BP families.

Fig. 9
figure 9

Mechanisms used in the different BPM life-cycle phases

Full size image

In the analysis phase there are not many specific mechanisms conceived to better shape the analysis phase to flexibility aspects. Indeed in general traditional analysis techniques are used to check if a configurable BP model is correct considering all the possible models that can be generated by the additional mechanisms mentioned above. Clearly this lead to issues related to the explosion of states of the resulting models. It is interesting to observe that there are research works suggesting to move the verification phase at run-time considering the resulting (adapted) enacted instance of a BP.

For what concerns the enactment/execution phase we observe that support to rules defined at design time is the mostly common mechanism. In this case ad-hoc modifications to BP instances can than applied during the execution.

The monitoring/improvement phase is not so much investigated and no relevant trends can be reported.

At last we considered the relations between languages and mechanisms (RQ3.1 and RQ3.2), for which some results are somehow subsumed by the relation between languages and phases. We observe that there are just few research works explicitly mentioning the relationship between languages and mechanisms, see Table 11. Some of them combines languages and mechanisms in a multi-artifact approach, for instance they propose to combine process family mechanisms to express variability and BPMN to represent BP variant. BPMN is also used in combination with patterns to represent variation point on the BP model already defined. This is also the case of rules that are externally defined from the BP behavior.

Table 11 Papers for each attribute (RQ 3.1 and RQ 3.2)
Full size table

6.2 Flexibility categories

The research works included in this SLR support different flexibility needs related to the taxonomy presented in Section 1. For readability purpose we shortly recall the defined taxonomy: (i) Variability when different BP variants can be provided; (ii) Adaptation when deviate the execution path of a running BP is possible; (iii) Looseness when the BP is partly or totally undefined and execution can be different case by case; and (iv) Evolution when a permanent modification of the BP is possible (Reichert and Weber 2012).

In general many research works can be classified in more than one category, see Table 12 for details. In particular, 12 research works can be clustered in the intersection between the Adaptation and the Evolution categories, 21 research works in the intersection between the Adaptation and the Variability categories, and 5 research works in the intersection between the Variability and the Evolution categories. On the other hand some work can be clustered in just one category. In particular 51 research works in the Variability category, 47 research works in the Adaptation category, whereas 18 research works in the Looseness category. Finally no research works can be classified in the Evolution category alone.

Table 12 Classification of papers related BP flexibility taxonomy
Full size table

Considering the defined clustering the following considerations can be made.

  • Variability. Research works in this category introduce flexibility based on the knowledge represented in a configurable BP model. BP managers can choose one variant during the configuration step (i.e. using feature modelling and modularity approaches), then all the generated BP variants do not change and they are executed following the control flow specification by the selected BP variant.

  • Variability and Evolution. Research works in the intersection of this two categories introduce flexibility based on a configurable BP model. BP managers can choose one variant during the configuration step. During the execution changes are also permitted. These changes are then reported on the BP model and will affect future executions.

  • Variability and Adaptation. Research works in the intersection of this two categories introduce flexibility based on a configurable BP model. BP managers can choose one variant during the configuration step. During the execution changes (eventually automatically chosen) are also allowed without influencing the BP model.

  • Adaptation and Evolution. Research works in the intersection of this two categories introduce flexibility based on the capability to deviate from the initially intended execution (no variability is explicitely specified in a model). The adaptation step leads to the definition and revision of BP models, that will be used for future executions.

  • Adaptation. Research works in this category introduce flexibility based on the capability to deviate the initially intended execution of a BP without influencing the possibly defined BP model.

  • Looseness. Research works in this category introduce flexibility based on goals specifications. Even though each BP instance derived from a model aims at reaching the same goal they will differ from each other for instance in the ordering of the performed activities.

According to the research questions RQ 3.1 we report here the most used languages for each category of the taxonomy considering possible overlapping, see Fig. 10. Declarative languages are the most used by approaches in the Looseness category. BPEL and process algebra are used only in the Adaptation category. BPMN is the most used language in the Variability category. Finally, no general trend in terms of language are observed for research works classified in the intersections among Adaptation and Evolution, Variability and Evolution, and Variability and Adaptation.

Fig. 10
figure 10

Languages resulting from RQ3.1 according to the identified categories

Full size image

According to the research questions RQ 3.2 we report here the most used mechanisms for each category of the taxonomy considering the overlapping, see Fig. 11. Case Based approaches is the most used in the Looseness category. For what concern research works classified in the Adaptation category, and in the intersection between Adaptation and Evolution, the most used mechanism is rule. Process families and again rules are the most used in research works classified in the Variability category. Patterns are the most used by research works in the intersection between Variability and Adaptation category. Research works in the category resulting from the intersection of Variability and Evolution do not highlight a specific trend in terms of mechanisms.

Fig. 11
figure 11

Mechanisms resulting from RQ3.2 according to the identified categories

Full size image

6.3 Directions for future research

In this section we highlight the research topics, related to BP flexibility, that are perceived as more interesting in the research works we identified. The list below has been derived mainly from a thoughtfully reading of the motivations and future work sections. At the same time we report those flexibility aspects that do not seem to have received enough attention from the research community.

  • Modeling languages for flexible BP. To model flexible BPs, most of the approaches address flexibility via variability. In particular they generally define a configurable BP model that includes all the different BP variants. A configuration step is then performed to derive a single BP variant. In order to define such general models it is necessary to know in advance all the possible structures for the control flow relation. Unfortunately, this is not always possible in particular with reference to scenarios where control flow relations are unclear at design time. In any case all the considered approaches manage flexibility with respect to only one of the categories listed in the flexibility taxonomy mentioned in Section 1. Indeed it seems to us that it would be really interesting to have languages and approaches permitting to handle flexibility according to all the possible categories. In particular it seems that the definition of a modeling language that natively; (i) permits to manage all the possible BP variants at design time even if not fully codified; (ii) enables instance deviations during execution; and (iii) supports evolution, is still an open challenge.

  • Verification of flexible BP. To guarantee correctness of BPs many approaches have been proposed, and they generally rely on mappings to formally defined languages where traditional verification algorithms can be applied. Flexibility clearly challenge this approaches since greatly increase the complexity of derived models possibly bringing verification algorithms to their limits. Research in this domain seems particularly needed both in relation to static and dynamic techniques (i.e. at run-time). In particular dynamic verification seems particularly appealing and requires the conceivement and introduction of suitable run-time mechanisms mixing BP monitoring techniques with strategies for on-the-fly exploration of models.

  • Adaptation of BP running instances. The adaptation of a BP instance during its execution still deserves further investigation. Proposed solutions do not have completely addressed the problems. In particular many research works propose to deviate the flow of activities inserting, skipping, deleting and undoing tasks. Nevertheless such solutions does not seem to be general and in particular the undoing of a task or a set of them is not always easy/obvious.

  • Evolving BPs. When most of the running BP instances are adapted according to a similar schema probably the BP needs to be evolved. However this is not always true. For instance let us imagine that a service goes down for a while due to a failure in the hosting system. As a result a cooperating service could receive an exception in more than one execution. Clearly the adaptation step, that for instance could be temporarily solved thanks to the involvement of a human, should not always become the correct way of performing the activity in a successive version of the process. The automatic transition from adaptation to evolution is an highly interesting topic that deserve more investigations.

7 Comparison of surveys on BP flexibility

In the following we consider seven related literature reviews such as: Ayora et al. (2015); Valenca et al. (2013); La Rosa et al. (2013); Mechrez and Reinhartz-berger (2014); Murguzur et al. (2014b); Lang (2012); and dos Santos Rocha and Fantinato (2013). They permit to widen the overall picture on BP flexibility. Some of these works were already available when we started working on this SLR while other has been published at the time we were working to finalize this SLR. In particular we quantitatively compare the different surveys and their results, and as shown below they surprisingly differ quite a lot even when systematic approaches have been adopted.

The mentioned surveys, plus this one, generate a set of 398 research works.Footnote 16 Overall considered works are spanned over a time period that starts in 2000 and ends in 2015, see Table 13. We can immediately observe that the overlaps between the surveys is somehow negligible. In particular no research work appears in all the surveys and neither in seven or six of them. Just 4 research works (1 % of the 398 total) have been analysed by five surveys. Three of them are also included in our literature review (Hallerbach et al. 2010; Reinhartz-Berger et al. 2010; Razavian and Khosravi 2008) while one of this four is not considered by us La Rosa et al. (2011). 6 research works (2 % of the 398 research works) have been analyses by 4 surveys, and 13 research works (3 % of the 398 research works) were included in 3 of them. 45 research works (11 % of the 398 research works) appear in 2 different surveys. All the others, i.e. the wide majority (330 research research works - 83 % of the total), have been considered by just one survey. Table 14 shows in detail the discussed overlapping.

Table 13 Comparison of related systematic literature reviews
Full size table
Table 14 Research works overlapping among considered reviews
Full size table

Nevertheless the small intersections among the different surveys can be justified mainly by the fact that different research questions and different inclusion and exclusion criteria were considered. We believe they do not invalidate each other , while they seems to focus on related but still different aspects as reported in Table 13. In our opinion considered all together they provide a quite complete overview on this vast and complex topic.

Finally in Fig. 12 we report the trend with respect to the number of research works published each year in the mentioned period. Interestingly the highlighted trend is quite in line with the one we observed even when the works identified by us are removed from the set. A similar result can be observed when publication venues are considered. In particular the Conference on Advanced Information Systems Engineering (CAiSE), and related workshops is the most recurring venue, where 5 % of selected research works (18) were published. The Business Process Management and the related workshop series accounts instead for 4 % of selected research works (17). Still relevant is the IEEE SCC - International conference on Service Computing where 3 % of selected research works (12) were published. Quite relevant are also the Hawaii International Conference on System Sciences (HICSS) and the International Conference of Service Oriented Computing (ICSOC) that published 7 research works each. The Enterprise Computing Conference (EDOC), the International Conference of Web Services (ICWS), the On The Move to Meaningful Internet Systems (OTM) and the Software Product Line Conference published 6 research works each. With reference to journals the most relevant one is still the Information System Journal. It published 3 % of the research works (10), and it is followed by the Data & Knowledge Journal that published 2 % of the considered research works (6).

Fig. 12
figure 12

Papers Distribution by Publication Year Considering all the Review Studies

Full size image

8 Conclusions

BP flexibility is indeed a more and more relevant aspect for organizations working in rapidly changing contexts. In this paper we performed a SLR on the BP flexibility using the Kitchenham guidelines. The results confirmed the increasing relevance of the considered topic, and in particular we observed that the number of published papers on the subject definitively increases till 2012. This somehow confirms a strong interest from the research community on the topic (authors and PC members).

The study has shown that all the BP life-cycle phases are affected by flexibility issues. At the same time interesting experiences are introduced with reference to languages and mechanisms supporting BP flexibility. Surprisingly even though a quite voluminous literature has been published on the topic, there is still a general lack of concrete and complex application scenarios. In addition the study permitted to us to identify four research directions that we believe require further investigations.

We are aware that, despite the fact that a SLR is a replicable method, there are some subjective decisions that may bias the final results. Clearly each selection activity in the Kitchenham protocol introduces some space for subjective choices. In this SLR we tried to involve experts in the definition of the research questions so to reduce the risk of getting results biased by our tastes. To provide a more comprehensive view on the topic we considered and compared a set of surveys recently published. Indeed the differences among each of them are quite relevant, nevertheless we believe that all together they can provide a quite complete perspective on flexibility aspects for BPs.

Most importantly we can certainly say that even though the SLR identified many interesting research contributions flexibility is still a topic under development and many issues still need to be solved.