Challenges for Model-Driven Development of Strategically Aligned Information Systems

Model-Driven Development (MDD) has been proposed as an alternative to the traditional development of information systems, given its ability to integrate different stakeholders into the information system engineering process. Currently, longtime researched MDD methods and modern no-code and low-code platforms support the generation of the working code of the information system and services. However, in today’s continuously changing environment, organisations need to align the information systems and services with the business structure, strategy, and processes they support. This article shows the design challenges for integrating business strategy information into a model-driven development method. We applied a set of mechanism experiments on an MDD method composed of three modelling frameworks with demonstrated semantic consistency, that covers the organisational, business process, and information system levels to identify information loss and transformation coverage issues that prevent the generation of information systems and services that are strategically aligned. The challenges were discussed with experts, confirming the relevance of avoiding the overlapping between the strategic and business process concepts, providing organisational-level constructs to express strategic ends and means, and considering the organisational structure in the modular design of business process and information systems and services.


I. INTRODUCTION
Model-Driven Development (MDD) puts conceptual models at the centre of the engineering process of information systems. Unlike traditional development approaches where the main activity of the developer is coding, the main activity of the MDD developer is to build a conceptual model of the software with enough detail to allow the automatic generation of the code that implements it. Considering the Model-Driven Architecture (MDA) [1] approach, the information represented in other conceptual models can be integrated in order to provide traceability from requirement models and, where possible, automatic transformations to ensure consistency among different models.
MDD methods and tools have been researched for decades: there are more than 50 different initiatives of code generation The associate editor coordinating the review of this manuscript and approving it for publication was Muhammad Ali Babar . from models, as reported in [2]. However, the next few years will see widespread adoption of no-code and lowcode development platforms. 1,2 However, in a constantly changing environment, traditional and model-driven software development approaches face the challenge of managing the complexity of designing and evolving information systems and services.
Information systems and services must enable organisations to address the new needs of their customers, explore new technology-based business models, and quickly react to external threats. In model-driven engineering, these tenets have been addressed for a long time by enterprise architecture [3], [4], and by connecting organisational goals with the requirements of the information system [5]- [8]. On the other hand, the agile principles [9] that initially supported requirements change in software development have been scaled to support the operation of the whole organisation, including business strategy [10]- [13]. Under this approach, the organisation is structured around business outcomes, forming cross-disciplinary business units that address a business process integrally, replicating this structure in the design of information systems and services.
In order to replicate the latter approach to strategic alignment in an MDD context, a holistic approach is needed. We call a Holistic Model-Driven Development (HMDD) method a software production method that generates code from conceptual models at different abstraction layers, starting from the business structure and goals at the organisational level to the code of the information system. An HMDD method exploits the MDD claims to support the analysis, design and implementation of information systems and services by providing traceability among models of different levels and automatic model-to-model transformations.
This article analyses the challenges that an HMDD method must face to provide traceability and automatic transformations of the organisational goals and strategies. We test whether the strategic information can go through the organisational modelling level to the information system modelling level through a set of mechanism experiments to identify modelling issues.
The challenges analysis is performed based on a set of existing methods that enable organisational structure and strategy, business processes, and information systems modelling: i* [14], Communication Analysis (CA) [15] and the OO-Method (OOM) [16], respectively. We consider these methods because i* supports the jointly modelling of organisational structure, strategy, and goals, and it has been applied for adding intentionality to organisational levels [17]- [19]. On the other hand, OOM supporting tool allows the generation of working code from the model of the information system [20]. Moreover, the methodological consistency for connecting these methods and their transformations have been scientifically validated [6], [21].
Our main contribution is the systematic identification of issues that hinder traceability and automatic model transformation in the model-driven development of strategically aligned information systems. Although the analysis is based on specific methods and techniques, the identified challenges are applicable for other different organisational modelling methods, business modelling methods, and object-oriented information system modelling methods. We shared our findings with experts in the above methods to validate the results. We discussed the relevance of the issues found and the known initiatives or novel proposals to solve them.
The article's structure is as follows: Section 2 summarises related work regarding the integration and connection of modelling methods. Section 3 introduces the modelling methods and transformation techniques considered in the challenge analysis, while Section 4 explains the scope of the analysis and the research method. Section 5 details the analysis of the challenges, and Section 6 presents the discussion of the identified challenges with experts. Finally, Section 7 presents the conclusions and future works.

II. RELATED WORK
Several initiatives for integrating conceptual models of different abstraction levels have been proposed in the last decade. Secondary and tertiary studies have also explored the challenges in the quality evaluation of modelling languages and model transformations. To the best of our knowledge, none of these initiatives has analysed the traceability and automatic transformation issues for the specific purpose of strategic alignment. In this section, we refer to secondary studies exploring challenges in integrating modelling methods.
The integration of heterogeneous models has been analysed in [22], specifically regarding the traceability among models. A systematic literature review of 330 model-driven and requirements engineering related articles examined the methods, tools, and current challenges in traceability. The identified challenges are the difficulty of comparing artefacts modelled with different languages and with different tools and the lack of semantics for the links among artefacts. A similar problem was identified by Santiago et al. [23] regarding model transformations: most proposals use custom traceability models, hindering the information interchange. It is also worth noting that an approach for the first challenge is presented in [6], using FRISCO [24] as an intermediate reference model to compare two heterogeneous models. Giraldo et al. have studied the quality of modelling languages in model-driven information systems engineering [25]. Thirty-four documents were reviewed in this survey, including specialised books and high-impact websites. The challenges identified for the integration of modelling methods include the quality evaluation of the overall resulting language, which is different from the addition of the qualities of integrated individual languages. In the systematic literature review presented in [26], findings for the quality of model transformations are categorised as internal and external. Internal quality attributes of model transformations are understandability, modifiability, reusability, modularity, completeness, consistency, and correctness. External quality attributes of model transformations must be evaluated as the change of quality in the target model of the transformation. The consolidation and demonstration of the challenges in the evaluation of quality in MDE is presented in [27]. Among others, identified challenges include the evaluation of the quality of a modelling language in the context of the abstraction level in which it is introduced, and the definition of quality metrics for both modelling languages and transformations.
With regard to the analysis of challenges in model transformations, two main quality attributes are widely referenced: Transformation Coverage and Information Loss. Transformation Coverage, as defined by van Amstel and van den Brand [28], ''denotes the degree of completeness of a transformation, i.e., how many metamodel elements of the source model to be transformed are in fact consumed by the transformation'' [29]. Information Loss [30] focuses on the loss of structural features due to transformation mismatch among metamodels. Both quality attributes have been formalised and implemented in algorithms for optimal transformation chains in [29]. These quality attributes refer to the definition of metamodels and transformations, regardless of the context of their application. According to Situational Method Engineering [31], an important aspect in method engineering is to consider the modelling goals and intention of each part of the method. In this context, Wang et al. [32] add a user focus for model transformation quality attributes. Considering both the impossibility of perfect semantic matching between metamodels and the different modelling and transformation intentions of the users, the authors classify transformation coverage and information loss as generic quality properties. On the other hand, Specific quality properties are attributes that are defined by the user of the method or method part. This definition is based on both the transformation goals and the modelling intentions for the source and target models.
The studies presented above confirm the scientific relevance of the quality evaluation of methods that connect several modelling languages. Apart from the internal quality of the existing modelling languages and transformations, it is important to consider both the overall method quality and the modelling and transformation intention of the user. Moreover, the reviewed literature supports the importance of connecting ontological-consistent modelling methods, in order to focus on the analysis of the modelling intentions, in this case, the strategic alignment of the information system.

A. RESEARCH GOAL AND SCOPE
The goal of the analysis is to identify the challenges for integrating strategic information at the organisational modelling level into the business process and information system modelling levels.
A challenge is an issue that hinders the HMDD goals, i.e., the traceability and the automatic transformation of strategic information into concepts at the lower modelling levels. We define the HMDD goals as follows: • Traceability is the capability to trace modelling elements through different stages of the modelling process [33].
• Practical Automation is a significant and non-redundant automated transformation of modelling elements through different stages of the modelling process. Non-redundance means that there must be differences in the rationale and detail of the source and target modelling elements to avoid adding overwhelming details to more abstract levels to have a completely automated transformation. A transformation is significant if it helps to provide a method quality feature, taking into account the features defined in [33]: refinement, modularity, repeatability, complexity management, expressiveness, reusability, scalability, and domain applicability.
We refer to strategic information at the organisational modelling level to 1) information that belongs to the business strategy domain and 2) that is relevant for the development or evolution of information systems. Concerning the first point, the traditional business strategy approach considers information about the goals of the organisation and the means to achieve them [34], including information regarding strategic planning (goals, objectives, strategies, and tactics, among others), organisational structure (organisational units and roles), and business capabilities [35]. Concerning the second point, modern approaches to strategy consider designing and developing of capabilities a long-term activity [36], so modelling capabilities would be out of the scope of an HMDD method. On the other hand, the organisational structure and high-level ends and means have a short-time scope and are considered by several agile frameworks as key for the strategic alignment of technology. Since systems' architecture replicate the organisational structure [37], units are structured around business outcomes, thoroughly addressing a business process. Consequently, the supporting information systems and services replicate this architecture, achieving strategical alignment. The strategic information considered by agile frameworks, thus organisational structure and high level means and ends, is valuable for an HMDD method.
Based on these elements, the analysis will focus on 1) challenges for modelling strategic information at the organisational level, and 2) challenges in preserving the strategic information throughout the model transformations, from the point of view of the business logic and business structure. These definitions lead to a set of analysis cases depicted in Figure 1.

B. ANALYSIS OBJECT
The analysis object of this article is an HMDD method covering business strategy modelling to information system modelling and code generation. We followed three main criteria for selecting the modelling frameworks to compose the HMDD method, listed below.
• Organisational level business strategy representation: the framework for representing organisational goals must be useful for representing business strategy. i* is one of the most used frameworks for business goals modelling for strategic alignment [17]- [19]. We choose i* based on this fact; however, it is worth noting that strategic concepts such as strategy, influence, motivation, and tactics are not present in i* but have been mostly covered by enterprise architecture frameworks such as Archimate [4].
• Information system level code generation: the modelling framework for the information system level must support code generation. As reviewed Sebastian et al. [2], there are more than 50 MDA-based initiatives with code generation, being UML the most used language. However, most of the research initiatives lack industrial adoption evidence. We choose the VOLUME 10, 2022 OO-Method [16] (OOM), since its tool support 3 has been applied for more than a decade in several software projects; also, OOM uses diagrams that are similar to UML's class and estate machine diagrams.
• Semantic consistency: As researched by Mustafa and Labiche [22], one of the most challenging aspects to connect different modelling languages is to have meaningful connections among them. Even though BPMN is one of the most used language for business process modelling, we opted for the Communication Analysis method [15], since it has been methodologically integrated with OOM [21] and with i* [6]. The stack of methods is depicted in Figure 2. Below, we describe the methods and the integration techniques.
At the organisational modelling level, we propose modelling organisational goals and strategic elements using i* [14]. i* is an agent-oriented modelling language whose central construct is social dependency among actors to achieve their goals. The current version of the language [38] allows the representation of the dependencies among actors (abstract concepts of interacting entities), agents (real-world persons or organisations), and roles (behavioural definition of interacting entities). These entities can depend on each other to achieve goals, acquire qualities, perform tasks, or to get resources. i* supports two modelling levels: the Strategic Dependency Model, where dependencies among actors are represented, and the Strategic Rationale Model, where details about the actors' inner goals, tasks, resources and qualities are modelled. Since i* is a multipurpose language, it allows the modelling of requirements, business processes, and organisational change analysis, among other applications. In the 3 Integranova Software Solutions -http://www.integranova.com/es/ context of this analysis, we focus on the application of i* at the organisational analysis level.
For the transformation of goal models to business process models, we use the GoBIS technique [6]. GoBIS uses FRISCO [24] as a pivot ontology [39] to ensure ontological consistency among models. Its main construct is that the satisfaction of a dependency between actors involves a communicative interaction between these actors. GoBIS presents nine guidelines to cover the different types of dependencies of i* and map as much information as possible about the process flow. The GoBIS approach provides semi-automated assistance for the analyst in the model transformation process.
For business process modelling, we use the Communication Analysis [15] method (CA). CA is a communicationcentred business process modelling method. Its main construct is the communicative interaction among actors. A communicative interaction is a fine-grained unit of valuable information about the problem space in the business process context [40]. The communicative interaction involves a primary actor that triggers the communication, a communicative event, that details the communication requirements, one or many receiver actors, that are the target of the communication, and ingoing and outgoing interactions. The communicative events can be specified in terms of the contact, content, and reaction system requirements for supporting the communicative event. The ingoing and outgoing interactions can be specified in terms of the structure of the messages, allowing to specify data fields, types, and structure.
For the transformation of business process models into information system models, we use the technique presented in [21], which allows the derivation of OOM structure, behaviour, and functional models. The main idea is that the structure of the messages interchanged among the actors can be mapped into classes, attributes, and their relationships. Moreover, the process flow and the actors' interactions can be mapped into methods and, partially, into functionality. The technique also ensures semantic consistency among CA and OOM using FRISCO [24] as pivotal ontology [39].
Finally, for the information system modelling level, we use OO-Method (OOM) [16]. OOM is an example of an MDD method: it is a software production method that is based on a formal language for the object-oriented specification of information systems called OASIS [41]. OOM is composed of four modelling views: the object model, the dynamic model, the functional model, and the representation model. The object model allows specifying the system structure using object orientation, while the dynamic model represents the system's behaviour. The functional model allows to specify business logic, and the representation model permits defining abstract user interface components for using the system services. The specific platform requirements are modelled as attributes of the information system. The tool support for the OO-Method is INTEGRANOVA Model Execution System [20], an industrial tool that fully supports OOM and generates codes in several technological platforms both for the back end and the front end of the information system.

C. ANALYSIS METHOD
From a Design Science perspective, the research method is based on the abductive inference from a mechanism experiment [42]. The mechanism experiment consists of exposing an artefact to stimuli, observing its response, and explaining the response based on the internal mechanisms of the artefact. In this analysis, we observe how modelling methods and transformation techniques respond to the attempt of preserving the strategic information from the top to the bottom modelling levels.
The null hypothesis is that it is possible to provide traceability and practical automation (the HMDD goals) of strategic information from the organisational modelling level to the business process modelling level to the information system modelling level. For each modelling level presented in Figure 1, we designed mechanism experiments, i.e., a modelling or model transformation situation based on a working example that aims to test the null hypothesis. For each experiment, we present the following topics: • The mechanism experiment, describing the modelling or model transformation situation.
• The problem, describing how the experimental situation hinders traceability and practical automation.
• The explanation, proposing a cause of the problem based on the methods' inner concepts, relationships, or mechanisms.
• The implications, describing the effects of the problem in the development process are commented.
• The rationale, classifying the problem in terms of quality attributes extracted from the literature review (information loss or transformation coverage) and its impact on traceability and practical automation of the HMDD method. We also comment on how the issue VOLUME 10, 2022 could be addressed, referencing existing methods and techniques.
• The challenge, as a statement of an improvement goal for the HMDD method. A limitation of this analysis method is that, as stated in [42], the explanations provided by the abductive inference method are not certain but probable. To explore whether these explanations are shared by other researchers, in Section V we discuss the identified challenges with three experts in requirements engineering and model-driven engineering that also know the methods under analysis. III-B.

IV. ANALYSIS OF CHALLENGES
In the following subsections, we present the challenge analysis for designing a Holistic Model-Driven Development (HMDD) method. First, we analyse two cases that expose issues regarding the representation of strategic information at the organisational modelling level with i*. Then, we analyse three cases of transformations from the organisational level to the business process level showing traceability or automation issues when attempting to preserve strategic information. Finally, we present two cases of transformations from the business process level to the information system level, showing traceability and automation problems with the same aim as the latter.
It is worth noting that these challenges are not intrinsically an issue of the methods and techniques but arise from the necessity of using them to accomplish the HMDD goals stated in subsection III.
As a working example, we introduce a real estate agency for house and apartment renting operations, namely a property. Currently, potential tenants ask the agency for properties that fulfil specific requirements. The company assigns an agent who offers a set of properties that might cover the requirements. The tenant makes a reservation, pays a booking fee, and submits his or her financial profile. The agency reviews the tenant's financial status and then confirms (or not) the reservation. Currently, the agency is facing competitors that offer shorter times from the property requirements specification to the reservation confirmation. In order to react to this threat, the agency is re-engineering the renting process to go entirely online. The agency expects to maintain and even increase its market share.

A. CHALLENGES IN ORGANISATIONAL MODELLING
At this modelling level, we look for challenges regarding how to design an organisational model using i* (presented in Section IV-A1) and about what concepts must be modelled at the organisational level (presented in Section IV-A2).

1) CASE 1: MODELLING PROCEDURE FOR THE ORGANISATIONAL LEVEL
This case shows that the mere presence of concepts regarding organisational structure and strategic intentionality is not enough to produce organisational level models.
Mechanism Experiment: An analyst is asked to design an organisational model as the first activity for re-engineering the renting process. The i* model in Figure 3.(A) describes the goal of the organisation (online renting service offered) that is refined by two tasks (receive booking and show available properties). These tasks depend on the Tenant, so two social dependencies are designed between the Agent and the Tenant. Then the analyst designs the model in Figure 3.(B) as the first step for designing business process models to implement the business strategy.
Problem: The i* model in 3.(A) is semantically correct and expresses the organisational goal of offering an online service as the motivation for more detailed tasks. However, in the context of HMDD, we identify a modelling issue when using the approach shown in Figure 4(B), which introduces redundancy: both 3.(A) and 3.(B) models have the same level of detail. Overlapping business process specification introduces redundancy, hinders complexity management of the model, and introduces process modelling detail that could be overwhelming at the organisational level.
Explanation: i* does not prescribes a modelling procedure, so it can be freely applied by the analyst. However, for its integration in an HMDD method, modelling guidelines for using i* at the organisational modelling level would be needed to prevent mixing business intention with business process specification. Figure 4 illustrates the difference between i* models representing (a) strategic ends and means, and (b) a model with fine-grained tasks.
Implications: In practice, this would lead to use the same model to reflect about business strategies and goals and for defining operational details about who delivers a document to whom. To avoid this issue, the business process details must be delegated to the CA model, and traceability must be provided from the motivation to the specification of business processes.
Rationale: the modelling issue can be classified as an information loss issue. Given the intention to model organisational strategy, not having a modelling procedure to avoid unnecessary detail at the organisational level could harm the traceability of strategic information in the HMDD method. It also harms the practical automation of the method since not having a modelling procedure does not ensure that an analyst could get to model the concepts that can be transformed into elements of the business process modelling level.
Challenge: Challenge 1 -Provide a modelling procedure to avoid overlapping between the organisational and business process modelling levels.

2) CASE 2: MODELLING CONSTRUCTS FOR THE ORGANISATIONAL LEVEL
This case aims to identify if more specific concepts are needed to represent organisational goals and strategic elements.
Mechanism Experiment: An analyst must represent the business strategy defined by the directors of the company. In addition to the goal of increasing market share and the strategic action of offering an online renting service, the agency's executives define that no more than 12 hours must   pass between the moment when a tenant contacts the agency to manage a property and the online publication of the property. Also, executives define that Tenants must be able to request the agency publication services at any time, from anywhere. The analyst represents this information in the model depicted in Figure 5.
Problem: The analyst applied the same i* modelling concepts (goals and tasks) to represent, in the same diagram, different business concepts. On the one hand, regarding organisational ends, ''market share increased'' is a general desire of the state of affairs. At the same time, ''property published in less than 12 hours'' is a more specific, measurable desired state of affairs. On the other hand, concerning organisational means, offering an online renting service is a high-level strategic action that can impact several business processes. At the same time, ''provide online property VOLUME 10, 2022 publishing request form'' is a precise action that affects a specific set of activities of the organisation.
Explanation: There is a construct deficit [43], this is, the i* constructs are not enough to represent relevant concepts of organisational modelling.
Implications: Given strategic information and the i* constructs (goals, tasks, resources and qualities), the decision of what to model could lead to the analysts to omit high-level information, to represent as goals the more precise definitions, or to omit the more detailed information, to favour a more high-level model. Since each analyst decides what concepts are important to model, two models could not be compared nor evaluated in terms of completeness and consistency, as already identified by Estrada et al. [33].
Rationale: Other organisational modelling initiatives such as the Business Motivation Model [44] and ArchiMate [4] define several concepts for the ends of an organisation (goals, vision, objectives) and for the strategical means (strategies, tactics, courses of action, business policies, etc.). The definition of these concepts and their relationships could improve the semantics of organisational models. This issue is related to information loss, and hinders the traceability of strategic information.
Challenge: Challenge 2 -Define the organisational level constructs that are valuable for representing strategic information.

B. CHALLENGES IN THE TRANSFORMATION OF THE ORGANISATIONAL MODEL TO THE BUSINESS PROCESS MODEL
This section shows issues when transforming organisational models in i* to business process models in Communication Analysis (CA). We took as reference the GoBIS technique [6] for transforming social dependencies between two actors in i* into communicative events between the same actors. In order to identify challenges for the HMDD goals, we present three cases. Case 3 exposes the current voids in transforming the organisational structure and business strategy information into elements of the business process models. Cases 4 and 5 show the effects of not preserving the organisational information in business processes' structure and logic.

1) CASE 3: PRESERVING ORGANISATIONAL STRUCTURE AND STRATEGY INFORMATION
This case shows that information at the organisational level that is not currently mapped could be important for designing strategically aligned business processes.
Mechanism Experiment: The agency's executives have decided to create a new business area, the Sales Department, responsible for the reservations. The agents will belong to the Sales Department and be responsible for confirming the reservations in less than 12 hours. The Agent must receive a booking from another actor (Lessor) to achieve this goal, creating a social dependency. The analyst models these strategic definitions as shown in 6.
Problem: The GoBIS [6] technique allows mapping social dependencies among actors into communicative interactions; however, strategic concepts that are not directly related to interactions among actors are not mapped into any business process concepts in CA. As detailed in Figure 6, the Agent's goal will not be mapped into the business process model, and the analyst must manually keep track of the constraint ''booking confirmation in less than 12 hours'' when designing the business process. On the other hand, since the organisational structure is only modelled at the organisational level, the information of these concepts will be lost.
Explanation: When using i* for representing the actor's goals for an information system, the transformation technique helps connect the actor's goals with the business processes that support them. However, when using i* for organisational modelling, extending the transformation to cover other relevant information besides the actor's goals is needed.

Implications:
The analyst may be ignoring relevant organisational definitions, hindering the strategic alignment of business processes. For example, the goal ''booking confirmed in less than 12 hours'' sets requirements for at least three communicative events or tasks in the business process model. First, it is needed to register the date and hour of the reservation and then register the date and hour of the confirmation. Finally, it is necessary to report this information to the Sales Department. These requirements also have effects on the design of the information system.
Rationale: This is a transformation coverage issue since there are elements in the source metamodel that are not being mapped to the target metamodel. Concerning organisational structure, the target of a ''participates-in' relationship in i* could be mapped as an organisational unit in CA, since this concept already exists in the CA metamodel [21]. In other notations such as Business Process Model Notation (BPMN) [45], the i* relationship could be mapped as the label of a pool group, where each pool represents an actor that belongs to the unit. Concerning goals and strategies, the CA metamodel allows specifying the goal of communicative events as an attribute of the Communication Event Template. It would be possible to map the i* intentional elements into a textual format to guide the analyst when designing the business process. Similarly, i* goals could be mapped to BPMN's process documentation since BPMN metamodel supports this attribute. This issue hinders the traceability of strategic information and its practical automation.
Challenge: Challenge 3 -Transform organisational structure and goals into business process concepts.

2) CASE 4: EFFECTS ON THE BUSINESS LOGIC OF THE BUSINESS PROCESS MODEL
Mechanism Experiment: The Agency defines as part of the strategy that the online renting service and all the associated services must provide maximum customer satisfaction. As part of the online renting service, the analyst must model the process to attend reimbursement claims by the Lessor. In 7.(A), the customer satisfaction is not considered, and the Lessor's claim is assessed first and then compensated, while in Fig 7(B), the claim is immediately compensated and then assessed.
Problem: Unless the assessment of the claim is extremely fast, the model in Figure 7.(A) will be misaligned with the organisational goal of customer satisfaction.
Explanation: There is no concept in i* to represent a strategic behavioural statement that could favour the traceability and practical automation of business process flow decisions from organisational level definitions.
Implications: There is a risk of designing business processes with logic that is not aligned with the organisational goals.
Rationale: In other organisational modelling frameworks, such as the Business Motivation Model (BMM), there is the concept of directives that can be business policies or business rules, both of which can be traceable to business process elements in BPMN [44]. Including a behavioural concept at the organisational level that could be mapped to the business process flow could help design strategically aligned business processes. This is an information loss problem, and an improvement opportunity for traceability and practical automation. There is also an opportunity to improve practical automation by encapsulating business process patterns [46] or interaction patterns [47] in these strategic behavioural statements. Including behavioural concepts at the strategic level would also allow taking advantage of the existing pattern repositories, analysis techniques, and methods [48].
Challenge: Challenge 4: Define a strategic behavioural concept to guide the design of business processes. VOLUME 10, 2022 FIGURE 7. Two different business process designs with and without taking into account the customer satisfaction goal.

3) CASE 5: EFFECTS ON THE STRUCTURE OF THE BUSINESS PROCESS MODEL
This case aims to show that losing information about organisational structure and goals impacts how the generated process elements are organised in different business processes.
Mechanism Experiment: When defining the organisational goal of offering an online renting service, the agency also requires training for the Agents to use the online renting platform and an advertising campaign of the new service. For the first, the agency depends on the Human Resources Department, specifically on the Chief of Human Resources; for the second, the agency depends on the Marketing Department, specifically on the Marketing Executive. The analyst models these definitions as shown in Figure 8 (the departments have been omitted for simplicity). Considering the transformation of social dependencies into parts of the business process, the agency's dependency with the Chief of Human Resources and with the Marketing Executive will lead to two separated business process elements. Whether these process elements belong to the same business process model or not must be decided by the analyst.
Problem: Three problems can arise when automatically transforming social dependencies of an organisational model into business process elements: (1) merging elements from different business processes, (2) mapping unnecessary process elements, and (3) spreading elements in different processes that are meant to be in the same re-engineered business process.
Concerning the first point, the dependencies with the Chief of Human Resources and the Marketing Executive displayed in Figure 8 could motivate the re-engineering of the training and advertisement processes (in addition to the re-engineering of the renting process). In this case, three different processes need to be modelled, and the elements generated by the transformation must be distributed according to the organisational structure of the dependencies. For the second point, it could be the case that the Agency needs the training and advertisement processes to be performed in the same way as usual, thus not requiring changes to the existing business processes. In this case, it would be wrong to automatically transform these dependencies into elements for designing the new business process model. For the third point, consider that all the dependencies in Figure 8 have the same source goal. As commented in Section III-A, agile alignment tends to group business processes around business outcomes. Knowing that a set of dependencies belongs to the same organisational goal would help group the automatically generated process elements in the same business process model.
Explanation: The current transformation technique does not consider information about the context of a social dependency (e.g., the organisational structure or source organisational goal) that could help to group the generated process elements into different business process models.
Implications: In practice, this means making the analyst responsible for manually organising the automatically generated portions of business process elements into different diagrams, without providing any guidance to identify separated business processes and sub-processes. To better assist the analyst in the transformation, the current transformation technique must be extended to identify the source grouping concept at the organisational level and map it as a grouping concept for business process elements. Also, the technique can consider identifying if an organisational goal or strategy affects the current design of business processes.
Rationale: this is an information loss issue, as the mapping between elements could be misplaced and hinder traceability and practical automation. In other organisational modelling approaches (BMM [44], [49]), it is possible to connect concepts that describe strategic courses of action with the affected business processes. In i*, there is no way to connect goals with the affected business processes or group the actors and concepts of the same business process. The transformation technique could be extended to identify organisational level actions that affect business processes. Since a CA model can have several diagrams [21] to support modularity [33], the transformation could be extended to define the target view in the business process model.
Challenge: Challenge 5 -Organising the transformed business process elements using the strategic organisational context.

C. CHALLENGES IN THE TRANSFORMATION OF THE BUSINESS PROCESS MODEL TO THE INFORMATION SYSTEM MODEL
This section presents two cases to expose issues in the transformation from business process models in CA to information system models in OOM. The transformation algorithm is detailed in [21]. The technique provides 29 guidelines to generate the OOM model's class structure, behaviour, and functional views. With a semi-automatic approach, the technique leaves some modelling decisions to the analyst during the transformation process. Since the transformation algorithm is broad in terms of the CA concepts mapped, the analysis will be focused on the effects on the structure and on the behaviour of the information system model, in Cases 6 and 7, respectively.

1) CASE 6: EFFECTS ON THE BUSINESS LOGIC OF THE INFORMATION SYSTEM MODEL
This case shows that the business logic modelled at the business process level, specifically designed to achieve an organisational goal, can be wrongly mapped to the information system model.
Mechanism Experiment: As part of the strategy to achieve the goal of customer satisfaction, the Agency sets the goal to provide high-quality reviews for the offered properties. The Agents must complete this information only after visiting the property. The analyst specified this textually in the Communicative Event Template (CET), as shown in Figure 9.(A) (For brevity, the example only refers to the textual description of the property). When transforming the business process to the information system model, the analyst could model the additional details as attributes of the Property class ( Figure 9.(B)), or as a new Property Details class, related to the Property class ( Figure 9.(C)). For the first case, the Property class has a method to set the property description. In the second case, a class that explicitly contributes to the organisational goal is modelled.
Problem: The design in Figure 9.(C)) better represents the strategic definition, however it is hard to get to this modelling detail only from textual descriptions. Although this is a very particular example, other critical business definitions are expressed textually in CA (and in other business process modelling languages), such as constraints and validations. However, it would be overwhelming for the analysts to detail business logic in a formal or structured manner since it would hinder the understandability of the processes' documentation.
Explanation: Different interpretations of textual descriptions could impact the alignment of the information systems and services with the organisational level definitions.

Implications:
The textual descriptions of business logic guide the analyst in the transformation process; however, the amount of business logic in large models could be overwhelming. It would be helpful to assist the analyst in making the mapping decisions by identifying the textual references for the entities under analysis.
Rationale: This is an information loss issue, that could hinder the practical automation of the method. It is possible to extract domain knowledge from unstructured text. Artificial Intelligence, specifically Natural Language Processing (NLP) algorithms and techniques, provides powerful tools to improve traceability and practical automation for transforming CA models into OOM models. From the HMDD perspective, there is a challenge regarding using domain knowledge in text requirements for automatically generating the OOM structure, behaviour and functional models. There are several initiatives about using textual requirements to generate object-oriented models [50], [51] that could complement the existing transformation technique.
Challenge: Challenge 6 -Assist the transformation of business process models to information system models business by automatically extracting domain knowledge from text requirements.

2) CASE 7: EFFECTS ON THE STRUCTURE OF THE INFORMATION SYSTEM MODEL
This case shows that transforming a business process model that covers many processes into a single information system model affects the strategic alignment of the design of the information system.
Mechanism Experiment: Consider that the Agency needs to re-engineer the renting process and the property publication process (related to Lessors asking the Agency to manage their properties). Although they are depicted in separated diagrams, both re-engineered processes are part of the same business process model. When transforming a CA model with several diagrams representing different business processes, the classes generated from those diagrams will be mixed into a single class model, regardless of their source business process.
Problem: Not grouping the information system classes and methods according to the business process that they serve yields to build a monolithic system that couples different business areas in the same software component. Explanation: The transformation does not consider the information about the source business process of the generated classes.
Implications: The analyst would have to manually group the generated classes with no guidance other than the business process model and documentation. The current transformation technique should be extended to better assist the analyst in this task.
Rationale: This is an issue of information loss, related to the business context of the generated classes, that hinders both traceability and practical automation. Business process context information is valuable and possible to map to the information system modelling level. The software engineering practitioners have adopted initiatives for managing the business logic complexity based on organising it with a business perspective. For example, Domain-Driven Design (DDD) [52] aims to strategically define subdomains for organising development teams, while Microservices [53] guides the architectural organisation of the system in services that represent cohesive business functions.
Given the rich business process context that CA can provide and the microservices support by OOM's tool support, there is an opportunity to add process context information to help (or even automate) the organisation of classes into subdomains and services. A similar challenge regarding the use of DDD and Microservices for Model-Driven Development has been identified by Rademacher et al. [54].
Challenge: Challenge 7: Organise the generated elements of the information system model according to the business process context.

V. DISCUSSION
As presented in Section III, the mechanism experiment allows identifying possible explanations for the modelling issues found, which we have named as challenges. However, there are two threats to the validity of these challenges. The first is that the modelling issues might not be relevant in achieving traceability and practical automation in HMDD. The second is that the modelling issues could be already solved by other methods or techniques different from or complementary to those examined in the analysis.
To mitigate these threats, we surveyed three experts on the modelling methods presented in Section III-B. These experts have worked with i*, CA and OOM for at least five years. They are researchers from Utrecht University (Netherlands), Zurich University of Applied Sciences (Switzerland), and Universidad de Castilla la Mancha (Spain), respectively. They have no relationship with the contributions of this paper.
We described each challenge with the same examples presented in Section IV, and we asked the questions detailed below.  Table 1 presents the data collected from the survey. In Fig. 10, we present the importance and frequency addition of each challenge. We comment on the main findings below.
Challenge 1 (Provide a Modelling Procedure to Avoid Overlapping Organisational and Business Process Modelling Levels): While experts agree that guidance for avoiding overlapping is necessary, there is no consensus about its importance. Expert 2 gave the maximum rating to importance. The other two experts (who gave a rating of medium importance) agreed that separated models make it easy to maintain the whole model and help to avoid inconsistencies among models. Expert 3 stated that ''it is important to keep a link between goals and business processes''. However, Expert 1 noted that ''avoiding overlap, the transformation of process models from goal models is difficult''.
Concerning the frequency of the problem, while Expert 2 gives a high rating to mixing goals and detailed tasks when modelling in i*, Experts 1 and 3 find it unusual. This contradiction could be due to the small size of academic projects. Finally, about existing initiatives to solve the problem, Expert 3 provided a reference to a proposal of a combination of different modelling methods, but at the same modelling levels [55] (Maps [56] and BPMN [45]), where the difference among levels is more clearly stated.

Challenge 2 (Define the Organisational Level Constructs That Are Valuable for Representing Strategic Information):
This challenge was the most supported by the experts of all of the other challenges. They all agreed on the need for systematic support to define organisational level concepts and rated it as very important and frequent. Expert 3 commented that ''Different people can make very different models of the same phenomenon under study due to the lack of specific and homogeneous guidelines to follow.''. Concerning current initiatives that could bridge this challenge, Expert 3 provided references to the work of Professors Joao Araujo and Jaelson Castro, from Universidade Nova de Lisboa and Universidade Federal de Pernambuco, respectively.
We reviewed the work by professors Araujo and Castro on a systematic review of i* extensions [57]. A catalogue of i* extensions was developed based on the study's results. 4 A total of 24 concepts in the organisation//business process category were found, some of which are important for modelling strategic definitions [58]. However, language constructs which are appropriate for describing business strategies, such as strategy, tactic, and objective, are not present among these extensions. The work by Kitsios et al. [35] also reviews strategy concepts in goal and enterprise architecture languages, including i* in the review. The findings show that some of the strategy concepts not included in i* are included in ArchiMate [4] or in Business Motivation Model [3]frameworks. However, these frameworks are much more extensive and complex than i*, lacking i*'s social approach to model actors' inner goals and strategies. On the other hand, no modelling procedures were found to ensure the consistent representation of organisational goals and strategies regarding requirements engineering.

Challenge 3 (Transform Organisational Structure and Goals Into Business Process Concepts):
There was no consensus about supporting this challenge. Experts 1 and 2 agreed on the importance of the problem but disregarded automatic transformation in favour of the analyst being principally responsible. Moreover, Expert 2 indicates that ''Traceability could be created using partial automatic transformations along with additional information provided by the analyst.''. Experts agreed on the problem's high frequency and that, to their knowledge, there is no solution for this issue. The experts did not provide references to existing initiatives addressing this challenge.
Challenge 4 (Define a Strategic Behavioural Concept to Guide the Design of Business Processes): This was the least supported topic by the experts. The experts agree that there is no need to add behavioural elements to i*, and Experts 2 and 3 gave the lowest importance and frequency to the modelling issue. Regarding the existing initiatives for tackling this challenge, even though experts 1 and 2 commented on the existence of i* extensions for including process flow definitions, no specific works or authors were mentioned.

Challenge 5 (Organisation of the Generated Business Process Elements Using the Strategic Organisational Context):
All three experts supported this challenge; however, Expert 2 stated that the solution could be combined with a manual approach similar to Challenge 2. Expert 1 stated ''What I would propose is that the traceability is generated automatically, but I think that the modularity of business processes must be determined by the analyst''. While the experts did not provide references about existing works to overcome this challenge, Expert 1 commented ''I think that a good way to solve this challenge could be joint modelling of i * and processes.''.
Challenge 6 (Assist the Transformation of Business Process Models to Information System Models Business by Automatically Extracting Domain Knowledge From Text Requirements): This challenge has significant support from Experts 1 and 3, while Expert 2 considered that [21] provided a satisfactory solution for the challenge. However, Expert 1 leads us to think that he believes that the problem is already solved. Expert 2 commented about two initiatives regarding the requirement extraction from textual specifications: in [59] authors use a machine learning-based approach to demarcate requirements from the unstructured text. Yue et al. [60] propose a structured use case format (RCMC) that is later extended for characterising uncertainty in requirements specifications [61]. These works can be used as a reference for structuring textual requirements and their automatic transformation into concepts at the information system model level.
Challenge 7 (Organise the Generated Elements of the Information System Model According to the Business Process Context): There is no consensus on supporting this challenge, and ratings about its importance and frequency are scattered. Expert 1 supports the idea of traceability, but not necessarily the automatic grouping of classes in packages. Expert 2 stated that the current metamodel of Communication Analysis allows grouping business objects (equivalent to classes) in goals and projects, which might be considered for code generation. Finally, Expert 3 stated that the problem is not clear, arguing that If a class is used in multiple business processes, what would be its proper context?. Regarding existing initiatives, Expert 1 suggested exploring how code generation tools like Mendix [62] manages to organise code from business processes. It is worth mentioning that approaches such as Domain Driven Design [52] provide answers to the question of classes and services that are shared across business domains through patterns.
From the above results, we conclude that defining what and how to model organisational level concepts with i* are the most supported claims and that it is an open issue: while organisational strategy concepts exist in enterprise architecture frameworks, these frameworks are more complex than i*, and in any case, there are no systematic modelling approaches to avoid overlapping and foster integration between organisational and business process levels. However, experts agreed that providing support for automatically tracing generated elements is desirable but not replacing the analyst when modularising business processes and system classes. The claims with minor relevance are related to the automatic collection of domain knowledge from textual requirements and adding strategic behavioural statements to the organisational level. Overall, the results of the survey lead us to think that the main challenges for achieving strategic alignment in an MDD context are the systematic modelling of organisations' goals and strategies and an assisted transformation from strategy to modular business processes.
From the above findings, we present three recommendations for designing an HMDD method for software development to address the challenges that the experts most supported.
• Recommendation 1: At the organisational level, the modelling language must precisely focus on strategy elements and must have a modelling procedure that prevents from having several levels of refinement for strategic actions to keep a higher level of granularity than business process elements. This recommendation addresses Challenges 1 and 2. Modelling Frameworks such as Eclipse Modelling Framework 5 or ADOxx 6 are suitable for building a modelling tool that includes both the language with the specific constructs and relationships and the validation algorithm for the modelling constraints.
• Recommendation 2: For the transformation from organisational models to business process models, an analysis framework for business process management could help to use the information about the organisational structure and the high-level organisational goals to design modularised business processes.

This recommendation addresses Challenges 3 and 5.
While tool support could help to scaffold the design of strategically business processes through automatic transformations, the analyst must decide how to match ideal business modules with the organisation's actual structure and change possibilities.
• Recommendation 3: For the transformation from business process models to information system models, the completeness of domain models can be automatically checked by applying existing natural language processing techniques to extract domain information from the textual descriptions of business processes. This recommendation addresses Challenges 6. This recommendation could be supported by an assisted modelling tool that suggests improvements for a model, given the textual description of business processes. It is worth noting that, even though the HMDD method is presented in a top-down approach, existing techniques for managing changes in models at different levels can be applied for the proposed stack of methods. We believe that the HMDD method could be suitable for organisations that follow traditional or model-driven development methodologies but aim to get an agile approach for analysing and designing their organisation structure, business processes, and supporting information systems.

VI. CONCLUSION
Quickly reacting to an uncertain environment is a key skill of modern organisations, and technology must be the enabler of agile responses to these changes. The design and evolution of information systems and services aligned to the organisation's goals and strategies is a challenge for software developers. Model-Driven Development can tackle this challenge by the precise integration of organisational, business process, and information system models to provide traceability and automatic transformations from strategy to code. In this article, we analyse the challenges for this integration by examining three modelling methods: i* for the organisational level, Communication Analysis for the business process level, and OO-Method for an executable conceptual model at the system level.
We identified a set of challenges to preserve strategic information from the organisational to the information system modelling level by designing experiments that expose modelling issues. We found challenges to represent strategic information at the organisational level caused by both construct deficit of the language and lack of guidance in the modelling process. We also identified challenges for preserving business structure from the organisational level to the modular design of business processes and system components, primarily due to the loss of organisation structure information during the model transformations. Finally, challenges to connect business policies with business processes and their implementation in the system's business logic were identified, produced by the lack of representation of behavioural elements at the organisational level.
The identified challenges were discussed with experts in model-driven development and requirements engineering and with broad experience using the methods used for the analysis. The experts were surveyed on whether the challenges were important and frequent. Also, the experts provided feedback about other modelling approaches that could have tackled the challenges and their opinion on the need to address the challenge systematically. The most agreed challenges by the experts were related to improving the representation of the organisation's goals and strategic elements. The experts partially supported the need to preserve the business structure and discouraged the inclusion of behavioural elements at the organisational level.
The results provide a starting point for designing a holistic model-driven method to develop strategically aligned information systems. The design goals of the method must focus on the representation of organisational goals and strategies and the preservation of the business structure to the business process and information system modelling levels. Future work will exploit i*'s simplicity and capabilities to improve business strategy representation. Improvements for the existing transformation techniques will be designed to preserve business structure from the organisational level to the design of the information system.