Keywords

1 Introduction

Organizations, whether operating in public or private sectors, are exposed to frequent changes in their environment driven by technology advancement, demanding customers, aggressive competitors, growing dependency on information technology as well as regulatory changes. In order to remain competitive, organizations need to adapt to swiftly changing their business strategy and/or their business processes. To do so, organizations need to have a holistic view over the impact of such changes.

In recent years, enterprise architecture (EA) has gain relevance for its holistic management of information systems in an organization. Fundamentally, EA describes a coherent whole of principles, methods, and models that are used in the design and realization of an enterprise’s organizational structure, business processes, information systems, and infrastructure [11]. EA is used as a means to design and communicate the desired organizational changes according to the business strategy, and to implement these changes across the operational structures, processes, and systems of the organization’s business and IT domains [18].

A considerable part of EA is model-based, in the sense that diagrammatic descriptions of the systems and their environment constitute the core of the approach. Therefore, EA models are used to represent the enterprise’s domains. All EA models must be compliant with the EA meta-model that specifies the elements and relationships used to structure and represent the enterprise in all its domains [6].

Co-evolution denotes the process of adapting models as a consequence of meta-model evolution [15, 16]. As the organization changes, so must its architecture. Therefore, to keep updated architectural views of the organization is necessary to co-evolve the EA meta-model and respective models.

Existing EA software tools do not fully address the co-evolution of the EA meta-model and models, thus making the task of maintaining a consistent and updated EA repository strenuous and error-prone. For instance, if one seeks to employ evolution-specific scenarios to the EA meta-model focusing on the organization’s goals, the information captured by the EA models at that time becomes inconsistent with the new EA meta-model. Without an automated support, the effort of updating and resolving all model inconsistencies manually is unsustainable and impractical when dealing with complex changes.

Furthermore, once the evolution scenarios are specified, information relative to the impact of changes in the EA models should be regarded. EA analysis, being the application of property assessment criteria on EA models, helps to understand which architectural scenarios are most appropriate towards realizing the organization’s strategy. For instance, one might see fit to assess semantic inconsistencies of a specific evolution scenario and a criterion for assessment of this property could be “If altering a relationship between two EA meta-model elements creates a semantic inconsistency in a single view, then the scenario is impractical”. If concerned with the impact of manual effort in updating the architectural views, a criterion for assessment of this property could be “If more manual refactoring than expected is required in updating all views, the evolution scenario should be disregarded as viable”. Criteria and properties such as these may be extracted from academic literature or from empirical measurements.

This paper presents a software tool for co-evolution and changes impact analysis of the EA meta-model and models. The tool supports the creation of evolution scenarios and generates quantitative assessments of such scenarios. Assessments can be of various quality attributes, such as dependency impact, performance, semantic inconsistencies and manual refactoring effort.

The outline of this paper is as follows. Section 2 specifies the research problem. Section 3 presents a state-of-the-art review on the problem domain. Then, Sect. 4 describes the architecture, design, and usage of the tool. Section 5 presents a discussion about the usage of the too and Sect. 6 concludes the paper with a summary and themes for future work.

2 Research Problem

Managing EA change requires awareness over what has been changed and the compliance of those changes with the rules in which EA models can be updated. Hence, robust change management processes and procedures are essential in maintaining the architecture of the enterprise [10].

IT projects define and implement the strategies that guide the enterprise in its evolution [24]. An issue that typically compromises the success rate of IT projects is the complexity that EA models may bring. EA models explicit traceability across multi-layered elements representing the various levels of the enterprise [24] reinforces their tendency to focus on holistic views of the enterprise, rather than on the subset of artifacts relevant for a given project, thus making the task of reading and updating these models more complex [22].

Furthermore, many of today’s enterprises struggle with transformation management from a baseline architecture to a target architecture via intermediary planned architectures [7]. Several causes were identified by Aier et al. [5] regarding this issue, such as missing practical methodologies for architecture road-mapping, inadequate representation of the concept of time in architectural models and insufficient tool support for architecture planning.

More than just providing EA model visualizations, EA software tools are used when making strategic decisions concerning the enterprise [20]. Despite the multitude of available tools on the market (Troux, Aris, Enterprise Architect, System Architect, ABACUS, etc.), few support change impact analysis and automated model updates while maintaining a well-integrated EA repository containing the past, present, and future states of the architecture [13, 14, 19].

3 Related Work

This section presents a literature review of research domain. Section 3.1 outlines research made on the topic of EA evolution. Then, Sect. 3.2 highlights existing methods for meta-model evolution from both the fields of Model Driven Engineering (MDE) and Enterprise Architecture (EA). Finally, Sect. 3.3 describes some approaches on EA model change visualization.

3.1 EA Evolution

Evolving an EA is an iterative and incremental process. The transition architecture is a state of the EA between the baseline and target architectures. An enterprise might experience more than one transition architectures during the evolution process. A road-map is the abstracted plan for the business or technology change, typically operating across various disciplines and over multiple years [4]. Architecture road-maps are used to describe the transformation path, over a certain period of time, from the baseline architecture to the desired target architecture. Thus, a time-line view is necessary for describing or visualizing the architecture road-map, thus showing the required activities needed to be performed to realize the target architecture.

Besides EA road-maps, other approaches have focused specifically on updating the EA meta-model and respective models. Roth and Matthes [19] proposed a four-layered conceptual design of an interactive visualization to drill down and analyze model differences in both the EA meta-model and EA models.

Sousa et al. consider the evolution of EA models as a means to address change within the organization’s domain [22]. In their approach, an enterprise is perceived as a graph G of artifacts and their relationships that can be represented and altered by two fundamental types of the enterprise type space:

  • Blueprint: “whose instances contain references to other artefacts. A given artefact is represented on a given blueprint if graph G holds as a relation between them”;

  • Project: “whose instances contain references to artefacts related with the project”.

A state of existence of all artefacts is also defined for all artefacts representing the EA other than Blueprint as one of the following states:

  • Conceived: “if it is only related with blueprints”;

  • Gestation: “if it is related with alive projects and is not related with any other artefact other than blueprints”;

  • Alive: “if it is related with other artefacts in the alive state. This means that it may act upon other artefacts in conceived, gestation or alive states”;

  • Dead: “if it is no longer in the alive state”.

Sousa et al. consider the relevance of IT project and life-cycle as two important concepts concerning EA evolution. Nonetheless, their approach lacks a more detailed rationale on how the life-cycle of EA model elements changes, i.e., which transformations were applied to the elements.

3.2 Meta-model Evolution

In MDE, meta-models create a semantic and symbolic manner that has to be respected when representing the models. Sometimes models can not be modeled based on the actual meta-model, thus having the need to co-evolve together with the meta-model in order to maintain consistency. Some changes in meta-model are additive changes, and this away, they don’t break the respective models, but other, introduce incompatibilities and cross-version inconsistencies, therefore invalidating models. Therefore, models must be adapted to the new meta-model through migrations, as stated by Mantz et al. [12].

Therefore, for Mantz et al. [12], co-evolution of meta-model and respective models has to respect the following requirements:

  1. 1.

    Migrated models must belong to the evolved modeling language. This property is usually called soundness. It subdivides into well-typedness and well-definedness with regard to language constraints. A migrated model is well-typed if all its elements are typed over the evolved meta-model. Moreover, all well-definedness rules of the evolved language have to be satisfied.

  2. 2.

    All models of the original modeling language can be migrated to the evolved language meaning that the migration is viable. This property is usually referred to as completeness.

  3. 3.

    Model migration should be specified on a high abstraction level. This means that a model migration is either automatically deduced from its meta-model evolution or specified using a high-level language.

  4. 4.

    The specification of model migrations is reusable (see also [1]). In particular, equivalent migration steps are specified only once.

  5. 5.

    General strategies for model co-evolution are formulated independently of a specific meta-modeling approach.

In order to perform co-evolution of meta-model and respective models, a process and a set of migration rules need to be defined. The following sections describe a process applied to Model Driven Development (MDD) by Gruschko et al. [8] and a set of migration rules defined for EA by Silva et al. [21].

Model Driven Development Meta-model Evolution. Gruschko et al. [8] describe an approach to address the model migration problem, implementing transformations to migrate models when meta-models are changed. Their approach is based on the Meta Object Facility (MOF) meta-modeling architecture. MOF introduce a four layer division, where each layer represents a different level of abstraction. The first layer, M3, represents the meta-meta-models, that are used to define M2, the second layer. M2 describes instances models that are instances of M3. M2 models represent meta-model. The third layer, M1, describes instances of M2 and finally, M0 represents instances of M1.

Fig. 1.
figure 1

(reproduced from [8])

Example of M1 migration when changes in M2 happens

Full size image

The focus of their approach is the migration of M1 models when M2 changes and is defined as a 5 step method (see Fig. 1):

  1. 1.

    Change detection or tracking;

  2. 2.

    Classification;

  3. 3.

    User input gathering;

  4. 4.

    Algorithms determination;

  5. 5.

    Migration.

The first step (Change detection or tracking) is comprised of two options. The first option is the direct comparison between two different versions of M2 models, in which the output will be the differences between them. On the other hand, the second option is tracing the differences, i.e., taking an older version of the M2 model and a tracing of change operations as input. This trace of changes operations represent the operations that allow the older version of an M2 model to get to the desired M2 model version.

The second step, Classification, refers to the classification of the detect changes in step 1. The changes can be classified into 3 groups:

  1. 1.

    Not breaking changes;

  2. 2.

    Breaking and resolvable changes;

  3. 3.

    Breaking and unresolvable changes.

Gruschko argues that the first group is not relevant since these changes do not change the instances of M2 models (M1), thus no migration is needed. The second group is the group of changes that can be propagated to M1 models without user input. Finally, the third group is a group of changes that although they can be propagated to M1 models, some user input to execute the propagation is needed.

The third step (User input gathering) execution depends on the type of changes. If there isn’t any change of “Breaking and unresolvable changes” type, this step is not required.

The four step, Algorithms Determination, will generate changes necessary to do the migration, i.e., generate a list of necessary steps to turn the old M1 models into new M1 models aligned with the new version of the M2 model.

The fifth and last step is the migration of the M1 model itself.

Enterprise Architecture Meta-model and Model Co-evolution. Silva et al. [21] proposed, based on Wachsmuth research [23], a set of migration rules applied to the EA meta-model and respective models:

  • Co-construction

    • Introduce EA Property

  • Co-destruction

    • Eliminate EA Class

    • Eliminate EA Property

  • Co-refactoring

    • Change EA Object Class

    • Change EA Property Type

    • Move EA Property

    • Inline EA Class

    • Association to EA Class

    • EA Class To Association

Every migration rule corresponds to a modification on the EA meta-model that needs to be propagated to the respective models. To do this propagation, every transformation has some properties, parameters, pre-conditions, post-conditions, and statements. The parameters are all the information needed to propagate the transformation. The pre-conditions are conditions that need to be met before the propagation is made. The post-conditions are the conditions that need to be met to guarantee that the propagation was well done. The statements are the required propagation steps.

When applied, the migration rules follow Sousa et al. life-cycle approach in which all artifacts defining both the EA meta-model and respective models had a life-cycle property composed of four states: gestating, alive, dead, and retired. So, when applying any co-destruction transformation no artifacts are removed, instead their life-cycle state changes to either dead or retired. This principle allows for a history of changes made to the EA meta-model and its models.

3.3 EA Model Changes Visualization

Buckl et al. identified the challenge in the visualization of the development of business support provided by the application landscape over time [7]. In their approach both a Gantt chart inspired graphical viewpoint for supporting EA transformation documentation and a conceptual model explaining the information demands that need to be satisfied with the creation of road-map plans were introduced. Their approach allows the analysis and visualization of the business application’s life-cycle given an IT project. Nonetheless, there is no evidence of the viewpoint’s expressiveness in representing both the drivers motivating each transformation as well as the nature of each transformation.

Ross et al. emphasize on the transformation procedure also from a visual perspective [17, 18]. A high-level maturity model for EAs was proposed providing starting points for the design of the transformation process to enhance the used EA management process. However, neither an information model nor visualizations supporting the transformation process are discussed in their approach.

Roth and Matthes [19] proposed visualization is based on 4 layers. In the first layer, changes to the meta-model are shown in a graph where:

  • New class is shown in green;

  • Altered class is shown in orange;

  • Delete class shown in red;

The changes on names of class tint the differences on the name with green to the added parts, and red to the deleted parts. Changes in relations between classes are also shown and follow the same logic, green to new relations, red to deleted relations and changed ones with orange.

On the second layer an overview of objects (meta-model instances) following the previous logic is showed. New instances in green, changed ones in orange and deleted ones in red. Besides the visualization is possible to filter and zoom in/out to facilitate the visualization.

The third layer shows the instance neighborhood, i.e., the neighbors of a chosen object, but focusing on relations of Objects instead of on attributes, because the expert states that links (instances of relationships) between objects are far more interesting for an analysis than changes of attributes [19]. The color code is the same as on other layers.

On the fourth and last layer, the user can choose an object and view the different versions of that object, thus comparing the different versions with the original one.

4 Research Proposal

This section describes the proposed under development software tool. The following requirements were identified from a set of interviews with practitioners:

  1. 1.

    Necessity of saving the motivation of a change;

  2. 2.

    Migration of the models;

  3. 3.

    Describe the impact of changes;

  4. 4.

    Rollback of changes made to the meta-model;

By considering the requirements above together with existing literature, the tool aims at achieving three main objectives:

  1. 1.

    EA practitioner support on EA co-evolution by means of a simple and interactive EA meta-model editor and visualizer;

  2. 2.

    EA practitioner support on EA co-evolution by providing change impact analysis features of specific model changes;

  3. 3.

    EA practitioner support on EA co-evolution by automated model migration.

4.1 Architecture of the Tool

In accordance with the objectives stated above, the tool’s architecture must be grounded in a set of concepts and relationships that define the evolution aspects of an EA. Figure 2 illustrates the conceptual model describing the architecture of the proposed tool.

Fig. 2.
figure 2

Conceptual model of the tool

Full size image

The remainder of this section presents the different elements of the conceptual model. An IT Project acts as the enabler of EA evolution by applying a set of Transformations that transform the “AS-IS” state of an EA description into a “TO-BE” state. Each transformation can be decomposed into a set of Changes, each one altering the Life-Cycle of an EA Description Element (either concept, property or relationship).

Howbeit these concepts expressing the process of EA change, the motivation and interested parties in the evolution process must also be considered. Therefore, the concepts of Driver and Stakeholder are introduced. A Driver “represents an external or internal condition that motivates an organization to define its goals and implement the changes necessary to achieve them” [1]. One or more Stakeholders, defined as in ISO 42010:2011 [9], can have one or more drivers.

Also, the tool’s co-evolution process is based on the process defined by Gruschko et al. [8], although in this case, the authors consider only a baseline version of the meta-model since all changes made to the meta-model are traced. The tool will support the model migration rules proposed by Silva et al. [21].

4.2 Design of the Tool

Tool Workflow. The design of the tool is based on a 7-step workflow as Fig. 3 illustrates.

Fig. 3.
figure 3

Tool usage work-flow

Full size image

Create/Open Project of Edition. First, the user creates or opens a saved project for meta-model edition. Only inside the project scope is possible to edit the EA meta-model. This concept of project is mapped into the concept IT Project of the conceptual model of the tool.

Create Driver. In order to edit the meta-model, from both retrieved practitioners and researchers data, the reason behind a specific change must exist. To do this the concept of Driver has been created and associated with one or more changes made to the EA meta-model.

Edit Meta-model. Editing the meta-model is mostly applying a set of predefined transformations to the meta-model. The edition can be done in an interactive way where the user can interact with the graphical representation of the meta-model.

Associate Transformation to Driver. A transformation to driver association must also exist, explaining the motivation behind a meta-model change. The association could be made while adding a transformation to the meta-model or after the transformation has been added.

Analyse Impact of Transformation. In this step, the user is presented with analysis-specific features regarding the change impact of a meta-model change to the respective models. The analysis is based on indicators of incoherences and problems with relations between classes, supporting the user in the decision-making task of which evolution scenarios would be preferred. The analysis can be specific to a list of changes, transformations, drivers or projects.

Submit Changes for Approval. The co-evolution must be approved before updating the organization’s EA repository. Therefore, the tool also allows the user to submit the evolution scenario for approval.

Apply Changes to the EA Repository. After the changes have been approved they must be implemented, i.e., be applied to the current version of the EA repository. In this step, the user selects an approved project and applies the editions made to the EA repository. In this step the modifications are also associated with life-cycle dates, i.e., if the user removes a class, on February 23, 2017, and applies that change to the EA repository, the life-cycle state changes to Dead dating February 23, 2017. Is also at this step that the migration of the models is automatically done following the migration rules defined by Silva et al. [21].

Tool Structure. In order to support the process specified above, the tool’s (see Fig. 4) interface is structured in three items: a tree-like data container with the associated drivers and transformations, EA meta-model visualizer and the transformation window.

Fig. 4.
figure 4

Tool’s interface mock-up

Full size image

The user can see which drivers and transformations were applied to the meta-model and also analyze the change impact of applying the transformations (and changes) to both the meta-model and models. This feature allows the user to filter for transformations that he or she wishes to see. Also, the future state of the EA meta-model, i.e., the new meta-model version after applying the changes can be seen on the meta-model visualizer with colors representing what changes were applied to a specific meta-model concept or relation type following Roth and Matthes approach [19].

Besides the graphical representation of the meta-model, presented by the meta-model visualizer, one can choose how he or she wants to view the meta-model, i.e., view “AS-IS” and “TO-BE” side by side, or as an integrated view in which both the “AS-IS” and “TO-BE” are incorporated into a single view. Another view option is the Domain, an option that works as a filter in which the user can choose, from the existent EA meta-model domains, the type of architecture he wants to focus the visualization on, thus, allowing either a holistic or domain-specific view of the EA meta-model.

An AS-IS/TO-BE date options, as well as the AS-IS/TO-BE bar, work as a time navigation feature, allowing the user to navigate to a previous version of the EA meta-model and observe which changes were made between the two chosen dates.

The transformation screen allows the user to (1) fulfill the properties of a transformation, (2) apply the transformation to the EA meta-model, and (3) observe the change impact of such transformation on the models. To view the properties screen the user has two options:

  1. 1.

    An interactive view in which the user goes to the meta-model visualizer and right-clicks an element or architectural domain to identify the applicable transformations;

  2. 2.

    Via the Add transformation button option.

The first option allows the user to interact with the model and also filters all the possible transformations. The second one is more conventional, where the user has to fill in both the element and the transformation to be applied to that element. Both options navigate the user to the same screen where he or she has to fill some properties (for example, the association with a driver or creation of a new one at that moment, as well as seeing the change impact of that transformation).

Concerning the change impact analysis, it covers quantitative aspects as number/percentage of instances impacted, number/percentage of relations between classes lost in a depth chosen by the user.

5 Discussion

To better understand the tool’s usage, the following use case was considered. Company ABC is a large company that relies on proper and updated use of EA as means of supporting the alignment between its business operations and IT infrastructure. In last years ABC had its EA supported by ArchiMate 2.1 meta-model [1], but with the appearance of ArchiMate 3.0, ABC wants to migrate its EA, in order to have its model valid with the latest version of ArchiMate.

In order to make this update of the meta-model, ABC needs to know what makes an Archimate 2.1 model invalid in ArchiMate 3.0 [2] and know how to change the meta-model. By following the information provided by The Open Group [3], the next transformations are required:

  1. 1.

    Rename “used by” relationships to “serving”;

  2. 2.

    Change relationship of type assignment of an application component to a business process or function, this may be replaced by a realization relationship from the application component to the business process or function;

  3. 3.

    If there is an assignment of a location to another element, this may be replaced by an aggregation;

  4. 4.

    If other relationships between two elements in a model are no longer permitted according to with the new meta-model change the relationship with an association.

Taking the above into account and to ensure meta-model and model conformance, ABC needs to edit its meta-model and migrate the model. The interaction’s workflow would be the following:

  1. 1.

    Create a project of edition of the repository that ABC wants to change;

  2. 2.

    Create a driver, for example, “Migration to ArchiMate 3.0”;

  3. 3.

    Edit the meta-model doing the before mentioned transformations associating them with the driver created before;

  4. 4.

    After all transformations are done apply the changes to the repository.

Once the desired change is applied all models are migrated, making ABC’s EA model valid according to ArchiMate 3.0.

6 Conclusion and Future Work

In this paper, a tool for managing the co-evolution of the EA meta-model and models was presented. Change impact analysis of each evolution scenario is also an important feature of the tool in order to support decision-making when choosing the most appropriate scenario according to the organization’s goals. To fulfill its purpose the tool consists of two separate parts: one defining the co-evolution scenario and another for performing analysis over the created scenario. Both parts of the tool support the co-evolution process comprised of the creation and analysis of co-evolving both the EA meta-model and models as described in Sect. 4.

Being an ongoing research, a final and fully functional version of the tool is currently being developed. The authors consider as future effort the possibility of implementing an interactive help feature to offer the user proper guidance and more visual refinements regarding the change impact analysis, specifically in the changes to the existing EA repository data and views.