Generic EA Analysis Framework for the Deﬁnition and Automatic

Execution of Analyses

Melanie Langermeier and Bernhard Bauer

Software Methodologies for Distributed Systems, University of Augsburg, Universit

atstrasse 6a, 86135 Augsburg, Germany

Keywords:

Analysis, Enterprise Architecture, Enterprise Architecture Analyses, Domain Speciﬁc Language.

Abstract:

Analysis is an essential part in the Enterprise Architecture Management lifecycle. An in-depth consideration of

the architecture obtains its strengths and weaknesses. This provides a sound foundation for the future evolution

of the architecture as well as for decision-making regarding new projects. Current literature provides a large

number of different analysis approaches, targeting different goals and utilizing different techniques. To provide

a common interface to analysis activities we studied the corresponding literature in previous research. Based

on these results we develop a language for the deﬁnition of EA analyses as well as an execution environment

for their evaluation. To cope with the high variety of meta models in the EA domain, the framework provides

a uniform and tool independent access to analysis activities. Additionally it can be used to provide an EA

analysis library, where the architect is able to select predeﬁned analyses according to his speciﬁc requirements.

1 INTRODUCTION

Today’s IT landscapes in organization are typically

the product of evolved structures extended with ad-

ditional parts through merger and acquisitions. Since

IT was not always seen as critical factor their manage-

ment and alignment was partially unattended. This

faces organization with the problem of a high com-

plexity and heterogeneity when regarding their IT

support. Enterprise Architecture Management (EAM)

provides means for organization to capture the essen-

tial business and IT elements as well as the dependen-

cies between them. This provides a clear understand-

ing of the structure and enables an organization-wide

optimization of the architecture (Lankhorst, 2013).

Therefore Enterprise Architecture (EA) models

are used within a plethora of different application

scenarios. Among those are IT business alignment,

project portfolio planning, business process optimiza-

tion, sourcing decision and IT service management.

To utilize the EA models in these contexts the con-

tained data has to be analyzed, summarized and in-

terpreted with suitable analysis techniques (Bucher

et al., 2006). For example during project portfo-

lio planning, analyses support the decision about ap-

proval or rejection of a project proposal. They are

used to calculate effects and evaluate the quality of the

future architecture. Another application scenario for

analysis techniques is the provisioning of a dashboard

with performance indicators to support management

decisions (Frank et al., 2009).

Summarized, EA analyses are means to utilize the

established EA models. They increase the under-

standing of the architecture and provide aggregated

information to the management, e.g. through a dash-

board. Through an evaluation of the current and tar-

get architecture as well as potential change scenarios,

they support decision-making and architecture evolu-

tion (Sasa and Krisper, 2011).

To cover the various application ﬁelds a plethora

of different EA analysis approaches can be found in

literature. The approaches fulﬁll various different

goals and use a wide selection of techniques to reach

them (Rauscher et al., 2017). Each approach typically

serves a speciﬁc use case and incorporates a speciﬁc

implementation. Their adaption to other use cases or

their use within different EA models is a complex task

and made reuse difﬁcult. To take advantage of the ex-

isting EA analysis approaches a uniﬁed approach to

EA analysis is important (Naranjo et al., 2014; Buckl

et al., 2009; Johnson et al., 2007). Such an approach

could also ease the development of a common analy-

sis catalog as proposed by (Lantow et al., 2016).

The broad application ﬁeld of EA analyses as well

as the speciﬁcs of EA models lead to several chal-

lenges. First, EA models are large and complex mod-

els that are created by using different, often discon-

nected modeling languages (Naranjo et al., 2015).

316

Langermeier, M. and Bauer, B.

Generic EA Analysis Framework for the Deﬁnition and Automatic Execution of Analyses.

DOI: 10.5220/0006379003160327

In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 3, pages 316-327

ISBN: 978-989-758-249-3

There exist several frameworks each providing a meta

model proposal but no common standard for EA mod-

els. Typically the organization chooses a speciﬁc

framework and additionally makes further adaptions.

Second, the EA models of an organization are often

not fully speciﬁed, i.e. an analysis technique has to

deal with incomplete models.

In previous research we analyzed current EA liter-

ature and identiﬁed different analysis types and cate-

gories (functional and technical) with their character-

istics (Rauscher et al., 2017). Additional in (Langer-

meier et al., 2014b) we presented an approach for the

execution of EA analyses based on a generic EA meta

model. In the following we combine both results to

deﬁne a framework for the generic EA analysis deﬁ-

nition and execution. Therefore we developed an EA

analysis deﬁnition language (Arla) that allows the ar-

chitect to deﬁne and customize analyses like perfor-

mance indicators or views, while abstracting from the

technical details. For evaluation the Arla analysis def-

inition is interpreted as executable rules. In order to

support a broad spectrum of EA analysis we use a

combination of SPARQL, a query language for triple

stores, and a data-ﬂow based approach for their exe-

cution.

In the next section we present the foundations

about EA analysis as well as the results of our pre-

vious work. In section 3 the developed language is

presented followed by the execution mechanism in

section 4. The evaluation is presented in section 5.

Therefore we determined the coverage degree of Arla

by analyzing the EA literature with respect to their

feasibility in Arla. Additionally examples of Arla def-

initions are presented in section 3, which were exe-

cuted on different EA models for evaluation purposes.

2 EA ANALYSIS

Enterprise architecture models support the architec-

ture process only in a visual and qualitative way

(Franke et al., 2009). Analysis techniques provide

means to quantify models, predict future behavior and

compare different alternatives. They make use of the

contained information in order to support the plan-

ning process. The EA cycle encompasses the phases

document, analyze, plan, act and control (Niemann,

2006). Thus they are an essential part in the overall

EAM process. Examples for analysis procedures are

coverage analysis, analysis of the interfaces, hetero-

geneity analysis, analysis of complexity, conformity,

costs and beneﬁts (Niemann, 2006). To receive more

expressive analyses the combination of several tech-

niques and analysis methods is proposed (Naranjo

et al., 2015).

The analysis activities during EAM are unforesee-

able, since they are not known in detail at the be-

ginning (Naranjo et al., 2015). Changing business

or IT requirements as well as strategic changes trig-

ger changes in the analysis necessities. For example

a new strategy will lead to new goals for business

and IT. Goals are often monitored using KPIs, thus,

changing the goals requires an adaption of the KPIs.

Additionally generated analysis results provide new

information, which inﬂuences the future proceeding.

For example if a severe impact is calculated for a tech-

nology change, the architect wants to analyze the im-

pact in detail.

Jonkers and Iacob propose a differentiation be-

tween design and analysis (Jonkers and Iacob, 2009).

The design space of EA is modeled using languages

like UML, business process modeling language like

BPMN or architectural description languages like

ArchiMate. For the analysis space they propose a

special-purpose language that enables the later anal-

ysis. Our approach focuses on the analysis space. We

deal with the analysis of the model data of an enter-

prise architecture, i.e. how can the data be analyzed

and how can the analysis procedure be deﬁned and

executed. This includes the decomposition in smaller

model parts and the evaluation of those. The result of

an evaluation is either a model part, the reduction of

the architecture or an architecture part to an attribute

or quantitative value or the extensions of an architec-

ture or architecture part with calculated attributes or

quantitative values. The visualization of the result is

basically covered in our approach in order to make

the results veriﬁable. Further research discusses the

topic of visualization and visual analysis in detail e.g.

(Naranjo et al., 2015)

In previous work we analyzed the current lit-

erature about enterprise architecture analysis. In

(Rauscher, 2013) we identiﬁed 105 analysis ap-

proaches, which are roughly grouped in 40 anal-

ysis types. The groups are created based on the

scope of the respective analyses. The goals and re-

alization methods summarized in one type can dif-

fer. Examples of analysis types are ‘Analysis of Ser-

vice Response Time’ (e.g. (N

arman et al., 2014)),

‘Change Impact Analysis’ (e.g. (Sunkle et al.,

2013)) and ‘Performance and Workload Analysis’

(e.g.(Lankhorst, 2013)). Based on this work we pro-

pose a two-dimensional categorization of EA analy-

ses in (Rauscher et al., 2017) in order to derive typ-

ical characteristics of EA analyses and requirements

for their execution. Each analysis approach was as-

signed to one technical category and at least one func-

tional category. A technical category summarizes ap-

Generic EA Analysis Framework for the Deﬁnition and Automatic Execution of Analyses

317

proaches utilizing a similar method with similar steps

regardless of the addressed goal and subject. In con-

trast a functional category summarizes approaches ad-

dressing the same objectives and goals. Since an ap-

proach can fulﬁll different goals, there are several ap-

proaches with more than one functional category. For

example the cost analysis of (Niemann, 2006) is as-

signed to the technical category KPI and the func-

tional category Financial. Whereas the quality analy-

sis of (N

arman et al., 2008) is assigned to the techni-

cal category Bayesian Networks and to the functional

categories System, Attribute, Quality and Data.

We identiﬁed 10 functional categories: System,

Attribute, Dependencies, Quality, Design, Effects,

Requirements, Financial, Data and Business Objects.

The technical dimension concluded with 17 cate-

gories: Bayesian Networks, Business Entities, Proba-

bilistic Relational Models, Social Network, Analytic

Hierarchy Process, Time Evaluation, Tree, KPI, Com-

parison, Views, Lifecycle, Ontology, Extended Inﬂu-

ence Diagrams, Weak Points, Matrices, Design and

Structural. The assignment of the analyses to the cat-

egories is described in detail in (Rauscher et al., 2017)

and (Rauscher, 2015). About 30% of the analysis ap-

proaches are assigned to a technical category describ-

ing probabilistic approaches. Further important tech-

niques are the calculation of measures and KPIs to

address the architecture quality and attributes as well

as the deﬁnition of views on the architecture. Addi-

tionally the functional category Dependencies is often

used. The technical realization for analyses address-

ing dependencies varies widely.

Current approaches that try to cover different anal-

ysis types are rare. The majority of the approaches

are isolated ones that cannot be related to each other.

A uniform interface to the different EA analyses is

missing. Further challenges that are given only little

attention are recursive analysis deﬁnitions. Cyclic de-

pendencies in the models as well as incomplete mod-

els are sparsely considered. Only a few approaches

(e.g. (Kurpjuweit and Aier, 2009)) deal with the in-

direct relationships in EA models. (Sunkle et al.,

2013) addresses EA analysis using ontologies. A

lot of approaches utilize probabilistic techniques (e.g.

arman et al., 2008; Franke et al., 2009)). But

none of these approaches is able to cover the vari-

ous different goals that are addressed by EA analyses.

(Naranjo et al., 2014) propose the PRIMROSe frame-

work for visual analysis of EA models. This is a graph

based, modular approach to compose predeﬁned anal-

ysis function and create sound visualizations by utiliz-

ing selectors and decorators. The architect can deﬁne

the analysis chains, although the scope of the analysis

functions is restricted to those that are prespeciﬁed.

Customization is possible through the deﬁning of a

composition chain.

Current EA modeling tools provide extensive

analysis support. Limitations are caused by to the

modeling approach, the supported meta models and

the technical analysis capabilities (Naranjo et al.,

2015). Such capabilities can for example only in-

clude conformity checks or the generation of prede-

ﬁned views. Some EA tools provide also a possibility

to query the model either by providing a DSL or by

integrating for example a SQL interface. EA tools

provide currently two major approaches to enterprise

architecture analysis: Either they are shipped with

a predeﬁned and static meta model (e.g. iteraplan,

leanIX). Upon their meta model these tools typically

provide several analysis techniques out of the box. In

the other case the meta model of the tool can be cus-

tomized to the organization needs (e.g. planningIT).

In this case the analysis functions of a tool typically

have also be adapted, which is associated with a high

effort.

3 ARCHITECTURE ANALYSIS

LANGUAGE

The Architecture Analysis Language (Arla) provides

a universal interface for the deﬁnition and execution

of analyses. Thereby Arla abstracts from technical

details. The architect deﬁnes only ”what” he is in-

terested in, how this information is retrieved is gen-

erated from the Arla analysis deﬁnition. This execu-

tion process is described in section 4. The language

supports the speciﬁcation of analyses for a concrete

EA model, but also the deﬁnition of templates us-

ing placeholder variables for EA stereotypes. In order

to apply a template on a concrete EA model, the de-

clared variables have to be mapped to existing stereo-

types. A re-deﬁnition of the analysis is not necessary.

Another concept to ease the re-use of analyses

and support template deﬁnition is node and edge

classes. Those classes are used to abstract from EA

speciﬁc stereotypes during analysis deﬁnition. Based

on a review of EA frameworks we classiﬁed relation-

ship types according to their semantics. We identi-

ﬁed ﬁve classes of relationship types: Provide, Con-

sumedBy, LocalizedAt, StructuralDependentOf and

BehavioralDependentOf. These edge classes are suc-

cessfully used in previous work for change impact

analysis (Langermeier et al., 2014a) in order to ab-

stract form the concrete EA meta model. Additionally

we adapted this concept to the element types. Thereby

we identiﬁed three types, that are used in all com-

mon EA meta models: Process, Application and In-

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

318

frastructureElement. The mapping between the EA

speciﬁc stereotypes and the respective classes has to

be deﬁned once. The concluding type declarations are

generated automatically during model import while

the original stereotype name is also kept. For example

the relationship types realizes and access from Archi-

Mate can be mapped to the edge class provide. In

DoDaF the relationship types provide and performs

can be mapped to this class. If the classes are insuf-

ﬁcient for an analysis deﬁnition, it is always possible

to use also stereotypes expressions.

3.1 Analysis Deﬁnition

An analysis or template deﬁnition is composed of a

general part and an analysis speciﬁc part. The general

part comprises attributes like the name, the analysis

type, the result type and a description. The analysis

speciﬁc part enables the deﬁnition of conﬁguration in-

formation, necessary for the analysis execution. The

language is designed in a modular way, i.e. complex

analyses are deﬁned through the composition of sim-

pler ones. Supported analyses in the language are:

• Metric Deﬁnition: Calculates a metric for each

element or a metric for the whole architecture

• Scope Deﬁnition: Deﬁnes a part of the model

• Path Analysis: Calculates available paths be-

tween two elements according to deﬁned require-

ments

• Change Impact Analysis: Calculates the impact

of a change in one element

• Composed Analysis: Enables the composition of

analyses

Figure 1: Arla template deﬁnition.

The speciﬁcation of an analysis respectively tem-

plate is exemplary shown for the change impact tem-

plate (see ﬁgure 1). Each template deﬁnition starts

with the signal word Template. A speciﬁc analysis

starts with the signal word Analysis respectively. This

is followed by the name of the analysis and a descrip-

tion. Afterwards the name of the result attributes (at

least one) are speciﬁed, here it is one attribute named

changestatus. Followed by the signal word as the

analysis type (here Element) and the result type (here

Attribute) are deﬁned. Afterwards the analysis conﬁg-

uration has to be chosen. The conﬁguration proposi-

tions are ﬁltered according to the chosen analysis and

result type. We choose the change impact conﬁgura-

tion, which is followed by an identiﬁer for later refer-

ence purposes. Then the analysis or template speciﬁc

part is followed.

In this case stereotypes are mapped to the re-

spective effect types to deﬁne the change semantic.

E.g. the last line deﬁnes that an outgoing aggrega-

tion edge has the change semantic of a weak effect.

Thereby edgeType: aggregation is only a place-

holder variable. For understand-ability reasons it is

recommended to give meaningful names to those vari-

ables, although every term is possible. In order to ex-

ecute the analysis on a speciﬁc EA model, the vari-

able has to be mapped to a concrete stereotype of the

model in a AdaptedAnalysis.

3.2 Language Overview

Figure 2 gives a simpliﬁed overview of the analysis

language and its elements. Due to readability reasons

not all concepts of the language are visualized. Arla

consists of three packages. The Base Package (in the

ﬁgure at the bottom and blue) deﬁnes those parts that

are used by both analysis types, the speciﬁc and the

generic ones. The Speciﬁc Package (in the left and

yellow) deﬁnes constructs for a concrete analysis def-

inition whereas the Generic Package (on the right and

green) deﬁnes the constructs for template deﬁnition.

The common attributes of an analysis are summa-

rized in the concept Analysis Header. This includes

the name, the description and the declaration of the

result attributes. The Base Package also deﬁnes enu-

meration types like AnalysisType, ResultType, Node-

Class and EdgeClass and a generic construct for ref-

erencing EA stereotypes. The AnalysisType deﬁnes

whether the analysis should be calculated once for

the whole architecture (Aggregate) or for each ele-

ment (Element). The ResultType deﬁnes the kind of

result. Possible results are Metric, Attribute, Boolean,

Modelelement, Modelelementset and Pathset. The re-

sult type and the analysis type are attributes of all

analyses. Since they can have predeﬁned values for

some analysis types, they are speciﬁed in the concrete

analysis deﬁnition. Additionally the conﬁguration for

each analysis type is deﬁned in the base package. This

includes calculation rules for metrics, conditions for a

node set, rules for analysis composition, the deﬁnition

of a scope, the conﬁguration of paths, the conﬁgura-

tion of a change impact and the deﬁnition of a perfor-

mance analysis.

The Speciﬁc Package and the Generic Package

Generic EA Analysis Framework for the Deﬁnition and Automatic Execution of Analyses

319

Figure 2: Simpliﬁed Arla Overview.

have a very similar structure. Each package has a rule

for the main analysis speciﬁcation. This rule includes

a header and a body with the analysis respective tem-

plate deﬁnition. The analysis or template deﬁnition

rule is speciﬁc for every analysis type.

ArlaSpecific.xtext

77 SpecificElementMetric:

78 analysisTyp=Element

79 resultTyp=Metric

80 'defined with calculation rule:' definition =

ElementMetricDefinition

81 ;

83 SpecificAggregatedMetric:

84 analysisTyp=Aggregate

85 resultTyp=Metric

86 'defined with calculation rule:' definition =

AggregateMetricDefinition

87 ;

89 SpecificComposedAnalysis:

90 analysisTyp=AnalysisTyp

91 resultTyp=ResultTyp

92 'defined with composition rule:' definition=CompositionRule

93 ;

95 SpecificNodeSetAnalysis:

96 analysisTyp=Aggregate

97 resultTyp=Modelelementset

98 'defined with set definition:' definition = NodeSetCondition

99 ;

100

101 CustomQuery:

102 analysisTyp=AnalysisTyp

103 resultTyp = ResultTyp

104 'defined with SPARQL Query' definition=STRING

105 ;

106

107 ChangeImpactAnalysis:

108 analysisTyp=Element

109 resultTyp=Attribute

110 'defined with change impact configuration' '{'

111 definition = ChangeImpactConfiguration

112 '}'

113 ;

114

115 SpecificPathAnalysis:

116 analysisTyp=Aggregate

117 resultTyp=Pathset

118 'defined with path configuration' '{'

Page 3

Figure 3: Rule for change impact analysis.

Figure 3 shows exemplary the analysis deﬁnition

rule for the change impact analysis. First, the re-

sult type and the analysis type are deﬁned. For the

change impact analysis these values are ﬁx, since a

change impact analysis calculates the change value

for each element. The analysis type is Element and

the result type is Attribute. The respective analysis

conﬁguration is deﬁned as reference to the rule in the

Base Package. This ChangeImpactConﬁguration rule

is presented in ﬁgure 4. There are three different pos-

sibilities for a change impact conﬁguration. One of

them, the conﬁguration using stereotypes is presented

in detail. Thereby stereotypes are mapped to the re-

spective effect types of change. A functional descrip-

tion of the change impact analysis can be found in

(Langermeier et al., 2014a).

One exceptionality of the Speciﬁc Package is the

AdaptedAnalysis. This analysis type is used to exe-

cute predeﬁned templates on a speciﬁc EA model and

has therefore no pendant in the Generic Package. Like

other analyses, the deﬁnition starts with the selection

of the result type and the analysis type. Afterwards

the analysis conﬁguration from the utilized template

is referenced. A mapping of the stereotype variables

to concrete stereotypes of the EA model follows this.

3.3 Example Application

We already presented the deﬁnition of a change im-

pact analysis above. To further illustrate the usage

of Arla, we present the realization of two additional

analyses in the following. As representative of the

technical category KPI we choose a KPI from the

EAM KPI catalog (Matthes et al., 2011). The deﬁni-

tion of the Business application technology standards

compliance in Arla is shown in ﬁgure 5. The KPI

calculates the compliance degree of business applica-

tions to technology standards. Therefore the business

applications that comply to a technology standard are

divided by the total number of business applications.

This KPI can be used to reduce operating costs and

security breaches as well as increase the homogene-

ity. The template in the ﬁgure includes the descrip-

tion, the name of the result attribute as well as the

calculation rule named complianceDegree. Executing

the analysis results in a single number indicating the

compliance degree.

Despite metrics the concept of Views is another

important analysis approach. Views provide the ar-

chitect with an excerpt of the architecture according

to his current needs. The analysis approaches in this

category often do not provide enough details for a

concrete analysis speciﬁcation and execution. There-

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

320

ArlaBase.xtext

196 EdgeReference:

197 EdgeTypeReference | EdgeClassReference

198 ;

199

200 EdgeTypeReference:

201 'edge:' name = STRING

202 ;

203

204 PropertyReference:

205 'property:' name = STRING

206 ;

207

208 TypeReference:

209 StereotypeReference | ClassReference

210 ;

211

212 ClassReference:

213 EdgeClassReference | NodeClassReference

214 ;

215

216 NodeClassReference:

217 'nodeClass:' className=NodeClass

218 ;

219

220 enum NodeClass:

221 Process | Application | InfrastructureElement

222 ;

223

224 EdgeClassReference:

225 'edgeClass:' className=EdgeClass

226 ;

227

228 StereotypeReference:

229 NodeTypeReference | EdgeTypeReference | PropertyReference

230 ;

231

232

233 ChangeImpactConfiguration:

234 ChangeImpactConfigurationByStereotpe | ChangeImpactConfigurationByEdgeClasses | StaticChangeImpactConfiguration

235 ;

236

237 ChangeImpactConfigurationByStereotpe : {

ChangeImpactConfigurationByStereotpe

}

238 ('WeakEffect In' '(' incomingWeakStereotypes +=EdgeTypeReference ( ',' incomingWeakStereotypes+=EdgeTypeReference)* ')')?

239 ('MediumEffect In' '(' incomingMediumStereotypes +=EdgeTypeReference ( ',' incomingMediumStereotypes+=EdgeTypeReference)* ')')?

240 ('StrongEffect In' '(' incomingStrongStereotypes +=EdgeTypeReference ( ',' incomingStrongStereotypes+=EdgeTypeReference)* ')')?

241 ('WeakEffect Out' '(' outgoingWeakStereotypes +=EdgeTypeReference ( ',' outgoingWeakStereotypes+=EdgeTypeReference)* ')')?

242 ('MediumEffect Out' '(' outgoingMediumStereotypes +=EdgeTypeReference ( ',' outgoingMediumStereotypes+=EdgeTypeReference)* ')')?

243 ('StrongEffect Out' '(' outgoingStrongStereotypes +=EdgeTypeReference ( ',' outgoingStrongStereotypes+=EdgeTypeReference)* ')')?

244 ;

245

246 StaticChangeImpactConfiguration: {

StaticChangeImpactConfiguration

}

247 'static'

248 ;

249

250 ChangeImpactConfigurationByEdgeClasses:'{'

251 'ModelEdge' 'in:' defaultEdgeIncoming=ChangePropagation 'out:' defaultEdgeOutgoing=ChangePropagation

252 (impactDefintion+=ImpactDefinition)* '}'

253 ;

254

255 ImpactDefinition:

256 class=EdgeClass 'in:' edgeIncoming=ChangePropagation 'out:' edgeOutgoing=ChangePropagation

257 ;

258

259 enum ChangePropagation:

260 no_effect | strong_effect | weak_effect | no_effect_exceptOne

Page 4

Figure 4: Change impact conﬁguration rule.

MidWagen.garla

propertyType:"changestatus" with value "extension" AND having

property

propertyType:"changestatus" with value "modification" AND

having property

propertyType:"changestatus" with value "deletion"

}

Template ImpactScope {

"Scope definition"

Result Attributes scope

as Aggregate Modelelementset

defined with composition rule myComposition :=

apply ChangeImpactScope on ChangeImpact

}

Template BusinessApplicationTechnologyStandardsCompliance {

"Measurement of the compliance degree of business

applications to technology standards."

Result Attributes ratio

as Aggregate Metric

defined with calculation rule complianceDegree :=

(COUNT( nodeType:"Business Application" AND

having relation to (nodeType:"Technology Standard")))

(COUNT( nodeType:"Business Application"));

}

Template BusinessDomainCoverageOfTargetArchitecture {

"A measure of how completely the target architecture has been

drawn

up for the business (process) domains."

Result Attributes ratio

as Aggregate Metric

defined with calculation rule coverage :=

(COUNT( nodeType:"Business domain" AND

having relation to (nodeType:"Target architecture")))

(COUNT( nodeType:"Business domain"));

}

Page 3

Figure 5: Example KPI deﬁnition.

fore we employ the viewpoint deﬁnitions included

in the ArchiMate speciﬁcation although they are not

categorized as analysis. Therein we chose the Ap-

plication Structure Viewpoint to illustrate the deﬁni-

tion of views in Arla (The Open Group, 2012). This

view contains elements with the type Application in-

terface, Application component, Application collab-

oration and Data object as well as dependencies be-

tween them with the types aggregation, composition,

used by, access and specialization (see ﬁgure 6).

Figure 6: ArchiMate Application Structure Viewpoint (The

Open Group, 2012).

Views are deﬁned in Arla as Scope Analysis.

There are two different possibilities: The ﬁrst one is

the deﬁnition of a node set using conditions and re-

strictions of node types. This possibility is shown in

ﬁgure 7. The rule restricts the architecture to elements

having one of the four given types.

MidWagen.garla

Template ApplicationStructureViewpoint {

"The Application Structure viewpoint shows the structure of

one or more applications or components. This viewpoint is

useful in designing or understanding the main structure of

applications or components and the associated data"

Result Attributes viewset

as Aggregate Modelelementset

defined with set definition viewpointDefinition :=

nodeType:"Application component" OR

nodeType:"Application interface" OR

nodeType: "Data object" OR

nodeType: "Application collaboration"

}

Template ApplicationStructureViewpoint2{

"Application structure viewpoint for one application"

Result Attributes viewset2

as Aggregate Modelelementset

defined with scope configuration applicationStructure {

ApplicationStructureViewpointEdges {

ModelEdge in: None out: None

BehavioralDependentOf in: None out: None

ConsumedBy in: Single out: None

LocalizedAt in: None out: None

Provide in: None out: Single

StructuralDependentOf in: Transitive out: Transitive

}

Template CombinedView {

"Description"

Result Attributes set

as Aggregate Modelelementset

defined with composition rule composition := combine

ApplicationStructureViewpoint and ApplicationStructureViewpoint2 with

operation INTERSECTION

}

Page 4

Figure 7: Viewpoint deﬁnition using node conditions and

restrictions.

In the second possibility conditions about the

edges are speciﬁed (see ﬁgure 8). Thereby for each

edge class it is speciﬁed, whether the edges should be

considered one time (single), in a transitive way or

not at all. This analysis is executed for a speciﬁc ar-

chitecture element, for example a concrete application

component. The elements for the view are then calcu-

lated according to the given scope conﬁguration. I.e.

in this case all direct and indirect nested components

are added to result model part according to the transi-

tive deﬁnition of the structural dependency class. Ad-

ditionally all provided interfaces and data objects of

these components as well as the used components are

added.

MidWagen.garla

Template ApplicationStructureViewpoint {

"The Application Structure viewpoint shows the structure of

one or more applications or components. This viewpoint is

useful in designing or understanding the main structure of

applications or components and the associated data"

Result Attributes viewset

as Aggregate Modelelementset

defined with set definition viewpointDefinition :=

nodeType:"Application component" OR

nodeType:"Application interface" OR

nodeType: "Data object" OR

nodeType: "Application collaboration"

}

Template ApplicationStructureViewpoint2{

"Application structure viewpoint for one application"

Result Attributes viewset2

as Aggregate Modelelementset

defined with scope configuration applicationStructure {

ApplicationStructureViewpointEdges {

ModelEdge in: None out: None

BehavioralDependentOf in: None out: None

ConsumedBy in: Single out: None

LocalizedAt in: None out: None

Provide in: None out: Single

StructuralDependentOf in: Transitive out: Transitive

}

Template CombinedView {

"Description"

Result Attributes set

as Aggregate Modelelementset

defined with composition rule composition := combine

ApplicationStructureViewpoint and ApplicationStructureViewpoint2 with

operation INTERSECTION

}

Page 4

Figure 8: Viewpoint deﬁnition with conditions for edge

classes.

The intersection of both view deﬁnitions provides

the ArchiMate Application Structure Viewpoint. The

resulting architecture part contains only the given el-

ement and edge stereotypes as well as is restricted to

the perspective of one element.

4 ANALYSIS EXECUTION

PLATFORM

The execution environment consists of three main

components. Figure 9 gives an overview of the struc-

ture. The analysis deﬁnition language Arla was al-

ready described in the previous section. The Executor

is the essential component of the execution platform.

It provides the interfaces to the analysis language and

the model storage as well as contains the logic to con-

Generic EA Analysis Framework for the Deﬁnition and Automatic Execution of Analyses

321

vert Arla into evaluable constructs. Therefore it has

interfaces to the evaluation technologies. We choose

SPARQL for structural requests and Data-ﬂow Anal-

ysis (DFA) for behavioral requests and recursive deﬁ-

nitions. SPARQL is a graph-based query language for

RDF. The Data-ﬂow Analysis formalism is a power-

ful method originating from the area of compiler con-

struction that allows computing context-sensitive in-

formation based on declarative speciﬁcations. Since

ﬂow analysis relies on the principle of information

propagation rather than ﬁxed navigation statements,

it is possible to anticipate a wide array of changes and

adaptions to the underlying modeling language (Saad

and Bauer, 2013; Saad and Bauer, 2011).

Figure 9: Execution architecture.

The model data is stored in a RDF Triple Store.

For the data import we currently developed two

adapters: An adapter for the modeling tool Innova-

tor and an adapter for CSV ﬁles, which is exemplary

used for loading models of the open source EA tool

Archi. Further adapters for other tools can easily be

added. The model storage and analysis execution is

described in detail in the following sections.

4.1 Model Storage

The analysis platform utilizes a generic data schema

for the storage of EA models, the Generic Meta

Model (GMM). This meta model represents an EA

model as a stereotyped graph with nodes and edges.

Each element in the EA model is either a ModelNode

or a ModelEdge. ModelEdges represent the relation-

ships between ModelNodes. Both, nodes and edges,

can have one or more ModelProperty representing at-

tributes of them like a strategic impact. All three types

have a relation to the respective stereotype. Possi-

ble stereotypes for ModelNodes are Process or Ap-

plication. Example for ModelEdges are used by or

provides. A stereotype is represented as MetaMod-

elNode respectively MetaModelEdgeConnection and

MetaModelProperty. A ModelEdge can be further

specialized as LocalizedAt, Realize, UsedBy, Behav-

ioralDependentOf or StructuralDependentOf. These

subclasses of ModelEdge are used to categorize the

individual stereotypes in an EA model and ease the

reuse of analysis deﬁnitions. They are equivalent to

the concept of EdgeClasses in Arla. For ModelNodes

currently supported stereotype categories are Process,

Application and Infrastructure Component (accord-

ingly to the concept of NodeClasses in Arla). Further

details about the GMM can be found in previous work

(Langermeier et al., 2014b).

Figure 10: Example for the instantiation of the generic meta

model (Langermeier et al., 2014b).

In order to run analyses on an EA Model, it has

to be transformed into a GMM model. Due to the

universality of GMM, this is possible for most of

the EA models. Figure 10 shows the instantiation

of the generic meta model. The example shows the

provisioning of the business service Reservation by

phone by the business process Booking a car. For

an import we capture the syntax of the serialized EA

model using an ANTLR

grammar. From this gram-

mar ANTLR generates a parser that enables the cre-

ation and walk through of the parse tree. We utilize

this parser to create an EMF model using the GMM

scheme. This EMF model is then persisted in RDF

using the Framework EMFTriple

. The whole model

loading process is illustrated in ﬁgure 11.

Figure 11: Model loading.

EMFTriple is a framework that provides a RDF

binding for EMF. Therewith we were able to persist

our EMF models in RDF instead of XMI. The frame-

work provides also interfaces to RDF data stores. We

http://www.antlr.org

https://github.com/ghillairet/emftriple

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

322

choose the Triple Store from Apache Jena, the TDB

as data store. This component allows the storage and

querying of RDF data via the Jena API.

4.2 Analysis Execution Process

In order to execute an analysis from an Arla ﬁle, the

ﬁrst step is to parse the analysis deﬁnition. We used

the Xtext language infrastructure

for this task. De-

spite a model parser Xtext also provides a text editor

with syntax highlighting and auto completion. Pars-

ing an Arla ﬁle ﬁnally provides us an EMF model of

the analysis deﬁnition. In a second the step the uti-

lized template deﬁnition are processed. Each template

is transformed into a speciﬁc Arla deﬁnition using

Text2Text Transformation. Thereby only those analy-

ses are transformed that are referenced in an Adapted-

Analysis. Afterwards all required analysis deﬁnitions

are available and processable. The following evalua-

tion process is illustrated in ﬁgure 12.

Figure 12: Workﬂow analysis execution.

In the case of an composite analysis or a metric

the analysis deﬁnition is composed in its components

in a ﬁrst step. According to the chosen analysis con-

ﬁguration the evaluation is done through the creation

and execution of a SPARQL query or through trigger-

ing a predeﬁned data-ﬂow analysis. Typically, before

executing a DFA several parameters have to be set in

a conﬁguration ﬁle. The evaluation details of the dif-

ferent analysis types is described in the following:

• Element or Aggregate Metric: Decomposition

in its components and evaluation of the atomic ex-

pressions. Expressions questioning a set of nodes

or edges are evaluated through the creation and

execution of SPARQL, a result reference triggers

the execution of the referenced analysis, a SUM

respectively COUNT triggers the execution of the

contained expression for each addressed element

and merges the results.

• Node Set Condition: Creation of a SPARQL

query to retrieve the requested node set.

• Scope: Generate the conﬁguration ﬁle and trigger

the DFA.

http://jena.apache.org/documentation/tdb/index.html

http://www.eclipse.org/Xtext/

• Change Impact Adapt the conﬁguration param-

eters, generate conﬁguration ﬁle and trigger the

DFA.

• Path Analysis Adapt conﬁguration and trigger

the DFA.

• Adapted Analysis Execute the respective gener-

ated speciﬁc analysis.

• Composed Analysis Three different composition

possibilities: Successive execution, result combi-

nation and within a calculation rule.

• DFA, e.g. Performance Analysis Triggers the ex-

ecution of the respective static DFA (e.g. perfor-

mance analysis)

• Custom Query Executes the explicit speciﬁed

SPARQL query in the analysis deﬁnition

The successive execution is deﬁned as: Apply

Analysis2 on Analysis1. This composition rule is real-

ized while executing analysis 1 (A1) ﬁrst. The result

of A1 is written back into the model. Then analysis

2 (A2) is executed on this new model. The result of

analysis 2 is the ﬁnal result. This execution process is

illustrated in ﬁgure 13a.

Figure 13: Arla composition rules.

In ﬁgure 13b the possibility of result combination

is presented. Thereby the two analyses A1 and A2

can be executed independently from each other. The

retrieved results, R1 and R2, are combined afterwards

to create the ﬁnal result R. Therefore different com-

bination possibilities exist: In the default mode the

results are combined according to the union seman-

tics. It is only possible to combine results of the same

type. Additionally converting the path set into a node

set allows the combination with a node set. The com-

bination of a element result and a aggregated result

is only possible, if the single element results can be

summarized to one result, i.e. union for sets. Addi-

tionally node set results can be composed using the

operators intersection and difference. The op-

erators are implemented according to set theory. Also

in this case a path result is transformed into a node set

result and element result are aggregated to one set.

At least analyses can be composed using a calcu-

lation rule. Therefore references to result attributes of

other analyses can be used within a calculation rule.

At execution time the ﬁrst analysis is evaluated and

Generic EA Analysis Framework for the Deﬁnition and Automatic Execution of Analyses

323

within this process the second analysis execution is

triggered. The process is illustrated in ﬁgure 13c.

The analysis composition is an important mean to

deal with incomplete models. Before executing a spe-

ciﬁc analysis, the model can be restricted to the rel-

evant part of the architecture that is sufﬁciently de-

scribed. For example performance parameters are not

available for all servers. Before executing a perfor-

mance analysis, those servers with their dependencies

can be excluded.

If it is not possible to implement an analysis in

Arla, for example a recursive deﬁnition in a metric,

the language provides an adapter to DFA. Instead of

deﬁning the execution rules for an analysis, the loca-

tion of the DFA conﬁguration and the executed strat-

egy is deﬁned. Based on this information the prede-

ﬁned DFA is executed and the results are processed.

Additionally it is also possible to deﬁne a new anal-

ysis type in Arla. In this case the user does not have

to deal with the concrete DFA conﬁguration path and

strategy name. Currently this is realized for the per-

formance analysis of (Jonkers and Iacob, 2009). Due

to the recursive deﬁnition it was not possible to re-

alize the analysis solely in Arla. Therefore we im-

plemented it as data-ﬂow analysis (see previous work

(Langermeier et al., 2014b)) and deﬁned an analysis

type PerformanceAnalysis in Arla. A further possibil-

ity to extend the scope of Arla is the explicit deﬁnition

of SPARQL queries in an analysis deﬁnition. There-

fore deep knowledge of the RDF graph is required,

but it provides access to the full expressive power of

SPARQL.

The ﬁnal result of an analysis execution is visual-

ized using Graphviz. Depending on the result types

different options exist for the visualization: Node

sets are visualized as the respective part of the whole

model. Analyses concluding in attribute values can

be visualized using colors or using text annotations

in the model. Numeric results are visualized as an-

notations in the model. Path results are visualized as

several model excerpts, each representing one path.

5 EVALUATION

For evaluation purposes we speciﬁed an analysis for

each Arla analysis type and executed them within

three use cases. These are a small, ﬁctional model

describing a car rental station (also used in (Langer-

meier et al., 2014a)), the EA model of a medium-

sized software product house and the EA model of

a medium-sized manufacturing company. In section

3 we already presented the template deﬁnitions for a

change impact analysis, an KPI calculation and a view

deﬁnition. The deﬁnition were executed in the three

use case by adapting them to the speciﬁc EA mod-

els. Figure 14 shows the adapted analysis deﬁnition

to calculate the application structure viewpoint for the

manufacturing use case.

specific2.sarla

Model "http://archimodel"

TripleStore "/Users/Melanie/UnA/EclipseMarsWSKopie/ARCHITECTURE-

ANALYSIS-TRIPLESTORE/TripleStore/ArchiModel"

Analysis_Package myAnalysis

"Description"

StartCongif {

apply Deletion on "Accounting

Service" ["ef0e6465-4644-3fba-55b2-86dcc778e9e7"]

calculate scope for ("Car

management" ["6f5e3313-8a0e-1207-8a29-8a8d8d0716db"])

source elements for paths ("Car management" ["dab3f36c-f7dd-

ef1e-7ab2-4359f6160ccb"])

target elements for paths ("Car Management" ["7b68e4c0-7b46-a008-

e4f0-31f199cb569e"])

max hops 10

}

Analysis ApplicationStructureViewpoint4CarRental {

"Adaption of the Application Structure Viewpoint

to the manufacturing case"

Result Attributes viewpoint

as Aggregate Modelelementset

adapt viewpointDefinition {

map "Application collaboration"

to node:"ApplicationFunction" ["ApplicationFunction"]

map "Application component" to nodeClass:Application

map "Application interface"

to node:"ApplicationService" ["ApplicationService"]

map "Data object"

to node:"BusinessObject" ["BusinessObject"]

}

Page 1

Figure 14: Adapted analysis deﬁnition to calculate the ap-

plication structure viewpoint.

Additionally we also executed a path analysis and

the performance analysis on these use cases. Figure

15 shows the result of the realizing paths analysis ap-

plied to the process Take back car in the rental car

model. The full model can be found in (Langermeier

et al., 2014a). The result visualize two paths that rep-

resent two different IT realizations of the process. In

this case the difference between the two paths is not

on the application layer but in the infrastructure layer.



  











































































































Figure 15: Realizing paths for process Take back car.

We were able to execute all speciﬁed analysis def-

initions in the three different use cases. If the EA

models contain the required information, for exam-

ple if applications comply to a technology standard,

we retrieve meaningful results. The templates could

be executed in all use cases after the deﬁnition of the

corresponding Adapted Analysis.

Additionally we evaluated the language and its

execution possibilities through an examination of

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

324

the current work in EA analysis. Thereby anal-

ysis approaches relying on expert interviews (e.g.

(Della Bordella et al., 2011; Plessius et al., 2012) or

approaches addressing the method EAM like maturity

analyses (e.g. (Aier et al., 2011)) are not considered in

our evaluation. According to these constraints the ap-

proaches summarized by the following analysis types

are not included in the evaluation: Business Entity

Analysis, Design Analysis, Run-time Analysis, In-

tentional Analysis, Maturity Analysis and Sensitivity

Analysis. For the remaining approaches, we decided

whether they can be completely described and evalu-

ated in Arla (i.e. they are covered by Arla), partially

described and evaluated with Arla or whether Arla

does not cover them. For example a partial coverage

is given for approaches considering dates. Currently

Arla does not comprise special expressions for evalu-

ating time spans or point of times. Indirectly it is pos-

sible by utilizing other expression types. Some anal-

yses in the technical category PRM (N

arman et al.,

2014) are also only partially covered. The probabilis-

tic aspects of these analyses, which are implemented

in a Monte Carlo fashion, cannot be reproduced with

Arla. By replacing the probability distributions with

single values, the analyses can be deﬁned and eval-

uated. An analysis approach is also declared as par-

tially covered, if it is necessary to specify new DFA

implementations or create custom SPARQL queries

for its realization.

We aggregated the results of our evaluation using

the analysis types as well as the technical and func-

tional categorization. We refer to the types and cate-

gories instead of the single approaches, since it is not

obvious to decide whether a following publication of

an approach is a new one or an extension to an exist-

ing one. Hence, referring to the concrete approaches

would provide a biased view on the coverage of Arla.

From the 33 analysis types 21 are covered by Arla

and additional 7 types are at least partially covered. A

total of 6 analysis types are not covered, that is 18%.

We say that Arla covers an analysis type, if there ex-

ists at least one analysis approach that is assigned to

this analysis type and is covered by Arla. If Arla cov-

ers none of the approaches but there is at least one ap-

proach that is partially covered, then the analysis type

is partially covered. Otherwise Arla does not cover

the analysis type.

To further evaluate the coverage of Arla we ana-

lyzed the results for the technical (ﬁgure 16) and func-

tional (ﬁgure 17) categorization of the approaches.

Most of the technical categories are covered or par-

tially covered by Arla. Only the categories containing

probabilistic approaches are not covered. These are

Bayesian Networks, Probabilistic Relational Model

and Extended Inﬂuence Diagrams.

Figure 16: Coverage technical categories.

Concluding, the functional category System is not

covered by Arla, since the approaches of this category

are all assigned to one of these three technical cate-

gories. For all other categories there exist approaches

that are covered or at least partially covered (Data) by

Arla.

Figure 17: Coverage functional categories.

The overall coverage of Arla regarding existing

EA analyses is quite high. The major weakness is

the missing support for probabilistic approaches, all

other categories are covered by Arla. The implemen-

tation within the case studies shows the applicability

of the language. The template mechanism in order

to enable reuse and predeﬁned analyses supported the

analysis execution within the case studies very well.

Currently we made no usability tests with architects

regarding the ease of use. From our experiences in

the case studies we identiﬁed several improvements

for Arla. If possible, they are already implemented.

For example a direct support of dates and date expres-

sion is planned for Arla in future work.

For executing the analyses we utilize a combina-

tion of SPARQL and data ﬂow based analysis. Both

approaches are successfully applied in large appli-

cation scenarios and thus provide a scalable techni-

cal foundation for our analysis execution. The graph

Generic EA Analysis Framework for the Deﬁnition and Automatic Execution of Analyses

325

based query language SPARQL provides features to

answer structural questions and extract model parts.

DFA is perfectly qualiﬁed to answer behavioral ques-

tions, execute recursive analysis deﬁnitions and deal

with cyclic dependencies. It enables a forward and

also backward traversing of the model. Combining

both techniques enables the execution of complex

analyses and provides means to deal with an incom-

plete model.

The GMM enables a tool and EA meta model

independent execution environment for the analyses.

The adaption process for a speciﬁc EA initiative is

kept as simple as possible: The concept of edge

classes and node classes provides a mechanism to de-

ﬁne generic analyses and execute them with small ef-

fort on a speciﬁc model. Only during import deﬁni-

tion the mapping of stereotype to the classes has to be

made once. Additionally, if more detailed semantics

about the nodes an edges are required, the analysis

templates can use stereotype variables. These vari-

ables have to be mapped to concrete EA model stereo-

types before execution. Finally the language Arla ab-

stracts from all the technical details. The concrete ex-

ecution procedures are generated form the Arla deﬁ-

nition at runtime.

6 CONCLUSION

In this paper we presented a language for the deﬁ-

nition of Enterprise Architecture analyses as well as

an execution environment for their evaluation. The

language (Arla) provides a universal interface to EA

analyses since it abstracts from the technical details of

the execution. Thereby Arla overcomes current weak-

nesses of EA analyses like the isolation of existing ap-

proaches or the difﬁculties in order to adapt them to a

speciﬁc EA initiative. We integrated different kinds

of EA analysis regarding their goals and addressed

topics as well a regarding their technical execution.

Additionally Arla contains a composition mechanism,

which enables the deﬁnition of complex analyses by

reusing simpler ones. The language with its execution

environment provides a foundation for an EA analy-

sis library. Through the possibility of template deﬁni-

tion as well as the independence from the meta model,

generic analyses can be deﬁned and easily adapted in

a speciﬁc context. Thereby architects can proﬁt from

reuse and experiences from other projects.

The utilization of SPARQL and DFA for analysis

execution enables the high coverage of Arla regard-

ing the technical and functional analysis categories.

The combination of both techniques in one frame-

work provides means to deal with incomplete models

as well as facilitate a high expressiveness and variabil-

ity for analysis deﬁnitions. The presented language

Arla abstracts from all those technical details and pro-

vides the architect a simple interface to analysis activ-

ities.

In future work the scope of Arla will be further

extended. Since probabilistic analyses are currently

not directly supported, we will elaborate ways to inte-

grate them. Additionally the change impact analysis

can be generalized in order to support universal ”if-

then” analyses based on attributes. Such an analysis

type can be used to deﬁne failure impact analyses or

availability analyses. Another point is the integration

of feasibility analyses before the analysis execution.

This provides an automatic way to deal with incom-

plete models and supports the architect in the interpre-

tation of results. Finally we will make use of further

RDF features like reasoning in order to deal with in-

direct relationships.

REFERENCES

Aier, S., Gleichauf, B., and Winter, R. (2011). Understand-

ing enterprise architecture management design-an em-

pirical analysis. In Proceedings of 10th Conference on

Wirtschaftsinformatik.

Bucher, T., Fischer, R., Kurpjuweit, S., and Winter, R.

(2006). Analysis and application scenarios of enter-

prise architecture: An exploratory study. In 10th IEEE

International Enterprise Distributed Object Comput-

ing Conference Workshops, EDOCW’06, pages 28–

28. IEEE.

Buckl, S., Matthes, F., and Schweda, C. M. (2009). Clas-

sifying enterprise architecture analysis approaches. In

Enterprise Interoperability, pages 66–79. Springer.

Della Bordella, M., Liu, R., Ravarini, A., Wu, F. Y.,

and Nigam, A. (2011). Towards a method for real-

izing sustained competitive advantage through busi-

ness entity analysis. In Enterprise, Business-Process

and Information Systems Modeling, pages 216–230.

Springer.

Frank, U., Heise, D., and Kattenstroth, H. (2009). Use of a

domain speciﬁc modeling language for realizing ver-

satile dashboards. In Proceedings of the 9th OOPSLA

workshop on domain-speciﬁc modeling (DSM).

Franke, U., Flores, W. R., and Johnson, P. (2009). En-

terprise architecture dependency analysis using fault

trees and Bayesian networks. In Proceedings of the

2009 Spring Simulation Multiconference, SpringSim

’09, pages 55:1–55:8, San Diego, CA, USA.

Johnson, P., Nordstr

om, L., and Lagerstr

om, R. (2007).

Formalizing analysis of enterprise architecture. In

Doumeingts, G., Mller, J., Morel, G., and Vallespir,

B., editors, Enterprise Interoperability, pages 35–44.

Springer London.

Jonkers, H. and Iacob, M.-E. (2009). Performance and

cost analysis of service-oriented enterprise architec-

ICEIS 2017 - 19th International Conference on Enterprise Information Systems

326

tures. Global Implications of Modern Enterprise In-

formation Systems: Technologies and Applications,

IGI Global.

Kurpjuweit, S. and Aier, S. (2009). Ein allgemeiner Ansatz

zur Ableitung von Abh

angigkeitsanalysen auf Un-

ternehmensarchitekturmodellen. In Wirtschaftinfor-

matik Proceedings 2009.

Langermeier, M., Saad, C., and Bauer, B. (2014a). Adap-

tive approach for impact analysis in enterprise archi-

tectures. In Business Modeling and Software Design,

pages 22–42. Springer.

Langermeier, M., Saad, C., and Bauer, B. (2014b). A

uniﬁed framework for enterprise architecture analysis.

In 18th IEEE International EDOC Conference Work-

shops, pages 227–236.

Lankhorst, M. (2013). Enterprise Architecture at Work:

Modelling, Communication and Analysis. Springer.

Lantow, B., Jugel, D., Wißotzki, M., Lehmann, B., Zim-

mermann, O., and Sandkuhl, K. (2016). Towards a

classiﬁcation framework for approaches to enterprise

architecture analysis. In The Practice of Enterprise

Modeling : 9th IFIP WG 8.1. Working Conference,

PoEM 2016, Sk

ovde, Sweden, November 8-10, 2016,

Proceedings, pages 335–343. Springer International

Publishing.

Matthes, F., Monahov, I., Schneider, A., and Schulz, C.

(2011). EAM KPI Catalog. Technical Report v 1.0,

Technical University Munich.

Naranjo, D., S

anchez, M., and Villalobos, J. (2014). To-

wards a uniﬁed and modular approach for visual

analysis of enterprise models. In Enterprise Dis-

tributed Object Computing Conference Workshops

and Demonstrations (EDOCW), 2014 IEEE 18th In-

ternational, pages 77–86. IEEE.

Naranjo, D., S

anchez, M., and Villalobos, J. (2015). Prim-

rose: A graph-based approach for enterprise archi-

tecture analysis. In Enterprise Information Systems:

16th International Conference, ICEIS 2014, Lisbon,

Portugal, April 27-30, 2014, Revised Selected Papers,

pages 434–452. Springer International Publishing.

arman, P., Buschle, M., and Ekstedt, M. (2014). An enter-

prise architecture framework for multi-attribute infor-

mation systems analysis. Software & Systems Model-

ing, 13(3):1085–1116.

arman, P., Schonherr, M., Johnson, P., Ekstedt, M., and

Chenine, M. (2008). Using enterprise architecture

models for system quality analysis. In 12th IEEE In-

ternational EDOC Conference, pages 14–23.

Niemann, K. D. (2006). From enterprise architecture to IT

governance. Springer.

Plessius, H., Slot, R., and Pruijt, L. (2012). On the cate-

gorization and measurability of enterprise architecture

beneﬁts with the enterprise architecture value frame-

work. In Trends in Enterprise Architecture Research

and Practice-Driven Research on Enterprise Trans-

formation, pages 79–92. Springer.

Rauscher, J. (2013). Analysen in Unternehmensarchitek-

turen - Ziele, Techniken, Anwendungsbereiche. Bach-

elor Thesis, University Augsburg.

Rauscher, J. (2015). Anforderungen an und Deﬁnition von

einer Analysesprache f

ur das Enterprise Architecture

Management. Master Thesis, University Augsburg.

Rauscher, J., Langermeier, M., and Bauer, B. (2017). Clas-

siﬁcation and deﬁnition of an enterprise architecture

analyses language. In Business Modeling and Soft-

ware Design, 6th Int. Symposium, LNBIP. Springer.

Accepted for publication.

Saad, C. and Bauer, B. (2011). The Model Analysis Frame-

work - An IDE for Static Model Analysis. In Pro-

ceedings of the Industry Track of Software Language

Engineering (ITSLE) in the context of the 4th Interna-

tional Conference on Software Language Engineering

(SLE’11).

Saad, C. and Bauer, B. (2013). Data-ﬂow based Model

Analysis and its Applications. In Proceedings of the

16th International Conference on Model Driven Engi-

neering Languages and Systems (MoDELS’13).

Sasa, A. and Krisper, M. (2011). Enterprise architecture

patterns for business process support analysis. Journal

of Systems and Software, 84(9):1480–1506.

Sunkle, S., Kulkarni, V., and Roychoudhury, S. (2013). An-

alyzable enterprise models using ontology. In CAiSE

Forum, volume 998, pages 33–40.

The Open Group (2012). ArchiMate 2.1. Technical Report

Open Group Standard.

Generic EA Analysis Framework for the Deﬁnition and Automatic Execution of Analyses

327