Fakultät für Informatik

Der Technischen Universität München

Bachelor's Thesis in Informatik

Evaluating an open source EA

management tool

Stephan Köhler

Fakultät für Informatik

Der Technischen Universität München

Bachelor's Thesis in Informatik

Evaluierung eines Open Source EA

Management Werkzeugs

Evaluating an open source EA

management tool

Erstbetreuer: Prof. Dr. rer. nat. Florian Matthes

Zweitbetreuer: Dipl.-Inf. Sabine Buckl

Tag der Einreichung: 15.10.2010

Erklärung

Ich versichere, dass ich diese Bachelor's Thesis selbst ändig verfasst und nur

die angegebenen Quellen und Hilfsmittel verwendet habe.

I assure the single handed composition of this bachelor's thesis only supported

by declared resources.

München, den 01.September 2010

Stephan Köhler

3

Abstract

While modern enterprises have to deal with complex and historically grown

application landscapes, the demand for �exibility and responsiveness to organi-

zational change increases. A commonly accepted instrument to deal with this

challenge is enterprise architecture (EA) management. The EA management

function is typically supported by specialized tools, which support communi-

cation and collaborative work among the various stakeholders.

In the Enterprise Architecture Management Tool Survey 2008 (EAMTS2008)

nine commercial EA management tools have been analyzed and evaluated in

respect to their performance in speci�c functionalities and their ability to han-

dle typical EA management scenarios. The objective of this thesis is to analyze

and evaluate the functional range of an Open Source EA management tool (it-

eraplan) based on the functionalities and scenarios used in the EAMTS2008.

In order to ensure an up-to-date evaluation, the scenarios are revised with the

help of an industry partner.

I

Contents

List of Figures IV

List of Tables VI

1. Introduction 1

1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2. Introduction to the Enterprise Architecture Management Tool

Survey 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3. Decision for Open Source . . . . . . . . . . . . . . . . . . . . . . 3

1.4. Evaluation Method . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Enterprise Architecture Management 5

2.1. Introduction to EA Management . . . . . . . . . . . . . . . . . 5

2.2. Meta model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3. Scenarios of the Enterprise Architecture Management Tool Sur-

vey 2008 10

3.1. Scenarios for Analyzing speci�c Functionality . . . . . . . . . . 10

3.1.1. Importing, Editing, and Validating Model Data . . . . . 10

3.1.2. Creating Visualizations of the Application Landscape . . 11

3.1.3. Interacting with and Editing of Visualizations of the Ap-

plication Landscape . . . . . . . . . . . . . . . . . . . . . 12

3.1.4. Annotating Visualizations with Certain Aspects . . . . . 12

3.1.5. Supporting lightweight Access . . . . . . . . . . . . . . . 13

3.1.6. Editing Model Data using an external Editor . . . . . . . 14

3.1.7. Adapting the Meta Model . . . . . . . . . . . . . . . . . 14

3.1.8. Handling large scale Application Systems . . . . . . . . . 15

3.1.9. Supporting multiple Users and collaborative Work . . . . 15

3.2. Scenarios for Analyzing EA Management Support . . . . . . . . 16

3.2.1. Landscape Management . . . . . . . . . . . . . . . . . . 17

3.2.2. Demand Management . . . . . . . . . . . . . . . . . . . 18

II

Contents

3.2.3. Project Portfolio Management . . . . . . . . . . . . . . . 18

3.2.4. Synchronization Management . . . . . . . . . . . . . . . 19

3.2.5. Strategies and Goals Management . . . . . . . . . . . . . 19

3.2.6. Business Object Management . . . . . . . . . . . . . . . 20

3.2.7. Service Oriented Architecture Transformation . . . . . . 20

3.2.8. IT Architecture Management . . . . . . . . . . . . . . . 21

3.2.9. Infrastructure Management . . . . . . . . . . . . . . . . 22

3.3. Scenario Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 22

4. Iteraplan 23

4.1. Di�erence between Enterprise and Community Edition . . . . . 23

4.2. Evaluation for Speci�c Functionality . . . . . . . . . . . . . . . 25

4.2.1. Importing, Editing and Validating . . . . . . . . . . . . . 25

4.2.2. Creating Visualizations of the application landscape . . . 25

4.2.3. Interacting with, Editing of Visualizations . . . . . . . . 26

4.2.4. Annotating Visualizations with Certain Aspects . . . . . 31

4.2.5. Supporting lightweight Access . . . . . . . . . . . . . . . 31

4.2.6. Editing Model Data using an external Editor . . . . . . . 32

4.2.7. Adapting the Meta Model . . . . . . . . . . . . . . . . . 33

4.2.8. Handling large scale Application Landscapes . . . . . . . 34

4.2.9. Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3. Evaluation for EA Management Support . . . . . . . . . . . . . 36

4.3.1. Landscape Management . . . . . . . . . . . . . . . . . . 36

4.3.2. Demand Management . . . . . . . . . . . . . . . . . . . 37

4.3.3. Project Portfolio Management . . . . . . . . . . . . . . . 38

4.3.4. Synchronization Management . . . . . . . . . . . . . . . 38

4.3.5. Strategies and Goals Management . . . . . . . . . . . . . 39

4.3.6. Business Object Management . . . . . . . . . . . . . . . 39

4.3.7. SOA transformation . . . . . . . . . . . . . . . . . . . . 40

4.3.8. IT Architecture Management . . . . . . . . . . . . . . . 42

4.3.9. Infrastructure Management . . . . . . . . . . . . . . . . 42

4.4. Initiator data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5. Summary 45

Bibliography i

A. List of Criteria ii

III

List of Figures

2.1. Root classes of the meta model of SoCaStore (Source: [Ma08]) . 7

2.2. Metamodel of SoCaStore (Source: [Ma08]) . . . . . . . . . . . . 9

4.1. Feature Comparison between Community and Enterprise Edi-

tion, Source: [it10] . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.2. Importing, Editing and Validating: Extract of iteraplan Com-

munity Edition data scheme . . . . . . . . . . . . . . . . . . . . 26

4.3. Creating Visualizations of the application landscape: Landscape

diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.4. Creating Visualizations of the application landscape: Cluster

diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.5. Creating Visualizations of the application landscape: Master

Plan diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.6. Creating Visualizations of the application landscape: Project

Portfolio Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.7. Creating Visualizations of the application landscape: Legend . . 29

4.8. Interacting with, Editing of Visualizations: Adjusting the Port-

folio Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.9. Interacting with, Editing of Visualizations: Adjusting the Port-

folio Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.10. Annotating Visualizations with Certain Aspects: Color-coded

cluster map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.11. Annotating Visualizations with Certain Aspects: An Excel Report 32

4.12. Supporting lightweight Access: iteraplan welcome screen . . . . 32

4.13. Adapting the Meta Model: iteraplan meta model . . . . . . . . 33

4.14. Handling large scale Application Landscapes: Cluster map cre-

ation error with more than 50 elements . . . . . . . . . . . . . . 34

4.15. Handling large scale Application Landscapes: Searching speci�c

elements in the tool repository . . . . . . . . . . . . . . . . . . . 35

4.16. Usability: Consistency checks . . . . . . . . . . . . . . . . . . . 35

IV

List of Figures

4.17. Usability: Error when saving after another user edited an element 36

4.18. Landscape Management: Table to select the time the applica-

tion system was active . . . . . . . . . . . . . . . . . . . . . . . 37

4.19. Business Object Management: Creating a business object ex-

change relation . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.20. Business Object Management: Tabular report of business object

exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.21. Business Object Management: Exemplary Visualization of a

business object exchange . . . . . . . . . . . . . . . . . . . . . . 40

4.22. SOA Transformation: Tabular report showing the application

systems that will be changed within the next year . . . . . . . . 41

4.23. IT Architecture Management: Sample Cluster diagram showing

the architectural solutions and their application systems . . . . 42

4.24. Infrastructure Management: Tabular report of databases run-

ning out of support . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.25. Infrastructure Management: Cluster map showing the databases

that are running out of support . . . . . . . . . . . . . . . . . . 43

V

List of Tables

1.1. Analyzed EA Management Tools . . . . . . . . . . . . . . . . . 2

5.1. Summary of the Evaluation Results . . . . . . . . . . . . . . . . 45

A.1. List of Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

VI

1. Introduction

1.1. Motivation

Until the 1990s information technology (IT) was typically seen as a support

function for business [Ca03], but in the last decades the complexity in IT

started to grow due to e�ciency bene�ts for the companies. Today IT is often

seen as an enabler to realize new strategies and processes into practice but it

may also appear as a barrier in the realization of opportunities. Therefore,

the argument that IT and business have to be managed as a whole gained

popularity [Ca03].

An increasing number of application systems in the application landscape of

an enterprise and the numerousness amount of interdependencies between IT

and business increase the di�culty of the EA management process. To coun-

teract these e�ects tool support is needed. There is a remarkable variety of

EA management tools which is caused by the fact that many tool vendors are

originated in di�erent areas or by di�erent opinions what EA management is

and what is included into EA management. Each approach has its individual

strengths and weaknesses.

This thesis builds on the scenario set which was released in the Enterprise

Architecture Management Tool Survey 2008 (EAMTS 2008) [Ma08]. This set

is based on the experience which was gathered by the sebis chair during three

workshops in cooperation with di�erent partners and sponsors [Ma08]. sebis is

the chair for Software Engineering for business information systems at the In-

stitute for Informatics of the Technische Universität München. The scenarios

can therefore be seen as a best practice approach for various parts of Enterprise

Architecture (EA) management. However the study only focuses on commer-

cial tools but since some years there are di�erent open source solutions for EA

1

1. Introduction

management available, e.g. iteraplan and Essential Project1. The objective

of this thesis is to extend the survey's range of evaluated tools by analyzing

iteraplan according to the scenarios of the EAMTS 2008.

1.2. Introduction to the Enterprise Architecture

Management Tool Survey 2008

The sebis chair released their EAMTS 2008 as a successor to their survey in

2005.

In their survey from 2008 they evaluated nine commercial EAMTS 2008 (see

Table 1.1) for their behavior in several scenarios.

Those scenarios where split in two groups. One group evaluates speci�c func-

tionalities of the tools while the other one aims for typical EA management

tasks. All of the scenarios where designed with the help of industry part-

ners [Ma08]. The di�erent scenarios will get introduced in chapter 3. Those

scenarios are shortened to �t into the context of this thesis.

No Name of Vendor Name of Tool(s) Version

1 Adaptive Adaptive EAM 5.0

2 alfabet AG planningIT 3.1

3 BOC ADOit 3.0

4 Embarcadero EA/Studio 1.1

5 IDS Scheer AG ARIS IT Architect 7.0.2

6 MEGA International SA MEGA Modeling Suite 2007 2007

7 Metastorm ProVision 6.0

8 Telelogic AB Telelogic System Architect 11.0

9 Troux Technologies Inc. Troux 7.0

Table 1.1.: Analyzed EA Management Tools (Source: [Ma08])

1http://www.enterprise-architecture.org/

2

1. Introduction

1.3. Decision for Open Source

Open source software can be de�ned as software that is made available freely

to all [Hi03]. However, open source development models, which produce open

source software, are de�ned as a process for software developers who "volun-

tarily collaborate to develop software that they or their organizations need"

[Hi03], page 209. Therefore open source software can be seen as "an environ-

ment in which the software source code is available for inspection, analysis,

and programming enhancements through a communal e�ort" [El09], page 4.

With this in mind and seeing that open source software has been o�ered for

more than twenty years now and that they represent an alternative to product

platforms that are restrained by proprietary claims [El09] we can now say that

open source software is a way to easily distribute a piece of software and to

get helpful response from the users and the community.

Due to the free distribution of open source projects many companies tend to use

open source software to introduce new tools. Those tools are preferred because

of the free-to-use policy and the possibility to implement needed changes into

the tool by the �rm. However, these changes have to be made public again

and there is no customer support from the developer's side. If the tool use

has grown in the company and the need for more or other functionality has

arisen, they tend to switch the open source tool with a commercial alternative.

The Enterprise Architecture Management Tool Survey currently only evaluates

commercial EA tools and doesn't consider open source tools. Seeing that there

are di�erent open source alternatives like iteraplan or The Essential Project,

the idea to use the scenarios of the survey for an evaluation of these tools

has come up. Therefor we will evaluate the open source tool iteraplan in this

thesis.

1.4. Evaluation Method

Although based on the EAMTS 2008 the results of this thesis are not compa-

rable to those in the survey anymore. This can one the one hand be subscribed

to the fact that the tools evaluated in the EAMTS 2008 have advanced since

the conduction of the survey in 2008. On the other hand the commercial tools

mostly have been on the market for a longer time.

3

1. Introduction

The results of the EAMTS 2008 have been illustrated in Kiviat diagrams to

show the di�erent aspects of the tool's performance and to make the results

comparable to each other. This ability to compare the results is not given in

this thesis as we here only focus on one tool. Anyway to give you a fast overview

of the evaluation result on a speci�c scenario we are using the metaphor of

thumbs. Thumbs up means that the tool performed good in the scenario.

Thumbs middle states a result that the tool didn't ful�ll all aspects of the

scenario. Last but not least thumbs down states that the tool didn't achieve

any of the scenario's objectives.

4

2. Enterprise Architecture

Management

2.1. Introduction to EA Management

De�ning enterprise architecture management is not an easy task as although it

has gained importance in research and practive during the last years no general

de�nition of the term exists. Therefore this thesis uses the de�nition of EA

management as introduced in the EAMTS 2008. This decision is reasoned due

to the fact that we still want a common evaluation basis for the tools evaluated

in the EAMTS 2008 and the tool iteraplan in this thesis.

"Enterprise architecture management is a continuous and itera-

tive process controlling and improving the existing and planned IT

support for an organization. The process not only considers the

information technology (IT) of the enterprise, also business pro-

cesses, business goals, strategies etc. are considered in order to

build a holistic and integrated view on the enterprise.

Goal is a common vision regarding the status quo of business and

IT as well as of opportunities and problems arising from these �elds,

user as a basis for a continually aligned steering of IT and business."

[Ma08], page 24

To o�er a communication basis for all stakeholders that are involved in the

management process, a common understanding of the Enterprise Architecture

(EA) is necessary. A de�nition of EA with a focal point on principles, methods,

and models is provided by Lankhorst [La05]: "Enterprise Architecture (EA) is

a coherent whole of principles, methods, and models that are used in the design

and realization of an enterprise organizational structure, business processes,

information systems, and infrastructure." [La05] In order to emphasize the

planning aspects of the process aligning business and IT, we also focus on

5

2. Enterprise Architecture Management

the dynamic aspects of EA management, as described in the de�nition stated

above.

EA management can therefore be seen as the way of managing and planning

the evolution of the EA. Hence the business strategy should be the driver and

adjuster of EA management, but also IT should play the role of an enabler

for business strategies and goals. This leads to the conclusion that "one of the

main e�orts of EA management is the alignment of business and IT." [Ma08]

Achieving this needs a common vision, alignment, and standardization not

only at the level of strategies but also regarding all activities governed by them:

"Typically, strategy is the only discipline that is cultivated at the enterprise

level. Strategy generates direction for the other disciplines, but then these are

executed at the project level, leading to both duplication of e�ort and a lack

of overall coherence. Now planning and implementation functions are being

extended across the enterprise as well, including IT. EA provides the means

to apply basic business disciplines within the IT organization. It must align

enterprise activities and priorities with business strategy." [ME02]

2.2. Meta model

Understanding of the EA and of concepts contained therein is necessary to

implement a tool support for EA. Therefore data is modeled conforming to a

meta model. Another name for a enterprise-wide meta model is information

model. The information model is de�ned as follows in the EAMTS 2008:

"A information model is a model, which models the relationships

and attributes of information objects using the concept of infor-

mation classes and associations between information classes. An

information object is an abstraction of a real existing object (e.g.

"Accounting:Business Process", "BMW 318i:Product", "Account-

ing System:Application System") aggregating the relevant infor-

mation." [Ma08], page 33

A meta model for EA management includes the relevant information classes,

their attributes, the associations between them, and an additional glossary

collecting specialized terms and their meanings.

6

2. Enterprise Architecture Management

EA frameworks like Zachman [Za08], TOGAF [Th08] are giving proposals for

organizing an enterprise architecture, establishing an EA management pro-

cess, and connecting the artifacts into one framework. However an integrated

meta model that is suitable for the evaluation in this thesis is not available.

Therefore this thesis will focus on the meta model introduced in the Enterprise

Architecture Management Tool Survey 2008 [Ma08] addressing the concerns

of the scenarios, which

� integrates the layers and cross functions into one model,

� is built on a modular basis, and

� distinguishes between optional and mandatory information.

The typical EA management tasks as introduced in Section 3.2 are re�ected

in the metamodel.

2.1 shows the common attributes shared among all classes as they are used in

the meta model. The core class InformationObject is holding the attribute id, a

mandatory attribute holding a globally unique identi�er of the corresponding

object. NamedObject is regarded as the common superclass for most of the

classes contained in the metamodel, such that these classes have a mandatory

name attribute containing the name of the object, e.g. "Headquarter", and

a description attribute holding optional description of the corresponding

object.

Figure 2.1.: Root classes of the meta model of SoCaStore (Source: [Ma08])

7

2. Enterprise Architecture Management

Figure 4.13 shows the metamodel that is used in simulating the scenarios in

this thesis. If not stated otherwise all classes contained in the �gure are sub-

classes of NamedObject. The classes, attributes, and associations are explained

in [Ma08].

8

2. Enterprise Architecture Management

Figure 2.2.: Metamodel of SoCaStore (Source: [Ma08])

9

3. Scenarios of the Enterprise

Architecture Management Tool

Survey 2008

This chapter describes the scenarios used for evaluating the tool iteraplan. The

scenarios are taken from the EAMTS 2008 [Ma08] and only shortly introduced

here.

3.1. Scenarios for Analyzing speci�c

Functionality

The scenarios introduced in the following sections are used to evaluate the

tool's skills regarding speci�c functionality. Those functionalities are not con-

nected to speci�c EA management tasks, but contribute to these tasks. For

better understanding of the scenarios we introduce the department store So-

CaStore [Ma08], which wants to introduce a tool support for EA management.

Every scenario will be explained in an exemplary story of that store.

3.1.1. Importing, Editing, and Validating Model Data

In companies this scenario can be seen as the main entry point for tool sup-

ported EA management. Data that has already been gathered in a spreadsheet

tool or any other database has to be imported into the EA management tool.

For simulation of this scenario the information about the EA is assumed to be

contained in various Microsoft Excel Spreadsheets. The following concerns are

addressed in this scenario:

10

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

"The department store SoCaStore wants to introduce a tool sup-

port for EA Management. Therefore, data previously gathered in

Microsoft Excel has to be imported to the repository of the tool.

The information model of the data imported is considered su�cient

for EA management in SoCaStore, such that the tool is demanded

to support this model or to be adaptable to it. In the importing pro-

cess the consistency of the data in respect to the information model

should be validated. Therein, especially the mandatory attributes

or relationships shall be considered. Data previously not main-

tained in the spreadsheet should additionally be added." [Ma08],

page 40

The ability to create reports on missing data or attributes or relationships

is also important. Another point is the possibility to edit the imported data

before saving. Also of importance is the ability to link external documentation,

e.g. present documents in Microsoft Word, to speci�c information objects in

the tool.

3.1.2. Creating Visualizations of the Application

Landscape

This scenario evaluates whether the tool supports the preparation of data into

visualizations thereof. This contains automatic creation of di�erent types of

visualizations. The concerns of this scenario are:

"The department store SoCaStore wants to get an overview of its

application landscape and its EA. This should be accomplished by

the creation of six di�erent visualizations for di�erent aspects of the

application landscape - the �rst four of them covering the software

maps [...]: a cluster map, a process support map, a time interval

map, and a graphlayout map as well as a swim lane diagram and

a portfolio matrix." [Ma08], page 41

Another aspect of this scenario is the automation of creating these visual-

izations and how �exible the tool provides them, e.g. does the tool support

representation of services instead of application systems.

11

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

3.1.3. Interacting with and Editing of Visualizations of

the Application Landscape

In this scenario the tool's support for manual adaptations in the previously

generated visualizations is evaluated. This includes if the tool is capable of

maintaining these adaptations during an automated (re-)generation of the vi-

sualizations. The possibility to apply �lters and highlight speci�c objects in a

visualization is also considered. The concerns of this scenario are described as

follows:

"In using the visualizations of the application landscape the users

from SoCaStore want to perform adaptations on the visualizations,

such as moving or resizing symbols. Additionally, for presentation

reasons speci�c objects in the visualization should be �ltered or

highlighted. Furthermore, the team of SoCaStore wants to execute

minor changes in the information about the application landscape

via adaptations to the visualizations, using the tool for graphical

modeling of the application landscape. Additionally, reports pre-

viously generated should be adapted, e.g. by applying �ltering,

sorting, or grouping." [Ma08], page 44

Also of interest in this scenario is the tool's support for navigation through

the models, e.g. the possibility to jump to a closely related object.

3.1.4. Annotating Visualizations with Certain Aspects

This scenario covers the possibility to add certain aspects, like operating costs

of application systems, to basic visualizations in order to characterize elements

of the application landscape. The most preferred way to accomplish this is to

extend already generated visualizations. Color-coding applications or adding

speci�c symbols, e.g. a tra�c lights symbol, can be used to achieve this goal.

The concerns of this scenario are:

"The department store SoCaStore wants to get an overview of the

application systems that raise high maintenance costs. This in-

formation should be visualized additionally on an already existing

visualization of the application landscape. As an additional prop-

erty of the application systems, availability should be visualized on

12

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

a similar map. Finally the process support of SoCaStore should

be analyzed regarding the usage of standard applications." [Ma08],

page 46

The main point of this scenario therefore is generating all or at least a subset of

the following �gures, which includes a cluster map with di�erent annotations

like maintenance costs via background color and availability via tra�c lights.

Also a process support map with indication of standard applications should

be generated. Another aspect is the possibility to create a tabular report that

shows the speci�c aspects of the application system.

3.1.5. Supporting lightweight Access

In this scenario the tool's capabilities concerning the methods for providing

lightweight access to the tool's data is evaluated. This contains the two aspects

of lightweight access (read-only and editing). The preferable access channel is

considered to be web access. The scenario addresses the following concerns:

"In order to promote the enterprise architecture e�ort and to in-

crease the awareness for EAM among the employees, the informa-

tion and visualizations gathered in the tool should be made accessi-

ble via a lightweight client, preferably a web client. Beside facilities

for publishing existing visualizations, this calls for the possibilities

to make these visualizations easy to use, hiding most of the features

available to the modeler. The visualizations and informations in

the web client should preferably be based on live data or should be

created by a scheduled batch export. Furthermore, visualizations

should be assigned unique identi�ers by the tool, providing a way

for creating a permalink 2 to the speci�c visualization.

Additionally, the department store wants to distribute the e�ort of

keeping data in the repository up-to-date to a broader group in the

enterprise. Therefore, a web client enabling the user to change a

2"The concept permalink originates from the �eld of blogging, where it represents a URL,which is associated unchangingly with a speci�c version of a speci�c element. Changesto this element are not re�ected in the version available at the URL, but are publishedunder a di�erent URL." [Ma08], page 48

13

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

subset of data, e.g. data about certain application systems, should

be provided by the tool." [Ma08], page 48

With the possibility of using a lightweight client comes the necessity for lim-

itation of access to certain visualizations and information for speci�c users.

Other aspects, that have already been mentioned before, e.g. the possibility

to hide/show layers in the visualization, are of interest again for the lightweight

client.

3.1.6. Editing Model Data using an external Editor

Instead of using the tool's built-in manipulation capabilities this scenario cov-

ers the possibility to use o�ce software, like Microsoft Excel, for editing EA

management data. If the tool doesn't have a strong support for batch editing

of the data this features is even more important. The concerns of this scenario

are as follows:

"Besides utilizing the tool's built-in facilities for manipulating the

data, a user involved with EA management in SoCaStore wants to

perform changes on the data about the application landscape o�ine

- preferably using o�ce software, as Microsoft Excel. After having

performed changes on the o�ine data, the information should be

synchronized with the data governed by the tool and a con�ict

resolution should be supported." [Ma08], page 49

3.1.7. Adapting the Meta Model

This scenario is concerned with the possibility to adapt the meta model of the

EA management tool even after data con�rming to the current meta model

has been imported. This scenario addresses the following concerns:

"The SoCaStore department store introduces new concepts to the

information model for EA management. These concepts should be

supported by the tool, such that adaptations of the information

model contained should be performed." [Ma08], page 49

This means that the tool's capabilities to edit the meta model in aspects like

the used classes, attributes and relationships is important in this scenario.

14

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

Another interesting aspect is if there is a way to export the meta model or

have a visualization of the current meta model with all its classes, attributes

and relationships.

3.1.8. Handling large scale Application Systems

In this scenario the tool's performance in handling large scale application land-

scapes containing a large amount of application systems and interconnections

between them is being evaluated. Aspects as the general performance as well

as a convenient tool use are considered, meaning a smart support for picking

an element from a list of several hundred entries. The concerns of this scenario

are as follows:

"SoCaStore wants to ensure that the EA management tool can

handle the application landscape, even if an extensive growth in

size and modeling granularity takes place. Therefore, exemplary

data about application systems should be imported into the tool

and visualized in exemplary visualizations." [Ma08], page 50

Most interesting in this scenario is the tool's response times in handling (not in

importing) the big amount of data. The duration times are only stated as live,

co�ee break, and overnight to give an impression of the tool's capabilities to

handle large scale application landscapes. The tool is tested to create a cluster

map and other aggregated visualization and if convenient editing mechanisms

are available.

3.1.9. Supporting multiple Users and collaborative Work

Concerning methods for providing multiple users and collaborative work this

scenario evaluates aspects like e.g. role or user based access controls on the

information. The di�erent levels of granularity to con�gure the access control

such as on model-level, entity-level, and attribute-level are of interest. An-

other aspect are the di�erent kinds of access rights that can be granted. Also

the tool's capabilities to support noti�cations service to identify aged data or

changes as well as work�ow management are evaluated in this scenario. This

scenario addresses the following concerns:

15

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

"By establishing a user management within the EA management

tool the department store SoCaStore wants to ensure that the ac-

cess to information and visualizations can be enabled according

to the position of a certain user and that modi�cations on data

or visualizations can be tracked to save audit trails. Besides, the

members of SoCaStore department store, as e.g. the application

owners would like to get noti�cations if certain information or vi-

sualizations are modi�ed. In addition the SoCaStore department

store wants to ensure that certain process steps within a work�ow,

as.e.g.an approval, are executed by prede�ned users before the next

step can be accomplished." [Ma08], page 52

The tool should allow multiple users and provide functionality to limit the

rights of them. Also metadata (e.g. last modi�cation date, last modifying

user) should be saved for information in the tool. Another aspect of this

scenario is the possibility to implement a work�ow management into the tool.

Meaning the possibility that demands have to be reviewed by an IT strategist

before being transformed to a project.

3.2. Scenarios for Analyzing EA Management

Support

Similar to the evaluation of speci�c functionality the next sections will describe

the scenarios used to evaluate EA management support provided by the tool.

The application landscape of the enterprise is a core artifact in the following

scenarios.

Di�erent versions of the application landscape have to be considered. First

the current landscape represents the status quo of the landscape. Next the

planned landscape describes a state of the landscape in the future at a speci�c

time and is mostly in�uenced by current projects. The last - long term per-

spective - of an application landscape is called target landscape, representing

the architecture of the landscape as envisioned at a certain time.This version

is representing the strategy of the business.

Di�erent variants of the planned and target landscapes can exist and should

be modeled in the tool as well. Projects transforming the current or planned

16

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

landscape into the target landscape do not have to be designed. In addition the

target landscape refers to envisioned application systems and does not specify

deployed application systems.

3.2.1. Landscape Management

In this scenario the tool's performance in planning and controlling the evolution

of the application landscape is evaluated. The concerns of this scenario are:

"Information about the application landscape should be stored in

the tool. Starting with the information about the current land-

scape potential development variants should be modeled. The

information about the current application landscape and future

states should be historicized in the tool to enable comparisons.

Chosen versions of the application landscape, e.g. current, planned,

and target landscapes should be analyzed and compared using dif-

ferent visualizations." [Ma08], page 55

The scenario emphasizes the three di�erent dimensions as known in landscape

management:

The �rst two dimensions relate to temporal aspects. The �rst dimension con-

veys when the planned landscape is predicted to be the current one. The

current and target landscapes don't rely on this dimension as the current

landscape is only up to date on a speci�c date and the target landscape is

scheduled for the futures. The second dimension indicates when the planning

took place. The ability to model di�erent landscape variants for the same

speci�c date in the future is shown in the third dimension.

The di�erent states of the landscape should be created in this scenario. The

planned and target landscape ought to show the di�erences to the current

landscape and what reasons have lead to those di�erences.

17

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

3.2.2. Demand Management

The management process concerned with gathering and documenting the de-

mands originating from business and IT are concerned in this scenario. In

doing so one or more demands may result in one or more IT projects.

The process involves demands and linking them to the a�ected elements of

the EA. The combination into one project proposal for di�erent demands,

which require a similar functionality or are related to the same application

system should be supported. The scenario addresses the following concerns:

"The IT department of the SoCaStore department store has re-

ceived numerous demands, which must be documented and linked

to the a�ected elements of the EA. To prepare the project portfo-

lio management a subset of the given demands has to be selected.

These demands must subsequently be transformed into project pro-

posals, combining demands asking for similar functionality or af-

fecting the same application systems." [Ma08], page 58

The demands that have been received should be compiled into a report also

showing the associated information.

3.2.3. Project Portfolio Management

In this scenario documenting project proposals and linking them with the

a�ected elements of the EA is simulated. In this process several measures like

project costs, economic impact, etc. have to be documented. After di�erent

kinds of analysis have been performed on the portfolio, a project to be realized

should be selected. The concerns of this scenario are:

"The IT department of the SoCaStore department store has re-

ceived numerous project proposals. In consideration of the pro-

cesses, organizational units, and application systems a�ected by

the project proposals, a selection of the project proposals should

be made. The available budget for projects is 5 million EUR."

[Ma08], page 59

18

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

The tool should show possible con�icts between project proposals in a report.

Also the a�ected business processes, organizational units, and business sup-

ports should be visualized (e.g. in a tabular report). The strategic impact

shall be delivered in a portfolio matrix.

3.2.4. Synchronization Management

The synchronization of projects is addressed in this scenario. Corresponding

to their interdependencies derived from the objects (e.g. application systems,

services) a given project is likely to change. Two projects modifying the same

application system at the same time thus exert a con�ict that is worth avoiding.

The scenario addresses the following concerns:

"To support the management of ongoing projects and to plan fu-

ture projects, there has to be the possibility to model and manage

project interdependencies or to derive them from the a�ected ele-

ments of the EA.

It should be possible to analyze the project timeline using Gantt-

like diagrams. This timeline shall than be updated and annotated

to re�ect delays of a single project as well as to identify projects,

that depend on it and might also be delayed." [Ma08], page 62

A deliverable should be created that shows, which organizational units are

a�ected by which projects.

There shall also be a deliverable displaying the projects that are a�ected by a

delay of another one.

3.2.5. Strategies and Goals Management

This scenario evaluates whether the tool supports transferring a strategy

through the organizational hierarchy by decomposing it into smaller and more

detailed pieces. This also implies the tracing back in the process, giving the

possibility to trace from a speci�c item on a �ne grained level to the strategy

it has been derived from.

"As part of the implementation of a balanced scorecard at the

SoCaStore department store the customer perspective is considered.

19

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

The strategies and goals lead to di�erent projects and changes in

the EA. These changes should be traceable to the previously de�ned

strategies and goals." [Ma08], page 66

The tool should retrieve which strategies lead to which goals and if those goals

have been reached. Another aspect is which organizational units reached their

goals. As well as which projects and demands support which goals.

3.2.6. Business Object Management

The tools capabilities to model business objects as well as the operations per-

formed on them and the exchange of the business objects between the applica-

tion systems are evaluated in this scenario. The concerns of this scenario are

described as follows:

"The department store SoCaStore wants to get an overview of the

business objects involved and exchanged in the execution of the

business processes. Therein, especially the data �ow between the

application systems performing operations on the business objects

should be modeled and the kind of operation performed in a speci�c

application system should be detailed. Furthermore, the technical

realizations of the data �ows should be taken into consideration,

as should exchange steps between application systems, where ad-

ditional manual operations have to take place." [Ma08], page 68

The tool should create some sort of visualization of the information �ows

between application systems.

3.2.7. Service Oriented Architecture Transformation

The tools performance in transforming an architecture into a Service Oriented

Architecture (SOA) is simulated in this scenario. The scenario addresses the

following concerns:

"The department store SoCaStore wants to transform its architec-

ture into a service oriented one. Thereby, a top-down as well as

a bottom-up approach for the identi�cation of possible candidates

20

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

for reusable services will be used. The top-down approach identi-

�es services according to the usage of business objects within the

conduction of di�erent business processes, whereas the bottom-up

approach identi�es technical functionalities currently provided by

applications, which should be transformed into reusable services to

demonstrate the bene�t. Besides the identi�cation of applicable

candidates, the e�ects the transformation will have on the applica-

tion landscape should be modeled and service level agreements for

the individual services must be de�ned." [Ma08], pages 69-70

The tool should inform the user if a application system changes frequently

and which application systems will be a�ected by a change in the near future.

Also the operations performed on business objects and the frequency of these

operations should be shown. Another point is to inform which application

systems are changed during the transformation to a SOA.

3.2.8. IT Architecture Management

This scenario is used to evaluate the tool's capabilities to deal with the intro-

duction of architectural standards, that future application systems should be

based on and current application systems should be adapted to. The concerns

of this scenario are described as follows:

"SoCaStore regards its heterogeneous application landscape as a

problem. The high number of technologies used in di�erent archi-

tectures calls for a high number of experts. A homogenization may

reduce operating costs, e.g. by consolidation of used software li-

censes, and maintenance expenses, e.g. by reducing administrative

e�orts." [Ma08], page 72

The tool should generate a cluster map showing which application system is

compliant with an architectural solution e.g. by color-coding the elements.

Also a report should be delivered showing the relationship between the appli-

cation systems and the architectural solutions they are based on.

Another deliverable is a report showing the number of usage of di�erent archi-

tectural solutions in the di�erent domains of SoCaStore.

21

3. Scenarios of the Enterprise Architecture Management Tool Survey 2008

3.2.9. Infrastructure Management

The issues of the IT infrastructure are dealt with in this scenario. Database

and middleware systems are contained in the infrastructure, though it is not

limited to them.

"The department store SoCaStore intends to consolidate its

database systems to decrease the costs for maintenance and li-

censes. Also, expected support periods o�ered by the database

vendors should be considered." [Ma08], page 75

The EAM tool should create a report showing the use of databases by the

application systems as well as a visualization thereof. There should also be the

possibility to show databases that run out of support before January 2012.

3.3. Scenario Simulation

The tool is tested for its performance in the di�erent scenarios stated above.

Important parts are the achievement of objectives (i.e. if all deliverables have

been possible to be created), tool handling (i.e. what lead to a high e�ort in

producing the deliverables), procedure consistency (i.e. does the methodology

of the tool correspond to the deliverables or do you need to misuse some

models to simulate a scenario), and procedure integration (i.e. are the activities

and objectives integrated to other relevant activities and objectives of EA

management and other simulated scenarios). The achievement of the tool will

be shown with a simple thumbs icon.

22

4. Iteraplan

This thesis focuses on the evaluation of the open source edition (called Com-

munity Edition) of the EA management tool iteraplan released by iteracec

GmbH. They are also o�ering a closed source alternative, the so called En-

terprise Edition, which is not in focus here. We will only discuss the main

di�erences between those two releases in the next bullet.

4.1. Di�erence between Enterprise and

Community Edition

The two versions are using the same main code base but the Community

Edition has restrictions to some functionality. An overview of the di�erent

functionality is given in Figure 4.1.

Figure 4.1.: Feature Comparison between Community and Enterprise Edition,Source: [it10]

23

4. Iteraplan

The main di�erences and limitations are that the "Data import interface" is

not accessible in the Community Edition. That means that you do not have

any possibility to import existing data out of Excel sheets or any other data

source. This leads to a huge barrier when introducing the tool especially if you

are already doing EA management based on e.g. Microsoft Excel sheets.

The next important feature that is missing in the Community Edition is "ex-

tensive rights and role concepts to support di�erent views on the model", as

shown in 4.1, meaning that you only have one standard user (called "Commu-

nityUser") to work with the tool. You are therefore not able to create further

user and/or limit access for anyone leading to a limited ability to collabora-

tively work with the tool in the company.

Another key feature that is only enabled in the Enterprise Edition is the pos-

sibility to easily update the tool to newer releases. In the open source version

you are not able to use the migration scripts from iteratec to transfer your

data. Thus leading to high maintenance expenditures once a new version of

the tool is planned to be used. Though when updating to the Enterprise Edi-

tion you are given the possibility to migrate all your data.

Of minor importance are the limitations for working with other databases

as HSQLDB or the missing LDAP Interface. They might be of interest for

some �rms but are not key features.

With the Enterprise Edition you also have the possibility to access support

o�ered by iteratec which may help you gain knowledge in working with their

tool and decrease the learning curve.

24

4. Iteraplan

4.2. Evaluation for Speci�c Functionality

This section describes the results of the scenario simulation for speci�c func-

tionality.

4.2.1. Importing, Editing and Validating

The import feature of iteraplan is - as already men-

tioned above - not active in the Community Edition.

That means that already existing data in Excel sheets

(like the SoCaStore data) or any other format can-

not be imported with the built-in functionality of the

tool.

As iteraplan is an open source tool you can still write your own functionality

for importing data from external sheets. The tool stores its data in a HSQLDB

database which can be accessed with common database tools. This process of

writing your own import functionality has got a high learning curve as you

have to understand the scheme and how iteraplan works with that informa-

tion. Also when iteratec releases an update for the HSQLDB interface (e.g.

a new standard database) the information could get lost and further e�ort is

necessary to work with the tool.

4.2.2. Creating Visualizations of the application

landscape

In iteraplan every visualization is generated automat-

ically by the tool. After selecting which kind of dia-

gram you want to create and which elements should

be visualized, you can adjust some attributes for the

visualization. The tool supports various visualization

types such as a landscape (see Figure 4.3), a cluster (see Figure 4.4), a portfolio

(see Figure 4.6), and a masterplan (see Figure 4.5) diagram. Thus iteraplan

does not support the creation of swim lane diagrams.

25

4. Iteraplan

Figure 4.2.: Importing, Editing and Validating: Extract of iteraplan Commu-nity Edition data scheme

The output format for the diagrams can be chosen by the user. Most diagrams

o�er you the possibility to create a JPEG, PNG, PDF, SVG, or a Visio �le.

However when creating a cluster diagram you are not able to choose Visio as

an output format. Once created the visualizations are not linked to the tool's

database, hence changes in the visualization will not lead to changes in the

tool's repository. However the settings for creating a visualization are saved

and can easily run again after changes have been made.

The names of the di�erent elements are mostly shown in a short abbreviation

in the diagrams. The tool will then generate a legend (see Figure 4.7) to link

the abbreviations with the full element's name.

4.2.3. Interacting with, Editing of Visualizations

The diagrams created with iteraplan can be adjusted

in several aspects to show di�erent objects of interest,

e.g. the project portfolio matrix can also be changed

to create a product portfolio matrix etc. (see Figure

4.8). The di�erent visualizations can further be ad-

justed in naming the axes or changing the attribute for size or coloring the

26

4. Iteraplan

Figure 4.3.: Creating Visualizations of the application landscape: Landscapediagram

diagram. When choosing coloring the objects iteraplan is automatically cal-

culating ranges and adds colors to them (see Figure 4.9).

As the output format of the diagrams do not allow editing (besides Visio �les)

there is no save option for user made changes. The settings for creating a

visualization are saved and can be loaded any time. If you want to highlight

objects of interest you must use the Visio �le format and edit the output �le

with Microsoft O�ce Visio. This way you can highlight speci�c objects or

color them di�erently.

The tool itself does support some kind of �ltering as you can select which

objects should be visualized. But there is no way to alter it once the diagram

has been created. On some visualizations you can also select which attributes

are important and should be visualized and which not.

27

4. Iteraplan

Figure 4.4.: Creating Visualizations of the application landscape: Clusterdiagram

Figure 4.5.: Creating Visualizations of the application landscape: Master Plandiagram

In the diagrams you are not able to traverse from one element to a connected

element as they are only static images without connection to the database.

Sorting or grouping regarding to a speci�c attribute can be adjusted before

the creation of the report as you can select which attributes to put on an axis.

28

4. Iteraplan

Figure 4.6.: Creating Visualizations of the application landscape: ProjectPortfolio Matrix

Figure 4.7.: Creating Visualizations of the application landscape: Legend

29

4. Iteraplan

Figure 4.8.: Interacting with, Editing of Visualizations: Adjusting the Portfo-lio Matrix

Figure 4.9.: Interacting with, Editing of Visualizations: Adjusting the Portfo-lio Matrix

30

4. Iteraplan

4.2.4. Annotating Visualizations with Certain Aspects

In iteraplan you can not annotate the visualization

with a threshold such as e.g. a tra�c light. However

you can set a color-coding for most of the diagrams

based on an attribute like users, maintenance costs, or

availability. Figure 4.10 shows the use of this feature in

a cluster map showing the application systems color-coded on their availability.

iteraplan is also able to create tabular reports showing speci�c aspects of each

Figure 4.10.: Annotating Visualizations with Certain Aspects: Color-codedcluster map

application system. It can be generated in di�erent �le formats, which are as

follows: The �rst possibility is to generate a table on the interface of iteraplan.

This report can be adapted to show more attributes or delete others in the

report. You are also able to generate an Excel �le, a XML �le, a Microsoft

Project 2003/2007 XML �le, a Gantt Project MPX �le, or a CSV �le.

The Excel output also has http links that can be followed back to the current

iteraplan installation (see Figure 4.11).

4.2.5. Supporting lightweight Access

iteraplan is a completely web based EA management

tool. The download package comes with a Apache

Tomcat installation that can be easily run by execut-

ing one simple batch �le. Therefore the only way to

access iteraplan is via web browser. This includes all

visualizations (which are getting re-generated by the saved diagram informa-

tion) and other information such as tabular reports.

But as the Community Edition does not allow you to create users you are not

able to limit the access of users to certain visualizations and information. Thus

31

4. Iteraplan

Figure 4.11.: Annotating Visualizations with Certain Aspects: An ExcelReport

Figure 4.12.: Supporting lightweight Access: iteraplan welcome screen

not allowing one to hide any information from other users or apply �ltering

for them.

4.2.6. Editing Model Data using an external Editor

As already mentioned above, iteraplan o�ers you the

possibility to export your data in Excel or XML �les.

Those �les can be edited using external editors, but

there is no functionality to update the tool's database

32

4. Iteraplan

with the changes made in the external editor. This

functionality is given in the Enterprise Edition which is not tested here.

4.2.7. Adapting the Meta Model

The meta model of iteraplan (see Figure 4.13 is based

on di�erent frameworks like TOGAF and Zachman,

but it does not directly comply to any of the exist-

ing frameworks. There are 13 �xed building blocks,

21 associations between them, plus 16 self-referential

associations in the meta model. A building block is a potentially re-usable com-

ponent of business, IT, or architectural capability that can be combined with

other building blocks, thus di�erentiating from classes by their re-usability.

You can add new attributes to the building blocks by using the system.

Figure 4.13.: Adapting the Meta Model: iteraplan meta model

There is currently no possibility to create further classes in the meta model

as the building blocks are �xed. The adaptability of the model therefore is

really low and therefore switching from a already existing meta model to the

33

4. Iteraplan

iteraplan model is not advised. While adding the data of SoCaStore some

tables could not be re�ected in the tool (such as strategies and goals).

4.2.8. Handling large scale Application Landscapes

iteraplan is not designed to handle large application

landscapes. Besides the missing import functionality

of the tool to import a large number of application

systems, there is also a limit for elements in the cluster

map. This limit is set to 50 elements and once it is hit

the tool refuses to create a visualization of a cluster map (see 4.14). However

this limit is not active in the textual report function.

Figure 4.14.: Handling large scale Application Landscapes: Cluster map cre-ation error with more than 50 elements

When managing a large amount of elements the search function helps to �nd

a speci�c candidate (see 4.15). The tool displays all elements that have the

search term in its name or description. The search functionality is not case

sensitive and also displays results when the search term is written in lowercase.

4.2.9. Usability

The menu structure of iteraplan is split into three

groups. The �rst group consists of all the build-

ing blocks de�ned in the meta model. You can edit

the speci�c elements and create connections between

them. The second group is controlling the reports.

You can create textual reports, visualizations, search for successor application

systems, run consistency checks (see Figure 4.16), or perform a simple search.

34

4. Iteraplan

Figure 4.15.: Handling large scale Application Landscapes: Searching speci�celements in the tool repository

Figure 4.16.: Usability: Consistency checks

In the last group all the administration is done. In the con�guration point

however you can only set if 'Inactive' elements are shown and create a new

index for the search. The next point subscriptions only leads to an error page

on our installation of iteraplan. You can also add or edit the attributes that

35

4. Iteraplan

are shown in the building blocks or run bulk updates on the repository. There

is also a function to export the information stored in the tool as a XMI and/or

Ecore �le. The last point clears your session, meaning that all unsaved progress

will get lost.

When opening a building block element or a visualization a new menu point

will be generated. A red font color indicates unsaved elements. When multiple

users edit the same object the one who saves it later will see a warning indi-

cating that the element has been modi�ed by another user (see Figure 4.17).

Thus big chances might get lost if the users are making changes on the same

object.

Figure 4.17.: Usability: Error when saving after another user edited an element

The open source version of iteraplan does not o�er any support packages from

iteratec. Hence the only help is a user manual explaining the important func-

tions of the tool. This manual is linked in the tool and can be found under

the point Help.

4.3. Evaluation for EA Management Support

This section describes the results of the scenario simulation for EA manage-

ment support.

4.3.1. Landscape Management

In iteraplan you can specify the application systems

you want to display in your landscape diagram. Those

elements can be �ltered (see Figure 4.18) by a spe-

ci�c Status attribute, allowing to set either current,

planned, target, or inactive. After executing the query

36

4. Iteraplan

a list of the speci�ed application systems is shown to the user. This list

can be further adapted by removing an application system or rede�ne the

search. Planned landscapes can be derived from the current landscape by

Figure 4.18.: Landscape Management: Table to select the time the applicationsystem was active

adding projects that are linked to the application systems. According to the

list of selected application system the di�erent scenarios can be generated.

iteraplan does not version the landscapes to plans. So there can only be one

version of the landscapes in the repository of the tool. There is no functionality

to compare two di�erent landscape diagrams with each other in iteraplan. So

you have to put them against each other and compare them by hand. A

textual report can be generated by the tool and can be set to show the dates

of productivity of the di�erent application systems and their state.

4.3.2. Demand Management

iteraplan does not handle demands in its current ver-

sion so there is no Demand Management in the tool.

Also there is no possibility to add demands to the meta

model as already discussed in Section 4.2.7. However

you can decide to use another building block, such as

the one for projects, to de�ne demands. Therefore you have to create the

desired attributes and especially one to di�erentiate projects from demands.

This however leads to inconsistency in the project building block as you know

have to determine if you are looking at a project or a demand every time.

37

4. Iteraplan

4.3.3. Project Portfolio Management

The meta model of iteraplan provides a building block

called Project, which can be set to a�ect di�erent ap-

plication systems and can be hierarchically ordered.

There are already some attributes like Costs, Value

added, State of Health (with good, average, and bad

as possible states), and Strategy contribution de�ned. Additional attributes,

like status or urgency, can be easily added by using the Administration tool

Attributes. Those can also be put together into one logical group.

Portfolio matrices can be created by using the Portfolio Diagram report type.

Again all required projects can be selected to be drawn. The �nal result could

look like Figure 4.6. Creating textual reports showing possible con�icts of

project proposals is not possible. You can however create reports that only

show projects a�ecting the same application system(s). Same is applying to a

portfolio matrix showing the number of modifying projects for an application

system. This information can however be entered into the tool's repository

manually as an extra attribute. But when doing so you won't have the infor-

mation which projects are actually modifying the application system.

4.3.4. Synchronization Management

iteraplan can create a time interval map showing the

di�erent projects, their durations (see Figure ??), and

how the projects are related with each other. The tool

does not support a delay of a project. The informa-

tion has to be changed in the end date of a project

and therefore does not get re�ected in the diagram. Also there is no impact

analysis on the delay. When creating attributes to re�ect the delay you can

set the tool to visualize projects that are in delay to be colored di�erently in

the visualizations and use this information to get an overview of interesting

projects.

You can create a tabular report re�ecting the delay of a project by de�ning

additional parameters to a project (see Figure ??). However this does not

38

4. Iteraplan

include an impact analysis, too. So you can only have a look at which projects

are successors of the current one or change the same application system.

4.3.5. Strategies and Goals Management

iteraplan does not support strategies and goals in its

meta model. Hence no strategies and goals manage-

ment can be done with the tool. The goals and strate-

gies can however be re�ected in the tool as already

done with the demands. You can use di�erent build-

ing blocks and add attributes for strategies and goals. Most of the important

information can than be generated by the tool, e.g. which strategy leads to

which goals. This again increases the maintenance complexity as one building

block gets used for 2 objects or even more.

4.3.6. Business Object Management

The exchange of business objects in the application

landscape can be modeled in the Interfaces building

block of iteraplan. You can set which application sys-

tems are involved and which business object is ex-

changed in which direction (see Figure 4.19). You can

set the direction to either a one-way or a bilateral exchange.

When entering a description for the exchange of business objects between two

application systems a tabular report can be generated. This list does not show

the business object that is part of the exchange, hence the description should

be entered. A sample list could look like Figure 4.20.

A model of the business object exchanges can be created by using the Informa-

tion Flow Diagram. This model type allows to display application systems as

well as corresponding business objects and their exchange. Figure 4.21 shows

an exemplary visualization of the exchange of the Price Tag between the two

application systems Price Tag Printing System and the Inventory Control Sys-

tem.

39

4. Iteraplan

Figure 4.19.: Business Object Management: Creating a business object ex-change relation

Figure 4.20.: Business Object Management: Tabular report of business objectexchanges

Figure 4.21.: Business Object Management: Exemplary Visualization of abusiness object exchange

4.3.7. SOA transformation

40

4. Iteraplan

To support the SOA transformation in iteraplan new

attributes for Service Level Agreements (SLA) have

to be added to the application systems. Further at-

tributes like the usage of business objects in the exe-

cution of a business process, or the rate of changes of an application system

have to be created as well. After this has been done reports can be generated

that show the necessary information for a top-down approach.

The tool provides the possibility to create a report showing the application

systems that will be changed within the next year. This can be easily done

by setting the search query to only show application systems that have got a

productionFrom after a speci�c date (here: 01.01.2007) AND before another

date (here: 31.12.2007). This will generate a tabular report as shown in Figure

4.22.

Figure 4.22.: SOA Transformation: Tabular report showing the applicationsystems that will be changed within the next year

41

4. Iteraplan

4.3.8. IT Architecture Management

The IT Architecture Management deals with the in-

troduction and implementation of architectural solu-

tions standardizing the architecture of speci�c appli-

cation systems to address heterogeneous application

landscapes. To address this scenario the meta model

of iteraplan o�ers the possibility to add Technical Components. There is

no concept to describe abstract architectures for application systems such as

client-server or 4-tier-thin-client-architecture.

With those data in the tool a cluster diagram can be created that displays

which application system is using and which architectural solution they should

conform to. Figure 4.23 shows detail of a sample output. Again the application

systems are abbreviated and shown in a legend.

Figure 4.23.: IT Architecture Management: Sample Cluster diagram showingthe architectural solutions and their application systems

The number of usages of a speci�c architectural solution can not be displayed

in a textual report or in the tool itself. Also no bar charts can be generated

showing this information. Also there is no possibility to create a textual report

that is showing the application systems and their architectural solution they

should conform to.

4.3.9. Infrastructure Management

42

4. Iteraplan

The meta model of iteraplan provides built-in support

for infrastructure elements. The prede�ned informa-

tion lacks support for temporal information, e.g. re-

garding support times, like start of production, and

aspects regarding costs. These attributes have to be de�ned manually again

by the user.

Once those attributes are de�ned a tabular report can be created showing the

end of the support period as in Figure 4.24.

Figure 4.24.: Infrastructure Management: Tabular report of databases runningout of support

With this information in the tool cluster maps can be created that show

databases running out of support with color-coding as in Figure 4.25.

Figure 4.25.: Infrastructure Management: Cluster map showing the databasesthat are running out of support

When replacing some of the databases through an external decision (e.g. a

management decision) the tool can display which databases are a�ected by it.

43

4. Iteraplan

This however only works with an extra attribute as already used in the other

scenarios.

4.4. Initiator data

The following information have been gathered by the List of Criteria, which

are appended to this thesis in A. The initiator of iteraplan is iteratec GmbH

with its headquarters in Munich, Germany and o�ces located in Frankfurt,

Hamburg, and Wien, Austria. The company was founded in 1996 and currently

employs 120 members of sta�. A total of 12 employees is concerned with

developing iteraplan (both versions).

Their motivation to release the tool iteraplan as Open Source in February 2008

was to "lower the barrier to use a tool in the still maturing EA world, giving a

broader audience access to an EA tool that uses a repository" and to "take the

burden of being stuck with O�ce or Wiki tools from Enterprise Architects".

The tool iteraplan is released under the AGPL 3.0 license. This license is an

OSI approved licenes (see [Wi10]). For further information on the license please

turn to [GN07]. The AGPL 3.0 license allows to edit the source as long as a

notice that it was edited and when is put on a popular place. The interactive

user interfaces have to display a legal notice. Also the new version must be

released under the AGPL 3.0 license again [GN07]. Four of the employees of

iteraplan have signed the Contribution Developer Agreement and contribute

code on a regular basis. The core decisions on the tool are made by employees

of iteratec.

44

5. Summary

Concluding this thesis an overview of how iteraplan has performed in the

di�erent scenarios is given in Table 5.1. The tool itself is easy to set up on a

conventional computer as the needed infrastructure is given with the download.

On the other side this means some bigger e�ort when planing to implement

iteraplan into already existing architecture.

Scenarioy Evaluation

Evaluation for Speci�c Functionality

Importing, Editing and Validating Model Data

Creating Visualizations of the Application Landscape

Interacting with, Editing of Visualizations

Annotating Visualizations with Certain Aspects

Supporting lighweight Access

Editing Model Data using an external Editor

Adapting the Meta Model

Handling large scale Application Landscapes

Usability

Evaluation for EA Management Support

Landscape Management

Demand Management

Project Portfolio Management

Synchronization Management

Strategies and Goals Management

Business Object Management

SOA transformation

IT architecture Management

Infrastructure Management

Table 5.1.: Summary of the Evaluation Results

45

5. Summary

As you can see in the table iteraplan still lacks a lot of features or needs

improvement in already existing functionality. Especially the missing feature

of importing data is a big drawback of an (Open Source) tool. Many companies

already have their EA Management started with O�ce tools and when they

are deciding to get tool support they have to spend hours to transfer all their

work into the tool.

The visualizations are sometimes not very intuitive and well-arranged. For

example you can't identify all the projects in a cluster map as they are overlap-

ping if both of them have got the same or similar attributes. The abbreviations

of the elements in the visualizations doesn't help to gain a quick overview. A

plus on this side is that the visualizations don't take long time to get gener-

ated, most of them are instantly shown to the user. The functionality to create

Visio �les is a good alternative to editing the model in the tool, but it also

needs a valid license of Visio to use. This functionality is not given on all the

visualizations, though. A further disadvantage while using the tool is the limit

of 50 elements for the cluster map. This limit is rather small and can be easily

hit by companies.

Another big disadvantage of the tool is the in�exibility of the meta model. You

can add attributes to the building blocks, but you can't add new classes or

relationships between the elements. The meta model of iteraplan does not have

the possibility to add demands or strategies and goals into the repository.

The tool however is good for companies that want to try EA Management in

their �rm and haven't done any previous work yet. The tool gives them a lead

how EA Management could work and what has to be considered. The general

usage of the tool is good and easy to understand. Combined with the easy

installation iteraplan is a great tool to access the EA world.

46

Bibliography

[Ca03] Carr, N. G.: IT doesn't matter. Harvard Business Review. 2003.

[El09] Election Technology Council: Open Source: Understanding its appli-

cation in the voting industry. ETC. 2009.

[GN07] GNU:GNU AFFERO GENERAL PUBLIC LICENSE. November

2007. http://www.gnu.org/licenses/agpl-3.0.html. 05.10.2010.

[Hi03] Hippel, E. von and Krogh, G: Open Source Software and the 'Private-

Collective' Innovation Model: Issues for Organization Science. Orga-

nization Science. Massachusetts Institute of Technology. 2003.

[it10] iteratec GmbH:iteraplan Homepage. 2010. http://www.iteraplan.

de/en. 05.10.2010.

[La05] Lankhorst, M.: Introduction to Enterprise Architecture. Springer.

Berlin, Heidelberg, New York. 2005.

[Ma08] Matthes F. et al.: Enterprise Architecture Managament Tool Survey

2008. Chair of Informatics 19 (sebis), Technische Universität München.

München, GER. 2008.

[ME02] META: Enterprise Architecture Desk Reference. META Group, Inc.

2002.

[Th08] The Open Group:TOGAF 9. The Open Group. 2008.

http://www.opengroup.org/togaf/. 22.09.2010.

[Wi10] Wikipedia:A�ero General Public License. June 2010. http:

//en.wikipedia.org/wiki/Affero_General_Public_License.

05.10.2010.

[Za08] Zachman Institute for Framework Advancement: Enterprise Architec-

ture: A Framework. 2008.

i

A. List of Criteria

In order to get an overview of the tool the tool's initiator was contacted prior

to the evaluation of the tool. The following questions were asked:

Id Chapter Question

1 Initiator data

1.1 Please provide the name of the company concerned

with the development of the tool.

1.2 Where is the headquarter of the company located?

Where does the company have subsidiaries?

1.3 When was the company founded?

1.4 How many employees does the company employ?

1.5 How many employees are concerned with developing

the tool?

1.6 What was the motivation to release the tool as open

source?

1.7 What are the main products of the company?

2 Community data

2.1 How many developers have joined the community?

2.2 How many of the community members can be de-

scribed as active, i.e. contribute code regularly?

2.3 Please outline how decisions are made in the com-

munity. Is a core team or board guiding the decision

making?

2.4 How often are code changes integrated?

2.5 Do you o�er several versions of the tool? For in-

stance, a stable version with fewer features and a

nightly version with the latest features.

2.5 In which ways do you support community members

(e.g. documentation, forum)?

3 Tool data

ii

A. List of Criteria

3.1 Please provide the name of the tool, including version

numbers.

3.2 When was the current version released?

3.3 When is the next major release to be expected?

3.4 Please provide a brief history of the tool.

3.5 Please outline the schedule for the next minor and

major releases of the tool and sketch the new func-

tions in the upcoming version..

3.6 Under which license is the tool available? Is it an

OSI approved license?

4 General tool architecture

4.1 Please provide an overview of the tool's infras-

tructure requirements (hardware, operating system,

RDBMS, browser - if appropriate distinguish di�er-

ent aspects of the tool, e.g. thin client)

4.2 Which open source libraries/components are used by

your tool?

4.3 What platforms or database systems (e.g. DB2,

MySQL) does the tool support?

5 Collaboration support

5.1 Does the tool support multiuser work? Please pro-

vide information due to multiple reading and writing.

5.2 What kind of synchronization mechanism is provided

to support multiple user edits, e.g. locking, times-

tamp based synchronization?

5.3 In case locking is supported, which locking modes

(e.g. shared, exclusive) does the tool support and

which locking granularities (e.g. whole models, dia-

grams, set of entities) are distinguished?

5.4 Does the tool provide rights management for restrict-

ing user's access, e.g. to models, diagrams or limit

their editing capabilities concerning e.g. certain en-

tities? Can users pass the rights given to them to

others (with grant)?

iii

A. List of Criteria

5.5 Does the tool support versioning of artifacts in re-

spect to collaboration support, i.e. can a model be

reverted to the status prior to changes by a certain

user?

5.6 Does the tool o�er capabilities for o�ine working

with the data, e.g. a client, from which edits can

be synchronized with the repository? What kind of

operations are supported on o�ine data?

5.7 Does the tool support multi-client capability to allow

simultaneous access to several clients without seeing

each other's data?

5.8 Does the tool support automatic noti�cations (espe-

cially when changing certain objects)?

5.9 Does the tool support substitution rights (e.g. vaca-

tion replacement)?

5.10 Does the tool support integration in corporate por-

tals (e.g. wikis) to support collaboration? If yes,

how is it implemented?

6 Internationalization/Localization

6.1 Does the tool provide capabilities to assign a locale to

a user pro�le? Which adaptions to e.g. the graphical

user interface of the tool may be de�ned in a locale

(e.g. date format, currency)?

6.2 Does the tool support multi-language data, e.g. nam-

ing or description of entities dependent on the user's

language within one installation/instance of the tool?

6.3 Does the tool support unicode characters?

7 Integration with related domains

7.1 Does the tool support business process modeling?

Which business process modeling standards/nota-

tions does the tool support?

EPC, BPML, BSEL, WSCI, BPEL, other

7.2 Does the tool support data modeling? Which mod-

eling standards/notations does the tool support?

E/R, Crowfoot notation, IDEF1X, UML with pro-

�les

iv

A. List of Criteria

7.3 Does the tool support UML modeling? How many

diagrams does the tool support? Which diagrams

does the tool support?

class diagram, composite structure diagram, compo-

nent diagram, deployment diagram, object diagram,

package diagram, activity diagram, use case diagram,

state machine diagram, sequence diagram, collabora-

tion diagram, timing diagram

8 Meta model

8.1 Please provide information on the prede�ned meta-

models shipped with the tool (number of classes, as-

sociations)?

8.2 Do the prede�ned metamodels comply with EA

frameworks, as e.g. Zachman, TOGAF?

8.3 Please provide information on the number of classes

(entity types) contained in the metamodels, espe-

cially of the standard or default metamodel employed

for EAM.

9 Integration with other tools

9.1 Please provide information on di�erent formats and

tools, from which data can be imported into the tool,

e.g. CVS, Excel, Microsoft Project. Please detail on

how transformations for importing this data can be

implemented or con�gured.

9.2 Does the tool support accessing data from a BPM

tool via an interface? Which BPM tools are sup-

ported by which interfaces (o�ine, online)?

ARIS Toolset (IDS Scheer), ADONIS (BOC), Cor-

porate Modeler (Casewise),...

9.3 Does the tool support accessing data from a CMDB

via an interface? Which CMDBs are supported by

which interfaces (o�ine, online)?

Atrium (BMC), Tivoli CMDB (IBM), CMDB

(HP),...

v

A. List of Criteria

9.4 Does the tool support accessing data from a systems

management tool via an interface? Which CMDBs

are supported by which interfaces (o�ine, online)?

Tivoli (IBM), OpenView (HP), SMS (Microsoft),...

9.5 Does the tool support accessing data from a project

management tool via an interface? Which CMDBs

are supported by which interfaces (o�ine, online)?

Clarity (CA), Mercury PPM (HP), BW (SAP),

Project (Microsoft),...

9.6 Does the tool support accessing data from an ERP

tool via an interface? Which CMDBs are supported

by which interfaces (o�ine, online)?

SAP, Oracle,...

9.7 Please detail on the mechanisms for synchronizing

and keeping consistency with data from an external

data source?

9.8 Does the tool support a connection to work�ow en-

gines?

9.9 What kind of export formats will be supported? Is

it possible to export XML?

9.10 Does the tool support single sign-on and can other

existing user directories (like LDAP) be used? Does

the tool support the OpenID standard?

Table A.1.: List of Criteria

vi