Analysis and implementation of the impact of change: application to heterogeneity algorithms in enterprise architecture

Received Jan 16, 2019 Revised Jul 31, 2019 Accepted Aug 29, 2019 Measurements play an important role in many scientific fields in general and in the analysis of enterprise architecture in particular. In software engineering, the measures are used to control the quality of the software product and better manage development projects to control the cost of production. In this article we proposed firstly models and measures to evaluate and analyze the complexity of the enterprise architecture and especially the heterogeneity of components and relationships, and secondely we developed a model to automatically detect the change of measures and their impact on enterprise architecture.


INTRODUCTION
Today, many organisations are concerned with how to successfully transition to organisations utilising information technology to its fullest strategic extent. It has become widely recognised that an organisation's enterprise architecture plays a key role in the transition and many organisations are now investing significant amounts of resources into developing or improving their enterprise architecture [1]. The enterprise architecture (EA) is the organizing logic for business processes and IT infrastructure, reflecting the integration and standardization requirements of the company's operation model, to analyze the result of enterprise architecture we present in this paper, a complete methodology for analyzing the heterogeneity of enterprise architecture. Our objective is to propose an evaluating methodology for guiding designers and architects in evaluating and improving the EA models. Furthermore, our enterprise architecture patterns system will be used for an automated support to manage the evaluation of enterprise architecture complexity The goal of this paper is to (1) present the enterprise architecture component regarding agility and complexity measurement, (2) identify and apply the heterogeneity metrics to enterprise architecture components and relationships (4) Detect changes in an enterprise architecture and update relevant metrics. The paper is structured as follows: the second et alion describes the state of the art of our research, the third et alion presents our proposed approach and presents some of our results, the fourth et alion presents the pototype of our contribution and finally, the last et alion is dedicated to conclude our paper.

OUR PROPOSAL PATTERNS FOR MODELLING
This et alion presents the information patterns for the analysis of the enterprise architecture. We define firstly the patterns to analyze and implementing enterprise architecture heterogeneity algorithms and secondly we detail our approach to modelize the impact of the changing algorithms.

Definition and conceptual foundation
Heterogeneity is defined as the diversity of elements or relationships of a system according to its characteristics [20]. More precisely, in computer science, the heterogeneity of a computer landscape is a statistical property that presents the diversity of the types of elements that compose it [17,21] taking as an example the heterogeneity of database management systems (DBMS). This heterogeneity can be understood as a frequency distribution [22,23] and can be expressed in graphical form as shown in the Figure 1. In the literature the most widely used method for measuring heterogeneity is the use of concentration measurements, which is entropy measure ∑ ( ) [23,24].

Analyzing enterprise architecture heterogeneity
Based on the information pattern I-50 presented on the paper [25] we present three types of concepts in which we apply the measure of entropy. Concept 1 represents only the heterogeneity of a single component of the enterprise architecture, concept 2 represents the relationship between two components and calculates heterogeneity with respect the relation and the concept 3 is an exceptional case from concept 2 it presents a relationship path that connects several components. These concepts are summarized in the Table 1. The I-pattern I-52 presents the measurements detailed in the Table 1. The measurements are illustrated and numbered from 1 to 8 in the diagram ( Figure 2).

Implementation of analysis algorithms
To propose an evolutionary implementation we must consider several constraints: 1-these algorithms can evolve over time, 2-we can have several versions of the same algorithm during the life cycle of our system and each version can represent an adaptation or an optimization of the old version, 3-we also want to isolate the algorithms compared to others to facilitate their use their implementation and maintenance. These cited constraints were managed and resolved by the "Strategy" design pattern; for that we will adapt the design pattern "Strategy" and apply it to our context. The Figure 3 shows the application of the design pattern to our context. We create a -StrategyInterface'' interface, we add an -applyAlgorithm‖ method that will be the method that applies our strategy or in other words that implements our algorithm. Concrete classes created implement this interface to encapsulate the algorithms and to redefine the -applyAlgorithm‖ method for implementing the algorithm of each class. In our contribution we proposed an algorithm hierarchy using the notion of "Abstract Class", we represent two large families of algorithms; the heterogeneity algorithms "AlgorithmeHeterogeneite" divided into two subtypes; type 1 algorithms and type 2 algorithms The Figure 4 shows an example of implementation and use of the database concentration algorithm.

Analysis the impact of change
Among the dimensions of complexity presented in the et alion 1, we have specified the impact of change as an important dimension to consider; in this et alion we will propose an implementation to resolve this need. The impact of managed change in our contribution is to automatically update the new measures and to progressively follow the changes of our proposed system proposed in the I-Pattern I-52 "Heterogeneity of Enterprise Architecture". In this et alion we will propose an implementation that detects the change of the considered components and reflects this change at the level of the measurement algorithms. To handle these constraints we propose to use the observer design patten. This pattern presents a solution to send a notification to modules that play the role of observers. In the event of notification, the observers take the appropriate action according to the information that arrives from the modules they observe (the "observables").
The diagram of the Observer pattern illustrated in the Figure 5 presents the proposed solution, it defines two interfaces and two classes: The Observer interface will be implemented by any class that wants to be an observer. This is the case of the ObservatorConcret class which implements the Observable method, this method will be called during a state change of the observed class. There is also an Observable interface that will be implemented by the classes that we want to observe. The ObservableConcret class implements this interface, which allows it to keep observers and informed by notifying them. Each ObservableConcret class has an attribute (or several) that we want to observe and a list of observers. The state is an attribute whose observers wish to follow the evolution of its values. The list of observers is the list of observers who are listening. The ObservableConcret class in our context is the EAModel class, it represents our ArchiMate models. This class will contain two elements: components and relationships. The EAModel class has the states that we want to observe, which are all the nodes and relationships of the enterprise architecture landscape.
The EAModel class also contains all observers who will receive notifications on each change. The ObserversConcret who are listening are the implementation classes of the analysis algorithms. If a component or relationship is added, deleted, or modified, the observers concerned with this model update are refreshed automatically. In our model the concrete observers are the algorithms of heterogeneity as shown in Figure 6.

PROTOTYPE
The application architecture is divided into three layers: an information management or backup layer that stores data from a model or from existing source files in a data warehouse, a reporting layer that presents the results as shwon in Figure 7. Heterogeneity measures in graphical form and an interaction layer that offers the possibility of modeling the desired points of view. The interaction layer represents the applications that will allow decision makers to model the views of the enterprise architecture and enrich it with existing data. The modeling editor is as shown in Figure 8. The illustrated tool represents the first step which is the modeling of the enterprise architecture by graphically describing the elements and existing relations, it is an ArchiMate point of view modeled by the Archi interface. It consists of an element set of each layer. The description of the AE is stored in two Commaseparated values CSV files. To manage this metadata, we have developed a desktop application java, illustrated in the Figure 9, which allows us to manage this metadata, to apply the heterogeneity measurement algorithms and to visualize the output graphs. To manage this metadata, we have developed a java desktop application, illustrated in Figure 10, that allows us to load relationships and components from csv files, view them and make changes if necessary. Figure 11 show the report generated for the distribution of databases instances. Figure 10. The interface to generate the heterogeneity graphs Figure 11. The report generated for the distribution of databases instances

CONCLUSION
Enterprise Architecture (AE) is a cross-cutting discipline that deals with the process, models, tools for describing organizations and building their IS. It also helps to plan the possible changes at the organizational level and the architecture level. As a result, different approaches have been employed to ascertain the challenges, yet they persist. Thus, the objective of this paper is to propose an evaluating methodology for guiding designers and architects in evaluating and improving the EA models and especially the impact of the change of the different components at the level of the complexity measures.