# An Approach to Assess Operational Business-IT Alignment

Ali Benjilany, Hugo Bruneliere, Pascal Andre, Dalila Tamzalit

► To cite this version:

Ali Benjilany, Hugo Bruneliere, Pascal Andre, Dalila Tamzalit. An Approach to Assess Operational Business-IT Alignment. 32nd International Conference on Information Systems Development (ISD 2024), Aug 2024, Gdańsk, Poland. hal-04626942

HAL Id: hal-04626942

https://hal.science/hal-04626942

Submitted on 27 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
<figure><img src="image_1.png" /></figure>

HAL
open science

# An Approach to Assess Operational Business-IT Alignment

Ali Benjilany, Hugo Bruneliere, Pascal Andre, Dalila Tamzalit

► To cite this version:

Ali Benjilany, Hugo Bruneliere, Pascal Andre, Dalila Tamzalit. An Approach to Assess Operational Business-IT Alignment. 32nd International Conference on Information Systems Development (ISD 2024), Aug 2024, Gdańsk, Poland. 10.62036/isd.2024.13. hal-04626942

HAL Id: hal-04626942

https://hal.science/hal-04626942v1

Submitted on 27 Jun 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_2.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# An Approach to Assess Operational Business-IT Alignment

**Ali Benjilany**

Nantes University - CNRS / LS2N
F-44000 Nantes, France

ali.benjilany@ls2n.fr

**Hugo Bruneliere**

IMT Atlantique - CNRS / LS2N
F-44000 Nantes, France

hugo.bruneliere@imt-atlantique.fr

**Pascal André**

Nantes University - CNRS / LS2N
F-44000 Nantes, France

pascal.andre@ls2n.fr

**Dalila Tamzalit**

Nantes University - CNRS / LS2N
F-44000 Nantes, France

dalila.tamzalit@ls2n.fr

## Abstract

Business-IT alignment (BITA) remains a challenging topic for enterprise architects, and especially operational BITA that focus on the alignment between business processes and IT applications. A major challenge is determining the level of alignment between these Business and IT layers. Some approaches propose to assess this alignment, but they are often context-specific. Moreover, no approach intends to combine various assessment means for a more in-depth alignment evaluation. Thus, we propose an alignment assessment approach combining different means (metrics, consistency rules, anti-patterns). We also provide a methodology that integrates this approach by relying on an established cartography expressing the current state of alignment. This cartography is composed of Business and IT models, and of explicit links between them. The proposed methodology and assessment approach are illustrated on the SoftSlate case study, an open-source Java E-commerce solution. In the reported experiment, we considered four metrics, two consistency rules, and four anti-patterns.

**Keywords:** Operational Business-IT Alignment - Alignment Assessment - Information Systems - Enterprise Architecture

## 1. Introduction

Business-IT alignment aims to efficiently integrate business goals and underlying IT operations within the information system of an organization. The ultimate goal is to reduce the technical debt, limit the related costs, and improve agility in order to be able to respond to evolving customers' or partners' expectations. As a consequence, Business-IT alignment (BITA) is a crucial challenge in the field of Information Systems (IS) [2]. In this context, several definitions have been associated to the notion of *alignment* since this term was coined in the 90's, for example *fitness* [10] or *congruence* [11]. Notably, the Strategic Alignment Model (SAM) [16] proposes a common definition that has already been adopted in several approaches [4, 12, 13].

In this context, one of the key aspects is the need to integrate the Business and IT domains, also called functional integration. This is the target of our paper which focuses on the *Business-IT operational alignment* [15, 1, 19]. Enterprise Architecture (EA) frameworks express the different abstraction levels (strategic and functional/operational) through a layered representation of the IS [24, 23]. Thus, the operational alignment occurs between the Business and IT
# An Approach to Assess Operational Business-IT Alignment

**Ali Benjilany**

Nantes University - CNRS / LS2N
F-44000 Nantes, France

ali.benjilany@ls2n.fr

**Hugo Bruneliere**

IMT Atlantique - CNRS / LS2N
F-44000 Nantes, France

hugo.bruneliere@imt-atlantique.fr

**Pascal André**

Nantes University - CNRS / LS2N
F-44000 Nantes, France

pascal.andre@ls2n.fr

**Dalila Tamzalit**

Nantes University - CNRS / LS2N
F-44000 Nantes, France

dalila.tamzalit@ls2n.fr

## Abstract

Business-IT alignment (BITA) remains a challenging topic for enterprise architects, and especially operational BITA that focus on the alignment between business processes and IT applications. A major challenge is determining the level of alignment between these Business and IT layers. Some approaches propose to assess this alignment, but they are often context-specific. Moreover, no approach intends to combine various assessment means for a more in-depth alignment evaluation. Thus, we propose an alignment assessment approach combining different means (metrics, consistency rules, anti-patterns). We also provide a methodology that integrates this approach by relying on an established cartography expressing the current state of alignment. This cartography is composed of Business and IT models, and of explicit links between them. The proposed methodology and assessment approach are illustrated on the SoftSlate case study, an open-source Java E-commerce solution. In the reported experiment, we considered four metrics, two consistency rules, and four anti-patterns.

**Keywords:** Operational Business-IT Alignment - Alignment Assessment - Information Systems - Enterprise Architecture

## 1. Introduction

Business-IT alignment aims to efficiently integrate business goals and underlying IT operations within the information system of an organization. The ultimate goal is to reduce the technical debt, limit the related costs, and improve agility in order to be able to respond to evolving customers' or partners' expectations. As a consequence, Business-IT alignment (BITA) is a crucial challenge in the field of Information Systems (IS) [2]. In this context, several definitions have been associated to the notion of *alignment* since this term was coined in the 90's, for example *fitness* [10] or *congruence* [11]. Notably, the Strategic Alignment Model (SAM) [16] proposes a common definition that has already been adopted in several approaches [4, 12, 13].

In this context, one of the key aspects is the need to integrate the Business and IT domains, also called functional integration. This is the target of our paper which focuses on the *Business-IT operational alignment* [15, 1, 19]. Enterprise Architecture (EA) frameworks express the different abstraction levels (strategic and functional/operational) through a layered representation of the IS [24, 23]. Thus, the operational alignment occurs between the Business and IT
(sometimes called Application [22]) layers. Operational alignment is a dynamic process that aims to align, sometimes continuously, these Business and IT layers [21]. This notably requires to be able to first assess the current state of alignment. Recent literature reviews on operational alignment [15, 1, 19] highlight the lack of assistance provided to the enterprise architects in charge of the alignment process [11]. More specifically, there is a lack of methodologies and tools to practically assess the operational alignment state of information systems. Some approaches already propose to assess the alignment level through different assessment means which are often specific to a given context (for example agility metrics [17] or metrics for all the SAM alignment types [9]). However, no approach intends to combine these assessment means in order to obtain a more thorough appreciation of the alignment level.

To overcome these limitations, we propose an approach to assess the state of alignment between the Business (process) layer and the Application layer. We consider two main phases: 1) *Cartography establishment* for representing the current alignment state, including the Business and IT models as well as of the explicit links between their respective concepts. 2) *Alignment assessment* for using this alignment state in order to assess the level of alignment. In this context, our first contribution is an alignment assessment approach that relies on the combination of several different assessment means (metrics, consistency rules, anti-patterns). Our second contribution is a global methodology that integrates this alignment assessment approach along with the previous cartography establishment phase. We applied in practice these methodology and assessment approach on the SoftSlate case study, an open-source Java E-commerce solution. To this end, we established a cartography of the SoftSlate information system that we then assessed by relying on four metrics, two consistency rules and four anti-patterns.

The remainder of this paper is structured as follow. Section 2 presents the existing works related to operational alignment and the required background in terms of corresponding assessment means. Section 3 details the alignment assessment approach we propose in terms of structure and computation method. Section 4 describes the global methodology we provide to integrate this alignment assessment approach with a previous cartography establishment phase. Section 5 demonstrates the practical application of the proposed methodology and assessment approach in the context of the SoftSlate case study. Section 6 discusses the obtained results, the current limitations, and the overall applicability of our contributions. Finally, Section 7 concludes the paper and opens on future perspectives.

## 2. Background and Related Work

Recent surveys [1, 19] highlighted the limitations of existing approaches regarding the provided support for operational alignment. Indeed, only 20% of the studied approaches reach the point of assessing the alignment while most of them focuses on establishing the cartography. Among these approaches, the framework of Aversano et al [3] is a major reference because it covers most of the alignment process. It starts with alignment links establishment, then alignment assessment via the computation of metrics, and finally evolution recommendations to improve the alignment quality. The framework comes with tooling support and is validated on a case study. Another reference work [10] provides metrics to quantify the fitness level between the business and the IT system which supports it. Business and IT domains are represented using referenced ontologies on which the metrics are applied. Therefore, the proposed metrics are independent from specific languages and can be adapted to specific context (e.g. on UML concepts). However, no corresponding tool support is provided yet. A more recent approach [9] aims at generalizing the assessment (of all types of alignment in SAM) by defining a dedicated metamodel. To the best of our knowledge, this approach has not been applied on any case study. Recently, two new types of links have been proposed to establish a cartography [5]. These links are also used to compute various metrics and verify a few consistency rules. This last approach provides a basic tool support but does not combine the different assessment means together.
(sometimes called Application [22]) layers. Operational alignment is a dynamic process that aims to align, sometimes continuously, these Business and IT layers [21]. This notably requires to be able to first assess the current state of alignment. Recent literature reviews on operational alignment [15, 1, 19] highlight the lack of assistance provided to the enterprise architects in charge of the alignment process [11]. More specifically, there is a lack of methodologies and tools to practically assess the operational alignment state of information systems. Some approaches already propose to assess the alignment level through different assessment means which are often specific to a given context (for example agility metrics [17] or metrics for all the SAM alignment types [9]). However, no approach intends to combine these assessment means in order to obtain a more thorough appreciation of the alignment level.

To overcome these limitations, we propose an approach to assess the state of alignment between the Business (process) layer and the Application layer. We consider two main phases: 1) *Cartography establishment* for representing the current alignment state, including the Business and IT models as well as of the explicit links between their respective concepts. 2) *Alignment assessment* for using this alignment state in order to assess the level of alignment. In this context, our first contribution is an alignment assessment approach that relies on the combination of several different assessment means (metrics, consistency rules, anti-patterns). Our second contribution is a global methodology that integrates this alignment assessment approach along with the previous cartography establishment phase. We applied in practice these methodology and assessment approach on the SoftSlate case study, an open-source Java E-commerce solution. To this end, we established a cartography of the SoftSlate information system that we then assessed by relying on four metrics, two consistency rules and four anti-patterns.

The remainder of this paper is structured as follow. Section 2 presents the existing works related to operational alignment and the required background in terms of corresponding assessment means. Section 3 details the alignment assessment approach we propose in terms of structure and computation method. Section 4 describes the global methodology we provide to integrate this alignment assessment approach with a previous cartography establishment phase. Section 5 demonstrates the practical application of the proposed methodology and assessment approach in the context of the SoftSlate case study. Section 6 discusses the obtained results, the current limitations, and the overall applicability of our contributions. Finally, Section 7 concludes the paper and opens on future perspectives.

## 2. Background and Related Work

Recent surveys [1, 19] highlighted the limitations of existing approaches regarding the provided support for operational alignment. Indeed, only 20% of the studied approaches reach the point of assessing the alignment while most of them focuses on establishing the cartography. Among these approaches, the framework of Aversano et al [3] is a major reference because it covers most of the alignment process. It starts with alignment links establishment, then alignment assessment via the computation of metrics, and finally evolution recommendations to improve the alignment quality. The framework comes with tooling support and is validated on a case study. Another reference work [10] provides metrics to quantify the fitness level between the business and the IT system which supports it. Business and IT domains are represented using referenced ontologies on which the metrics are applied. Therefore, the proposed metrics are independent from specific languages and can be adapted to specific context (e.g. on UML concepts). However, no corresponding tool support is provided yet. A more recent approach [9] aims at generalizing the assessment (of all types of alignment in SAM) by defining a dedicated metamodel. To the best of our knowledge, this approach has not been applied on any case study. Recently, two new types of links have been proposed to establish a cartography [5]. These links are also used to compute various metrics and verify a few consistency rules. This last approach provides a basic tool support but does not combine the different assessment means together.
Existing works rely mostly on quantitative assessment means, namely metrics. A reference work [2] defines two main alignment criteria that led to metrics. These criteria are: Technological Coverage (TC) for the percentage of process activities adequately supported by an IT system, and Technological Adequacy (TA) for the similarity between linked concepts. Based on this, 5 metrics for TC and 4 metrics for TA have been proposed [3]. The results of a single metric are then aggregated across several linked concepts. Another work [10] provides 10 metrics for 10 alignment criteria grouped in 4 different alignment factors, for example the functional factor addressing functional integration. However, the proposed metrics are not combined in practice and a weighted aggregation is just discussed as future work. A more recent work provides a catalog of 25 metrics [9]. It proposes a reinterpretation of 9 metrics coming from previous works [10, 3]. In addition, 16 new metrics are proposed at different levels, including 2 metrics to assess functional integration at the operation level (namely *Business function automation rate & Business interaction automation rate*). These 2 metrics targeting operational alignment have been recently generalized to *Business functional concepts' support rate* and complemented with 5 other metrics [5]. Complementary to the use of metrics, consistency rules have also been considered as another suitable assessment mean. For instance, they can allow for the verification of the consistency between functional and data concepts in Archimate [5] or between functions and data in the more general case [20]. In another approach, rules are defined by a model transformation from business to IT and the consistency is checked by verifying few conditions [6]. Consistency heuristics can also be defined by querying such a mapping, for example with the Kalcas Query Language [7]. In this approach, an alignment Query and a Redundancy Query are specified to detect a potential misalignment on some particular objects. Another tool-supported approach aims to consistently synchronize related Business and IT process models, and to propagate changes to the other views [18]. Patterns can also represent a relevant assessment mean. For instance, common misalignment patterns between the Business and IT layers have been identified from the study of 30 different information systems [14].

Overall, we observed that most of the existing metrics have never been combined together in order to provide a general assessment of a current state of operational alignment. Moreover, other complementary assessments means, such as consistency rules and anti-patterns, are either not implemented yet nor combined together (also with metrics). We consider that these different assessment means would benefit from being aggregated in order to target a more thorough alignment assessment. We explore this idea by proposing a corresponding alignment assessment approach in the next section.

# 3. An Alignment Assessment Approach Combining Different Evaluation Means

We aim to propose an assistance to enterprise architects through an assessment dashboard allowing the combination of different assessment means: metrics, consistency rules and anti-patterns. According to his (mis)alignment assessment needs, the architect select the most suitable means and combine them by attaching appropriate weights to indicate their degree of importance. These selected means with their weights are thus combined within a single formula. To ease their definition and selection, these means are structured by specific criteria according to identified factors.

## 3.1. Alignment Assessment Structure

The structure of our alignment dashboard is inspired from the hierarchical structure of Cavano & McCall's framework [8] proposing *Factors, Criteria and Metrics*. We adapted it as follows. *Factors* present qualitative attributes referring to different alignment perspectives, like 4 alignment factors (intentional-functional-informational-dynamic) defined in [10] or 2 alignment factors (functional, data) considered in [5]. We set in our context *Alignment Factors*.
Existing works rely mostly on quantitative assessment means, namely metrics. A reference work [2] defines two main alignment criteria that led to metrics. These criteria are: Technological Coverage (TC) for the percentage of process activities adequately supported by an IT system, and Technological Adequacy (TA) for the similarity between linked concepts. Based on this, 5 metrics for TC and 4 metrics for TA have been proposed [3]. The results of a single metric are then aggregated across several linked concepts. Another work [10] provides 10 metrics for 10 alignment criteria grouped in 4 different alignment factors, for example the functional factor addressing functional integration. However, the proposed metrics are not combined in practice and a weighted aggregation is just discussed as future work. A more recent work provides a catalog of 25 metrics [9]. It proposes a reinterpretation of 9 metrics coming from previous works [10, 3]. In addition, 16 new metrics are proposed at different levels, including 2 metrics to assess functional integration at the operation level (namely *Business function automation rate & Business interaction automation rate*). These 2 metrics targeting operational alignment have been recently generalized to *Business functional concepts' support rate* and complemented with 5 other metrics [5]. Complementary to the use of metrics, consistency rules have also been considered as another suitable assessment mean. For instance, they can allow for the verification of the consistency between functional and data concepts in Archimate [5] or between functions and data in the more general case [20]. In another approach, rules are defined by a model transformation from business to IT and the consistency is checked by verifying few conditions [6]. Consistency heuristics can also be defined by querying such a mapping, for example with the Kalcas Query Language [7]. In this approach, an alignment Query and a Redundancy Query are specified to detect a potential misalignment on some particular objects. Another tool-supported approach aims to consistently synchronize related Business and IT process models, and to propagate changes to the other views [18]. Patterns can also represent a relevant assessment mean. For instance, common misalignment patterns between the Business and IT layers have been identified from the study of 30 different information systems [14].

Overall, we observed that most of the existing metrics have never been combined together in order to provide a general assessment of a current state of operational alignment. Moreover, other complementary assessments means, such as consistency rules and anti-patterns, are either not implemented yet nor combined together (also with metrics). We consider that these different assessment means would benefit from being aggregated in order to target a more thorough alignment assessment. We explore this idea by proposing a corresponding alignment assessment approach in the next section.

## 3. An Alignment Assessment Approach Combining Different Evaluation Means

We aim to propose an assistance to enterprise architects through an assessment dashboard allowing the combination of different assessment means: metrics, consistency rules and anti-patterns. According to his (mis)alignment assessment needs, the architect select the most suitable means and combine them by attaching appropriate weights to indicate their degree of importance. These selected means with their weights are thus combined within a single formula. To ease their definition and selection, these means are structured by specific criteria according to identified factors.

### 3.1. Alignment Assessment Structure

The structure of our alignment dashboard is inspired from the hierarchical structure of Cavano & McCall's framework [8] proposing *Factors, Criteria and Metrics*. We adapted it as follows. *Factors* present qualitative attributes referring to different alignment perspectives, like 4 alignment factors (intentional-functional-informational-dynamic) defined in [10] or 2 alignment factors (functional, data) considered in [5]. We set in our context *Alignment Factors*.
Factors of Cavano & McCall's framework are broken down into *Criteria*, like the two alignment
criteria given in [3]: Technological Adequacy and Technological coverage. We set in our context
*Alignment Criteria*. While Cavano & McCall's framework leans on *Metrics*, we consider more
assessment means. We set in our context *Alignment Assessment Means*: metrics, consistency
rules and anti-patterns. Metrics and consistency rules, introduced in [5], are defined on COB-
ITA links between the business and the application layers and BITA Anti-patterns, introduced
in [14], are also based on links between the business and the application layers since these links
between layers are the core element to assess alignment and conduct an alignment process.

**Assessment Means Selection.** In our approach, alignment factors are selected according to the architect's objectives. For example, an architect could prioritize the support of all the business processes while another could favor the applications' performances. Each factor is then broken-down in different underlying alignment criteria chosen by the architect. Each alignment criteria can then be evaluated by relying on one or several alignment assessment means selected regarding the needs. Thus, selecting alignment factors, criteria, and assessment means strongly depends on the IS objectives and business priorities.

**Assessment Means Weighting.** The architect assigns weights to each assessment mean. A weight reflects the importance of a given assessment mean compared to the others. We introduce two different types of weights: **specific weights** relate to individual assessment means, while **aggregated weights** are associated to types of assessment mean. Thus, the weight associated to the metrics can be different than the weight associated to consistency rules or anti-patterns. For instance, metrics can be considered for 20% of the whole weight while consistency rules and anti-patterns are respectively considered for 40% regarding their most important coverage of the considered system.

**3.2. Alignment Assessment Score Calculation**

The assessment is complex because some alignment/misalignment means are hardly quantifiable
and, sometimes, difficult to identify. Moreover, the types of mean can be heterogeneous (numer-
ical values, rates, etc.) and require an harmonisation step before combining them in aggregate
factors. We propose a scoring approach to calculate an overall alignment score from such het-
erogeneous assessment means: metrics, consistency rules and anti-patterns. In this paper, we
started with an initial catalog of assessment means we selected from the literature. Table 1
shows these different assessment factors, criteria and means. Note that providing a complete
catalog is beyond the scope of this paper, and would require extra-work with expert architects.

**Assessment Means: Harmonisation.** Results obtained from different types of assessment means need to be harmonized in a unified scale so that they can be combined and interpreted correctly. For example, if a given mean gives result within a scale between 0 and 10 and another mean gives a percentage or a rate, this last can be transformed to a number within the same predefined scale. Also, the same result for different assessment means should be considered carefully. For example, the value of "80%" of aligned concepts and the same value of "80%" of misaligned concepts does not reflect the same information about the alignment. Instead, a harmonized result would allow a more uniform appreciation of the alignment level.

**Weighted Score Calculation per Type of Assessment Mean.** Before aggregating all the har-
monized results, we first group the results by type of means. We calculate the aggregated weight
score from specific weights as follow:

*Metrics weighted.* Let *Mi* the i-est metric, *rMi* its result and *wMi* its weight with Σ *wMi* = 1.
To calculate a combined score of selected metrics, we use the formula: *rM* = Σ *wMi* × *rMi*.
*Consistency Rules.* Let *CRi* the i-est metric, *rCRi* its result and *wCRi* its weight with Σ *wCRi* =
1. The weighted score of consistency rules score equals: *rCR* = Σ *wCRi* × *rCRi*.
*Anti-patterns.* Let *APi* the i-est anti-pattern, *rAPi* its result and *wAPi* its weight with Σ *wAPi* =
Factors of Cavano & McCall's framework are broken down into *Criteria*, like the two alignment criteria given in [3]: Technological Adequacy and Technological coverage. We set in our context *Alignment Criteria*. While Cavano & McCall's framework leans on *Metrics*, we consider more assessment means. We set in our context *Alignment Assessment Means*: metrics, consistency rules and anti-patterns. Metrics and consistency rules, introduced in [5], are defined on COB-ITA links between the business and the application layers and BITA Anti-patterns, introduced in [14], are also based on links between the business and the application layers since these links between layers are the core element to assess alignment and conduct an alignment process.

**Assessment Means Selection.** In our approach, alignment factors are selected according to the architect's objectives. For example, an architect could prioritize the support of all the business processes while another could favor the applications' performances. Each factor is then broken-down in different underlying alignment criteria chosen by the architect. Each alignment criteria can then be evaluated by relying on one or several alignment assessment means selected regarding the needs. Thus, selecting alignment factors, criteria, and assessment means strongly depends on the IS objectives and business priorities.

**Assessment Means Weighting.** The architect assigns weights to each assessment mean. A weight reflects the importance of a given assessment mean compared to the others. We introduce two different types of weights: **specific weights** relate to individual assessment means, while **aggregated weights** are associated to types of assessment mean. Thus, the weight associated to the metrics can be different than the weight associated to consistency rules or anti-patterns. For instance, metrics can be considered for 20% of the whole weight while consistency rules and anti-patterns are respectively considered for 40% regarding their most important coverage of the considered system.

## 3.2. Alignment Assessment Score Calculation

The assessment is complex because some alignment/misalignment means are hardly quantifiable and, sometimes, difficult to identify. Moreover, the types of mean can be heterogeneous (numerical values, rates, etc.) and require a harmonisation step before combining them in aggregate factors. We propose a scoring approach to calculate an overall alignment score from such heterogeneous assessment means: metrics, consistency rules and anti-patterns. In this paper, we started with an initial catalog of assessment means we selected from the literature. Table 1 shows these different assessment factors, criteria and means. Note that providing a complete catalog is beyond the scope of this paper, and would require extra-work with expert architects.

**Assessment Means: Harmonisation.** Results obtained from different types of assessment means need to be harmonized in a unified scale so that they can be combined and interpreted correctly. For example, if a given mean gives result within a scale between 0 and 10 and another mean gives a percentage or a rate, this last can be transformed to a number within the same predefined scale. Also, the same result for different assessment means should be considered carefully. For example, the value of "80%" of aligned concepts and the same value of "80%" of misaligned concepts does not reflect the same information about the alignment. Instead, a harmonized result would allow a more uniform appreciation of the alignment level.

**Weighted Score Calculation per Type of Assessment Mean.** Before aggregating all the harmonized results, we first group the results by type of means. We calculate the aggregated weight score from specific weights as follows:

*Metrics weighted.* Let $M_i$ the i-est metric, $rM_i$ its result and $wM_i$ its weight with $\sum wM_i = 1$. To calculate a combined score of selected metrics, we use the formula: $rM = \sum wM_i \times rM_i$.

*Consistency Rules.* Let $C_R$ the i-est metric, $rC_R$ its result and $wC_R$ its weight with $\sum wC_R = 1$. The weighted score of consistency rules score equals: $rCR = \sum wC_R \times rC_R$.

*Anti-patterns.* Let $A_P$ the i-est anti-pattern, $rAP_i$ its result and $wAP_i$ its weight with $\sum wAP_i =$
<table><caption>**Table 1.** Catalog of assessment means</caption><thead><tr><th>Category</th><th>Assessment means</th><th>Factor</th><th>Criteria</th><th>Mean name in related works</th></tr></thead><tbody><tr><td rowspan="10">Metrics</td><td>Support ratio of business concepts per IT concepts</td><td>Functional</td><td>Coverage</td><td>M2 in [5]<br>TC Metrics in [3]</td></tr><tr><td>Useness ratio of IT concepts per business concepts</td><td>Functional</td><td>Coverage</td><td>M5 in [5]</td></tr><tr><td>Over used IT concepts</td><td>Functional</td><td>Overload</td><td>M6 in [5]</td></tr><tr><td>Over implemented business concepts</td><td>Functional</td><td>Overload</td><td>M3 in [5]</td></tr><tr><td>Number of links for a functional business concept</td><td>Functional</td><td>Coverage</td><td>M1 in [5]</td></tr><tr><td>Number of links for a functional IT concept</td><td>Functional</td><td>Coverage</td><td>M4 in [5]</td></tr><tr><td>Ratio of business data concepts IT data concepts</td><td>Data</td><td>Coverage</td><td>Information completeness in [10]</td></tr><tr><td>Ratio of IT data concepts for business data concepts</td><td>Data</td><td>Coverage</td><td>Information completeness in [10]</td></tr><tr><td>Number of links for a business data concept</td><td>Data</td><td>Coverage</td><td>N/D</td></tr><tr><td>Number of links for an IT data concept</td><td>Data</td><td>Coverage</td><td>N/D</td></tr><tr><td>Similarity between linked concepts</td><td>All</td><td>Consistency</td><td>TA Metrics in [3]</td></tr><tr><td rowspan="2">Consistency rules</td><td>Existence of functional links</td><td>All</td><td>Consistency</td><td>CR1 in [5]</td></tr><tr><td>Existence of data links</td><td>All</td><td>Consistency</td><td>CR2 in [5]</td></tr><tr><td rowspan="4">Anti-patterns</td><td>Pure technical integration</td><td>Functional</td><td>Consistency</td><td>AP1 in [14]</td></tr><tr><td>Functional SILO</td><td>Functional</td><td>Consistency</td><td>AP2 in [14]</td></tr><tr><td>Monolith application</td><td>Functional</td><td>Coverage</td><td>AP3 in [14]</td></tr><tr><td>Multiple functional implementation</td><td>Functional</td><td>Coverage</td><td>AP4 in [14]</td></tr></tbody></table>

1. Then, the weighted score of anti-patterns score equals: $rAP = \sum wAPi \times rAPi$. Other assessment means. The enterprise architect in charge of the alignment process also has the possibility of adding new assessment means or new types of assessment means. To integrate them in our approach, it is required to respect the harmonized format used for the already considered assessment means.

**Overall Alignment Score Calculation.** The calculation of the aggregated weighted scores for each type of assessment means, in addition to the associated aggregated weights, enable the calculation of an overall score of alignment. Thus, the alignment overall score *S* is calculated by aggregating the results of the previous step: $S = \omega M \times rM + \omega CR \times rCR + \omega AP \times rAP$ where *wM*, *wCR* and *wAP* are respectively the aggregated weights allocated to metrics overall score *rM*, consistency rules overall score *rCR* and anti-patterns overall score *rAP*.

## 4. A Methodology for Cartography Establishment and Alignment Assessment

In order to perform the alignment assessment approach presented in the previous section, we propose in this section the methodology for operational cartography establishment and alignment assessment. We express the corresponding process in BPMN <fnref n="1" /> as shown in Figure 1.

The main actor is the enterprise architect as she/he is usually responsible for dealing with the alignment-related issues [11]. Throughout the process, the enterprise architect also has to communicate and collaborate with other stakeholders from the business side (e.g., Business Architects) or the IT side (e.g., Solution Architects or Software Architects). The overall process, composed of two sub-processes, starts when the need for alignment assessment is expressed.

### 4.1. Cartography establishment

The first sub-process is called "Cartography establishment" and provides the steps needed to establish the cartography by setting up the Business and IT models, providing their concepts and specifying the links between them (cf. Section 2). This sub-process is depicted in Figure 2.

<footnote n="1">¹https://www.omg.org/spec/BPMN/2.0/PDF</footnote>
<table><caption>**Table 1.** Catalog of assessment means</caption><thead><tr><th>Category</th><th>Assessment means</th><th>Factor</th><th>Criteria</th><th>Mean name in related works</th></tr></thead><tbody><tr><td rowspan="10">Metrics</td><td>Support ratio of business concepts per IT concepts</td><td>Functional</td><td>Coverage</td><td>M2 in [5]<br>TC Metrics in [3]</td></tr><tr><td>Useness ratio of IT concepts per business concepts</td><td>Functional</td><td>Coverage</td><td>M5 in [5]</td></tr><tr><td>Over used IT concepts</td><td>Functional</td><td>Overload</td><td>M6 in [5]</td></tr><tr><td>Over implemented business concepts</td><td>Functional</td><td>Overload</td><td>M3 in [5]</td></tr><tr><td>Number of links for a functional business concept</td><td>Functional</td><td>Coverage</td><td>M1 in [5]</td></tr><tr><td>Number of links for a functional IT concept</td><td>Functional</td><td>Coverage</td><td>M4 in [5]</td></tr><tr><td>Ratio of business data concepts IT data concepts</td><td>Data</td><td>Coverage</td><td>Information completeness in [10]</td></tr><tr><td>Ratio of IT data concepts for business data concepts</td><td>Data</td><td>Coverage</td><td>Information completeness in [10]</td></tr><tr><td>Number of links for a business data concept</td><td>Data</td><td>Coverage</td><td>N/D</td></tr><tr><td>Number of links for an IT data concept</td><td>Data</td><td>Coverage</td><td>N/D</td></tr><tr><td>Similarity between linked concepts</td><td>All</td><td>Consistency</td><td>TA Metrics in [3]</td></tr><tr><td rowspan="2">Consistency rules</td><td>Existence of functional links</td><td>All</td><td>Consistency</td><td>CR1 in [5]</td></tr><tr><td>Existence of data links</td><td>All</td><td>Consistency</td><td>CR2 in [5]</td></tr><tr><td rowspan="4">Anti-patterns</td><td>Pure technical integration</td><td>Functional</td><td>Consistency</td><td>AP1 in [14]</td></tr><tr><td>Functional SILO</td><td>Functional</td><td>Consistency</td><td>AP2 in [14]</td></tr><tr><td>Monolith application</td><td>Functional</td><td>Coverage</td><td>AP3 in [14]</td></tr><tr><td>Multiple functional implementation</td><td>Functional</td><td>Coverage</td><td>AP4 in [14]</td></tr></tbody></table>

1. Then, the weighted score of anti-patterns score equals: $rAP = \sum wAPi \times rAPi$. Other assessment means. The enterprise architect in charge of the alignment process also has the possibility of adding new assessment means or new types of assessment means. To integrate them in our approach, it is required to respect the harmonized format used for the already considered assessment means.

**Overall Alignment Score Calculation.** The calculation of the aggregated weighted scores for each type of assessment means, in addition to the associated aggregated weights, enable the calculation of an overall score of alignment. Thus, the alignment overall score *S* is calculated by aggregating the results of the previous step: $S = \omega M \times rM + \omega CR \times rCR + \omega AP \times rAP$ where *wM*, *wCR* and *wAP* are respectively the aggregated weights allocated to metrics overall score *rM*, consistency rules overall score *rCR* and anti-patterns overall score *rAP*.

# 4. A Methodology for Cartography Establishment and Alignment Assessment

In order to perform the alignment assessment approach presented in the previous section, we propose in this section the methodology for operational cartography establishment and alignment assessment. We express the corresponding process in BPMN <fnref n="1" /> as shown in Figure 1.

The main actor is the enterprise architect as she/he is usually responsible for dealing with the alignment-related issues [11]. Throughout the process, the enterprise architect also has to communicate and collaborate with other stakeholders from the business side (e.g., Business Architects) or the IT side (e.g., Solution Architects or Software Architects). The overall process, composed of two sub-processes, starts when the need for alignment assessment is expressed.

## 4.1. Cartography establishment

The first sub-process is called "Cartography establishment" and provides the steps needed to establish the cartography by setting up the Business and IT models, providing their concepts and specifying the links between them (cf. Section 2). This sub-process is depicted in Figure 2.

<footnote n="1">¹https://www.omg.org/spec/BPMN/2.0/PDF</footnote>
<figure><img src="image_2.png" /><figcaption>**Fig. 1.** A process for operational cartography establishment and alignment assessment</figcaption></figure>

The initial step is to check the existence of the required Business and IT models: (i) When

<figure><img src="image_3.png" /><figcaption>**Fig. 2.** A process for Cartography establishment</figcaption></figure>

available, the architect needs to check if the used modelling languages allows representing all the required Business and IT information. If this it not the case, she can perform corresponding transformations from the used modelling languages to more suitable ones (manually or in an automated way). (ii) If not available, the models need to be built from scratch using suitable modelling languages. To do so, the enterprise architect solicit both Business Architects for collecting the Business requirements and IT architects for getting the IT specification. The objective is that they build together the necessary models and elaborate on the links between these models (cf. Section 2). The result of this sub-process is the obtained cartography that will be assessed in the following sub-process.

## 4.2. Alignment Assessment

The second sub-process is called "Alignment assessment" and is depicted in Figure 3. It describes the steps going from the obtained cartography to the overall alignment score in two main steps. First, the structure of assessment is defined by the architect via the selection of the factors, criteria and assessment means with the desired weights. Second, the results of these assessment means are computed and then harmonized accordingly (if needed). Finally, the different weighted scores are calculated before aggregating them to obtain the overall score.
<figure><img src="image_3.png" /><figcaption>**Fig. 1.** A process for operational cartography establishment and alignment assessment</figcaption></figure>

The initial step is to check the existence of the required Business and IT models: (i) When

<figure><img src="image_4.png" /><figcaption>**Fig. 2.** A process for Cartography establishment</figcaption></figure>

available, the architect needs to check if the used modelling languages allows representing all the required Business and IT information. If this it not the case, she can perform corresponding transformations from the used modelling languages to more suitable ones (manually or in an automated way). (ii) If not available, the models need to be built from scratch using suitable modelling languages. To do so, the enterprise architect solicit both Business Architects for collecting the Business requirements and IT architects for getting the IT specification. The objective is that they build together the necessary models and elaborate on the links between these models (cf. Section 2). The result of this sub-process is the obtained cartography that will be assessed in the following sub-process.

## 4.2. Alignment Assessment

The second sub-process is called "Alignment assessment" and is depicted in Figure 3. It describes the steps going from the obtained cartography to the overall alignment score in two main steps. First, the structure of assessment is defined by the architect via the selection of the factors, criteria and assessment means with the desired weights. Second, the results of these assessment means are computed and then harmonized accordingly (if needed). Finally, the different weighted scores are calculated before aggregating them to obtain the overall score.
<figure><img src="image_4.png" /><figcaption>Fig. 3. A process for Alignment Assessment</figcaption></figure>

The architect can look at the overall score, analyse it, and decide if she accepts the results or
wants to go back in the process. This sub-process corresponds to the Alignment Assessment
approach we presented in the Section 3.

**5. Application of the Methodology and Approach on a Case Study**

We experiment with our proposed methodology (cf. Section 4) and corresponding assessment approach (cf. Section 3.2) by applying them on the *SoftSlate Commerce Java shopping cart system* powering dozens of E-commerce websites. This case study (i) is realistic since *SoftSlate Commerce* actually exists<fnref n="2" />, (ii) is challenging since business and application models are not provided (we designed them from scratch, simulating the case where an information system would not come with such models), (iii) is reasonably complex in terms of structure and relatively large in terms of number of lines of code, (iv) provides an implementation available online<fnref n="3" />, including its complete source code and documentation.

**5.1. Setting the Cartography of SoftSlate**

**Check the existence of models.** Models representing the business and application layers are not available. The only exploitable inputs to build the needed models are the user guide, source code, and MVC pattern architecture description.

**Design models.** We exploit the user guide as a business specification to design a business process model. Then, we rely on the source code and MVC pattern architecture description as IT documents to design an (IT) application model. Once these models are designed, the next step is to check their validity. In our case, we do not have a direct contact with SoftSlate's business domain experts or developers. We validated the models ourselves by cross-checking them.

**Create Links.** We used a simple typology of links [5] to create alignment links between the designed models, resulting in a cartography of the SoftSlate system. Due to the available resources, we elaborated on a partial cartography that only details the administrator part of the system. However, this cartography is rich enough in terms of concepts and links.

**5.2. Alignment Assessment Structure for SoftSlate**

**Alignment factors.** For this first experiment, we consider only the functional assessment factor. Other factors could be integrated in further and more advanced experiments.

<footnote n="2">²https://www.softslate.com/</footnote>

<footnote n="3">³The SoftSlate web application - https://www.softslate.com/category/archivedDocs</footnote>
<figure><img src="image_5.png" /><figcaption>**Fig. 3.** A process for Alignment Assessment</figcaption></figure>

The architect can look at the overall score, analyse it, and decide if she accepts the results or wants to go back in the process. This sub-process corresponds to the Alignment Assessment approach we presented in the Section 3.

**5. Application of the Methodology and Approach on a Case Study**

We experiment with our proposed methodology (cf. Section 4) and corresponding assessment approach (cf. Section 3.2) by applying them on the *SoftSlate Commerce Java shopping cart system* powering dozens of E-commerce websites. This case study (i) is realistic since *SoftSlate Commerce* actually exists<fnref n="2" />, (ii) is challenging since business and application models are not provided (we designed them from scratch, simulating the case where an information system would not come with such models), (iii) is reasonably complex in terms of structure and relatively large in terms of number of lines of code, (iv) provides an implementation available online<fnref n="3" />, including its complete source code and documentation.

**5.1. Setting the Cartography of SoftSlate**

**Check the existence of models.** Models representing the business and application layers are not available. The only exploitable inputs to build the needed models are the user guide, source code, and MVC pattern architecture description.

**Design models.** We exploit the user guide as a business specification to design a business process model. Then, we rely on the source code and MVC pattern architecture description as IT documents to design an (IT) application model. Once these models are designed, the next step is to check their validity. In our case, we do not have a direct contact with SoftSlate's business domain experts or developers. We validated the models ourselves by cross-checking them.

**Create Links.** We used a simple typology of links [5] to create alignment links between the designed models, resulting in a cartography of the SoftSlate system. Due to the available resources, we elaborated on a partial cartography that only details the administrator part of the system. However, this cartography is rich enough in terms of concepts and links.

**5.2. Alignment Assessment Structure for SoftSlate**

**Alignment factors.** For this first experiment, we consider only the functional assessment factor. Other factors could be integrated in further and more advanced experiments.

<footnote n="2">²https://www.softslate.com/</footnote>

<footnote n="3">³The SoftSlate web application - https://www.softslate.com/category/archivedDocs</footnote>
**Alignment criteria.** Our alignment assessment structure for SoftSlate relies on two main assessment criteria corresponding to the functional assessment factor: **Coverage and Overload**. Coverage consists in verifying that one business layer concept is at least implemented by one application layer concept. Overload consists in verifying that no business concept is over-implemented (e.g., many applications for one business process) and/or no application concept is over-used (e.g., one application for many business processes). **Consistency.** In this use case, consistency consists in avoiding a misalignment between different alignment factors and layers.

**Assessment means: Selection.** According to the defined alignment criteria, we select the following assessment means from the catalog (cf. Table 1): We consider **Metric 2**, **Metric 3**, **Metric 5 & Metric 6** for coverage and overload verification. We implement consistency rules **CR1** and **CR2** for consistency verification. We develop algorithms supporting the detection of anti-patterns **AP1**, **AP2**, **AP3**, **AP4** also for consistency and coverage verification. The two first columns on the left in Table 2 shows these selected assessment means.

<table><caption>**Table 2.** Softslate score calculation</caption><thead><tr><th>ASSESSMENT MEANS</th><th colspan="3">COMPUTATION & RESULTS</th><th>w</th><th>Harmonisation OF RESULTS</th><th>SCORE (r)</th><th>Aggregated WEIGHT</th><th>Alignment SCORE (S)</th></tr></thead><tbody><tr><td rowspan="4">METRICS</td><td>M2</td><td>41,60%</td><td>0,25</td><td>58,40%</td><td></td><td rowspan="4">73,65%</td><td rowspan="4">0,2</td><td rowspan="4"></td></tr><tr><td>M3</td><td>0</td><td>0,25</td><td>100%</td><td></td></tr><tr><td>M5</td><td>53,80%</td><td>0,25</td><td>46,20%</td><td></td></tr><tr><td>M6</td><td>1</td><td>0,25</td><td>90%</td><td></td></tr><tr><td rowspan="2">CONSISTENCY RULES</td><td>CR1</td><td>0</td><td>0,5</td><td>100%</td><td></td><td rowspan="2">100%</td><td rowspan="2">0,4</td><td rowspan="2">93,73%</td></tr><tr><td>CR2</td><td>0</td><td>0,5</td><td>100%</td><td></td></tr><tr><td rowspan="4">ANTI-PATTERN DETECTION</td><td>AP1</td><td>0</td><td>0,25</td><td>100%</td><td></td><td rowspan="4">97,5%</td><td rowspan="4">0,4</td><td rowspan="4"></td></tr><tr><td>AP2</td><td>0</td><td>0,25</td><td>100%</td><td></td></tr><tr><td>AP3</td><td>1</td><td>0,25</td><td>90%</td><td></td></tr><tr><td>AP4</td><td>0</td><td>0,25</td><td>100%</td><td></td></tr></tbody></table>

**Assessment means: Weighting.** We reproduce the weighting system from Section 3.2:

* *Specific weights.* The column *w* in Table 2 reports on the specific weights allocated to each assessment mean. For the four metrics, we allocate the same weight as we consider them of equal importance. As a result, we have $wMi = 1/\text{number of metrics} = 0,25$. For the two consistency rules, we also allocated the same weight as well. As a result, we have $wCRi = 0,5$. Finally, we allocated the same weight to the four anti-patterns. As a result, we have $wAPi = 0,25$. Note that it is possible to customize the different specific weights for the metrics, consistency rules, or anti-patterns, depending on how important they are for the architect.

* *Aggregated weights.* A dedicated column in Table 2 shows the aggregated weights per type of assessment means. In our case, we consider that consistency rules and anti-patterns represent more powerful indicators of the alignment level than metrics, as they allow validating advanced constructs in the cartography (notably in terms of coverage). For example, a detected inconsistency may be critical for the system whereas an unimplemented business process does not necessarily implies an error. Therefore, we allocated a smaller weight to metrics ($wM = 0,2$) than to consistency rules and anti-patterns ($wCR = wAP = 0,4$).

## 5.3. Alignment Score Calculation for SoftSlate

**Compute results.** The results are shown in the column **Computation & Results** in Table 2.

**Harmonisation.** These results need to be harmonised as explained in Section 3.2.

a) *Harmonisation of metrics results.* We propose to use an unified format as follows.

* Metric M2 refers to the rate of unimplemented business processes, i.e. not related to any
**Alignment criteria.** Our alignment assessment structure for SoftSlate relies on two main assessment criteria corresponding to the functional assessment factor: **Coverage and Overload**. Coverage consists in verifying that one business layer concept is at least implemented by one application layer concept. Overload consists in verifying that no business concept is over-implemented (e.g., many applications for one business process) and/or no application concept is over-used (e.g., one application for many business processes). **Consistency.** In this use case, consistency consists in avoiding a misalignment between different alignment factors and layers.

**Assessment means: Selection.** According to the defined alignment criteria, we select the following assessment means from the catalog (cf. Table 1): We consider **Metric 2**, **Metric 3**, **Metric 5 & Metric 6** for coverage and overload verification. We implement consistency rules **CR1** and **CR2** for consistency verification. We develop algorithms supporting the detection of anti-patterns **AP1**, **AP2**, **AP3**, **AP4** also for consistency and coverage verification. The two first columns on the left in Table 2 shows these selected assessment means.

<table><caption>**Table 2.** Softslate score calculation</caption><thead><tr><th>ASSESSMENT MEANS</th><th colspan="3">COMPUTATION & RESULTS</th><th>w</th><th>Harmonisation OF RESULTS</th><th>SCORE (r)</th><th>Aggregated WEIGHT</th><th>Alignment SCORE (S)</th></tr></thead><tbody><tr><td rowspan="4">METRICS</td><td>M2</td><td>41,60%</td><td>0,25</td><td>58,40%</td><td></td><td rowspan="4">73,65%</td><td rowspan="4">0,2</td><td rowspan="4"></td></tr><tr><td>M3</td><td>0</td><td>0,25</td><td>100%</td></tr><tr><td>M5</td><td>53,80%</td><td>0,25</td><td>46,20%</td></tr><tr><td>M6</td><td>1</td><td>0,25</td><td>90%</td></tr><tr><td rowspan="2">CONSISTENCY RULES</td><td>CR1</td><td>0</td><td>0,5</td><td>100%</td><td></td><td rowspan="2">100%</td><td rowspan="2">0,4</td><td rowspan="2">93,73%</td></tr><tr><td>CR2</td><td>0</td><td>0,5</td><td>100%</td></tr><tr><td rowspan="4">ANTI-PATTERN DETECTION</td><td>AP1</td><td>0</td><td>0,25</td><td>100%</td><td></td><td rowspan="4">97,5%</td><td rowspan="4">0,4</td><td rowspan="4"></td></tr><tr><td>AP2</td><td>0</td><td>0,25</td><td>100%</td></tr><tr><td>AP3</td><td>1</td><td>0,25</td><td>90%</td></tr><tr><td>AP4</td><td>0</td><td>0,25</td><td>100%</td></tr></tbody></table>

**Assessment means: Weighting.** We reproduce the weighting system from Section 3.2:

* *Specific weights.* The column *w* in Table 2 reports on the specific weights allocated to each assessment mean. For the four metrics, we allocate the same weight as we consider them of equal importance. As a result, we have $wMi = 1/\text{number of metrics} = 0,25$. For the two consistency rules, we also allocated the same weight as well. As a result, we have $wCRi = 0,5$. Finally, we allocated the same weight to the four anti-patterns. As a result, we have $wAPi = 0,25$. Note that it is possible to customize the different specific weights for the metrics, consistency rules, or anti-patterns, depending on how important they are for the architect.

* *Aggregated weights.* A dedicated column in Table 2 shows the aggregated weights per type of assessment means. In our case, we consider that consistency rules and anti-patterns represent more powerful indicators of the alignment level than metrics, as they allow validating advanced constructs in the cartography (notably in terms of coverage). For example, a detected inconsistency may be critical for the system whereas an unimplemented business process does not necessarily implies an error. Therefore, we allocated a smaller weight to metrics ($wM = 0,2$) than to consistency rules and anti-patterns ($wCR = wAP = 0,4$).

## 5.3. Alignment Score Calculation for SoftSlate

**Compute results.** The results are shown in the column **Computation & Results** in Table 2.

**Harmonisation.** These results need to be harmonised as explained in Section 3.2.

a) *Harmonisation of metrics results.* We propose to use an unified format as follows.

* Metric M2 refers to the rate of unimplemented business processes, i.e. not related to any
implementation link. The harmonised rate *rM2* of Metric 2 becomes the rate of implemented business processes. Thus, the higher is *rM2* the better is the appreciation of the alignment level.

* Metric M3 refers to the list of the most implemented business processes, i.e. implemented by more than a given number of implementation links. The harmonised rate *rM3* of Metric 3 becomes calculated as *rM3* = 100% - (N * 10%) with N the number of elements in the list. Thus, the higher is *rM3* the better is the appreciation of the alignment level.

* Metric M5 refers to the rate of unused application functions, i.e. not related by any implementation link. The harmonised rate *rM5* of Metric 5 becomes the rate of used application functions. Thus, the higher is *rM5* the better is the appreciation of the alignment level.

* Metric M6 refers to the most used application functions, i.e. having more than a given number of implementation links. The harmonised rate *rM6* of Metric 6 is calculated as *rM6* = 100% - (N * 10%) with N the number of elements in the list. Thus, the higher is *rM6* the better is the appreciation of the alignment level.

b) *Harmonisation of consistency rules results.* We set $rCRi = 100\% - (N * 10\%)$ where N is the number of occurrences when consistency rule *i* is not verified. For instance, if there is 1 occurrence of the non-verified consistency rule *k* and 2 occurrences of the non-verified consistency rule *l*, then the harmonised results are:

$$rCRk = 100\% - (1 * 10\%) = 90\% \text{ and } rCRl = 100\% - (2 * 10\%) = 80\%.$$

c) *Harmonisation of anti-patterns results.* For anti-patterns we set $rAPi = 100\% - (N * 10\%)$ where N is the number of occurrences when Anti-Pattern *i* is detected. For instance, if there is 0 occurrence of Anti-Pattern *p* then $rAPp = 100\% - (0 * 10\%) = 0\%$.

All these results are reported in Table 2 in the column **Harmonisation of results**.

**Weighted Score Calculation per Type of Assessment Mean.** By combining the harmonised results and specific weights as explained in Section 3, we obtained the aggregated weighted score for each assessment mean's type. The results are given in column **SCORE (r)** of Table 2.

* For metrics, we have: $rM = \sum_{i=2}^{6} \omega M_i \times rM_i = \omega M_2 \times rM_2 + \omega M_3 \times rM_3 + \omega M_5 \times rM_5 + \omega M_6 \times rM_6 = 73.65\%$

* For consistency rules, we have: $rCR = \sum_{i=1}^{2} \omega CR_i \times rCR_i = \omega CR_1 \times rCR_1 + \omega CR_2 \times rCR_2 = 100\%$

* For anti-patterns, we have: $rAP = \sum_{i=1}^{4} \omega AP_i \times rAP_i = \omega AP_1 \times rAP_1 + \omega AP_2 \times rAP_2 + \omega AP_3 \times rAP_3 + \omega AP_4 \times rAP_4 = 97.5\%$

**Overall Alignment Score Calculation.** Based on the calculation of the aggregated weighted scores and on the associated aggregated weights, we can now calculate the overall alignment score. Thus, we have: $S = \omega M \times rM + \omega CR \times rCR + \omega AP \times rAP = 0,2 \times 73,95\% + 0,4 \times 100\% + 0,4 \times 97,5\% = 93.73\%$

When low, the overall alignment score is an alarm indicating a potential misalignment. In that case, the architect needs to check the nodes of the scoring tree not having a good score. The objective is to identify the alignment means providing a poor result. Different interpretations are possible: 1) The initial cartography may be incomplete → the architect must double-check and add the missing model elements or links between these elements. 2) The implementation of the assessment means may be incomplete → the architect needs to revise the used algorithms, e.g. to take into account all the links between model elements. 3) The weights may be wrongly allocated → the architect has to revise the considered weights, e.g. a (minor) factor can have an
implementation link. The harmonised rate *rM2* of Metric 2 becomes the rate of imple-
mented business processes. Thus, the higher is *rM2* the better is the appreciation of the
alignment level.

* Metric M3 refers to the list of the most implemented business processes, i.e. implemented by more than a given number of implementation links. The harmonised rate *rM3* of Metric 3 becomes calculated as *rM3* = 100% - (N * 10%) with N the number of elements in the list. Thus, the higher is *rM3* the better is the appreciation of the alignment level.

* Metric M5 refers to the rate of unused application functions, i.e. not related by any imple-
mentation link. The harmonised rate *rM5* of Metric 5 becomes the rate of used application
functions. Thus, the higher is *rM5* the better is the appreciation of the alignment level.

* Metric M6 refers to the most used application functions, i.e. having more than a given number of implementation links. The harmonised rate *rM6* of Metric 6 is calculated as *rM6* = 100% - (N * 10%) with N the number of elements in the list. Thus, the higher is *rM6* the better is the appreciation of the alignment level.

b) *Harmonisation of consistency rules results.* We set $rCRi = 100\% - (N * 10\%)$ where N is the number of occurrences when consistency rule *i* is not verified. For instance, if there is 1 occurrence of the non-verified consistency rule *k* and 2 occurrences of the non-verified consistency rule *l*, then the harmonised results are:

$$
rCRk = 100\% - (1 * 10\%) = 90\% \text{ and } rCRl = 100\% - (2 * 10\%) = 80\%.
$$

c) *Harmonisation of anti-patterns results.* For anti-patterns we set $rAPi = 100\% - (N * 10\%)$ where N is the number of occurrences when Anti-Pattern *i* is detected. For instance, if there is 0 occurrence of Anti-Pattern *p* then $rAPp = 100\% - (0 * 10\%) = 0\%$.

All these results are reported in Table 2 in the column **Harmonisation of results.**

**Weighted Score Calculation per Type of Assessment Mean.** By combining the harmonised results and specific weights as explained in Section 3, we obtained the aggregated weighted score for each assessment mean’s type. The results are given in column **SCORE (r)** of Table 2.

* For metrics, we have: $rM = \sum_{i=2}^{6} \omega M_i \times rM_i = \omega M_2 \times rM_2 + \omega M_3 \times rM_3 + \omega M_5 \times rM_5 + \omega M_6 \times rM_6 = 73.65\%$

* For consistency rules, we have: $rCR = \sum_{i=1}^{2} \omega CR_{i} \times rCR_{i} = \omega CR_{1} \times rCR_{1} + \omega CR_{2} \times rCR_{2} = 100\%$

* For anti-patterns, we have: $rAP = \sum_{i=1}^{4} \omega AP_{i} \times rAP_{i} = \omega AP_{1} \times rAP_{1} + \omega AP_{2} \times rAP_{2} + \omega AP_{3} \times rAP_{3} + \omega AP_{4} \times rAP_{4} = 97.5\%$

**Overall Alignment Score Calculation.** Based on the calculation of the aggregated weighted scores and on the associated aggregated weights, we can now calculate the overall alignment score. Thus, we have: $S = \omega M \times rM + \omega CR \times rCR + \omega AP \times rAP = 0,2 \times 73,95\% + 0,4 \times 100\% + 0,4 \times 97,5\% = 93.73\%$

When low, the overall alignment score is an alarm indicating a potential misalignment. In
that case, the architect needs to check the nodes of the scoring tree not having a good score. The
objective is to identify the alignment means providing a poor result. Different interpretations
are possible: 1) The initial cartography may be incomplete → the architect must double-check
and add the missing model elements or links between these elements. 2) The implementation of
the assessment means may be incomplete → the architect needs to revise the used algorithms,
e.g. to take into account all the links between model elements. 3) The weights may be wrongly
allocated → the architect has to revise the considered weights, e.g. a (minor) factor can have an
exceeding weight compared to others. 4) The alignment criteria may be complex to assess →
the architect must perform a deeper analysis of some criteria such as coverage and consistency.

In the general case, the obtained alignment score must always be carefully considered and analysed according to the architect's knowledge and experience. For instance, in our case, the alignment score is high (93.73 %) but only two business processes have been modelled so far.

**6. Discussion**

Up to now, the proposed alignment assessment approach and corresponding methodology have only been applied on the SoftSlate case study. They need to be experimented on other case studies. Moreover, they must also be evaluated with more alignment assessment factors than the functional assessment one we considered in the case study. The realisation of these additional experiments will require to have access to the Business and IT models of more information systems, which is a major obstacle since companies do not share their IS. Otherwise, it will require to build these models and corresponding links manually, which is time consuming and error prone without the business knowledge. If IS are made available, our work could gain strength by using AI and LLM in order to exploit the huge amount of information within the IS. This could also help to propose a maturity model (like CMMI).

As mentioned in Section 3.2, the proposed overall alignment score can be an interesting indicator of the current alignment level. However, its interpretation may differ from one architect to another, or between the Business and IT actors. To prevent from such a situation, it is important to define explicit alignment objectives as a formal contract with a set of alignment clauses to be checked, a set of thresholds integrated into an interactive dashboard, etc. The defined objectives could notably include corresponding specific weights or thresholds for particular factors/criteria, so that the architect could specify her/his alignment strategy.

In addition, our current catalog of assessment means could be complemented with more implementations of metrics, consistency rules, anti-patterns, and eventually other means. In this paper, we started by collecting from the literature some existing assessment factors, criteria and means. In the long term, the development of a richer open repository dedicated to operational Business-IT alignment would be beneficial for enterprise architects. This will notably imply a direct collaboration between researchers and architects from different companies.

Another area for improvement would be to provide alternative calculation methods for align-
ment assessment. The proposed variations should concern not only the weighting system but
also the formulas themselves. This way, we could build and provide a library of calculation
methods that could be shared across different alignment processes in the context of various in-
formation systems. Going further, different calculation methods could be considered depending
on the selected factors/criteria (e.g., a coverage-specific method) and then eventually combined
together whenever relevant.

Overall, these alignment objectives, assessment means, and calculation methods, can be ad-
apted in the context of our approach. Our current implementation already supports a given set of
objectives, means, and methods. It also allows developing and integrating new ones by replacing
and/or complementing the existing ones. For instance, a challenge is to tackle the complexity of
today's SW architectures (multi-layer architectures, micro-services, etc.) by proposing appro-
priate assessment factors, criteria and means. In any case, a finer-grained definition and selection
process could be specified to better guide the architect while expressing her alignment needs. To
go further in terms of tooling, a deeper integration within Archi (or another open source CASE
tool) can also be envisioned and that can help to propose a customisable framework. This could
be done in collaboration with an editor for instance.

Finally, we could propose guidelines on how to improve the current cartography based on
the obtained alignment assessment results. Such recommendations could be just indications on
where in the cartography the architects need to look at in order to improve the alignment. They
exceeding weight compared to others. 4) The alignment criteria may be complex to assess →
the architect must perform a deeper analysis of some criteria such as coverage and consistency.

In the general case, the obtained alignment score must always be carefully considered and analysed according to the architect's knowledge and experience. For instance, in our case, the alignment score is high (93.73 %) but only two business processes have been modelled so far.

# 6. Discussion

Up to now, the proposed alignment assessment approach and corresponding methodology have only been applied on the SoftSlate case study. They need to be experimented on other case studies. Moreover, they must also be evaluated with more alignment assessment factors than the functional assessment one we considered in the case study. The realisation of these additional experiments will require to have access to the Business and IT models of more information systems, which is a major obstacle since companies do not share their IS. Otherwise, it will require to build these models and corresponding links manually, which is time consuming and error prone without the business knowledge. If IS are made available, our work could gain strength by using AI and LLM in order to exploit the huge amount of information within the IS. This could also help to propose a maturity model (like CMMI).

As mentioned in Section 3.2, the proposed overall alignment score can be an interesting indicator of the current alignment level. However, its interpretation may differ from one architect to another, or between the Business and IT actors. To prevent from such a situation, it is important to define explicit alignment objectives as a formal contract with a set of alignment clauses to be checked, a set of thresholds integrated into an interactive dashboard, etc. The defined objectives could notably include corresponding specific weights or thresholds for particular factors/criteria, so that the architect could specify her/his alignment strategy.

In addition, our current catalog of assessment means could be complemented with more implementations of metrics, consistency rules, anti-patterns, and eventually other means. In this paper, we started by collecting from the literature some existing assessment factors, criteria and means. In the long term, the development of a richer open repository dedicated to operational Business-IT alignment would be beneficial for enterprise architects. This will notably imply a direct collaboration between researchers and architects from different companies.

Another area for improvement would be to provide alternative calculation methods for align-
ment assessment. The proposed variations should concern not only the weighting system but
also the formulas themselves. This way, we could build and provide a library of calculation
methods that could be shared across different alignment processes in the context of various in-
formation systems. Going further, different calculation methods could be considered depending
on the selected factors/criteria (e.g., a coverage-specific method) and then eventually combined
together whenever relevant.

Overall, these alignment objectives, assessment means, and calculation methods, can be ad-
apted in the context of our approach. Our current implementation already supports a given set of
objectives, means, and methods. It also allows developing and integrating new ones by replacing
and/or complementing the existing ones. For instance, a challenge is to tackle the complexity of
today's SW architectures (multi-layer architectures, micro-services, etc.) by proposing appro-
priate assessment factors, criteria and means. In any case, a finer-grained definition and selection
process could be specified to better guide the architect while expressing her alignment needs. To
go further in terms of tooling, a deeper integration within Archi (or another open source CASE
tool) can also be envisioned and that can help to propose a customisable framework. This could
be done in collaboration with an editor for instance.

Finally, we could propose guidelines on how to improve the current cartography based on
the obtained alignment assessment results. Such recommendations could be just indications on
where in the cartography the architects need to look at in order to improve the alignment. They
could also be more precise instructions including transformation plans for the IT layer according
to the state of the Business layer.

Despite these current limitations, we already showed that the proposed alignment assess-
ment approach and corresponding methodology are applicable in practice on a realistic case
study. Thus, they are also relevant to any other information system sharing similar character-
istics than *SoftSlate*. Moreover, our approach is quite novel as combining different types of
assessment means to provide aggregated alignment indicators (cf. Section 2). Furthermore,
our methodology integrates two important consecutive steps of the alignment process, namely
cartography establishment and alignment assessment. Except from a few works proposing dir-
ectives for alignment evolution based on previous assessment results [3, 20], the other existing
approaches only address one step of the process (often cartography establishment) [1, 19].

7. Conclusion

Enterprise architects need more methods and tools in order to assist them in their Business-IT
alignment activities. Despite various research efforts, there is still no global solution to fully
support operational BITA, nor to assess the current state of operational alignment. To go a
step further in this direction, we proposed an alignment assessment approach that rely on the
combination of several different assessment means (metrics, consistency rules, anti-patterns).
Thanks to this approach, the architects can compute an overall alignment score that can guide
them when dealing with operational alignment-related issues. In addition, we also proposed a
global methodology that integrates this alignment assessment approach along with a previous
cartography establishment phase. Such a cartography is composed of both Business and IT
models, interrelated via different types of alignment links. To illustrate the applicability of these
approach and methodology, we experimented with them on a realistic case study named SoftS-
late. We established a cartography of the SoftSlate information system that we then assessed by
considering four metrics, two consistency rules and four anti-patterns.

Among the different possible future works we discussed earlier in the paper, we can not-
ably mention the realisation of additional experiments in the context of other case studies and
information systems. Additional tool support can also be provided to the enterprise architects
by offering them an explicit way of specifying their alignment objectives. Moreover, we can
mention the enrichment of the proposed catalog of assessment means, in parallel to the work
on alternative calculation methods for improving the quality of the overall alignment score. As
mentioned before, the extended tool support could rely on an open repository dedicated to op-
erational Business-IT alignment. This support could also include the provisioning of detailed
recommendations to assist enterprise architects on how to realise in practice the operational
Business-IT alignment they target. For instance, already identified anti-patterns could be pos-
sibly resolved by following such recommendations [14].

References

1. André, P., Tamzalit, D., Benjilany, A., Bruneliere, H.: A review of core operational business-it alignment. In: ISD 2023 Proceedings. pp. 1–12. AIS eLibrary, Lisbon, Portugal (2023)

2. Aversano, L., Bodhuin, T., Tortorella, M.: Assessment and impact analysis for aligning business processes and software systems. In: Proceedings of the 2005 ACM symposium on Applied computing. pp. 1338–1343 (2005)

3. Aversano, L., Grasso, C., Tortorella, M.: Managing the alignment between business processes and software systems. Information and Software Technology 72, 171–188 (2016)

4. Avila, O., Goepp, V., Kiefer, F.: Addressing alignment concerns into the design of
could also be more precise instructions including transformation plans for the IT layer according
to the state of the Business layer.

Despite these current limitations, we already showed that the proposed alignment assess-
ment approach and corresponding methodology are applicable in practice on a realistic case
study. Thus, they are also relevant to any other information system sharing similar character-
istics than *SoftSlate*. Moreover, our approach is quite novel as combining different types of
assessment means to provide aggregated alignment indicators (cf. Section 2). Furthermore,
our methodology integrates two important consecutive steps of the alignment process, namely
cartography establishment and alignment assessment. Except from a few works proposing dir-
ectives for alignment evolution based on previous assessment results [3, 20], the other existing
approaches only address one step of the process (often cartography establishment) [1, 19].

7. Conclusion

Enterprise architects need more methods and tools in order to assist them in their Business-IT
alignment activities. Despite various research efforts, there is still no global solution to fully
support operational BITA, nor to assess the current state of operational alignment. To go a
step further in this direction, we proposed an alignment assessment approach that rely on the
combination of several different assessment means (metrics, consistency rules, anti-patterns).
Thanks to this approach, the architects can compute an overall alignment score that can guide
them when dealing with operational alignment-related issues. In addition, we also proposed a
global methodology that integrates this alignment assessment approach along with a previous
cartography establishment phase. Such a cartography is composed of both Business and IT
models, interrelated via different types of alignment links. To illustrate the applicability of these
approach and methodology, we experimented with them on a realistic case study named *SoftS-
late*. We established a cartography of the *SoftSlate* information system that we then assessed by
considering four metrics, two consistency rules and four anti-patterns.

Among the different possible future works we discussed earlier in the paper, we can not-
ably mention the realisation of additional experiments in the context of other case studies and
information systems. Additional tool support can also be provided to the enterprise architects
by offering them an explicit way of specifying their alignment objectives. Moreover, we can
mention the enrichment of the proposed catalog of assessment means, in parallel to the work
on alternative calculation methods for improving the quality of the overall alignment score. As
mentioned before, the extended tool support could rely on an open repository dedicated to op-
erational Business-IT alignment. This support could also include the provisioning of detailed
recommendations to assist enterprise architects on how to realise in practice the operational
Business-IT alignment they target. For instance, already identified anti-patterns could be pos-
sibly resolved by following such recommendations [14].

References

1. André, P., Tamzalit, D., Benjilany, A., Bruneliere, H.: A review of core operational business-it alignment. In: ISD 2023 Proceedings. pp. 1–12. AIS eLibrary, Lisbon, Portugal (2023)

2. Aversano, L., Bodhuin, T., Tortorella, M.: Assessment and impact analysis for aligning business processes and software systems. In: Proceedings of the 2005 ACM symposium on Applied computing. pp. 1338–1343 (2005)

3. Aversano, L., Grasso, C., Tortorella, M.: Managing the alignment between business processes and software systems. Information and Software Technology 72, 171–188 (2016)

4. Avila, O., Goepp, V., Kiefer, F.: Addressing alignment concerns into the design of
domain-specific information systems. Journal of Manufacturing Technology Management 29(5), 726-745 (2018)

5. Benjilany, A., André, P., Tamzalit, D., Bruneliere, H.: Towards a link mapping and evaluation approach for Core Operational Business-IT Alignment. In: 26th International Conf. on Enterprise Information Systems (ICEIS 2024). Insticc, Angers, France (2024)

6. Buchwald, S., Bauer, T., Reichert, M.: Bridging the Gap between Business Process Models and Service Composition Specifications (2012)

7. Castellanos, C., Correal, D.: KALCAS: A Framework for Semi-automatic Alignment of Data and Business Processes Architecture. In: Advances in Databases and Information Systems. pp. 111-124. LNCS, Springer, Berlin, Heidelberg (2012)

8. Cavano, J.P., McCall, J.A.: A framework for the measurement of software quality. In: Proceedings of the Software Quality Assurance Workshop on Functional and Performance Issues. p. 133-139. ACM, New York, NY, USA (1978)

9. Darii, H., Laval, J., Botta-Genoulaz, V., Goepp, V.: Measurement of the business/it alignment of information systems. In: ILS 2020-8th International Conference on Information Systems, Logistics and Supply Chain. pp. 228-235 (2020)

10. Etien, A., Rolland, C.: Measuring the fitness relationship. Requirements Engineering 10(3), 184-197 (Aug 2005)

11. Gellweiler, C.: It architects and it-business alignment: a theoretical review. Procedia Computer Science 196, 13-20 (2022), international Conference on ENTERprise Information Systems 2021

12. Gerow, J.E., Thatcher, J.B., Grover, V.: Six types of it-business strategic alignment: an investigation of the constructs and their measurement. European Journal of Information Systems 24(5), 465-491 (2015)

13. Goepp, V., Avila, O.: An extended-strategic alignment model for technical information system alignment. International Journal of Computer Integrated Manufacturing 28(12), 1275-1290 (2015)

14. Gouigoux, J.P., Tamzalit, D.: Business-it alignment anti-patterns: a thought from an empirical point of view. In: ISD 2021, Valencia, Spain (2021)

15. Habba, M., Fredj, M., Benabdellah Chaouni, S.: Alignment between Business Requirement, Business Process, and Software System: A Systematic Literature Review. Journal of Engineering 2019, 6918105 (2019)

16. Henderson, J.C., Venkatraman, H.: Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems 38(2.3), 472-484 (1999)

17. Imgharene, K., Doumi, K., Baina, S.: Agility metrics model for business it alignment. In: 2020 7th International Conference on Control, Decision and Information Technologies (CoDIT). vol. 1, pp. 662-667 (2020)

18. Küster, J.M., Völzer, H., Favre, C., Branco, M.C., Czarnecki, K.: Supporting different process views through a shared process model. Softw. Syst. Model. 15(4), 1207-1233 (2016)

19. Őri, D., Szabó, Z.: A systematic literature review on business-it misalignment research. Information Systems and e-Business Management pp. 1-31 (2024)

20. Pepin, J., André, P., Attiogbé, J.C., Breton, E.: An improved model facet method to support EA alignment. Complex Syst. Informatics Model. Q. 9, 1-27 (2016)

21. Tarafdar, M., Qrunfleh, S.: It-business alignment: A two-level analysis. Information Systems Management 26(4), 338-349 (2009)

22. The Open Group: TOGAF Version 9.1. van Haren Publishing, 10th edn. (2011)

23. The Open Group: Archimate 2.1 Specification. Van Haren Pub (2013)

24. Zachman, J.A.: A framework for information systems architecture. IBM systems journal 26(3), 276-292 (1987)
domain-specific information systems. Journal of Manufacturing Technology Management 29(5), 726-745 (2018)

5. Benjilany, A., André, P., Tamzalit, D., Bruneliere, H.: Towards a link mapping and evaluation approach for Core Operational Business-IT Alignment. In: 26th International Conf. on Enterprise Information Systems (ICEIS 2024). Insticc, Angers, France (2024)

6. Buchwald, S., Bauer, T., Reichert, M.: Bridging the Gap between Business Process Models and Service Composition Specifications (2012)

7. Castellanos, C., Correal, D.: KALCAS: A Framework for Semi-automatic Alignment of Data and Business Processes Architecture. In: Advances in Databases and Information Systems. pp. 111–124. LNCS, Springer, Berlin, Heidelberg (2012)

8. Cavano, J.P., McCall, J.A.: A framework for the measurement of software quality. In: Proceedings of the Software Quality Assurance Workshop on Functional and Performance Issues. p. 133–139. ACM, New York, NY, USA (1978)

9. Darii, H., Laval, J., Botta-Genoulaz, V., Goepp, V.: Measurement of the business/it alignment of information systems. In: ILS 2020-8th International Conference on Information Systems, Logistics and Supply Chain. pp. 228–235 (2020)

10. Etien, A., Rolland, C.: Measuring the fitness relationship. Requirements Engineering 10(3), 184–197 (Aug 2005)

11. Gellweiler, C.: It architects and it-business alignment: a theoretical review. Procedia Computer Science 196, 13–20 (2022), international Conference on ENTERprise Information Systems 2021

12. Gerow, J.E., Thatcher, J.B., Grover, V.: Six types of it-business strategic alignment: an investigation of the constructs and their measurement. European Journal of Information Systems 24(5), 465–491 (2015)

13. Goepp, V., Avila, O.: An extended-strategic alignment model for technical information system alignment. International Journal of Computer Integrated Manufacturing 28(12), 1275–1290 (2015)

14. Gouigoux, J.P., Tamzalit, D.: Business-it alignment anti-patterns: a thought from an empirical point of view. In: ISD 2021, Valencia, Spain (2021)

15. Habba, M., Fredj, M., Benabdellah Chaouni, S.: Alignment between Business Requirement, Business Process, and Software System: A Systematic Literature Review. Journal of Engineering 2019, 6918105 (2019)

16. Henderson, J.C., Venkatraman, H.: Strategic alignment: Leveraging information technology for transforming organizations. IBM Systems 38(2.3), 472–484 (1999)

17. Imgharene, K., Doumi, K., Baina, S.: Agility metrics model for business it alignment. In: 2020 7th International Conference on Control, Decision and Information Technologies (CoDIT). vol. 1, pp. 662–667 (2020)

18. Küster, J.M., Völzer, H., Favre, C., Branco, M.C., Czarnecki, K.: Supporting different process views through a shared process model. Softw. Syst. Model. 15(4), 1207–1233 (2016)

19. Őri, D., Szabó, Z.: A systematic literature review on business-it misalignment research. Information Systems and e-Business Management pp. 1–31 (2024)

20. Pepin, J., André, P., Attiogbé, J.C., Breton, E.: An improved model facet method to support EA alignment. Complex Syst. Informatics Model. Q. 9, 1–27 (2016)

21. Tarafdar, M., Qrunfleh, S.: It-business alignment: A two-level analysis. Information Systems Management 26(4), 338–349 (2009)

22. The Open Group: TOGAF Version 9.1. van Haren Publishing, 10th edn. (2011)

23. The Open Group: Archimate 2.1 Specification. Van Haren Pub (2013)

24. Zachman, J.A.: A framework for information systems architecture. IBM systems journal 26(3), 276–292 (1987)