# Assessing Operational Business-IT Alignment for Architecture Improvement

Pascal Andre, Ali Benjilany, Hugo Bruneliere, Dalila Tamzalit

► To cite this version:

Pascal Andre, Ali Benjilany, Hugo Bruneliere, Dalila Tamzalit. Assessing Operational Business-IT Alignment for Architecture Improvement. Advances in Information Systems Development: Exploring New Horizons and Opportunities, 77, Springer, pp.231-253, 2025, Lecture Notes In Information Systems and Organisation (LNISO), 10.1007/978-3-031-87880-0_12. hal-05092727

HAL Id: hal-05092727

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

Submitted on 2 Jun 2025

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>

Distributed under a Creative Commons Attribution 4.0 International License
# Assessing Operational Business-IT Alignment for Architecture Improvement

**Pascal André**

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

pascal.andre@ls2n.fr

**Ali Benjilany**

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

ali.benjilany@etu.univ-nantes.fr

**Hugo Bruneliere**

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

hugo.bruneliere@imt-atlantique.fr

**Dalila Tamzalit**

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

dalila.tamzalit@ls2n.fr

## Abstract

Business-IT alignment (BITA) remains a challenging topic for enterprise architects. This is notably the case of operational BITA that focuses on the alignment between business processes and IT applications. In this context, a major challenge is determining the level of alignment between these Business and IT layers. Existing approaches already 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 evaluation of the alignment. As a solution, we propose an alignment assessment approach combining different means (metrics, consistency rules, and anti-patterns). We also provide a methodology that integrates this approach by relying on an established cartography (expressing the current state of alignment) and proposes a corresponding redress step. This cartography is composed of Business and IT models, and of explicit links between them. Both the proposed methodology and assessment approach are illustrated on two case studies for validation purposes. In the reported experiments, we considered six metrics, two consistency rules, and four anti-patterns.

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

This article is a revised and extended version of the ISD 2024 paper entitled "An Approach to Assess Operational Business-IT Alignment" [7].
# 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) [4]. 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* [14] or *congruence* [15]. Notably, the Strategic Alignment Model (SAM) [19] proposes a common definition that has already been adopted in several approaches [16, 6].

In this context, the integration of the Business and IT domains is a fundamental need. We target a functional integration called *Operational BITA* [18, 2, 25]. Existing Enterprise Architecture (EA) frameworks already allow to express the different abstraction levels (strategic and functional/operational) through a layered representation of the IS [29, 28]. *Operational alignment* is thus a dynamic process that aims to align, sometimes continuously, these Business and IT layers [27]. To this end, it is first required to be able to properly assess the current state of alignment. Recent literature reviews on operational alignment [18, 2, 25] highlight the lack of assistance provided to the enterprise architects in charge of the alignment process [15]. More specifically, there is a lack of methodologies and tools to practically assess the current level of operational alignment. A few approaches propose to assess the alignment level through assessment means which are often specific to a given context (for example agility metrics [20] or metrics for all the SAM alignment types [13]). However, no approach intends to combine different assessment means to obtain a more thorough appreciation of the alignment level.

To overcome these limitations, we propose an approach to assess the level of alignment between the Business (process) layer and the Application layer for any given IS. We consider two main phases: 1) *Cartography establishment* for representing the current alignment state, including the Business and IT models as well as the explicit links between them. 2) *Alignment assessment* for using this alignment state in order to assess the current level of alignment. Our first contribution is an alignment assessment approach that relies on the combination of several different assessment means (metrics, consistency rules, and anti-patterns). Our second contribution is a global methodology that integrates this alignment assessment approach along with the previous cartography establishment phase and a next redress phase. We applied in practice these methodology and assessment approach on two case studies, namely SOFTSLATE (an open-source Java E-commerce solution) and ARCHIMETAL (a standard example of modeled IS). To this end, we established in both cases a cartography of the concerned IS that we then assessed by relying on six metrics, two consistency rules and four anti-patterns (in total).

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 in order to integrate this alignment assessment approach with a previous cartography establishment phase and next redress phase. Section 5 demonstrates the practical application of the proposed methodology and assessment approach in the context of our two case studies. Section 6 discusses the obtained results, current limitations, and overall applicability of our contributions. Finally, Section 7 concludes the paper and opens on future perspectives.

# 2. Background and Related Work

Recent surveys [2, 25] 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 only on establishing the alignment car-
tography. Among them, the framework of Aversano et al [5] is a major reference because it covers most of the alignment process. It starts with alignment links establishment, then alignment assessment via metrics computation, and finally evolution recommendations to improve the alignment quality. The framework comes with some tool support and has been validated on a single case study. Another reference work [14] provides metrics to quantify the fitness level between the business and the IT system supporting it. Business and IT domains are represented using dedicated ontologies on which these metrics are applied. Therefore, the proposed metrics are independent from specific languages and can be adapted to specific context (e.g. to UML). However, no corresponding tool support is provided yet. Another recent approach [13] aims at generalizing the alignment assessment by defining a dedicated metamodel. To the best of our knowledge, this approach has not been applied on any case study. Very recently, two new types of links have been proposed to establish a cartography [1]. These links are also used to compute various metrics and verify a few consistency rules. This last approach already provides a basic tool support but does not combine different assessment means together.

We generally observed that most existing works rely on quantitative assessment means, namely metrics. A reference work [4] defines two main alignment criteria that led to metrics: 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 [5]. The results of single metrics are then aggregated across several linked concepts. Another work [14] 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 [13]. It proposes a reinterpretation of 9 metrics coming from previous works [14, 5]. 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 [1]. 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 [1] or between functions and data in the more general case [26]. In another approach, rules are defined by model transformations from business to IT allowing to check consistency by verifying few conditions [8]. Consistency heuristics can also be defined by querying such a mapping, for example with the Kalcas Query Language [10]. 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 [22]. Patterns can also represent a relevant assessment mean in many cases. For instance, common misalignment patterns between the Business and IT layers have been identified from the study of 30 different ISs [17].

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

Complementary to assessing the alignment, it appears useful to also offer correction actions in order to redress a potentially incorrect alignment. However, according to a recent survey [2], only few works (8/44) discuss such corrective changes (propagation, impact, migration). Among
these few works, only three of them explicitly mention re-alignment. In a first work [G38]
business process re-engineering is addressed using i*, but the support for the IT layer remains
implicit. In a second work [5], the authors mention that increasing the alignment level cannot
be performed without the experience and knowledge of the process stakeholders and software
engineers. As a result, they only introduce two automated evolution actions in the context of a
particular case study. In a third work [G16], the Alignment Correction and Evolution Method
(ACEM) performs the change operations on a pivot model that reflects alignment refinements
from intention to implementation. More generally, the term redress is often associated to the
notion of "misalignment" [25]. A prior study on addressing strategic alignment [3] already
made the same observation we did: "most of the current research efforts investigate IT-business
alignment/misalignment in terms of detection, but they are not targeted a specific set of actions
to solve this issue." As a possible solution, these efforts envision different algorithms for IT-
business misalignment redress, e.g. by identifying symptom/therapy actions [9, 23]. Still, these
are currently mostly ideas and few of the proposed actions are directly applicable to our context
of operational BITA. For instance, BITAM [12] propose 12 steps to address the management of
misalignment, including the realignment of both business and architectural strategies. However,
no concrete application guidelines are provided. Another approach proposes 28 symptoms [24]
but its implementation is actually left to the readers. Also, a misalignment correction framework
was proposed to analyzes the cause and effect of misalignment symptoms [30]. Nevertheless, it
remains relatively incomplete. Based on these efforts, we notably propose a process for Align-
ment Redress as part of our global methodology in Section 4.

3. An Alignment Assessement Approach Combining Different Evaluation Means

One of our main goals is 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 her (mis)alignment assessment needs, architects can 1) select
the most suitable means and 2) combine them by attaching appropriate weights to indicate their
importance. These selected means, along with their weights, are then combined within a single
formula. In order to ease their definition and selection, these means are structured based on
specific criteria and according to identified factors.

**3.1. Alignment Assessment Structure**

The structure of our alignment dashboard is adapted from the hierarchical structure of the
Cavano & McCall's framework [11] proposing *Factors*, *Criteria* and *Metrics*. *Factors* present
qualitative attributes referring to different alignment perspectives, e.g. intentional-functional-
informational-dynamic [14] or functional-data [1]. In our context, we call them *Alignment
Factors*. Factors of the Cavano & McCall's framework are then broken down into *Criteria*, e.g.
Technological Adequacy and Technological coverage [5]. In our context, we call them *Align-
ment Criteria*. Finally, while the Cavano & McCall's framework only relies on *Metrics*, we
consider more assessment means. Thus, in our context, we call them *Alignment Assessment
Means*: metrics, consistency rules and anti-patterns. For example, metrics and consistency rules
can be defined on Operational BITA links between the business and the application layers [1].
Anti-patterns can also be based on such links, as core elements allowing to assess alignment and
conduct an alignment process [17].

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

**Assessment Means Weighting.** After selection, the architect has to assign 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 metrics can differ from 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 can be respectively considered for 40% (if more relevant in terms of coverage in a particular case).

## 3.2. Alignment Assessment Score Calculation

Alignment assessment is complex because some alignment/misalignment means are hardly quantifiable, and sometimes difficult to analyze. Moreover, such means can provide different kinds of results (numerical values, rates, etc.) and require a harmonization step before combining them in aggregate factors. To overcome this, we propose a scoring approach calculating an overall alignment score from heterogeneous assessment means: metrics, consistency rules and anti-patterns. In practice, we started with an initial catalog of assessment means we selected from the literature. Table 1 shows different assessment factors, criteria and means we currently consider. Note that providing a complete catalog is beyond the scope of this chapter, and would require extra-work with expert architects.

<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>Ratio of BU concepts per IT concepts</td><td>Functional</td><td>Coverage</td><td>M2 in [1], TC Metrics in [5]</td></tr><tr><td>Ratio of IT concepts used per BU concepts</td><td>Functional</td><td>Coverage</td><td>M5 in [1]</td></tr><tr><td>Over used IT concepts</td><td>Functional</td><td>Overload</td><td>M6 in [1]</td></tr><tr><td>Over implemented business concepts</td><td>Functional</td><td>Overload</td><td>M3 in [1]</td></tr><tr><td>Number of links for a fun BU concept</td><td>Functional</td><td>Coverage</td><td>M1 in [1]</td></tr><tr><td>Number of links for a fun IT concept</td><td>Functional</td><td>Coverage</td><td>M4 in [1]</td></tr><tr><td>Ratio of BU data concepts per IT data concept</td><td>Data</td><td>Coverage</td><td>Infor. completeness in [14]</td></tr><tr><td>Ratio of IT data concepts per BU data concept</td><td>Data</td><td>Coverage</td><td>Infor. completeness in [14]</td></tr><tr><td>Number of links per BU data concept</td><td>Data</td><td>Coverage</td><td>M7</td></tr><tr><td>Number of links for an IT data concept</td><td>Data</td><td>Coverage</td><td>M8</td></tr><tr><td>Similarity between linked concepts</td><td>All</td><td>Consistency</td><td>TA Metrics in [5]</td></tr><tr><td rowspan="4">Consistency rules</td><td>Existence of functional links</td><td>All</td><td>Consistency</td><td>CR1 in [1]</td></tr><tr><td>Existence of data links</td><td>All</td><td>Consistency</td><td>CR2 in [1]</td></tr><tr><td>Symmetry of data (resp. functional) links</td><td>All</td><td>Consistency</td><td>CR3, CR4</td></tr><tr><td>Transitivity of functional/data links</td><td>All</td><td>Consistency</td><td>CR5, rules 6.32 to 6.34 in [26]</td></tr><tr><td rowspan="4">Anti-patterns</td><td>Pure technical integration</td><td>Functional</td><td>Consistency</td><td>AP1 in [17]</td></tr><tr><td>Functional SILO</td><td>Functional</td><td>Consistency</td><td>AP2 in [17]</td></tr><tr><td>Monolith application</td><td>Functional</td><td>Coverage</td><td>AP3 in [17]</td></tr><tr><td>Multiple functional implementation</td><td>Functional</td><td>Coverage</td><td>AP4 in [17]</td></tr></tbody></table>

**Assessment Means: Harmonization.** The results obtained from different types of assessment means first need to be harmonized in a unified scale so that they can be combined and interpreted correctly. For example, if a given mean gives a result within a scale between 0 and 10, and another mean gives a percentage or a rate, the latter can be transformed to a number using the same predefined scale. Also, similar results for different assessment means should be considered carefully. For example, the value of "80%" of aligned concepts and of "80%" of misaligned concepts does not provide the same information about the alignment. Instead, a harmonized result would allow a more uniform appreciation of the current 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: (I) *Metrics weighted*. Let $Mi$ the i-est metric, $rMi$ its res-
ult and wMi its weight with $\sum wMi = 1$. To calculate a combined score of selected metrics, we use the formula: $rM = \sum wMi \times rMi$. (II) *Consistency Rules*. Let CRi the i-est consistency rule, rCRi its result and wCRi its weight with $\sum wCRi = 1$. The weighted score of consistency rules score equals: $rCR = \sum wCRi \times rCRi$. (III) *Anti-patterns*. Let APi the i-est anti-pattern, rAPi its result and wAPi its weight with $\sum wAPi = 1$. Then, the weighted score of anti-patterns score equals: $rAP = \sum wAPi \times rAPi$. (IV) *Other assessment means*. The enterprise architect in charge of the alignment process has the possibility of adding new assessment means or new types of assessment means. To integrate them, she needs to respect the harmonized format already used for the other 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 General Methodology for Cartography Establishment, Alignment Assessment, and Alignment Redress

In order to perform the previously presented alignment assessment approach, we propose a general methodology for cartography establishment, alignment assessment, and alignment redress. We summarize the corresponding process in BPMN <fnref n="1" /> as shown in Figure 1. The main actor is the enterprise architect as she is usually responsible for dealing with the alignment-related issues [15]. Throughout the process, she 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 starts when the need for alignment assessment is expressed, and ends with the IS is (sufficiently) realigned. It is composed of three sub-processes dedicated to cartography, assessment and redress. As indicated in previous work [21], BITA alignment is an iterative process that often requires several consecutive applications over time. This is also the case of the process we propose in this chapter.

<figure><img src="image_2.png" /><figcaption>**Fig. 1.** A process for Cartography Establishment, Alignment Assessment, and Alignment Redress</figcaption></figure>

## 4.1. Cartography establishment

The first sub-process, depicted in Figure 2, is called "Sstablish Cartography" and provides the steps needed to establish the cartography. This is realised by setting up the Business and IT models, providing their concepts, and specifying the links between them (cf. Section 2). The initial step is to check the existence of the required Business and IT models: (i) When available, the architect needs to check if the used modelling languages allows representing all

<footnote n="1">¹https://www.omg.org/spec/BPMN/2.0/PDF</footnote>
the required Business and IT information. If this is 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 solicits 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 further 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.

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

## 4.2. Alignment Assessment

The second sub-process, depicted in Figure 3, is called "Alignment assessment" and corresponds to the Alignment Assessment approach we presented in Section 3. This sub-process describes the two main steps going from the obtained cartography to the overall alignment score. First, the assessment structure is defined by the architect via 1) the selection of the factors, criteria and assessment means, and 2) the indication of their corresponding weights. Second, the results of these assessment means are computed and then harmonised accordingly (if needed). Finally, the different weighted scores are calculated before aggregating them to obtain the overall alignment score.

<figure><img src="image_4.png" /><figcaption>Fig. 3. A process for Alignment Assessment</figcaption></figure>
all score. The architect can look at the overall score, analyze it, and then decide if she accepts the results or wants to go back to the process<fnref n="2" />.

When low, the obtained 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 then 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.

### 4.3. Alignment Redress

Once the overall alignment score is consolidated, alignment correction actions may have to be considered according to the obtaine result. To this end, we propose a third and last sub-process, depicted in Figure 4 and called "Alignment redress". Based on common Operational BITA practices, and according to the assessment structure used in our approach, we propose to follow three consecutive steps: (1) correct the misalignments detected by consistency rules; (2) refactor the misalignments detected by anti-patterns; (3) re-align the models to improve the metrics values and overall assessment score. Indeed, in order to properly redress, we must look deeper into each "bad" result of assessment mean, find the symptoms, and look for a cure. To start with, related "bad" values can be grouped together by families of symptom: one single problem may concern several different means. A given symptom can denote two main kinds of issue (i) modelling issues (missing business or IT concepts, missing links, redundancy, inadequate representation, name mismatch, etc.) and (ii) real-world issues (legacy debt, inadequate processes, missing digitalised data, etc.). Both kinds of issue require that the architects, business and IT stakeholders work in collaboration and discuss possible solutions for improvement. To allow this, they need a commonly shared terminology in order to avoid contradictions, redundancies, ambiguities, etc. In this context, another interesting aspect to consider is the notion

<figure><img src="image_5.png" /><figcaption>**Fig. 4.** A process for Alignment Redress</figcaption></figure>

<footnote n="2">²The covered assessment means and associated tooling are presented in detail in a previous work [1].</footnote>
of **dimension** as a point of view on the alignment [1]. Dimensions have to play a role in the organization of the alignment redress since they target the possible concerns of the different stakeholders, e.g. functions, data, urbanisation, actors, security, privacy. For example, in IS modelling, we usually make a distinction between the structure, the functional behavior and the dynamic behaviour. As a consequence, we propose to operate first on individual dimensions (only the data and function dimensions are taken into account in this chapter) and then later on cross dimensions for broader consistency and completeness.

# 5. Validation of the Methodology and Approach on Two Case Studies

We validated the methodology proposed in Section 4) and corresponding assessment approach presented in Section 3 by applying them on two different case studies. The first one is the *SoftSlate Commerce Java shopping cart system* powering dozens of E-commerce websites. The second one is *ArchiMetal*, an example Enterprise Architecture model of a metallurgy company using Archimate. In both cases, we implemented the models and links in *Archi*, the reference Archimate tool, and the evaluation means with *jArchi*, a script language provided as an extension of the *Archi* tool. The complete information and data related to the performed experimentations are available online<fnref n="3" />.

## 5.1. SoftSlate

We opted for this case study in our first experiment because it is (i) realistic since *SoftSlate Commerce* actually exists<fnref n="4" />, (ii) challenging since business and application models are not provided (we designed them from scratch, simulating the case where an IS would not come with such models), (iii) reasonably complex in terms of structure and relatively large in terms of number of lines of code, (iv) provided with an implementation available online, including its complete source code and documentation<fnref n="5" />.

### A) Setting the Cartography of SOFTSLATE

**Check the existence of models.** Models representing the business and application layers are not available in this case study. The only directly exploitable assets to build the needed models are the user guide, source code, and MVC pattern architecture description provided with the system.

**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 this case study, we do not have a direct contact with SOFTSLATE's business domain experts or developers. Thus, we validated the models ourselves by cross-checking them.

**Create Links.** We use a simple typology of links [1] 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 already rich enough in terms of concepts and links.

### B) Alignment Assessment Structure for SOFTSLATE

**Alignment factors.** For this first case study, we consider mainly the functional assessment factor. Other factors could be integrated later in the context of more advanced experiments.

<footnote n="3">³https://uncloud.univ-nantes.fr/index.php/s/wMQ6NPgbpkgRgWa</footnote>

<footnote n="4">⁴https://www.softslate.com/</footnote>

<footnote n="5">⁵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 case study, 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 displayed in Table 1: We consider **Metric 2 & Metric 5** for functional coverage, **Metric 3 & Metric 6** for functional overloading and **Metric 7 & Metric 8** for data coverage. 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="2">COMPUTATION & RESULTS</th><th>WEIGHT</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="6">METRICS</td><td>M2</td><td>41,60%</td><td>0,165</td><td>58,40%</td><td rowspan="6">76,50%</td><td rowspan="6">0,2</td><td rowspan="12">94,30%</td></tr><tr><td>M3</td><td>0</td><td>0,165</td><td>100%</td></tr><tr><td>M5</td><td>53,80%</td><td>0,165</td><td>46,20%</td></tr><tr><td>M6</td><td>1</td><td>0,165</td><td>90%</td></tr><tr><td>M7</td><td>16,66%</td><td>0,165</td><td>83,33%</td></tr><tr><td>M8</td><td>14,28%</td><td>0,165</td><td>85,72%</td></tr><tr><td rowspan="2">CONSISTENCY RULES</td><td>CR1</td><td>0</td><td>0,5</td><td>100%</td><td rowspan="2">100%</td><td rowspan="2">0,4</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 rowspan="4">97,5%</td><td rowspan="4">0,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 apply the weighting system proposed in Section 3.2:

* *Specific weights.* The column *w* in Table 2 reports on the specific weights allocated to each assessment mean. For the six 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,165$. 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.* The third column of Table 2 shows the aggregated weights per type of assessment means. 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$).

### C) 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 M2 becomes the rate of implemented business processes. 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 M3 becomes calculated as $rM3 = 100\% - (N * 10\%)$ with N the number of elements in the list. 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 M5 becomes the rate of used application functions. 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 M6 is calculated as $rM6 = 100\% - (N * 10\%)$ with N the number of elements in the list. The higher is rM6 the better is the appreciation of the alignment level.

* Metric M7 (respectively M8) counts the number of links per data business (respectively IT) concept. The harmonised rate rM7 (respectively rM8) denotes the rate of unlinked concepts. The higher are rM7 or rM8 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\%$

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 this case study, the alignment score is high (93.73 %) but only two business processes have been modelled so far. We can mitigate this good score since the input models are directly inspired from the source code, they are quite small compared to large enterprise ISs, and we paid a particular attention when linking the business and application layers (which is not always the case in companies).
## D) Alignment Redress for SOFTSLATE

We apply the general guidelines we proposed in Section 4.3. In this case study, the redress step notably aims to correct the low values of the means displayed in Table 2: M2, M5 and AP3. Thus, we suggest the following corrections in this SOFTSLATE case study: (i) To improve M2, we should fix the case of business functions and activities that are parts of composite activities, and vice-versa. For instance, corresponding links could be added automatically by a dedicated model transformation applied to the business model. (ii) Due to our initial assumption of partial business modelling, we should cover a wider range of business processes models. This should allow to reduce the value of M5 because more application functions will be (correctly) linked. (iii) AP3 raised a warning because the application concept Add Shipping Rate is linked to three different business concepts which correspond to three alternatives. Thus, we should factorise the common parts in one business function only. Moreover, we observed that M7 and M8 do not present any significant shortcomings. The related issue simply comes from a missing link for the Payment data object. This should be addressed by adding a corresponding business object in the business layer.

## 5.2. ArchiMetal

We opted for this complementary case study in our second experiment because it (i) is a representative example or EA modelling as provided by *TheOpenGroup*<sup>6</sup>, (ii) presents a ready-to-study mapping, and therefore a different context than for SOFTSLATE, (iii) comes with an EA model than can be easily integrated into Archi thanks to The Open Group library.

### A) Setting the Cartography of ARCHIMETAL

**Check the existence of models & Design models.** Models representing the business and application layers are already available in the ArchiMate® Model Exchange File Format<sup>7</sup>. The given models are quite detailed since the objective of their authors is to demonstrate the full capabilities of ArchiMate in terms of modelling.

**Create Links.** Archimate provides a rich set of inter-layer relations. However, "many" is not the best for every case. Applying the Occam's razor principle, we restrict to two kind of association (implementation, representation) [1]. As a consequence, we *transformed* the other kinds of ArchiMate relationships (*e.g.* *Realization*, *Serving*) into the two kinds above-mentioned.

### B) Alignment Assessment Structure for ARCHIMETAL

We keep the same choices than the ones of the SOFTSLATE case study (cf. Section 5.1-B).

### C) Alignment Score Calculation for ARCHIMETAL

The results we obtained for this second case study are provided in Table 3.

The harmonisation and score calculation steps are computed in the same way than for SOFTSLATE. The overall alignment score is good (91,615%). We can explain that by the fact that the ARCHIMETAL model designers are Archimate experts and thus focused on rigorous modelling of functions/services. Indeed, the enterprise application integration is modelled by application functions that maps to business functions (cf. the 01. Functional enterprise-control model view in the Archi model for instance). However, the

<footnote n="6">⁶https://pubs.opengroup.org/architecture/case-study-models/Archimetal-html/
⁷https://github.com/archimatetool/ArchiModels/tree/master/Archimetal</footnote>
<table><caption>**Table 3.** ARCHIMETAL score calculation</caption><thead><tr><th>ASSESSMENT MEANS</th><th colspan="2">COMPUTATION & RESULTS</th><th>WEIGHT</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="6">METRICS</td><td>M2</td><td>45,68%</td><td>0,165</td><td>54,32%</td><td rowspan="6">68,075%</td><td rowspan="6">0,2</td><td rowspan="12">91,615%</td></tr><tr><td>M3</td><td>0</td><td>0,165</td><td>100%</td></tr><tr><td>M5</td><td>35,52%</td><td>0,165</td><td>67,60%</td></tr><tr><td>M6</td><td>0</td><td>0,165</td><td>100%</td></tr><tr><td>M7</td><td>66,66%</td><td>0,165</td><td>33,33%</td></tr><tr><td>M8</td><td>46,80%</td><td>0,165</td><td>53,20%</td></tr><tr><td rowspan="2">CONSISTENCY RULES</td><td>CR1</td><td>0</td><td>0,5</td><td>100%</td><td rowspan="2">100%</td><td rowspan="2">0,4</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 rowspan="4">95%</td><td rowspan="4">0,4</td></tr><tr><td>AP2</td><td>0</td><td>0,25</td><td>100%</td></tr><tr><td>AP3</td><td>2</td><td>0,25</td><td>80%</td></tr><tr><td>AP4</td><td>0</td><td>0,25</td><td>100%</td></tr></tbody></table>

provided application models are rather high level (ERP, CRM, control application) and are missing/hidding some details that lead to uncovered links. Moreover, not all inter-layer links are represented, especially for data as illustrated by M7 and M8. As As a result, the data dimension is not very well covered in the used ARCHIMETAL models. Overall, this case study does not really allow to reflect on complex situations where many defaults and misalignment exist. In this sense, it is quite complementary to the previous SOFTSLATE case study.

### D) Alignment Redress for ARCHIMETAL

Once again, we apply the general guidelines we proposed in Section 4.3. In this case study, the redress step notably aims to correct the low values of the means displayed in Table 3: M2, M5, M7, M8 and AP3. Thus, we suggest the following corrections in this ARCHIMETAL case study: (i) To improve M2, we should fix the missing details in the application model and, for each application concept, find the link to its business counterpart. Still, we do not have the same problem as in SOFTSLATE because the ARCHIMETAL business model already follows best practice in terms of modelling (e.g. layered ordering of functions and activities). (ii) Due to hidden details, we should cover a wider range of application models. This should allow M5 to better reflect the reality because more application functions will be linked. (iii) M7 and M8 should be improved by making the data dimension more explicit in the models. This would require enriching them with business objects and data objects. (iv) AP3 raised two warnings because the application concepts are high-level and gather several application functions. To overcome this, we should be more precise and set representative, and atomic enough, interlayer links (e.g. for the ERP and CRM applications).

## 6. Discussion

Following the validation of our methodology and approach on two complementary case studies, we now discuss the current limitations of the work presented in this chapter. We also explain how we intend to possibly tackle these limitations in the future. Finally, we discuss the relevance and novelty of our work according to the current state-of-the-art.

### 6.1. Considering threats to validity.

The proposed methodology and approach have been empirically validated thanks to their practical application in the context of two case studies. Still, they should be experimented further by considering additional case studies in order to demonstrate their relevance in more different realistic scenarios. For example, we cannot completely ensure at this stage that (i) the alignment score fully reflects the real alignment level of the IS (conclusion validity); (ii) each
assessment means value adequately captures the targeted symptom (*internal validity*); (iii) the set of provided assessment means is sufficiently consistent and complete (*construction validity*); (iv) the cartography covers a majority of the common enterprise situations (*external validity*).

## 6.2. Performing more validation on different case studies.

As introduced before, we still need to experiment with both our methodology and approach in the context of other case studies. Moreover, these case studies must also be evaluated by integrating more alignment assessment factors than the functional assessment one we considered so far. The realisation of these additional experiments will require to have access to the Business and IT models of more IS, which is a major obstacle since companies do not usually share their IS. Otherwise, it will require to build the appropriate 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 notably LLMs) in order to automatically exploit the huge amount of information within the IS. This could also help to propose a maturity model (like CMMI) dedicated to the alignment.

## 6.3. Working on alignment objectives and their specification.

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. This could be done by specifying a set of alignment clauses to be checked, an associated set of thresholds integrated into an interactive dashboard, etc. The defined objectives could notably include corresponding specific weights or thresholds for particular factors/criteria. This way, the architect could more easily specify her alignment strategy.

## 6.4. Improving the catalogue/repository of evaluation means.

In addition, our current catalogue 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. The ultimate goal is to classify the application architectural styles (up to the notation, the business process styles remain very similar), and to provide a catalogue of pertinent assessment means for each style.

## 6.5. Proposing different calculation methods.

Another area for improvement would be to provide alternative calculation methods for alignment 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 IS. Going one step 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 in the context of a same IS.
## 6.6. Adapting the approach and corresponding tooling.

Overall, the already provided alignment objectives, assessment means, and calculation methods, can be adapted to different contexts. Our current implementation already supports by default a given set of objectives, means, and methods. It also allows developing and integrating new ones, in order to replace and/or complement the existing ones. For instance, a challenge is to tackle the complexity of contemporary software architectures (multi-layer architectures, micro-services, etc.) by proposing appropriate 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 the Archi tool (or any other suitable open source CASE tool) can also be envisioned, in collaboration with a company for example.

## 6.7. Diagnosing and repairing Operational BITA.

Identified symptom/cure actions (cf. Section 2) are interesting from the management point of view (strategy, organisation, performance) or deployment point of view (distribution and quality). However, only few of these actions address our requirements for Operational BITA. Among them, we notably found (i) S.13 (ambiguity), S.19 (duplicates), S.23 (data redundancy), S.24 (discontinuity), S.26 (function redundancy), S.30 (integrity) [9], (ii) LF.6 (redundancy) [3], (iii) OS.14 (CRUD requirement), OS.15 (unused data), OS.16 (unused functions), OS.18 (S.23), OS.19 (part of LF.6), OS.20 (S.26), OS.27 (S.19) [24]. We already address a significant number of them in our current assessment means (S.13, S.19, S.26, OS.15, OS.16), while others remain to be studied as targeting other quality factors (S.23, S.24, S.30, LF.6, OS.14). Morevoer, misalignment corrections in those approaches often refer to general guidelines and actions rather than concrete and practical tasks.

## 6.8. Summarizing the relevance of our work.

Despite the discussed limitations, we already showed that the proposed alignment assessment approach and corresponding methodology are applicable in practice on realistic case studies. Thus, they are potentially also relevant in the context of any other IS sharing similar characteristics than SoftSlate. Moreover, our assessment approach is quite novel since combining different types of assessment means to provide aggregated alignment indicators (cf. Section 2). Furthermore, our methodology integrates three important consecutive steps of the alignment process, namely cartography establishment, alignment assessment, and alignment redress. Except from a few works also proposing some directives for alignment evolution based on previous assessment results [5, 26], a large majority of the other existing approaches only address one step of the process (often cartography establishment) [2, 25].

## 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 and derive correction actions accordingly. To go a step further in this direction, we proposed in this chapter 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 and globally assess the current alignment level in the context of a given IS. In addition, we also proposed a global methodology that integrates this alignment assessment approach along with a previous cartography establishment phase and a next alignment redress 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 two complementary case studies named SOFTSLATE and ARCHIMETAL. In both cases, we established a cartography of the concerned IS, that we then assessed by considering six metrics, two consistency rules and four anti-patterns (in total). Based on the obtained results, we were able to propose some actions in order to improve the current IS architecture.

Among the different possible future works we discussed earlier in the paper, we can not-
ably mention additional experiments in the context of other case studies and IS. 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 pro-
posed 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 operational Business-IT alignment. This
support could also include the provisioning of detailed recommendations to assist enterprise ar-
chitects on how to achieve in practice the operational Business-IT alignment they target. Last
but not least, we believe that our methodology and approach can help to more efficiently work
on the implementation of existing misalignment methodologies [1, 11, 22, 23].

References

1. André, P., Benjilany, A., Bruneliere, H., Tamzalit, D.: A Practical Approach to Evaluate Operational Business-IT Alignment. In: Filipe, J., Smialek, M., Brodsky, A., Hammoudi, S. (eds.) 26th Int. Conf. on Enterprise Information Systems, ICEIS, Angers, France, April 28-30, 2024, Revised Selected Papers. LNBIP, Springer (2024), to appear

2. André, P., Bruneliere, H., Tamzalit, D., Benjilany, A.: Core Operational Business-IT Alignment: Current Trends and Open Challenges, pp. 41–62. Springer Nature Switzerland, Cham (2024)

3. Aseeva, N., Babkin, E., Malyzhenkov, P., Masi, M.: Strategic integration of alignment models for the it-business misalignment detection and redress. In: Digitalization of Society, Economics and Management: A Digital Strategy Based on Post-pandemic Developments, pp. 97–113. Springer, (2022)

4. 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)

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

6. 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)

7. Benjilany, A., Bruneliere, H., André, P., Tamzalit, D.: An Approach to Assess Operational Business-IT Alignment. In: Proceedings of the 32nd International Conference on Information Systems Development. ISD 2024, vol. 72. University of Gdańsk (Sep 2024), http://dx.doi.org/10.62036/ISD.2024.13

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

9. Carvalho, R., Sousa, P.: Business and information systems misalignment model (bismam): an holistic model leveraged on misalignment and medical sciences approaches. Proceedings of BUSITAL 8, 105 (2008)

10. Castellanos, C., Correal, D.: KALCAS: A FrameworkK for Semi-automatic ALignment of Data and Business ProCesses ArchitectureS. In: Advances in Databases and Inform-
ation Systems. pp. 111–124. LNCS, Springer, Berlin, Heidelberg (2012)

11. 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)

12. Chen, H.M., Kazman, R., Garg, A.: Bitam: An engineering-principled method for managing misalignments between business and it architectures. Science of Computer Programming 57(1), 5–26 (2005), system and Software Architectures

13. 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)

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

15. 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

16. 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)

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

18. 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)

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

20. 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)

21. Kassahun, A., Tekinerdogan, B.: Collaboration viewpoint for modeling cross-organizational business concerns. In: ICST 2016. pp. 3–21. Springer (2016)

22. 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)

23. Luftman, J.N.: Competing in the information age: Align in the sand. Oxford University Press (2003)

24. Őri, D.: Misalignment symptom analysis based on enterprise architecture model assessment. IADIS International Journal on Computer Science & Information Systems 9(2), 146–158 (2014)

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

26. 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)

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

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

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

30. Zhang, M., Chen, H., Liu, J.: Cause-effect analysis for multiple misalignment symptoms in misalignment correction stage. Arabian Journal for Science and Engineering 44, 2729–2735 (2019)