Context-Sensitive Impact Analysis for Enterprise Architecture

Management

Melanie Langermeier, Christian Saad and Bernhard Bauer

Software Methodologies for Distributed Systems, University of Augsburg, Germany

{langermeier, saad, bauer}@ds-lab.org

Keywords:

Enterprise Architecture Analysis, Impact Analysis, Change Propagation, Data Flow Analysis.

Abstract:

Since Enterprise Architecture (EA) models are typically very large, it is often difﬁcult for humans to fully

grasp their contents. Due to this inherent complexity, the task of generating additional value from these

models is very challenging without a suitable analysis method. Impact analysis, which is able to determine

the effects which changes have on other architectural elements, can therefore provide valuable information for

an enterprise architect. Whether an element is affected by a change depends on its context, i.e. its (transitive)

connections to other elements and their status with respect to the analysis. In this paper we propose a context-

sensitive approach to the implementation of impact analyses. This method relies on the technique of data-ﬂow

analysis to propagate the effects of changes throughout the model. As a consequence, the speciﬁcation can be

deﬁned in a very generic fashion, which only relies on relationship classes. Therefore it can be easily adapted

to organization-speciﬁc EA meta models as only the relationship types have to be mapped to the respective

classes.

1 INTRODUCTION

Enterprise Architecture Management (EAM) pro-

vides methods for managing the inherent complexity

of the large IT infrastructures encountered in many

organizations. As a result, Enterprise Architecture

(EA) models usually contain many elements which

are connected through complex relationships. It is

therefore vital to provide suitable methods for (semi-

)automatically analyzing their contents to be able to

beneﬁt from this methodology once it has been suc-

cessfully established in an organization.

Although much research has been done in the EA

domain, most of this work focuses on methodolo-

gies for the development and the representation of en-

terprise models. By contrast, approaches and tech-

niques which explore possible applications scenarios

are very rare (N

arman et al., 2012; Niemann, 2006).

Regarding the analysis of EA models, a major fo-

cal point exists in their quantiﬁcation. This encom-

passes the deﬁnition and computation of quality at-

tributes such as application usage and service avail-

ability. (N

arman et al., 2012) Furthermore, it is pos-

sible to evaluate the performance and cost aspects in

the different layers of enterprise models (Jonkers and

Iacob, 2009). Finally, (Matthes et al., 2012) establish

a catalog of KPIs to measure EA management goals.

One of the most important analysis methods how-

ever, is the so-called impact analysis which allows to

simulate the effects of changes (e.g. the modiﬁcation

of a CRM system) and to assess risks in the current

architecture (e.g. which business operations would

be affected if a speciﬁc server goes ofﬂine) (de Boer

et al., 2005). To generate this information, an impact

analysis has to evaluate the dependencies between the

architecture’s constituents. However, in order to make

proper assertions about these relationships, it is neces-

sary to evaluate each element in its respective context.

This means, that its relationships with other elements

in the model have to be taken into consideration. For

example, to examine the impact of a server failure on

business processes, one has to determine which ap-

plications rely on this server. This requires a careful

evaluation of indirect and transitive paths in the model

to ensure that all necessary information is retrieved,

while at the same time excluding irrelevant relation-

ships.

Existing approaches and tools for the creation and

analysis of EA models usually rely on a static meta

model structure. This can be a problem since each

organization tends to employ its own meta model,

making the adaption of existing analyses very difﬁcult

(Kurpjuweit and Aier, 2009). To rectify this situation,

more ﬂexible methods for handling structural depen-

Langermeier M., Saad C. and Bauer B.

Context-Sensitive Impact Analysis for Enterprise Architecture Management.

DOI: 10.5220/0005424200470055

In Proceedings of the Fourth International Symposium on Business Modeling and Software Design (BMSD 2014), pages 47-55

ISBN: 978-989-758-032-1

dencies are required.

In this paper we present a technique which sup-

ports the context-sensitive impact analysis of EA

models. It is based on the principle of data-ﬂow anal-

ysis, a method which originates from the ﬁeld of com-

piler construction. Using this approach, it is possible

to derive context-sensitive information by propagat-

ing contextual information along the model’s edges.

Since the developed analysis distinguishes between

different semantic relationship classes it can be easily

adapted to the conventions in different organizations

by mapping the relationship types in the respective

target domain to the proposed categories. Further-

more, it is possible to extend the analysis with indi-

vidual impact propagation rules. To demonstrate the

viability as well as the generic applicability of this

approach, we implement multiple impact analyses for

different EAM languages.

2 IMPACT AND DEPENDENCY

ANALYSIS

According to (Bohner, 2002), determining the effects

of a change requires an iterative and discovery-based

approach. Change impact analysis can be performed

for a single software system, but also on an architec-

tural level for a full application landscape or an en-

terprise architecture. A related topic which is also of

interest in this context is the analysis of dependency

relationships.

Typically, any change which is made to a model

element also affects its neighboring elements (direct

impact). However, as these changes may in turn af-

fect other elements (indirect impact), the effect prop-

agates throughout the model. Consequently, even a

small change in a single element can cause ripple-

effects, resulting in non-trivial consequences. While

the direct impact can be derived from the connectiv-

ity graph, the computation of indirect impacts (n-level

impacts) requires reachability information. However,

since this method approximates potential impacts, it

tends to overestimate the result by generating false-

positives. The precision of the analysis can be im-

proved by using a constraint mechanism or by incor-

porating structural and semantic information (Bohner,

2002).

Most of the work regarding impact analysis

of software focuses on the code level (Lehnert,

2011). Approaches which evaluate architectures usu-

ally only regard concepts such as components, pack-

ages, classes, interfaces and methods. Due to the

limited amount of supported types and the domain-

speciﬁc characteristics, these approaches are not suit-

able for use in EAM.

Nevertheless, some techniques which target the

UML are more closely related to the EAM domain.

(Briand et al., 2003) propose a methodology for sub-

jecting analysis and design documents to an impact

analysis to detect side effects of changes in the con-

text of UML-based development. To restrict the set

of affected model elements they propose the use of a

coupling measure and a predictive statistical model.

The impact analysis itself is speciﬁed using the OCL.

(von Knethen and Grund, 2003) developed an ap-

proach which supports traceability by providing re-

quirements engineers, project planers and maintain-

ers with the ability to monitor the effects that changes

have on software systems. They differentiate between

three types of relationships to deﬁne the traces: repre-

sentation, reﬁnement and dependency. To determine

the change impact, they (semi-)automatically analyze

requirement traces using these three categories.

(Kurpjuweit and Aier, 2009) and (Saat, 2010) pro-

pose techniques for EA dependency analysis. Saat

focuses on time-related aspects (org. ”zeitbezogene

Abh

angingkeitsanalysen”) by considering for each el-

ement its life time, the status (current or proposed) as

well as the life cycle phase with its duration. How-

ever, no execution or implementation details are pro-

vided for this approach. Kurpjuweit and Aier devel-

oped a formal method for ﬂexible and generic depen-

dency analysis. To determine dependent elements,

they use the transitive closure of a set of relations.

They also deﬁne an expansion function, which allows

to consider special relation semantics, e.g. hierarchi-

cal reﬁnement or reﬂective relation types.

(Holschke et al., 2009) as well as (Tang et al.,

2007) propose the use of Bayesian Belief Networks

(BBN) for EA modeling. These approaches rely on

causal dependencies as well as inference methods for

BBN and a diagnosis analysis to determine the im-

pact. The former realizes a failure impact analysis,

theoretically described in the pattern catalogue (Buckl

et al., 2008), using the diagnostic analysis

and the

modeling tool GeNIe. As a result, architectural com-

ponents can be ranked with respect to their critical-

ity for a business process. However, this approach

focuses on availability, not on changes. Tang et al.

employ a combination of predictive reasoning to de-

termine affected elements and diagnostic reasoning to

determine the cause of a change. Prior to the analy-

sis, the architect has to assign a probability to each

root node and a conditional probability table to each

Jagt, R.M.: Support for Multiple Cause Diagnosis with

Bayesian Networks. Vol. M. Sc. Delft University of Tech-

nology, the Netherlands and Information Sciences Depart-

ment, University of Pittsburgh, PA, USA, Pittsburgh (2002)

Fourth International Symposium on Business Modeling and Software Design

non-root node.

Propagation rules are another method for deter-

mining the impact of changes. This technique al-

lows to deﬁne effects that depend on structural and se-

mantical properties. An iterative application of those

rules to a model yields the direct and indirect im-

pacts. (de Boer et al., 2005) present such rules for

the most important relationships in ArchiMate mod-

els, differentiating between the removal, the exten-

sion and the modiﬁcation of an architectural element.

However, the deﬁnitions are given in an informal and

textual manner and no technical realization is sup-

plied. (Kumar et al., 2008) propose rules that encode

the dependency relationships of the attributes of en-

tities. Changes are thereby propagated to determine

the impact on a deﬁned set of element types, namely

business goals, processes, services and infrastructure

components as well as the relations runs on, provides,

executes and delivers. No mechanism is speciﬁed for

implementing the change propagation. (Aryani et al.,

2010) also rely on the propagation concept to deﬁne a

conceptual coupling measurement for software com-

ponents. Based on this information a dependency ma-

trix is established which allows to predict change im-

pacts.

In (Lankhorst, 2012), a tool for impact-of-change

analysis is described. The author represents enterprise

architectures in XML and uses the Rule Markup Lan-

guage (RML) to deﬁne transformations which repre-

sent the rules which deﬁne the impact-of-change. The

RML rules are analyzed through a pattern matching

of the antecedent against the input XML. If a rule

matches, the variables will be bound and an output

XML is generated based on the rule output.

3 A CONTEXT-SENSITIVE

APPROACH TO IMPACT

ANALYSIS

The foundation for the deﬁnition of any impact is

the computation of reachable elements. Accord-

ing to (Bohner, 2002), reachability denotes transitive

connections, whereas dependability refers to directly

connected elements. To determine reachability rela-

tionships we employ data-ﬂow analysis, a technique

which is based on the principle of information propa-

gation. This allows to directly implement the follow-

ing recursive speciﬁcation: An element is reachable

if at least one predecessor element is reachable. In

this context, a predecessor is deﬁned as the source el-

ement of an incoming edge. Since there are typically

no isolated areas in an EA model, this would normally

result in almost all elements being classiﬁed as reach-

able. For a more focused analysis, we therefore need

to extend the reachability computation with contex-

tual information. For this purpose, we establish two

different categorization mechanisms for relationships.

For each relationship class in these categories we de-

ﬁne a change propagation rule which speciﬁes how a

change will be propagated through the model.

In the following we will ﬁrst formalize the rep-

resentations of model and meta model data in a way

which ensures the applicability of the approach even

if an organization employs a customized version of

the meta model. We will then describe a data-ﬂow

based speciﬁcation of a naive reachability analysis

and subsequently propose extensions which enable a

context-sensitive analysis of change impacts.

3.1 Formalizing the Meta Model and

the Model

The high diversity of meta models results in a major

challenge when devising techniques in the context of

EAM. To overcome this issue, we developed a generic

meta model which is able to support any EA language

based on traditional modeling paradigms. Apart from

abstracting from the particular structure of an input

language, this approach has the beneﬁt of combining

meta model and model data in a single representation.

Figure 1: Generic representation for EA (meta) model data.

A condensed version of this speciﬁcation is de-

picted in ﬁgure 1. The relevant elements can be de-

scribed as follows: Each concept of the respective

target EA language is translated into either a Meta-

ModelNode or a MetaModelEdge. Connections be-

tween these elements have to be established accord-

ingly during the transformation process. Both types

Context-Sensitive Impact Analysis for Enterprise Architecture Management

also carry additional meta information such as their

stereotype, the concept’s name and its properties. In-

stances from the target EA model are converted into

ModelNodes and ModelEdges and connected to their

respective meta model stereotypes.

3.2 Analyzing Reachability for EA

Models

The computation of reachability information forms

the basis for the subsequent impact analysis. An ele-

ment is declared reachable, if there exists a path con-

necting the element to the starting point (indirectly

connected elements). The reachability analysis is car-

ried out using the Model Analysis Framework (MAF)

(Saad and Bauer, 2011) which supports the speciﬁ-

cation and execution of data-ﬂow based analyses on

models.

Data-ﬂow analysis is used by compilers to derive

optimizations by examining the structural composi-

tion of program instructions. Canonical examples in-

clude the calculation of reaching deﬁnitions and vari-

able liveness. For this purpose, the program is con-

verted into a control-ﬂow graph with the nodes rep-

resenting the basic blocks and the edges denoting the

ﬂow of control. A set of data-ﬂow equations is then

evaluated in the context of each node. Each equation

takes the results computed at the immediate prede-

cessor nodes as input, applies a conﬂuence operator

(union or intersection) to combine these sets and ﬁ-

nally modiﬁes the values to reﬂect the effects of the

local node’s instructions. Effectively, this method

describes an equation system which propagates in-

formation throughout the underlying graph, thus en-

abling a context-sensitive evaluation of each instruc-

tion. If loops are present, ﬁxed-point evaluation se-

mantics are employed to approximate the runtime be-

havior of the program.

In (Saad and Bauer, 2013) we discussed an adap-

tion of this analysis technique to the modeling do-

main which we referred to as a generic “programming

language” for context-sensitive model analysis. This

approach deﬁnes a declarative speciﬁcation language

that allows to annotate data-ﬂow attributes at meta

model classes that can subsequently be instantiated

and evaluated for arbitrary models. This technique

has several signiﬁcant advantages: Data-ﬂow analy-

sis provides inherent support for the implementation

of recursive speciﬁcations which iteratively propagate

information throughout a model. Also, since informa-

tion is routed along model edges, each model element

can be evaluated in its overall context, thus eliminat-

ing the need for static navigational expressions which

are common in languages such as OCL. This is impor-

tant in the EAM domain where the structure of both

meta models and models is highly dynamic. Finally,

the usage of ﬁxed-point semantics allows to imple-

ment a correct handling of cyclic paths.

Using MAF, a reachability analysis for model ele-

ments can be speciﬁed in the following way:

1: analysis reachability analysis {

2: attribute is reachable : Boolean initWith false;

3: extend node with {

4: occurrenceOf is reachable calculateWith

5: self.incoming.source.is reachable()

6: ->includes(true);

7: }

8: extend startnode with {

9: occurrenceOf is reachable calculateWith true;

10: }

11: }

As described above, an element e1 is reachable

from another element e2, if there exists a path be-

tween e1 and e2. Here, we assume that the meta

model deﬁnes the classes node and startnode, the

latter one being a specialization of the former one.

We further classify changed elements in the model

as startnodes for the analysis. The reachability sta-

tus is computed by a data-ﬂow attribute is reachable

of type boolean which is initialized with the value

false (line 2). Lines 3-7 attach this attribute to all in-

stances of the node class. To determine the reacha-

bility status of a node, the data-ﬂow equation in lines

5-6 accesses the is reachable values computed at the

respective node’s predecessors, thereby directly im-

plementing the recursive speciﬁcation. Finally, lines

8-10 overwrite this equation at startnodes which are,

by deﬁnition, always reachable.

3.3 Context-aware Change Propagation

The execution of the reachability analysis in section

3.2 will result in an large result set, containing mostly

false positives regarding change impact. By enrich-

ing the rules with context-speciﬁc declarations, the

impact set can be restricted to contain only meaning-

ful data and to additionally reﬂect different types of

changes.

In the following, we will differentiate between the

change types extend, modify and delete as proposed

by (de Boer et al., 2005). Extensions refer to cases

where new issues are added but the initial function-

ality or structure remains the same. Consequently,

extensions do not propagate to depending elements.

By contrast, a modiﬁcation also affects the function-

ality or the structure and therefore it cannot be guaran-

teed that initially provided issues will still be available

Fourth International Symposium on Business Modeling and Software Design

or that their behavior remains unchanged. Finally,

deletion indicates that an element will be removed

from the enterprise architecture. The change types

are prioritized as follows: delete overrides modiﬁes

overrides extends overrides no change (NO). Depend-

ing on the respective requirements, additional change

types can be implemented.

Due to the lack of detailed information in enter-

prise architecture models, an accurate deﬁnition of the

impact of a change is not possible. We therefore pro-

pose to approximate the impact using a worst case and

a best case analysis similar to the practices in software

analysis. For the worst case, the impact is deﬁned as

the maximal set of affected elements, whereas the best

case includes only the minimal set. The real impact

typically lies somewhere between both cases.

To implement the context-dependent impact anal-

ysis, we deﬁne rules which are able to differentiate be-

tween the different change and relationship types. To

make the technique generically applicable, we intro-

duce custom relationship classes to which the speciﬁc

relationship types in the target EA language can be

mapped. The developed speciﬁcations can be divided

into two categories: In section 3.3.1 describe how the

propagation of effects is inﬂuenced by different rela-

tionship classes while section 3.3.2 introduces an ad-

ditional classiﬁcation along different effect types.

3.3.1 Change Propagation Rules Depending on

Relationship Classes

To classify the relationships of an enterprise architec-

ture, we grouped them according to their semantics,

which we identiﬁed through a literature review of ex-

isting EA frameworks and their meta models. This in-

cludes the Core Concepts Model (CC) of ArchiMate

(The Open Group, 2012) and the DM2 Conceptual

Data Model of DoDAF (U.S. Department of Defense,

2010).

Overall, we were able to identify ﬁve classes of

relevant EA relationship types: Locate denotes the al-

location to some location or organization unit. Any

kind of provision of functionality, information and be-

havior is of the type provide while the consume class

denotes the consumption of those elements. Struc-

tural dependency relationships deﬁne the structure or

organization of entities in one layer. The behavioral

dependency class on the other hand summarizes rela-

tionships which declare dependencies between the be-

havior of elements in a single layer which are neither

of the type provide nor consume. The following table

lists all classes along with corresponding examples

from the ArchiMate Core Concepts and the DoDAF

DM2.

Table 1: Classiﬁcation of EA relationships.

class examples

locate CC: assignment

DM2: is-at

provide CC: realize, assess

DM2: provide, performedby

consume CC: used by, access

DM2: consume

structural

dependency

CC: aggregate, composite

DM2: part-of

behavioral

dependency

CC: trigger, ﬂow to

Note that the mapping in table 1 is only a sugges-

tion based on our interpretation of the concepts and

has to be adapted if an organization assigns different

semantics to these types. It is also important to real-

ize that each relationship may belong to multiple cat-

egories. In the worst case analysis, the strongest rule

will be chosen while the best case analysis will use

the weakest one.

To formalize the change semantics of these

classes, we employ the following syntax:

A.X → B.Y (1)

This statement indicates that if element A is changed

in the manner X then element B has to be changed in

manner Y . A and B represent the source and the target

of the relationship while X, Y ∈ {modify, delete, ex-

tend}. It is also possible to cluster change operations

on the left hand side. A.{X, Y} → B.Z means that if

A is changed in the manner X or in the manner Y , B

has to be changed in the manner Z. Optionally, it is

possible to differentiate between a worst case (WC)

and a best case (BC) impact on the right hand side of

the rule.

We will now demonstrate this concept using the

location relationship. Assuming that an applica-

tion component (A) is hosted by a organization unit

(B), this connection is mapped to the class located

at. If a change to the application component has

no effect on the organization unit the rule will be

A.{del, mod, ext} → B.NO. If, on the other hand, the

organization unit is deleted, the application compo-

nent loses its host. In the worst case it needs to be

deleted as well while in the best case it will simply

be assigned to another host. This is formalized as:

B.del →WC : A.del, BC : A.ext. Finally, if the organi-

zation unit is modiﬁed or extended, the worst case de-

mands that the application component has to be mod-

iﬁed too while, in the best case, it remains as is. This

can be addressed with the rule: B.{ext, mod} → WC :

A.mod, BC : A.NO. Change rules for other relation-

ship classes are deﬁned in a similar manner as shown

in table 2.

Context-Sensitive Impact Analysis for Enterprise Architecture Management

Table 2: Impact rules for the relationship classes.

class rule

located at A.{del,mod,ext} → B.NO

B.del → WC: A.del BC: A.ext

B.{ext,mod} → WC: A.mod BC:

A.NO

provides A.del → WC: B.del BC: B.ext

A.mod → WC: B.mod BC: B.NO

A.ext → WC: B.ext BC: B.NO

B.{del,mod,ext} → A.NO

consumes A.{del,mod,ext} → B.NO

B.{del,mod} → WC: A.mod BC: A.ext

B.ext → A.NO

structurally

dependent

A.del → WC: B.del BC: B.mod

A.{mod,ext} → B.NO

B.{del,mod} → WC: A.mod BC:

A.NO

B.ext → WC: A.ext BC A.NO

behaviorally

dependent

A.{del,mod,ext} → B.NO

B.{del,mod,ext} → A.NO

3.3.2 Change Propagation Rules Depending on

Effect Types

In addition to the classiﬁcation along the lines of rela-

tionship types, a differentiation between different ef-

fect types can be useful as well. We therefore deﬁne

the following three effects: strong, weak and no effect.

The type of effect has to be speciﬁed for each direc-

tion of a relationship. The notation X − Y indicates

that a change in the source has a effect of type X on

the target and vice versa. Overall, this leads to six ef-

fect classes: Strong-Strong, Strong-Weak, Strong-No

effect, Weak-Weak, Weak-No effect and No effect-No

effect.

The semantics of these effects can be deﬁned us-

ing rules similar in nature to those presented in section

3.3.1. They are shown in table 3.

Table 3: Impact rules for the effect classes.

effect rule

strong A.del → WC: B.del, BC: B.ext

A.mod → B.mod

A.ext → B.ext

weak A.del → WC: B.mod, BC: B.no

A.mod → WC: B.mod,BC: B.ext

A.ext → WC: B.ext, BC: B.NO

no effect A.{del,mod,ext} → B.NO

If A strongly affects B, this indicates that if A is

deleted, in the worst case, B has to be deleted as well

and, in the best case, it only needs to be extended. A

modiﬁcation in A leads to a modiﬁcation of B and the

same applies to extensions. If, for example, an appli-

cation component realizes a service, then the appli-

cation component has a strong impact on the service

while the service may only have a weak impact on the

application component. This speciﬁc interpretation of

realize would result in an assignment to the Strong-

Weak class. A weak effect denotes that the deletion

of A conducts no change in B in the best case and a

modiﬁcation in the worst case. A modiﬁcation of A

in the worst case requires a modiﬁcation of B. In the

best case it has only to be extended. Finally if A is

extended, in the best case B must not be changed, in

the worst case it has to be extended, too. If the rela-

tionship is mapped to no effect, any change of A has

no effect on B.

Further examples for effect mappings of Archi-

Mate relationships are:

• Strong-Weak: realize

• Strong-No effect: aggregation

• Weak-No effect: use, assign

• Weak-Weak: triggers

3.3.3 Realization of the Rules

The rules deﬁned in sections 3.3.2 and 3.3.1 can be

realized as data-ﬂow equations. First, the meta model

and model data has to be converted to the generic rep-

resentation presented in section 3.1. Then, the status

of the changed elements whose impact should be ana-

lyzed is set to the respective value while the result for

all other elements is initialized with no change. After-

wards, these values will be iteratively recomputed to

propagate the effects of the changes. For illustration

purposes, we include a Java-based implementation of

the rule which calculates the best case result based on

the presented effect types:

1: Object node changestatus bestcase(Node currentNode){

2: for (Edge edge : currentNode.getIncomingEdges()){

3: Status sourceStatus = edge.source.getStatus()

4: Status currentStatus = currentNode.getStatus()

5: if (edge.effectClass == StrongEffectTarget)

6: if (sourceStatus == (DEL||EXT))

7: return computeStatus(currentStatus, EXT)

8: else if (sourceStatus == MOD)

9: return computeStatus(currentStatus, MOD)

10: if (edge.effectClass == WeakEffectTarget)

11: if (sourceStatus == (DEL||EXT))

12: return computeStatus(currentStatus, NO)

13: else if (sourceStatus == MOD)

14: return computeStatus(currentStatus, EXT)

15: if (edge.effectClass == NoEffectTarget)

16: if (sourceStatus == (DEL||MOD||EXT))

17: return computeStatus(currentStatus, NO)

18: }

19: for (Edge edge : currentNode.getOutgoingEdges()){

20: ...

21: }

22: }

Fourth International Symposium on Business Modeling and Software Design

The status of the current element (currentNode)

depends on the status of the connected elements as

well as the direction of the relationship. Therefore,

to correctly determine the change status, all incom-

ing (lines 2 - 18) and outgoing edges (lines 19 - 21)

have to be processed. The status value which has

been computed for a connected element is retrieved

through an invocation of getStatus() (line 3). This

call instructs the data-ﬂow solver to recursively com-

pute and return the requested value. Based on the type

of each incoming edge, it is then decided whether it

has a strong effect (line 5), a weak effect (10) or no

effect (15) on its target. The concrete type of the

change is determined by evaluating the status of the

edge’s source element (lines 6-9, 11-14, 16-17). Fi-

nally, computeStatus() is invoked to compute and re-

turn the status of the local element. To implement the

priorization relationships between the change types,

e.g. to ensure that a weak change like no change can-

not override a stronger one like delete, this method

takes both the current and the newly computed status

as input. A similar approach is used to calculate the

result for the source elements of outgoing edges (line

19-21).

3.4 Customization of the Impact

Analysis

In the case where the rules proposed in section 3.3

are not sufﬁcient to capture all requirements of the

organization, it is possible to customize the analysis.

For example, if a speciﬁc relationship type cannot be

mapped to one of the proposed classes, a new rule

can be created. In addition to evaluating relation-

ship types and change status of connected elements,

a rule may also consider the type of the connected

elements or class properties. It would also be possi-

ble to extend the rule deﬁnitions with the ability to

quantify a change (e.g. in terms of costs). These

features can be implemented through additional data-

ﬂow attributes. For example, to compute potential

savings on IT maintenance, the maintenance costs of

all deleted application and infrastructure components

and their corresponding services could be aggregated.

Another customization consists of a modiﬁcation

of the rule set to support change probabilities. Instead

of a single status, we can deﬁne four separate data-

ﬂow attributes, which compute the respective prob-

abilities for the types delete, modiﬁcation, extension

and no change. Additionally, the rule speciﬁcation

would have to be extended. For example, a rule could

be deﬁned as:

P(A.del) = X → P(B.del) = 0.8 × X (2)

This means that if the probability that A is deleted is

X, then the probability that B has to be deleted is 0.8×

X or, in other words, if A is deleted then in 80% of the

cases B will be deleted as well.

4 EVALUATION

Most of the research work regarding change impact

analysis has been carried out theoretically and thus

has not yet been applied to real architecture models

(e.g. (de Boer et al., 2005), (Kurpjuweit and Aier,

2009), (Kumar et al., 2008)). An exception exists in

the work of (Tang et al., 2007) who employ predic-

tive and diagnostic reasoning in BBN. However, one

disadvantage of their approach can be found in the

high effort required to annotate probability informa-

tion. The technique proposed in this paper simpli-

ﬁes analysis speciﬁcation through a generic represen-

tation of model data and through predeﬁned and ex-

tensible categorizations of relationships and effects.

Many existing approaches do not address prob-

lems relating to cyclic dependencies or contradicting

results, the latter one for example being a weakness

of the tooling proposed by (Lankhorst, 2012). Fur-

thermore, the issue of the scalability of the technique

which is based on pattern matching and model trans-

formations is not considered and the employed RML

technique is highly dependent on speciﬁc usage sce-

narios as well as on the respectively chosen EA lan-

guage. By utilizing the data-ﬂow analysis method

with its inherent support for cyclic dependencies, re-

cursive speciﬁcations and iterative result computa-

tion, we are able to address these challenges. The

scalability of DFA (and the Model Analysis Frame-

work in particular) has been demonstrated in the con-

text of other domains including the analysis of exten-

sive AUTOSAR models (Kienberger et al., 2014).

For a practical evaluation, we implemented the

proposed methods in the form of an addin for MID In-

novator (MID GmbH, 2014) using the MIDWagen ex-

ample which is shipped with the tooling. MIDWagen

describes the IT landscape of a car rental organization

with its actors, business services, business processes,

application components and services as well as the

required infrastructure components and services. Al-

though it is not a real world example, the level of de-

tail and the extensibility of the underlying EA lan-

guage enables a thorough evaluation of the viability

and the robustness of our technique.

To illustrate the application of our approach, we

focus on a modiﬁcation of the Booking System. We

assume that this component, which is responsible for

payment transactions, has to be modiﬁed due to secu-

Context-Sensitive Impact Analysis for Enterprise Architecture Management

rity issues. We further state that this change will only

affect the Payment service while the Bonus Booking

service does not have to be adapted. The modiﬁcation

of the Payment application service (AS) also causes

a change to the supporting Return service, which in

turn will affect the Payment business service (BS) as

well as the Renter role. Figure 2 shows the respective

excerpt from the MIDWagen model.

Figure 2: Excerpt of the ArchiMate model for the MID-

Wagen Use Case (MID GmbH, 2014) with the worst case

change propagation path.

For this scenario, we employ the relationship clas-

siﬁcation described in section 3.3.1. Since the model

is given in the ArchiMate language, we are able to use

the mappings listed in table 1.

In ﬁgure 2, the resulting worst case change prop-

agation path is indicated by red arcs. Solid lines rep-

resent paths along with a change is forwarded, while

dashed lines stand for relationships, which are con-

sidered but do not result in a change propagation. The

ﬁnal impact set consists of the elements {Payment

AS modiﬁed, Bonus Booking modiﬁed, Return mod-

iﬁed, Collect Bonus modiﬁed, Payment BS modiﬁed,

Renter modiﬁed}, while the ﬁnal result set for the best

case analysis is empty. Both results represent realistic

approximations which have to be interpreted consid-

ering the severity of the modiﬁcation. In the best case

scenario (e.g. performance issues), the modiﬁcation

of the Booking System does not affect the provided

functionality, and therefore the service does not need

to be changed. In the worst case, for example a sub-

stantial change in the functionality due to security is-

sues, the effects of the change propagate to the role

in the business layer which is potentially affected by

the modiﬁcation. Both impact sets represent approx-

imations, which can be of great value for estimating

the real effects of a change especially in early design

stages.

Carrying out the analysis using the effect classes,

the result consists of {Payment AS modiﬁed, Return

modiﬁed, Payment BS modiﬁed, Renter modiﬁed}.

This result, which lies in between the worst and the

best case of the relationship analysis, is able to pro-

vide more detailed information in the case where the

required data is available.

5 CONCLUSIONS

In this paper we proposed a context-sensitive impact

analysis technique for EA models. The approach re-

lies on two underlying concepts: The problem of di-

verse EA languages is addressed by a generic repre-

sentation of model data while the data-ﬂow analysis

method enables an intuitive speciﬁcation of analyses,

which depend on the iterative propagation of results.

We argued that a traditional reachability analysis

which returns all direct and indirect neighbors of an

element is not suitable in the EA context and there-

fore has to be extended with context-sensitive prop-

agation rules. For this purpose, we deﬁned a rela-

tionship classiﬁcation which reﬂects the semantics of

different edge types as well as the semantics of the

change types extend, modify and delete. By apply-

ing this concept, change effect propagation depends

both on the change type as well as on the meaning

of the relationships which connect the respective ele-

ments. For example, if an element which is still in use

is deleted, this change will affects consumers. If, on

the other hand, the element is extended, leaving the

existing functionality unchanged, the potential effect

is not propagated.

For a more focused analysis, we proposed two

different kinds of relationship classiﬁcations. Sec-

tion 3.3.1 categorizes relationships according to their

semantics with respect to the architecture by deﬁn-

ing the classes located at, provides, consumes, struc-

turally dependent and behaviorally dependent. In sec-

tion 3.3.2, the severity of a change on the respective

source and the target elements is considered by intro-

ducing the categories strong, weak and no effect. In

both cases we deﬁned propagation rules in the form of

DFA equations for best and worst case analysis. By

extending these deﬁnitions, it is possible to include

support for organization-speciﬁc semantics and addi-

tional relationship types. Executing the analysis us-

ing the DFA solver of the MAF framework yields the

results which can be interpreted as estimations that

reﬂect the best and worst case of the actual impact.

The combination of the generic model represen-

Fourth International Symposium on Business Modeling and Software Design

tations, extensible DFA-based analysis speciﬁcations

and the classiﬁcation approach for relationships en-

sures that this technique can be applied to the various

EA conventions found in different organizations. Fur-

ther work has to be done to determine a suitable visu-

alization of the results. It would also be interesting to

evaluate rules for other impact scenarios such as fail-

ure impact analysis which analyzes the availability of

architecture elements. Finally, it should be explored

how the computation of best and worst case results

could be improved through an integration of proba-

bility distributions. At the moment we only support a

simple and naive way for the integration of probabili-

ties.

ACKNOWLEDGEMENTS

This work was partially sponsered by the FuE-

Programm Informations- und Kommunikationstech-

nik Bayern. The authors would like to thank MID

GmbH for providing their demo use case, licenses for

their tool as well as for their support during the im-

plementation.

REFERENCES

Aryani, A., Peake, I., and Hamilton, M. (2010). Domain-

based change propagation analysis: An enterprise sys-

tem case study. In 2010 IEEE International Confer-

ence on Software Maintenance (ICSM), pages 1–9.

Bohner, S. (2002). Software change impacts-an evolving

perspective. In International Conference on Software

Maintenance, 2002. Proceedings, pages 263–272.

Briand, L., Labiche, Y., and O’Sullivan, L. (2003). Impact

analysis and change management of UML models. In

International Conference on Software Maintenance,

2003. ICSM 2003. Proceedings, pages 256–265.

Buckl, S., Ernst, A., Lankes, J., and Matthes, F. (2008).

Enterprise Architecture Management Pattern Catalog

(Version 1.0). Technical Report TB 0801, Technical

University Munich, Chair for Informatics 19.

de Boer, F., Bonsangue, M., Groenewegen, L., Stam, A.,

Stevens, S., and van der Torre, L. (2005). Change

impact analysis of enterprise architectures. In Infor-

mation Reuse and Integration, Conf, 2005. IRI -2005

IEEE International Conference on., pages 177 – 181.

Holschke, O., Nrman, P., Flores, W., Eriksson, E., and

Schnherr, M. (2009). Using enterprise architecture

models and bayesian belief networks for failure im-

pact analysis. In Service-Oriented ComputingICSOC

2008 Workshops, page 339350.

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

cost analysis of service-oriented enterprise architec-

tures. Global Implications of Modern Enterprise In-

formation Systems: Technologies and Applications,

IGI Global.

Kienberger, J., Minnerup, P., Kuntz, S., and Bauer, B.

(2014). Analysis and Validation of AUTOSAR Mod-

els.

Kumar, A., Raghavan, P., Ramanathan, J., and Ramnath, R.

(2008). Enterprise Interaction Ontology for Change

Impact Analysis of Complex Systems. In IEEE Asia-

Paciﬁc Services Computing Conference, 2008. AP-

SCC ’08, pages 303 –309.

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

Ansatz zur Ableitung von Abhngigkeitsanalysen auf

Unternehmensarchitekturmodellen. Wirtschaftinfor-

matik Proceedings 2009.

Lankhorst, M. (2012). Enterprise Architecture at Work.

Springer-Verlag Berlin and Heidelberg GmbH & Co.

KG, Berlin.

Lehnert, S. (2011). A review of software change impact

analysis. Ilmenau University of Technology, Tech.

Rep.

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

(2012). EAM KPI Catalog v 1.0. Technical report,

Technical University Munich.

MID GmbH (2014). MID Innovator for Enterprise Ar-

chitects. in: http://www.mid.de/produkte/innovator-

enterprise-modeling.html, accessed 15/04/2014.

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

prise architecture framework for multi-attribute infor-

mation systems analysis. Software & Systems Model-

ing, pages 1–32.

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

governance. Springer.

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).

Saat, J. (2010). Zeitbezogene Abh

angigkeitsanalysen

der Unternehmensarchitektur. Multikonferenz

Wirtschaftsinformatik 2010, page 29.

Tang, A., Nicholson, A., Jin, Y., and Han, J. (2007). Using

bayesian belief networks for change impact analysis in

architecture design. Journal of Systems and Software,

80(1):127148.

The Open Group (2012). ArchiMate 2.0 speciﬁcation: Open

Group Standard. Van Haren Publishing.

U.S. Department of Defense (2010). The DoDAF

Architecture Framework Version 2.02. in:

http://dodcio.defense.gov/dodaf20.aspx, accessed

15/03/2015.

von Knethen, A. and Grund, M. (2003). QuaTrace: a

tool environment for (semi-) automatic impact analy-

sis based on traces. In International Conference on

Software Maintenance, 2003. ICSM 2003. Proceed-

ings, pages 246–255.

Context-Sensitive Impact Analysis for Enterprise Architecture Management