Keywords

1 Introduction

Analysis is an important part of the Enterprise Architecture Management (EAM) Process. Many analysis approaches have been proposed by researchers and current Enterprise Architecture Management tools implement analysis functionalities.

In practice, Enterprise Architectures (EA) are often analysed by using visualizations and are typically created using EAM tools. However, several studies show a lack in EAM tools’ visualization capabilities [20, 24, 31]. Visualizations generated by EAM tools are often report-like and static in respect to the displayed information. Modern analysis approaches like [21, 24, 25] should combine interactive visualizations with automated analysis techniques. In this regard enterprise architect’s responsibilities are changing [30]. By using automated analysis techniques, enterprise architects can focus on more advanced analyses for which no algorithm exists. We investigate related work of classifying EA analysis approaches. Based on the results, we propose a classification framework. Therefore, the remainder of this paper is organized as follows. Section 2 discusses existing approaches to EAA classification and derives a common classification framework based on these approaches and a discussion of general attributes that are important for analysis methods and tools independently of the EAA domain. Section 3 classifies EAA tools and methods that have been described in literature based on the developed EAA classification framework. The last Sect. 4 then summarizes the findings and draws an outlook on further investigations of the topic.

2 EAA Classification Framework

In this section we develop a framework for enterprise analysis classification. It is based on previous work by Buckl et al. [7], Hanschke [14, 15], Niemann [28], and Lankhorst et al. [23] in connection with Ramos et al. [29, 30, 33, 34] which is presented in Sect. 2.1 “Related Work”. These major approaches on the field are used to derive dimensions (D) for classification, labelled with roman numbers I to VIII. Additional sources are included were appropriate in order to emphasize on possible additions and alternatives for classification. Section 2.2 then describes the developed classification framework which tries to provide a common view on the topic.

2.1 Related Work

Buckl et al. define in [7] a classification schema that uses five dimensions: (I) Body of Analysis (II) Time Reference (III) Analysis Technique (IV) Analysis Concern and (V) Self-Referentiality.

Regarding (I) Body of analysis: Buckl et al. make a distinction between (1) structure, (2) behaviour statistics and (3) dynamic behaviour. While structure analysis assesses the architecture as it is defined, behaviour statistics include operational data like server availability and dynamic behaviour considers the consequences of changes in the system status on instance level. (II) Time Reference: Differentiates between the analysis of current (ex-post) and planned (ex-ante) architectures. (III) Analysis Technique: (1) Expert-based means that the analysis is performed manually by experts that may provide concrete action plans or just general strategy recommendations. (2) Rule-based analysis defines constraints to the enterprise architecture that must be fulfilled in the form of rules. (3) Indicator-based analysis describes also automated analysis techniques with results of quantitative nature. (IV) Analysis Concerns differentiates between (1) functional and (2) non-functional approaches. Functional approaches check the function of the EA. Non-functional approaches in contrast consider quantitative measures regarding system performance. There is a correlation for analysis approaches between being non-functional and being indicator-based. (V) Self-referentiality: aims at the identification of approaches that analyze the Enterprise Architecture Management itself. While EA analysis does not consider EAM parts of the EA in special (self-referentiality: none) also EAM processes might be analysed (self-referentiality: single level). If additional cross-layer aspects of EAM are considered, Buckl et al. speak of multi-level Self-referentiality.

Hanschke provides an operationalization of EA analysis and planning via so-called “patterns” and defines two dimensions for the classification of analysis approaches [14]: (VI) Analysis function and (VII) Architecture Sub-model. Thus, a particular analysis goal can be intended for a particular layer of the EA. Hanschke identifies Business, Information Systems, Technical, and Infrastructure Layer. Regarding the analysis functions, the following distinctions are made: (1) Discovery of potential redundancies (2) Discovery of potential inconsistencies (3) Needs for organizational changes (4) Implementation of business goals (5) Optimization and required changes on technical and infrastructure layer.

Niemann [28] classifies by analysis function (VI) only and does not consider Architecture Sub-models. He names the following analysis functions: (1) Dependencies (2) Redundancies (3) Interfaces (4) Heterogeneity (5) Complexity (6) Compliance (7) Costs and (8) Benefits. This distinction has also for example been used by [3]. The problem of this classification is the mixture of rather general functionality like assessment of complexity and costs and rather concrete one like the assessment of application interfaces.

Lankhorst et al. [23] use two dimensions in order to classify enterprise architecture analysis approaches. In the first dimension they make a distinction between functional and quantitative approaches. This is similar to the dimension (IV) Analysis Concerns by Buckl et al. [7], considering non-functional approaches as quantitative. The second dimension by Lankhorst et al. differentiates between analytical and simulation approaches. These match dimension (III) Analysis Technique by Buckl et al. However, different classes are defined.

Ramos et al. [29, 30, 33, 34] made additions to the classification approach by Lankhorst et al. in order to provide a more detailed classification schema. They assign analysis functions to either quantitative or functional analysis. Thus dimension (IV) Analysis Concern is connected with dimension (VI) Analysis Function. The values are for quantitative approaches: (1) Performance (2) Optimization (3) Cost (4) Availability (5) Capacity Planning (6) Quality Trade-off. Functional analysis functions are: (1) Alignment (2) Coherence (3) Correctness (4) Gap analysis (5) Counting/Complexity (6) Process (7) Human Resources (8) Conformance (9) Graph Structure (10) Impact of Change. Ramos et al. [29, 30] also divide analysis approaches by dimension (VII) Architecture Sub-model. In contrast to Hanschke they base their layering in the ArchiMate standard. An additional dimension for the classification of EAA approaches is provided by Ramos et al. with (VIII) the Status (used in their EAA functions repository [33]). Here the status of implementation is considered. Thus, whether an analysis approach is (1) described in general (2) fully specified or (3) implemented.

Naranjo et al. [26] made a survey regarding enterprise analysis techniques (dimension (III)). The result was a collection of analysis techniques which are more concrete regarding implementation than those provided by Buckl et al. and analysis functions (dimension (VI)) that are implemented by these techniques. In the context of the paper by Naranjo et al. what we consider analysis functions is called analysis concern.

2.2 Framework Construction

Based on the discussion in the previous section, the dimensions for the classification of EAA approaches are derived which and shown in Table 1. The proposed dimensions are assigned to four main EAA questions to be answered.

Table 1. Enterprise architecture classification framework
Full size table

Most of the dimensions considered so far are dealing with (question-A). (D-I) basically deals with the origin of data used for analysis. Thus, is only the enterprise architecture model considered (structure) or also the operational data (behaviour)? We do not make the distinction between behaviour statistics and dynamic behaviour as in the original source by Buckl et al. Even there, only one approach has been identified that specifically considers dynamic behaviour. We also decided to omit (D-II) Time Reference [7], because in general all analysis approaches can be applied to current and planned enterprise architecture models as well. The distinction between functional and quantitative approaches (D-IV) is used by several authors and thus also adopted for our classification framework. (D-V) Self-referentiality is not considered because it is only proposed by Buckl et al. They provide only one example for an analysis approach that is explicitly designed to be applied to the EA-function within an enterprise. Furthermore, EA specific analysis can be considered as an analysis function that is specific to a certain architecture sub-model (D-VII). Regarding (D-VII) Architecture Sub-model we suggest to use the ArchiMate modelling standard – its layers and extensions – as a framework to identify sub-models because of the general acceptance of ArchiMate [3]. Moreover, there is a lot of flexibility in the ArchiMate standard to address very specific EA sub-models. Additionally, there is a class “General” for EAA techniques that are described on an abstraction level that allows their application to all possible EA sub-models.

Although (question-B) is only connected to (D-III) Analysis Technique, there are different approaches at different abstraction levels to this topic. On the most general level we distinguish expert-based (manual) approaches (cf. Buckl et al.), automated approaches, and integrated approaches. Since, EAA is part of a decision making process, experts’ decision and interpretation comes into place at a certain point and expert analysis of EA models must be supported by tools in order to handle the model complexity [21]. However, we consider a method only as integrated when the interplay between expert and automated analysis is explicitly described. We introduce a new (D-IX) Coverage to depict this. Regarding automated analysis there is a broad variety of available analysis techniques. Describing them on the level of being rule-based/indicator based [7] or analytical/simulation based [23] is too coarse. As shown for example by [25] there are families of techniques that can be used to implement a variety of analysis functions (e.g. Quantitative Performance Analysis, Probabilistic Relational Models, Rule Validation). Furthermore, techniques for expert based analysis may be described. Typically, expert-based analysis techniques are used to analyse complex or new situations for that no rules or algorithms exists. Another reason why expert-based analyses are used is a lack in the underlying EA model. In this case, relevant characteristics are missing in the model and therefore only exist in human brains. Jugel et al. describe in [19] interactive functions of a cockpit. The interactive function “graphical highlighting and filtering” is an example of an expert-based analysis. Using this interactive functions, e.g. stakeholders are able to enrich elements of the EA model by using annotations. In addition, annotations can be used as criteria to highlight elements of the architecture. Thus, we populated this dimension with values from Naranjo et al. and our literature review that is described in the next section.

Also regarding (question-C), different sets have been proposed for possible answers (D-VI) by the respective authors. The most comprehensive set based on the number functions of has been defined by Ramos et al. [33, 34]. Still, there are EAA functions that are not covered by this set and the field is developing. Thus, values should be based on an analysis of EAA approaches in the field. Furthermore, some approaches describe general techniques that are not bound to a certain analysis function. Thus, we introduce a class “General” here. From the general analysis perspective we add (D-X), analysis type based on the analysis taxonomy provided by Delen et al. [11]. Analysis can be either descriptive, predictive, or prescriptive. While the last type - prescriptive analysis - covers the complete decision making process. There are clear criteria necessary in order to make a distinction between descriptive and predictive analysis. Generally, an analysis based on models that describe the current state is descriptive and an analysis that bases on models that describe a future state is predictive. Thus, each technique that analyzes a model is descriptive and predictive as well. We attribute “predictiveness” to all EAA approaches that do not rely on current operational data and that are able to describe future EA states.

(Question-D) aims at the validation EAA approaches. While Ramos et al. [33, 34] only consider the status of implementation in their EAA framework, a broader view is necessary. Thus we differentiate between (1) proposed (2) prototype and (3) case study here.

3 Assessment of EAA Approaches from Literature

While there are many applications for the developed EAA classification framework like providing a catalogue of EAA approaches or assessing the descriptions of EAA approaches, in a first step we investigate, how the classes defined by the framework are filled by current EAA approaches from literature. This is on the same hand a first validation of the framework by validating its applicability and coverage. We performed a Systematic Literature Review (SLR) according to Kitchenham [17, 22]. The literature review process generally consists of 4 steps. The first three steps are described in Sect. 3.1. Table 2 describes the result of data analysis which includes the application of our EAA classification framework.

3.1 Paper Selection and Data Extraction

The goal of the literature search was to systematically identify EAA approaches that are present in scientific publications while being replicable and thorough. Finally, 16 relevant publications have been identified (AIS Electronic Library: 3, IEEE Xplore: 6, Science Direct: 1, Springer Link: 6) listed in the reference section [1, 2, 4–6, 8–10, 12, 13, 16, 18, 25, 27, 31, 35].

We conducted the data extraction with a focus on EAA techniques. Thus, first we clustered the approaches by used techniques/technologies and then we made a classification according to our framework. For reasons of brevity not all dimensions are covered. Most Publications (5) used Probabilistic Relational Models (PRM) for EAA. Based on literature, their main area of application is the predictive, quantitative analysis of technical and of application components. The mentioned analysis functions were Availability, Maintainability, and Security or in general system performance. The second cluster of approaches uses semantic technologies. Out of the 5 publications [1, 2, 4–6], three refer to the same approach [1, 2, 4]. Generally, semantic technologies are fit for structural, functional analysis. An advantage is the good integration of different domains. Thus, the technology is applicable to generally all possible architecture sub-models/sub-domains. A common analysis function of all described semantic approaches is Impact Analysis. Graph-based approaches have been presented by two authors [5, 25]. These approaches assess graph characteristics of the EA-model in order to analyze the EA. The remaining three EAA techniques have been presented by just one paper each. The paper regarding AHP [31] on its very general level also considers the use of operational data (Body of Analysis – Behaviour) and is the only approach performing a prescriptive analysis. The Wiki-based approach [9] remains on a very general level. The Extended Influence Diagram (EID) approach [18, 27] is very close to PRM in its classification.

Table 2. Class instances based on the performed SLR (number of instances in braces ())
Full size table

Looking at the framework dimensions and the classes defined in this dimensions regarding their coverage (Table 2), it reveals that there are approaches missing that consider operational data (Body of Analysis – Behaviour), that describe solely interaction of experts (Coverage – Expert-based), and that provide prescriptive analysis. On the other hand, most of the approaches have been validated in form of a prototype or a case study.

4 Summary and Outlook

The developed framework for EAA classification uses established dimensions for classification by deriving a common view based on existing EAA classification approaches from literature. This comes with omitting dimensions that did not seem to have established and with suggestion of new ones. Within the dimensions, a possible class structure has been presented. Section 3 proved the general applicability of the framework based on a SLR. It also showed its usefulness for the assessment of EAA techniques. Furthermore, possible directions for future research can be derived, which is one of the goals of an SLR and in this case supported by the framework (see Table 2). For example, prescriptive analysis approaches are underrepresented, as well as approaches explicitly including operational data and methodological support for experts performing EAA.

However, more insight should be provided by extending the number of assessed EAA approaches. The SLR base may be extended. Furthermore, the authors of EAA classification approaches provide examples themselves, that be applied to our framework. Ramos et al. present a variety of EAA techniques on their project site (see [33, 34]). Even more insight can be gained from the assessment of EAA in practice: Which of the techniques are actually used in enterprises? How is EAA done in practice? Results may be an assessment of the practical relevance of certain EAA classes but also additional dimensions for classification. Possible points for an extension of the framework may be the analysis effort that is of course relevant for practice and a deeper investigation of the role of EAA in the EAM process.

In addition to the assessment of EAA techniques and the identification of research gaps, the framework may also be used to improve the description of EAA approaches by providing a template and also to create an EAA catalogue that allows the selection of appropriate EAA approaches depending on the situation at hand.