Automating the Migration of Enterprise Architecture Models

Introduction

In Enterprise Architecture management (EAM), EA models are structured, object-oriented models conforming to an organization-specific meta-model that evolves over time. The data regarding these object-oriented models is stored in EA repositories used by EA software tools to aid in the EAM tasks.

EA meta-models specify the information about EA concepts, i.e., the elements and relationships, which will be used to represent and/or model the organization (Sabine Buckl & Ernst, 2007).

EA development projects start with the definition of a set of concepts that will be used to represent and/or model the organization. These concepts, such as the ones presented in EA frameworks as TOGAF® (The Open Group, 2009) or notations like ArchiMate® (The Open Group, 2013), are used or proposed, as in domain-specific languages (Ulrich Frank et al., 2009).

Since EA projects are very ambitious, the idea of starting with a simplified meta-model and enriching it while growing within the organization is appealing. However, addressing these projects implies that EA meta-models are supported as living artifacts that evolve according to the organization’s needs (Tribolet, Sousa, & Caetano, 2014). Furthermore, each EA project, being an EAM process, is supported by three central tasks: documenting the current state of the organization’s architecture, envisioning the future perspective of the architecture, and planning different intermediate architecture scenarios deciding on an architecture roadmap (Sabine Buckl, Ernst, Matthes, & Schweda, 2009). From these tasks, one derives the transformation from the AS-IS EA state to the envisioned TO-BE state.

This transformation occurs in cycles, over and over again. Usually, the meta-models and concepts used to model the first AS-IS are no longer enough to model the current AS-IS or even the current TO-BE. For example, an organization wants to reformulate its business model by changing, deleting and creating new business concepts. The current information systems architecture that supports the AS-IS and, supposedly, the TO-BE business cannot be adapted in any way. Thus, the organization’s EA needs to be drastically re-designed not only business-wise but also in terms of the information systems that will support the TO-BE business. Migrating all these changes can lead to many issues.

All the issues that result from performing this challenging task have to do with uncoordinated, ad hoc decisions concerning EA components and their interrelationships resulting in the duplication of efforts and resources, poor coordination and control, management and business performance issues, and inefficiencies in operation (Kaisler, Armour, & Valivullah, 2005). Therefore, co-evolving the EA meta-model and its models by stepwise adaptation, i.e., evolving the meta-model together with (the migration of) its instance models, can lead to an error-prone task as well as become time-consuming (due to duplication and poor coordination of manual effort).

Consequently, the EA model migration poses resistance to the incremental approach of EA practice within organizations. As a result, the research problem can be identified as follows: The process of migrating EA models using stepwise EA meta-model evolution is error-prone and time-consuming.

With regard to the above-mentioned research problem, based on a Design Science Research Methodology (DSRM) iteration (Hevner, March, Park, & Ram, 2004) the authors proposed a set of nine migration rules specifications as an innovative, purposeful IS artifact that were then implemented in a commercial EA tool for automating the migration task of EA models when stepwise EA meta-model evolution takes place. Each migration rule specification is an adaptation of Wachsmuth’s research (Wachsmuth, 2007) in which he deduced a set of automatic co-evolution steps from well-defined evolution steps when evolving MOF¹ compliant meta-models.