Alignment is a very wide subject that can be used to support an organization’s information system. Many authors have dealt with this topic according to various dimensions, including the operational alignment dimension. Our work aims to review approaches that discuss the operational alignment by reducing the gap between business requirement, business process, and software system. Therefore, this study was conducted by a systematic literature review (SLR). In the first step, we gather 1846 papers relative to the subject. In the last step, we filter those articles and select only the most pertinent ones, which leave us with 63 studies to focus on. These primary studies were analyzed according to 9 quality assessment criteria.

1. Introduction

The profitability of organizations is improved by an effective information system. Indeed, the performance of organizations depends on the evolution of information technologies. Besides, an organization needs to have an information system that is in coherence with its objectives [1]. Thus, alignment becomes an important issue for numerous authors and for organization’s stakeholders. Alignment can be understood as a tracking line which goes across layers of IS [2]. Business-IT alignment is necessary for supporting organizations to increase their visibility and efficiency which helps in staying ahead of the competition [3].

The authors deal with the topic of alignment according to various levels. In our research, we consider the operational alignment. More precisely, we analyze alignment by focusing on three types of models: business requirement, business process, and software system. Several studies focused on the alignment process by proposing some steps to align at least two of these three types of models [4]. The objective of this paper is to give an overview of the state of the art in the operational alignment. For that, we conduct our study by using a systematic literature review (SLR). This method aims to identify, evaluate, and interpret the research related to a topic [5]. The remainder of our paper is structured as follows: Section 2 provides a background of our topic. We present the work that treats the topic of alignment to explain this issue. Next, we address articles that deal with business-IT alignment and conduct their research by using a systematic literature review. Then, we explain our purpose in choosing the operational alignment. In Section 3, the research method is presented. In Section 4, we expose the planning of the review. This includes the research questions, data sources, keywords, inclusion and exclusion criteria, and quality assessment criteria. In Section 5, we analyze the primary studies. The results of our study are discussed in Section 6. Finally, we conclude by identifying the limits of the primary studies.

2. Background and Motivation

In the literature, various terms were used for the alignment. Chan [6] referred to alignment by fit and synergy concepts. Henderson and Venkatraman [7] used fit, integration, and interrelationships. It is called linkage in [8]. Ciborra [9] defined the term as a bridge, whereas Smaczny [10] designed alignment by fusion. Luftman [11] used harmony. For Nickels [12], it is designed by congruence.

Moreover, alignment can be analyzed from two sides (strategic and operational views). Very early, Henderson and Venkatraman [7] proposed the strategic alignment model (SAM) (cf. Figure 1).

Figure 1 shows two domains: business and information technology (IT). Business is composed of an external domain, Business Strategy (which includes business scope, distinctive competencies, and business governance), and an internal domain, Organizational Infrastructure and Processes domain (which includes administrative infrastructure, processes, and skills). In the same way, IT domain is also composed of an external domain, IT Strategy (including technology scope, systemic competencies, and IT governance), and an internal domain, IS Infrastructure and Processes (including architecture like the configuration of hardware and software and processes like system development and skills).

In Figure 1, the strategic fit represents the relation between external and internal components, whereas the functional integration exposes the integration between business and IT domains.

More precisely, the SAM shows the need for two types of linkage between business and IT domains:Strategic integration: this type deals with the business strategy and IT strategy according to external componentsOperational integration: this type makes the link between organizational infrastructure and processes and IS infrastructure and processes according to the corresponding internal domains

The SAM proposed by Henderson and Venkatraman is a global representation of the strategic alignment’s topic. Its advantage appears in the fact that it represents the existing relationships between the different elements that can be evoked in an alignment approach. Moreover, the model shows the components from the strategic and the operational side.

Recently, Aversano et al. [13] dealt with the topic of alignment by reviewing alignment approaches. They expose approaches treating two levels: the strategic and the functional alignments. They focus their research on the second level (using generally modeling languages). This level corresponds to the operational alignment in our work. Finally, they propose an approach to align business process to the software system.

Besides, some authors dealt with the topic of alignment and conduct their research by using a systematic literature review. Each review treats a particular field. Ullah and Lai [14] focus on 10 research questions related to background, definition, challenges, phases, measurement, alignment directions, business environment’s role, and successful alignment. Among their results through a systematic review, they notice that the majority of the studied research pays attention to the business perspective more than the IT-driven solutions. Thus, alignment may be studied as short term or long term. Therefore, they found that measurement of alignment makes the alignment more successful. Then, developing systems which can meet business needs may improve the IT/business alignment. Spósito et al. in [15] conduct their systematic literature review of the business/IT alignment by replying to 6 research questions. These questions deal with the alignment’s research topics, alignment’s dimensions, IT and business domains explored in alignment research, alignment’s goals, types of research’s results provided by alignment, and methods used in alignment research studies. In the outcome of their research, they note that the topic of business process management is the most used subject by selected papers that address the issue of business/IT alignment. The business strategy is also the most addressed domain. Furthermore, all the papers they studied care about the strategic dimension of the alignment. In a decreasing order, a number of papers present the structural, social, and cultural dimensions. The majority of the papers describe an approach for the alignment issue. Then, a greater number of papers propose a model for the business/IT alignment. Finally, Spósito et al. [15] found that the method which is the most used for the validation of approaches is the case study. Vasconcellos et al. [16] aim towards their SLR to analyze strategic alignment approaches of software process improvement.

In our paper, we focus our study on the operational alignment which represents the functional integration between internal domains. The aim is to analyze approaches that map internal components of business and IT domains. For the business domain, we are particularly interested in business requirement and business process. Concerning the IT domain component, we are focusing on the software system model (cf. Figure 2).

Today, information technologies are in progress. Furthermore, processes can be represented by a diversity of models. Organizations need an alignment approach that deals with the operational side. Moreover, even if there are systematic literature reviews dealing with the topic of alignment [1416], no SLR focuses its research questions on the operational alignment. For this reason, we choose to study the operational alignment through a systematic literature review which will be useful to organizations and authors interested in the topic of alignment. More specifically, we define operational alignment as a methodology that aims to reduce the divergence between at least two levels of different nature by taking into account their models. In fact, each level can be represented by a specific modeling language. Moreover, the considered levels (business requirement, business process, and software system) represent a global overview of the organization’s information system. As a result, there is a mutual relation between these levels. This is why their models must be consistent. Thus, we limit our study on the operational alignment problem. Our goal is to reduce the gap between three levels: business requirement, business process, and software system.

3. Research Method

Systematic literature review (SLR) is a method to identify, evaluate, and interpret all available research studies related to a particular topic area [5]. Our paper aims to conduct a SLR to identify, compare, analyze, and discuss the different steps, models, languages, and tools used by the existing approaches in the field of operational alignment. This methodology is also our way to find out approaches which propose a guideline for organization and an exhaustive approach for this field. This paper refers to the methodology of Kitchenham [5] which is structured according to the following three steps:Planning the review: this level helps in the determination of the objectives of the systematic literature review by identifying the research questions related to the topic and developing a protocol of the review.Conducting the review: this level begins after the development of the protocol. It consists on selecting the primary studies, extracting the data to collect the information from those studies, and discussing the results.Reporting the review: this level consists on communicating the results of the review.

4. Planning the Review

In this section, we identify the protocol of the systematic literature review.

4.1. Development of Review Protocol

We developed a review protocol according to the suggestions given by Kitchenham [5]. Our protocol consists of the following steps:(i)Identification of the research questions relevant to the topic(ii)Determination of the sources in which we will gather the relevant papers(iii)Identification of search terms and keywords(iv)Determination of the inclusion and exclusion criteria(v)Identification of the quality assessment criteria which will help to weight the importance of the studies

4.2. Research Questions

We specified several research questions to have a state of the art according to the topic of operational alignment. Our study aims to identify and analyze several studies in the literature that involve business-IT alignment, precisely those which consider the operational category. The operational alignment treats the technical side of the models. In this context, we propose seven research questions that concern alignment between each two levels, the models and languages used, the approach implementation, the existence or not of a guideline, and finally the approach degree of alignment coverage:(i)RQ1: How is the operational alignment between business requirements and business process being addressed?Motivation: The aim throughout this question is to analyze approaches that try to reduce the gap between business requirement and business process levels.(ii)RQ2: How is the alignment between business process and software system being addressed?Motivation: The aim throughout this question is to analyze approaches that try to reduce the gap between business process and software system levels.(iii)RQ3: How does the alignment between business requirement and software system is addressed?Motivation: The aim throughout this question is to analyze approaches that try to reduce the gap between business requirement and software system levels.(iv)RQ4: What types of models are used for each level?Motivation: This research question aims to identify languages, frameworks, or models used by each approach to represent business requirement, business process, or software system models.(v)RQ5: What are the main tools used by studies to implement the approaches?Motivation: The answer to this question will help us to identify the technical tools used by the studied approaches.(vi)RQ6: Do the approaches provide a guideline (a pattern system) to organizations to apply alignment?Motivation: Knowing the great importance of alignment for organizations, this research question aims to identify approaches that propose a guideline that helps them in applying alignment and improving their information system.(vii)RQ7: Do the approaches allow organizations which have three existing models (business requirements model, business process model and software system model) to apply the alignment phases between each two models?Motivation: Taking into account the importance of each level in itself, this question is very interesting for organizations that have three models and have the intention to align the three levels: the goal is to get all the models aligned and updated after the process of alignment.

4.3. Data Sources

To apply our research method, we firstly gather papers that deal with our topic from scientific databases. For this reason, we use the electronic databases shown in Table 1.

4.4. Search Terms

We analyze the research questions presented in Section 4.2 to identify the main keywords. As a result of this analysis, we use the keywords as follows: “Business-IT Alignment,” “Alignment Approach,” “Steps of alignment,” “Business Requirement,” “Business Process,” “Software System,” “Information Technology.” In addition to these keywords, some synonyms and other words were also used. Then, we formulate several search queries by joining groups of terms using the Boolean “and” or “or” operators.

4.5. Inclusion and Exclusion Criteria

To select primary studies, inclusion and exclusion criteria are used to help in filtering articles. Table 2 presents the inclusion and exclusion criteria related to our work.

4.6. Quality Assessment Criteria

We defined nine questions as quality assessment criteria to evaluate the papers. Then, we scored each question by “Yes (1)”, “Partially (0.5)”, or “No (0).” This score is defined according to each criterion.QA1: Does the approach consider operational alignment between business requirement and business process?QA2: Does the approach consider operational alignment between business process and software system?QA3: Does the approach consider operational alignment between business requirement and software system?We scored the questions QA1, QA2, and QA3 as follows:(i)Yes = 1: if the alignment between the two levels is well described in the paper(ii)Partially = 0.5: if the alignment between the two levels is cited in the paper but is not described(iii)No = 0: if the alignment between the two levels is not cited in the paperQA4: Does the approach propose a method for linking models?(i)Yes = 1: if the paper considers a method to link models in a direct manner(ii)Partially = 0.5: if the paper proposes a method to link indirectly(iii)No = 0: if the paper does not mention any way to have the link between modelsQA5: Does the approach propose a method for evaluating alignment?(i)Yes = 1: if the paper proposes a method to calculate the degree of alignment and to evaluate it(ii)Partially = 0.5: if the paper evaluates alignment without calculating the degree of alignment(iii)No = 0: if the paper does not evaluate alignmentQA6: Does the approach propose a method to correct misalignment detected?(i)Yes = 1: if the paper proposes a method to correct misalignment in a direct manner(ii)Partially = 0.5: if the paper proposes a method to correct misalignment indirectly(iii)No = 0: if the paper does not propose any method to correct misalignmentQA7: Does the approach describe the steps of alignment?(i)Yes = 1: if the paper presents steps of alignment and describes them in details(ii)Partially = 0.5: if the paper presents steps of alignment without describing them(iii)No = 0: if the paper does not describe steps of alignmentQA8: Does the approach propose a pattern system for organizations to apply alignment?(i)Yes = 1: if proposing a pattern system is one of the main goals of the paper(ii)Partially = 0.5: if a guideline is presented indirectly to apply alignment(iii)No = 0: if the paper does not propose any indication of applying the approach in organizationsQA9: Does the paper propose a technical tool to implement the approach?(i)Yes = 1: if the paper proposes a new technical tool to implement the approach(ii)Partially = 0.5: if the approach is implemented using a tool already existing(iii)No = 0: if the paper does not use any tool to implement the approach

5. Conducting the Review

To perform this phase, we select the primary studies according to the inclusion and exclusion criteria. These studies are also analyzed and weighted by the use of the quality assessment criteria. Finally, we extract the data and synthesize and discuss the result using quantitative and nonquantitative description.

5.1. Selection Procedure

The procedure of selection is summarized in Figure 3. We run queries in the six databases presented in Table 1 as primary data sources and we carried out the steps as follows:Step 1: in the first step, 1755 papers were selected from the electronic databases. Moreover, 91 papers were determined from other sources.Step 2: in a preliminary analysis, we identify and eliminate the duplicated papers; it reduces the number of papers from 1846 to 1500.Step 3: we analyze the abstracts of the selected papers based on inclusion and exclusion criteria. As a result, only 652 papers were selected for further analysis.Step 4: in this phase, we go through introductions and conclusions of the 652 papers according to inclusion and exclusion criteria. This step further reduces the number of papers to 367.Step 5: in this final step, for each article, we analyze the whole paper and evaluate each one using quality assessment criteria. By the end of these selective processes, 63 papers were selected to be used as primary studies.

5.2. Primary Studies

In this section, we report the results of the analysis of the primary studies. The 63 papers on which we based our study belong to the years 2003 up to 2017. Figure 4 shows the number of selected papers by year.

5.3. Evaluation of the Studies

To evaluate the primary studies, we use the quality assessment criteria represented in Section 4.6. Table 3 shows the result of this evaluation.

The percentage of studies that answers to the quality assessment criteria by type (Yes, Partially, or No) is given in Figure 5. We notice that the levels which are directly the most involved in these studies are business process and software system for 49.21%, then business requirement and business process which represent 25.40%, and only 12.70% of studies align business requirement and software system. According to QA4, we note that more than 87% of studies consider linking models as the most important stage of alignment. However, evaluation of alignment (QA5) and correction (QA6) are not considered as a basic stage of alignment. Moreover, according to QA7, more than 96% of studies describe the steps they use to achieve alignment. In addition to that, the QA8 shows that there is no study that presents a guideline for organizations as the main goals and that 93.65% of studies present indirectly a guideline to apply alignment. Finally, conforming to QA9, more than 50% of studies use a tool to achieve their approach.

6. Results and Discussion

6.1. Research Question 1: Alignment between Business Requirement and Business Process

To discuss the first research question, we focus on the five following criteria: QA1, QA4, QA5, QA6, and QA7. Indeed, we analyze approaches that deal with business requirement and business process levels (QA1). Next, we identify which steps are followed to apply alignment: linking models (QA4), evaluation (QA5), and amelioration (QA6). Then, we consider if the steps are described in details (QA7).(i)Paydar and Kahani [19] propose an approach for web applications based on UML which allows adaptation of the UML activity diagrams to new use cases. The approach is based on the reuse of models that concern existing web applications. They use a model repository and an ontology repository. As a result, new UML activity diagrams are generated from the new use case diagrams.(ii)Li et al. [21] propose an approach (GSP) for the CIM (computation independent model) level based on goal, scenario and process models. The business goal model is represented by the goal-oriented requirement language (GRL) and scenario model notation by use case maps (UCM) and BPMN is used to represent business process model. The use case maps aim to determine the operational scenarios and functional requirements. Thus, to link business goal to business process models, they define a set of mapping rules from GRL to UCM and other mapping rules from UCM to BPMN.(iii)Ruiz et al. [24] propose a framework that integrates two methods: which is a goal-oriented modeling method and communication analysis (CA) which is a communication-oriented business process modeling method. To achieve their goal, they use an intermediate reference ontology named FRISCO. Then, they define mapping rules from to FRISCO and from FRISCO to CA. As a result, the framework integrates and CA concepts and facilitates the traceability between the goal and business process models.(iv)Gröner et al. [26] define a set of mapping rules to map each task of the goal model to the corresponding activity in the business process model.(v)Kraiem et al. [28] propose mapping rules and a mapping process to translate MAP models to BPMN models.(vi)Sousa and do Prado Leite [29] present an approach that firstly map and BPMN and then merge the two models using an intermediate layer.(vii)Alves et al. [30] propose an approach to map the to BPMN models bidirectionally.(viii)Doumi et al. [34] propose a metamodel using UML for business-IT alignment toward phases of mapping and evaluation. Some metrics are measured to calculate the average between goals and business processes.(ix)Dubois et al. [37] propose an approach for aligning requirement assurance to business services using framework and UML. For this reason, they use guidelines presented by the ISO 15504 norm.(x)Frankova et al. [40] propose the BP&SLA methodology to reduce the gap between early business requirement and executable business processes. Indeed, they analyze the organizational context using Tropos, and they define a hypergraph as an intermediate for reasoning about business processes and their qualities. They built a hierarchy of business processes using BPEL specifications. Then, they built a constraint system.(xi)Decreus and Poels [43] define a set of mapping rules to transform a B-SCP model to BPMN model. B-SCP framework is based on the goal language.(xii)Borba and Da Silva [44] present some consistency rules between UML diagrams (use case, activity, status, sequence and class diagrams) based on the literature. These rules are then used to build a semantic network and are formalized with OCL.(xiii)Veres et al. [49] propose an extension of B-SCP framework. In fact, they present rules to map VMOST (vision, mission, objective, strategy, and tactic) analysis to BMM model (business motivation model).(xiv)Chanda et al. [50] propose a formalization methodology using a context-free grammar. Then, they define a first traceability rule which ensures that events in the use case diagrams correspond to the events in the activity diagrams in the analysis phase.(xv)Gutiérrez et al. [56] propose an approach that generates an UML activity diagram from the description of the steps in each use case.(xvi)Lübke and Schneider [64] propose an approach to generate BPMN processes from a tabular use case by using characteristics of use cases like preconditions, postconditions, and triggers.(xvii)Sapna and Mohanty [65] present structural consistency rules between UML diagrams (such as use case and activity diagrams). Rules are written in OCL and converted to SQL triggers for tables that store UML diagrams.(xviii)Lapouchnian et al. [67] propose an approach to map a goal model to BPEL (business process execution language).(xix)Pourshahid et al. [68] present a method to reduce the gap between business requirement and business process using a KPI (key performance indicator) model.(xx)Shinkawa [70] uses the Colored Petri Net (CPN) model as an intermediary to enhance coherence between UML models (use case, activity, state, and sequence diagrams).(i)Bleistein et al. [71] propose an approach to map role activity diagrams (RAD) to goal model.(ii)Lübke [73] presents transformation rules to generate event-driven process chain model from use cases.(iii)Kazhamiakin et al. [75] propose a methodology for integrating business requirements represented with with business processes represented by BPEL.

6.1.1. Conclusion of RQ1

According to the 23 studies, we remark that most approaches deal with the topic of alignment by defining a set of rules that helps to map the business requirement model to business process model. We can consider that the alignment is indirectly treated by some approaches that aim to allow coherence between UML models [44, 50, 65, 70]. However, only one approach [34] presents metrics to evaluate the alignment.

6.2. Research Question 2: Alignment between Business Process and Software System

To discuss the research question 2, we focus on the following five criteria: QA2, QA4, QA5, QA6, and QA7. In fact, we analyze approaches that deal with business process and software system levels (QA2). Next, we identify which steps are followed to apply alignment: linking models (QA4), evaluation (QA5), and amelioration (QA6) and if these steps are described in details (QA7).(i)Aversano et al. [13] align business process to software system following three steps. Firstly, they model business process and software system levels using UML. Then, they evaluate the alignment by proposing a method to codify the concept of alignment by using a set of metrics. Those metrics are useful to identify the degree of alignment. Finally, they deal with the evolution of activities when a misalignment is detected.(ii)Martinez et al. [18] use the framework to deal with the topic of alignment at the conceptual level. The authors follow three phases: business modeling, technology modeling, and technology incorporation.(iii)Sbai et al. [20] focus on process-aware information system (PAIS). They propose mapping rules to generate VarSoaML [79] from variant rich BPMN models. They enhance the transformation between CIM and PIM levels.(iv)Pepin et al. [22] link business and IT dimensions by proposing a pragmatic approach that assimilates the two dimensions. In fact, they aim to converge the two sides (business and IT). They built the business models and extract IT models. Next, they establish the relationships between models in a consistent way.(v)Rhazali et al. [17, 23] propose a set of transformation rules from CIM to PIM (platform independent model) level. In fact, they link in [17] between UML models. However, they propose rules to link between BPMN and UML models. For the CIM level, they use UML activity diagram in [17] and BPMN in [23]. The PIM level is represented by use case diagram, state diagram, class diagram, and package diagram in [17, 23].(vi)Cruz et al. [25] define a method to generate a model of software requirements and a data model from the business model. They use BPMN to represent business process and UML to represent the software level.(vii)Ide et al. [27] propose a methodology for the mapping system to business architectures using XBMC, an extension of BMC (business model canvas) and SMC (system model canvas).(viii)Dahman et al. [31] propose a conceptual mapping between BPMN and SCA (service component architecture). The objective is to maintain the alignment between business and IT even with the evolution of business processes. The correction aspect is specified in the approach to ensure the update of models.(ix)Kijas and Zalewski [32] propose a methodology to manage the changes between business process and services.(x)Castellanos and Correal [33] apply an ontology matching techniques to support alignment between business and information architectures. They use Tartarus metamodel to achieve their objective.(xi)Doumi et al. [34] present a metric to calculate the average between business process and information system business area.(xii)Branco et al. [35] present an algorithm for matching the business level to their correspondences in the IT level using BPMN.(xiii)Delgado et al. [36] propose a method to generate the SoaML model from a collaborative business process. The approach follows MDA’s construction and is based on BPMN2.0, SoaML, and QVT.(xiv)Buchwald et al. [38] propose a model called business-IT-mapping model (BIMM). It allows traceability of transformations between business and system processes.(xv)DeCastro et al. [39] exploit an approach based on MDA. They aim to support the business-IT alignment by specifying the correspondences between the CIM and PIM. Therefore, the authors use e3 value to represent relations and values between actors of business process and BPMN to represent the business view. Software view is represented by UML. To achieve their goal, they define mappings between models by natural language before collecting the mappings by a set of rules.(vxi)Ullah and Lai [41] propose an approach for business/IT alignment and start by business goals. Then, to model business process and IT infrastructure, BPMN and UML are used.(vxii)Zhao and Zou [42] propose an approach to derive software modular structures from business processes using clustering algorithms.(vxiii)The consistency rules presented in [44] (cf. Section 6.1) also concern the coherence between UML activity diagram and class diagram.(xix)Lemrabet et al. [45] propose mapping rules between BPMN and SoaML to support the transformation from CIM to PIM levels.(xx)Yi Wang et al. [46] propose an approach for the change management taking into account business processes and services. They link activities and operations.(xxi)Elvesæter et al. [47] perform the mapping between BPMN and SoaML. For that, they propose 8 rules. These rules allow transformation of BPMN model to SoaML model.(xxii)Scheithauer and Wirtz [48] propose an approach to develop the corresponding UML profile from business-oriented service descriptions.(xxiii)Chanda et al. [50] define a second traceability rule to ensure that events in the activity diagrams have one-to-one mapping with a method in class diagram in the design phase.(xxiv)Yousef et al. [54] propose an approach to derive software service from a business process architecture.(xxv)Cibran [55] presents an automatic translation from BPMN to UML activities to support business-IT Alignment.(xxvi)Koehler et al. [59] propose an approach to transform business process models into executable services towards SOA.(xxvii)Ralha and Gostinski [60] present a methodology to align business and IT alignment, using process modeling and ontology theory.(xxviii)Rychlý and Weiss [61] present an approach to transform business processes diagrams into services diagrams using BPMN and UML.(xxix)Yao et al. [62] propose an approach for supporting business changes and designing the software system.(xxx)Zarvić et al. [63] propose an alignment approach by planning IT functionality for a given value model.(xxxi)Sapna and Mohanty [65] present in their approach one structural consistency rule between activity and class diagrams.(xxxii)Xiao et al. [66] propose an approach that maps business process components to the source code entities to reinforce the change impact analysis for business and service levels.(xxxiii)Korherr and List [72] link the UML 2 profile for event-driven process chains with UML use case and component diagrams. The method allows integrating software perspectives in the business process model. In fact, it connects each action with a specific software component.(xxxiv)Etien and Rolland [74] use the ontology SW (Soffer and Wand [80]) to represent the business models and the ontology WW (Wand and Weber [81]) to represent software system models. The SW ontology and WW ontology are then modeled using UML. The authors propose two types of connection (“maps” and “Represents”) to model the correspondence between WW and SW models. Then, they propose metrics to measure the alignment between the business and the software.(xxxv)Shishkov and Dietz [76] propose an alignment approach between the software model and business process using a component based way.(xxxvi)Ha and Kang [78] propose consistency rules using the OCL formalism to ensure the coherence between structural and behavioral diagrams of UML.

6.2.1. Conclusion of RQ2

Most approaches handle the problem of alignment by proposing mapping rules to link or transform the business model into software model. However, the evaluation phase is presented by just 4 studies [13, 34, 63, 74]. The correction level is treated by 2 papers only [13, 31]. Some approaches such as [44, 65] present consistency rules between UML models which may be considered as a way to reduce the gap between business and software levels.

6.3. Research Question 3: Alignment between Business Requirement and Software System

To discuss the research question 3, we focus on the five following criteria: QA3, QA4, QA5, QA6, and QA7. Indeed, we consider approaches that deal with business requirement and software system levels (QA3). After that, as for the previous research questions, we identify which steps are to be followed to apply alignment: linking models (QA4), evaluation (QA5), and amelioration (QA6) and if these steps are described in detail (QA7).(i)Borba and Da Silva [44] (cf. Section 6.1) use the consistency rules between UML use case diagram and class diagram in their approach.(ii)Han et al. [51] propose an approach to align goals with services. For this purpose, they map their business motivation model (BMM) to SoaML.(iii)Ramel et al. [52] follow an approach based on requirements of business and software services. Indeed, they identify the business requirements using the goal-oriented modeling notation and define them by using the UML activity and class diagrams.(iv)Jing Wang et al. [53] use a quantitative evaluation method to measure the degree and evaluate how the services in SOA can contribute to the satisfaction of the business requirements.(v)Galster and Bucherer [57] align high-level business goal with services using the BGSC (Business-Goal-Service-Capability) Graph.(vi)Gehlert et al. [58] align business requirement to services using Tropos.(vii)Sapna and Mohanty [65] present in their approach one structural consistency rule between use case and class diagrams.(viii)Shishkov et al. [69] propose an alignment approach to address business requirements and to map them to technology platforms.(ix)Bleistein et al. [71] propose the approach B-SCP for integrating strategy, context, and process using requirements engineering. In fact, their approach combines QA1 and QA3.(x)Wan-Kadir et al. [77] propose an approach to model business rules and to link them into software design elements.

6.3.1. Conclusion of RQ3

The majority of studies that deal with the topic of alignment between business requirement and software system consider the linking level. Thus, there is just one paper [53] that proposes the evaluation step. However, there is no paper that proposes a method to correct the misalignment detected.

6.4. Research Question 4: Modeling Levels

Modeling is considered as a basic side of activities that conduct to a good software by well understanding of the system [82]. To answer the research question 4, we analyze all primary studies in order to identify the type of models used to represent business requirement, business process, or software system. The types used to represent these models are the following:(i)UML (unified modeling language): a language used to model business and to design, analyze, and implement software-based systems [83].(ii)BPMN (business process model and notation): it aims to provide a notation to be understandable by different stakeholders like business analysts who create the processes and technical developers who implement technologies that achieve those processes [84].(iii) framework: this modeling framework aims to maintain the initial phase of requirement engineering. It consists of two modeling components: the strategic dependency (SD) and the strategic rationale (SR) models. Intentional actor is the central concept in this framework. Actors have properties such as goals and commitments [85].(iv)GRL (goal-oriented requirement language): this language is based on language’s syntax. It supports the actor evaluation and integrates strategies [86].(v)Tropos: it is a methodology that aims to support analysis and design activities in the process of software development. Models in Tropos are obtained as instances of a conceptual metamodel. Among the key concepts in Tropos: actor, goal, plan, resource, dependency, capability, and belief [87].(vi)MAP: it is a process model in the form of a labeled directed graph with nodes (intentions) and edges (strategies) between intentions [88].(vii)BMM (business motivation model): it is developed by the Business Rules Group (BRG). It contains concepts that define business plan’s elements. The BMM is useful for developers of business plans and business modelers and implementers of software tools and repositories [89].(viii)VMOST (vision, mission, objective, strategy, tactic) analysis: it is a technique that answers a number of questions in the aim to deconstruct business strategy [49].(ix)CA (communication analysis): it is a method that focuses on communicative interactions appeared between information system and its environment [90].(x)XBMC (extended business model canvas): it is a visual language whose objective is representing business models’ contribution to the business goals [27].(xi)SMC (system model canvas): it is a visual language that allows designing a system architecture to match business goals [27].(xii)Tartarus metamodel: this metamodel comprises five packages like Architecture which is divided into four domains of Enterprise Architecture [33].(xiii)SOA (service-oriented architecture): it defines the way people, organizations, and systems support and use services to accomplish results [91].(xiv)SoaML (service-oriented architecture modeling language): it is a language that presents a standard way to model SOA solutions by the use of UML language [91].(xv)e3 value: it is a method for business modeling that defines concepts of marketing and business administration [39].(xvi)BPEL (business process execution language): it is a standard to specify business processes in the world of web services [92].(xvii)UCM (use case maps): it is a visual scenario model which specifies scenarios and functional requirements by offering complementary scenario notation [21].(xviii)RAD (role activity diagrams): it aims to describe business processes which can implicate actions and interactions between roles [71].(xix)EPC (event-driven process chain): this language aims to describe processes on the level of business logic. It consists of functions, events, and logical connectors [93].(xx)OWL (web ontology language): it is a language for the semantic web. It aims to represent knowledge about things and relations between them. It publishes ontologies on the WWW (World Wide Web) [94].(xxi)VarSOAML (variability-based service-oriented architecture modeling language): it is a result of merging between a metamodel of services modeling by adopting SoaML language and a metamodel that represents services variability [79].(xxii)ERD (entity relationship diagram): this model may be used to unify the view of data [95].(xxiii)SCA (service component architecture): it is a model which intends to include technologies for service components and for methods used to connect them [96].

Table 4 shows the models used in each paper, and Figure 6 indicates the number of each type of models used by studies.

6.4.1. Conclusion of RQ4

As illustrated in Figure 6, the most used models for representing business requirement are framework and UML, whereas BPMN is the most used for representing business processes. However, the majority of studies use UML to represent software system.

6.5. Research Question 5: Tool Support

To implement their approaches, 53% of primary studies use a support tool:(i)Aversano et al. [13] develop a tool in Java composed of modeling and alignment evaluation engine.(ii)Paydar and Kahani [19] implement the model repository using OpenRDF API.(iii)Li et al. [21] implement their approach using an MDA tool.(iv)Pepin et al. [22] use Eclipse modeling framework (EMF).(v)Ruiz et al. [24] use Eclipse modeling framework (EMF) and graphical modeling framework (GMF), and they follow a model-driven architecture (MDA) to implement the proposed approach.(vi)Dahman et al. [31] implement an algorithm by using Drools [97].(vii)Castellanos and Correal [33] implement their approach using a set of tools like graphical modeling framework (GMF) editor.(viii)Branco et al. [35] implement their algorithm in Java.(xi)Delagdo et al. [36] use Eclipse SoaML plug-in.(x)Dubois et al. [37] use the tool “Efficient.”(xi)Buchwald et al. [38] create the business-IT-mapping model by using IBM WebSphere Business Modeler.(xii)Frankova et al. [40] implement their main algorithm in the Eclipse framework.(xiii)Zhao and Zou [42] use the BPE tool to recover tasks from Opentaps.(xiv)Borba and Da Silva [44] implement their approach by developing a system called the knowledge-based system to guide the maintenance of UML diagrams.(xv)Lemrabet et al. [45] realize the mapping rule by using ATL (Atlas Transformation Language).(xvi)Decreus and Poels [43] use Eclipse-based B-SCP and Atlas Transformation Language.(xvii)Elvesæter et al. [47] implement the approach within CIMFlexMT and by using Atlas Transformation Language (ATL).(xviii)Scheithauer and Wirtz [48] develop UML Pofile 2 using Eclipse UML 2 Toolset (Eclipse Model Development Tools).(xix)Veres et al. [49] used Protégé which is a tool for building knowledge-based systems [98].(xx)Ramel et al. [52] use the tool “Efficient.”(xxi)Jing Wang et al. [53] implement their approach by developing a web application tool.(xxii)Yousef et al. [54] use the Web Ontology Language.(xxiii)Cibran [55] uses the Atlas Transformation Language (ATL).(xxiv)Gutiérrez et al. [56] implement in Java the transformations defined by QVT-relational language.(xxv)Ralha and Gostinski [60] use the IBM WebSphere tool.(xxvi)Lapouchnian et al. [67] use the OpenOME tool and the GUI tool.(xxvii)Pourshahid et al. [68] use the Cognos 8 BI.(xxviii)Lübke [73] implements the transformation rules from use cases to EPC using XSLT stylesheet (extensible style sheet language transformations) [99].(xxix)Kazhamiakin et al. [75] use the T-Tool framework.(xxx)Shishkov and Dietz [76] develop two graphical tools.

6.6. Research Question 6: Pattern System to Apply Alignment

According to QA8, we notice that the majority of approaches deal with this question partially. No study presents a pattern system in a direct manner. Indeed, the studies propose approaches for alignment without proposing to the organizations a pattern system, to apply alignment as the main objective.

6.7. Research Question 7: Integral Alignment Approach

To discuss this question, we base our analysis on all quality assessment criteria. It can be seen that the studied approaches do not propose methods that allow us to obtain three aligned and updated models based on three existing models by the alignment process. For example, Aversano et al. [13] propose an approach based on the different phases of alignment but highlight only the business process and software system models. Some notions of the requirements level are taken into account in the notation added at the level of the business processes (namely, the objectives and the actors). However, the level of business requirements is not considered to be an independent level in itself. Thus, the approach does not propose methods to align the business requirements and business process levels neither business requirements or the software system levels. Doumi et al. [34] are more interested in aligning the objectives at the strategic level with the information system by proposing a business-IT alignment metamodel and by proposing a set of metrics to evaluate this alignment. However, their approach does not allow us to obtain the three aligned models, each representing a level (business requirements, business process, and software system), from the existing models. Neither approach of the primary studies considers the three existing models in order to have as a result three updated and aligned models. All approaches offer methods to align only two levels.

6.8. Evaluating Alignment

The evaluation of the alignment is one of the important phases which help to achieve good alignment. As mentioned in previous subsections, some approaches propose methods to evaluate alignment. We present in Table 5 the results of this analysis:

7. Conclusion

In this paper, we have presented the results of a systematic literature review dealing with the topic of alignment. Our objective is to analyze different approaches that aim to reduce the gap between the three following levels: business requirement, business process, and software system. 63 papers were selected as primary studies. We noticed that business process and software system levels are the most studied levels. Finally, we assumed that the alignment process can best be carried out by using a pattern system that should proceed in twofold: it must take into consideration the three levels and must propose a guideline that will help stakeholders to apply alignment in their organization. The results of this SLR show that the alignment between business requirement, business process, and software system levels may be subjected to several phases of treatment (linking models, evaluation, and amelioration). Despite the fact that some authors give importance to the phases of evaluation and amelioration, most approaches deal with alignment by focusing on the phase of linking models (by transformation or generation of models, by proposing some mapping, or consistency rules etc.). In our future work, we aim to propose an exhaustive approach that deals with the phases of alignment between each of the two levels. We also intend to exploit the results of this SLR with regard to the languages that are most used for each level. Indeed, we propose to use the UML use case diagram to model business requirement level, BPMN for business process model, and UML class diagram for software system level.

Conflicts of Interest

The authors declare that there are no conflicts of interest regarding the publication of this paper.


This work was supported by the Excellence Research Scholarships Program of CNRST (National Center for Scientific and Technical Research) of Morocco (grant number 51UM52016).