Upload
lequynh
View
213
Download
0
Embed Size (px)
Citation preview
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