See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/221399926

Towards Living Landscape Models: Automated Integration of Infrastructure

Cloud in Enterprise Architecture Management

Conference Paper · July 2010

DOI: 10.1109/CLOUD.2010.20 · Source: DBLP

CITATIONS READS

9 1,032

6 authors, including:

Matthias Farwick Ruth Breu

Txture GmbH University of Innsbruck
34 PUBLICATIONS   396 CITATIONS    196 PUBLICATIONS   2,482 CITATIONS   

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

SECTISSIMO View project

Software Quality Assurance View project

All content following this page was uploaded by Matthias Farwick on 10 June 2014.

The user has requested enhancement of the downloaded file.

 2010 IEEE 3rd International Conference on Cloud Computing
Towards Living Landscape Models: Automated Integration of Infrastructure Cloud
in Enterprise Architecture Management
Matthias Farwick, Berthold Agreiter, Ruth Breu
Institute of Computer Science
University of Innsbruck,
Innsbruck, Austria
{matthias.farwick,berthold.agreiter,ruth.breu}@uibk.ac.at
Abstract—Enterprise Architecture Management (EAM), and
in particular IT–landscape management try to model the IT-
and business elements of a company, in order to analyze its effi-
ciency towards supporting business goals, optimize business–IT
alignment, and to plan future IT–transformation as well as IT–
standardization. A major challenge in this field is the elicitation
of infrastructure information from run–time systems, e.g., to
answer the question which servers provide services to a specific
information system. Capturing this data is a time consuming
manual task which leads to quickly outdated information.
Similar to traditional hardware, cloud infrastructure needs to
be documented in an EA model in order to gain insight on its
relationships with business information systems and ultimately
the business goals. The aim of our research in this area
is the automatic integration of various runtime information
sources into an EAM view. The overall goal is to minimize
manual work to keep enterprise architecture information up–
to–date. This enables enterprise architects to make timely and
precise decisions. In this work we focus on how information
on the cloud infrastructure can be seamlessly integrated into
an EA view. Making the cloud visible for enterprise architects
is especially important to meet legal (privacy) requirements,
on the storage and processing location of data. We present
a conceptual approach for the information integration prob-
lem, and introduce our prototypical implementation with the
open–source infrastructure cloud implementation Eucalyptus,
and the open–source enterprise architecture management tool
iteraplan.
Keywords-infrastructure cloud; eam; it–management; cloud
computing; cloud api; it–landscape modeling; enterprise archi-
tecture management; open-source; iaas
I. I NTRODUCTION
Enterprise Architecture Management (EAM) is an often
used practise in mid-sized to large organizations to align IT
and business goals, to assess risks, and to check compliance
with legal regulations. EAM helps to discuss and clarify
business processes and procedures and aims to visualize
the relationships among regulations, business processes,
software and the underlying infrastructure. This practice
achieves transparency over the IT–landscape, enables man-
agers to see how business and IT interrelate, and where the
This work was partially supported by the Austrian Federal Ministry of
Economy as part of the Laura-Bassi – Living Models for Open Systems –
project FFG 822740/QE LaB
978-0-7695-4130-3/10 $26.00 © 2010 IEEE
DOI 10.1109/CLOUD.2010.20
Matthias Häring, Karsten Voges, Inge Hanschke
iteratec GmbH
Munich, Germany
{matthias.haering,karsten.voges,inge.hanschke}@iteratec.de
mutual dependencies lie [8]. It is typically conducted by
people within one organization having different technical
and non–technical backgrounds. Hence, it brings together
experts to (i) analyze the current situation regarding the
aforementioned topics, and (ii) to define requirements and
plans for future standardization and changes. These planned
changes to the IT–environment, however, are mostly exe-
cuted in an unchecked manner by specialists and their status
is often not synchronized with the enterprise architecture
model.
IT–landscape modeling, as a sub–area of EAM, tries
to assess the IT–landscape of an organization to bring it
into relation with the information systems that ultimately
support the actual business functions. EAM tools support the
modeling of the IT–landscape, however the creation of these
models is a time–consuming task. Furthermore, the problem
that the manually created landscape models are often quickly
outdated persists also here.
To date, there exists no automated method to keep land-
scape models up–to–date. Certainly, current and consistent
information about the as–is landscape is needed in order
to come to the right business- and technology-decisions for
future changes.
Seen from another perspective, increased IT efficiency
and minimized costs are these days often promised by
shifting certain parts of the own IT infrastructure into public,
private or hybrid clouds. Infrastructure cloud computing,
also referred to as Infrastructure as a Service (IaaS), is
aimed at realizing higher utilization rates with less over-
provisioning, which means that money is only spent for
infrastructure that is actually used. Furthermore, it allows
for fast infrastructure changes when the business requires it,
because of its on demand availability. Clouds allow for self–
service provisioning through APIs, bringing a higher level
of automation and reducing management costs [16].
The lack of synchronicity between the planned enterprise
architecture model and real architecture persists also in
the case where cloud infrastructure is used to support an
organization’s own IT infrastructure. Hence, the question
we are tackling in the present contribution is: how can
infrastructural runtime information about cloud instances be
35
integrated into enterprise architecture models in an auto-
mated way? This question is an integral part of the three
main problems that we try to solve in our research project
Living IT–landscape Models:
1) How can enterprise IT–landscape models be auto-
matically kept in–sync with the IT–landscape they
represent, and
2) how can this be achieved for (private) infrastructure
clouds that are emerging in many organizations?
3) Also, how can this automation be integrated into typi-
cal IT–infrastructure planning processes in enterprises.
It is the overall goal to minimize manual work to keep
enterprise architecture information up–to–date. In this paper
we focus on how planned and unplanned changes to the
cloud infrastructure can be automatically updated in an EAM
view. This helps IT architects to have an overview of the
current cloud infrastructure for decision making.
A. EAM and the Cloud
Similar to traditional hardware, cloud infrastructure needs
to be documented in an EA model in order gain insight
on its relationships with business information systems and
ultimately the business goals. Figure 1 shows an extremely
simplified enterprise architecture model, that includes a
private and a public infrastructure cloud. It contains three
common layers of EA models: the business architecture
layer, the information system architecture layer and the
infrastructure landscape layer. These layers can, for example,
be found in the best-practice enterprise architecture by
Hanschke [8]. Via the visualization of the interconnection
between elements of these layers, enterprise architects can
immediately see which business functions are provided by
which application, and where the applications are hosted. In
the given example, one can see that the brokering application
is hosted both in the private as well as in the public cloud.
In addition to the basic requirement of the coupling of EA
and infrastructure, several other motivating factors can be
identified. For example, making the usage of clouds visible
for higher–level management, highlights the advantages of
utilizing the infrastructure cloud by pointing out infrastruc-
ture simplification and cost savings. It thereby strengthens
proponents of cloud initiatives in the enterprise by showing
the return on investments. Also, cloud infrastructure is much
more volatile than traditional hardware infrastructure. There-
fore, it is important to couple EAM and cloud management
to form an IT–governance approach that controls change
processes in the cloud.
Further, it is important to make cloud computing visible to
enterprise architects to be able to monitor compliance with
laws and regulations. For instance, regulations might prohibit
the storage of private data in a public cloud, as it can be seen
in Figure 1. An example for such a regulation is the EU Data
Protection Directive 95/46/EC1 , which restricts the export of
1 http://ec.europa.eu/justice home/fsj/privacy/index en.htm
36
private data, to non–EU countries that do not comply with
the data protection standards of the European Union. Non–
compliance to such regulations can lead to monetary loss,
as well as loss in trust by customers.
Business
Architecture
Brokering Online Banking
Business Business
Function Function
Information supports supports
System
Architecture
Online
Brokering
Banking
Application
Application
Infrastructure hosted on hosted on
Landscape
Public Cloud Private Cloud
Datacenter
Figure 1. Example of simplified EAM model instance.
The need for this kind of integration has been identi-
fied by researchers and practitioners alike. For example,
Frank et al. [6] propose the integration of an EAM view
with the underlying IT–landscape to elicit Key Performance
Indicators (KPIs) from the runtime. On the practitioners
side, mainly IT–consulting firms and tool vendors, have
identified the need for cloud and EAM integration. In his
online article2 Wolfgang Jost, member of the executive
board of IDS Scheer AG3 , states that Cloud Computing
in the enterprise can only work with the precise planning
of enterprise architecture management. The Oracle white
paper on cloud computing [3] argues that EAM helps to
more efficiently align business and IT with cloud computing.
In his blog the IT–consultant David Linthicum argues that
“Cloud computing needs governance to be successful”4 .
Also, consulting agencies give high–level advice on how
cloud infrastructure should be managed [13]. However, there
currently do not exist sophisticated tools or methods to
support a cloud and EAM integration.
B. Contribution
In this work we present a method and a prototypical
implementation to integrate several management tools, to
keep them in–sync with the cloud infrastructure. These
management tools are an enterprise architecture management
tool (iteraplan5 ), and a project portfolio management tool
2 http://www.computerwoche.de/software/soa-bpm/1928049 (in german)
3 IDS Scheer AG is one of the leading vendors of EAM tooling.
4 http://www.infoworld.com/d/architecture/cloud-computing-needs-
governance-be-successful-757
5 http://www.iteraplan.de
(project.net6 ). As the underlying infrastructure cloud we
use the open–source infrastructure cloud implementation
Eucalyptus [14], which implements the same API as the
Amazon EC2 Web Services (AWS). All components are
indirectly connected via a central model, that provides model
versioning. To the best of our knowledge no automated
approach has been documented in literature that enables the
coupling of EAM and underlying IT–infrastructure in gen-
eral, and none that enables this automation for infrastructure
cloud in specific.
C. Structure
The remainder of this paper is structured as follows: the
next section briefly expands on our overarching vision of
Living Models in the enterprise and how we plan to make
most use of such models. After that, Section III presents a
usage scenario highlighting the challenges of this contribu-
tion. Section IV describes our approach for integrating cloud
data into EAM by detailing our prototypical implementation.
In Section V the update mechanism is described. Section VI
presents related work and Section VII concludes.
II. T HE V ISION OF L IVING M ODELS
One of the key deficiencies in most of the current
modeling methodologies and modeling applications is the
unsatisfactory integration of model instances with the run-
time environment. I.e. current modeling approaches fail in
automatically keeping model elements in–sync with what
they represent in the real world. For example, models of
a server landscape need to be manually updated when a
new server is started up, or legacy hardware is faded out
of production mode. Roundtrip–engineering approaches go
a step in the right direction, however, integration halts at
the source code level and does not allow for feeding back
runtime information into models. In the course of the project
Living Models for Open Systems and its sub–projects we
investigate on the tight coupling of models with runtime
artifacts, such as business process models, security(-policy)
models, SOA models, as well as enterprise and IT–landscape
models. In [5] we define the ten principles of our future
vision of Living Models. Living models specifically tackle
the particular challenges for handling changes in evolving
systems. The principles of living models are summarized in
Table I.
The contribution at hand specifically focuses on
stakeholder–centric modeling environments (P1) by devel-
oping extensions for an enterprise architecture and project
management tool, thereby creating a view for two spe-
cific stakeholders. The implication is that IT architects
and technical project managers always possess up–to–date
information, that is in–sync with the cloud architecture of
the enterprise. For example, enterprise architects can always
correctly answer the question which information objects
6 http://www.project.net
37
ID Living Models Principle Description
P1 Stakeholder–Centric Modeling Environments.
P2 Close Coupling of Models and Code/Runtime.
P3 Bidirectional Information Flow between Models
and Code/Runtime.
P4 Common System View.
P5 Persistence.
P6 Information Consistency and Retrieval.
P7 Domains and Responsibilities.
P8 Model Element States.
P9 Change and Change Propagation.
P10 Change–Driven Process.
Table I
T HE TEN PRINCIPLES OF LIVING MODELS ACCORDING TO [5].
are stored in the cloud and which information systems are
hosted in the infrastructure cloud. Additionally, we propose
a methodology for the close coupling of models and runtime
artifacts (P2) and the support of a bidirectional information
flow between models and the runtime (P3). This is realised
with the help of a common system model capturing all
information available and bringing it into relation with
each other (P4). Living Landscape Models allow for tight
coupling of the EAM tool, the project management tool
and the cloud architecture. This directly tackles the syn-
chronicity problem between EA models, resp. key figures
relying thereon, and the infrastructure. Furthermore, also
project management information is automatically pushed to
the EAM tool which allows IT architects to have insight into
current and planned projects so decisions are made with the
most current information.
III. U SAGE S CENARIO
The aim of IT–landscape management is to assess
the current state of the IT–landscape, and among others,
the target–focused planning towards a structurally and
technologically consolidated infrastructure landscape. We
now proceed with giving a typical scenario of planned
infrastructural change in an enterprise that needs to be
supported by tooling.
The banking–group XYZ–banking wants to give their
professional brokering customers a faster real–time
brokering experience within their existing brokering
application. As the enterprise architects assess the
corresponding IT–landscape in their EAM tool, they
realize that the server–cluster, which is responsible for the
brokering application, has already reached its maximum
capacity, is accessed with an outdated message format, and
would be costly to extend. They decide that the new backend
IT–architecture will reside in their private infrastructure
cloud. This is in accord with the longtime standardization
effort of the enterprise towards homogeneous usage of the
private infrastructure cloud. The IT architects decide that
some, security and privacy in–sensitive, computations can
be offloaded to a public infrastructure cloud at peak times.
However, they recognize that the transition from the old aim to only extend existing industry standard tools with
architecture to the infrastructure cloud needs to be precisely integration support.
planned to be successful.
During the planning effort by the systems operation
team, a new infrastructure change project is initiated in the
project management tool of the company. The high–level
information on this project, like the planned cloud instances,
is automatically forwarded to the EAM tool over a central
integration component. Hence, this information is immedi-
ately visible to the enterprise architecture stakeholders.
As the systems operation team executes the project
plan to create new cloud instances (e.g. using a cloud
administration tool like Elasticfox7 ) the cloud instances
are tagged with the IDs that were assigned to them during
the planning phase. Once the instances in the private and
public cloud are started up, they are recognized by the
central component as running. From this information, the
integration component can inform the EAM tool, that the
originally planned cloud servers have been started up, Figure 2. Automated information flow to EAM tool. The information
i.e. their status changes from PLANNED to CURRENT. sources relevant to this publication are colored in grey.
This way the EAM stakeholders always have a high–level
overview of the status of each cloud component. Since
Figure 2 shows this federated approach. In this work, we
the status of the planned servers is also updated in the
focus on the communication solution for the components
project management tool, the systems operation team is
in Figure 2 that are colored in grey. It shows three layers,
also informed that the new brokering application can finally
of which the topmost represents the management view that
be deployed to the production environment.
is constituted by an EAM tool. Information from lower
layers is first synchronized with a central repository. The
data–structure of this repository is based on an extensible
By this precise planning and monitoring, XYZ–banking
meta–model and capable of expressing all information that
manages to switch the underlying IT–landscape of the bro-
is important to the management view of a specific enterprise.
kering application from a legacy server–cluster to an elastic
The consolidated data from the lower layers is then pushed
infrastructure cloud, that corresponds to the longtime stan-
from the central model to the EAM tool. The middle layer
dardization roadmap of the enterprise, without significant
contains information sources that can be summarized as the
downtime.
systems operation information sources. Data from this layer
IV. A PPROACH TO AUTOMATED C LOUD INTEGRATION IN that is communicated to the central model can be character-
EAM ized by the fact that it is not information coming directly
As mentioned before, our approach to automatically in- from the runtime, but is rather data that is entered/created by
tegrate information about running infrastructure cloud in- operation personnel. This could, for example, be information
stances, is part of a larger effort to integrate various runtime on ongoing infrastructure change projects that are planned
information sources into an EAM view. In our solution, this in a project management tool, or data that has already
integration is achieved by a central model which receives been (possibly automatically) gathered in a Configuration
model updates from various sources, and pushes new, veri- Management Database (CMDB) [12]. The bottom layer
fied information to the EAM view. This central model will shows information sources from the runtime that can be fed
be further discussed in Section IV-A2. With this setup we into the central model. These can be, for instance, business
follow the approach by Fischer et al. [1] who state that each process engines, applications and hardware that have agents
stakeholder in an enterprise (e.g. systems operation, project deployed to them, or, as in the case of this publication, cloud
management, etc.) needs their own set of tools, i.e. views infrastructure that actually exposes an interface which can
on the enterprise model, with which they are familiar. The be queried for the current state of cloud instances.
opposite approach would be to create a tool that caters for A. Prototypical Implementation Architecture
the needs of all stakeholders at once. This, however, would
entail that all users need to get accustomed to a new generic The major challenge for the implementation is the
tool, which would lead to productivity loss. Therefore, we synchronization of the different technologies and
applications involved. Figure 4 shows the basic setup
7 http://sourceforge.net/projects/elasticfox/ of our approach – each component will be further explained

38

Figure 3. The open–source enterprise architecture management tool
iteraplan.
in the following subsections. In the center of the figure
is the central model controller. It handles the access and
changes to the model in the model repository. Other attached
components can push model changes to the model controller
via the provided Web service interface. This interface is,
for example, used by the project portfolio management tool
project.net, that we extend to push information on planned
infrastructure change projects to the central model. On a
regular basis, the central model controller polls the public
and the private cloud interfaces, which are drawn on the
lower left, to find out whether new instances have been
started up, or instances have been terminated. This queried
information is then compared with planned changes to the
infrastructure. The duration of this interval should be chosen
according to the frequency of changes within the cloud
infrastructure. For some organizations, a daily poll might
be sufficient, for others, however, a much smaller interval
is advisable. The top of Figure 4 shows the open–source
EAM tool iteraplan that we extend, in collaboration with
our partner company iteratec, with a Web service interface
to push changes that occur in the systems operation layer
or in the runtime layer to this EAM view. The lower right
corner of the figure shows a possible future extension
towards agents that are installed on hardware to report the
state of the machines to the central model.
1) Tagging Cloud Instances with enterprise–wide IDs:
To test our approach we use the open–source infrastructure
cloud implementation Eucalyptus, which exposes the same
WSDL8 interface as Amazon EC29 . Because this interface
is seen by some as the emerging standard API for the
infrastructure cloud [14], and it works for a private cloud
8 http://www.w3.org/TR/wsdl
9 http://aws.amazon.com/ec2/
39
with Eucalyptus as well as for a public cloud with EC2
we use it for our implementation. However, in the future a
generic cloud API wrapper, like the one proposed by Harmer
et al. [9] could be used as well, to allow for the usage of
different cloud providers. For our setup we use one Cloud
Controller installed on a laptop as well as several Node
Controllers, also installed on laptops.
In our approach all infrastructure elements have a UUID
(Universally Unique Identifier) assigned to them, as soon as
they are planned in the project management tool. This way,
once it is signaled to the central model that an instance,
tagged with a planned UUID, is running, it can be inferred
that a planned infrastructure element changed its status from
PLANNED to CURRENT.
A major problem we faced with the Amazon EC2 API was
that it does not directly provide a method to tag instances
with user–defined tags or IDs. Global IDs for cloud instances
are necessary in our approach, since they allow for globally
identifying cloud instances, in order to represent their status
in the EAM tool. This is needed to find out whether a
newly started instance corresponds to a planned instance.
Cloud management tools like Elasticfox provide tagging
functionality, however they store the tags locally, so they
are not globally available.
For this reason we utilize a workaround via security
groups to tag instances with IDs, as proposed in [15].
This is achieved by assigning security groups without any
added permission to a new instance that should be created.
This way, instances are tagged with security groups, but
no changes to permission assignment are done. With this
approach, however, care has to be taken not to assign the
same security group UUID to two different instances.
Security groups can be created and assigned to instances
on startup with graphical interfaces like Elasticfox or via
the Eucalyptus/EC2 commandline tools:
$ euca-add-group "UUID:123" -d "Global ID".
A new instance with this UUID can then be started with
the ID via:
$ euca-run-instances ami-bgf54s6g --instance-type
m1.medium --key keypair --group default --group UUID:123.
The new instance is now tagged with the security group
named “UUID:123” that does not add any extra restrictions
on permissions of the instance. This way the the global ID
of the instance can be stored in the cloud and be retrieved
and parsed, e.g. via
$ euca-describe-instances.
Of course, this is only a workaround. Amazon has identified
the need for a tagging mechanism which stores the tags
in the cloud, however, at the editorial deadline it was not
available.
2) Central Model Controller: In our approach, all
changes that happen in the infrastructure and the systems

EAM Tool (iteraplan)
Push changes to
EAM view
Central
Model Model
Repository
Controller
Pull instance IDs
Eucalyptus EC2
WSDL API
Private Infrastructure Cloud Public Infrastructure Cloud
Eucalyptus Cloud Controller
Amazon EC2
Cloud Nodes (Running Eucalyptus Node Controllers)
Figure 4. Infrastructure cloud EAM integration architecture.
operation layer are either pushed to the central model on
change events, or are pulled by the central model controller
in regular intervals. The central controller implements a
WSDL interface that allows other components to update the
central model. The implementation builds on a co–project
called MoVE (Model Versioning and Evolution). This
model repository provides for model versioning and roll
back of EMF10 models, as well as the evolution of models
and the corresponding metamodels. It provides us with
the basic means to tackle transaction problems, and the
evolution of the underlying metamodel while the actual
model instance is already existing. More details about this
tool can be found in an accompanying publication [4].
3) EAM view with iteraplan: The web–based application
iteraplan is the first open–source enterprise architecture
management tool. Its source code has been contributed
by our partner, the consulting company iteratec, which
continues to contribute further development. Figure 3 shows
the web interface with its underlying extensible metamodel
for enterprise architecture. For our approach to combine
iteraplan with the infrastructure cloud we develop a Web
service interface that allows for the remote manipulation of
10 http://www.eclipse.org/emf
40
Project Portfolio
Management Tool
(project.net)
Iteraplan WSDL/
REST API
Model WSDL
API
Push planned
cloud changes,
e.g. creation of
new instance with
Pull instance IDs UUID XYZ.
Amazon EC2
WSDL API
Traditional Data Center Hardware with
Agents (Future Work)
Data Center Hardware
IT–landscape data in the iteraplan datastore.
V. C HANGE S CENARIOS
In the preceding section we discussed the components
that are involved in a planned cloud infrastructure change
process. In this section we will expand on concrete change
scenarios that relate to the usage scenario of Section III.
Figure 5 shows an UML sequence diagram visualizing the
timing of actions, and messages between the interfaces in a
planned and unplanned change scenario of the infrastructure
cloud.
As in the usage scenario, the planned infrastructure change
project is first discussed by the enterprise architects and
then submitted as a new project to the project management
tool (steps 1 & 2). On this submission, the tool forwards
the project information to the central model controller in
step 3. In the following, the central model forwards these
new planned infrastructure elements to iteraplan and also
creates a new project within the EAM tool. According to
an automated interval, the controller polls the private cloud
for new instances that have been started up (steps 5 & 6).
However, it discovers in step 7 that no new and unknown
instances have been created by the cloud management team
since the last poll. In step 8, the cloud management team
starts up new instances with the UUIDs according to the
plan defined in the project management tool (step 8 &
9). At the next polling interval the controller notices the
new instances (steps 10 – 12) and compares them with the
planned instances. Once it finds an instance whose state
has the PLANNED status, it updates its status in the EAM
view to CURRENT. If the UUID of a new instance cannot
be identified as planned, steps 14 and 15 are executed. In
step 14 a manual check needs to be executed since the
new instance does not correspond to any planned instance.
Staff from the systems operation team could either decide
that the instance is not important for the EAM stakeholders
(e.g. it is a test server that has a short life span), or decide
to push the enriched information on this new infrastructure
element to iteraplan (step 15).
This walkthrough showed a possible execution of a
planned infrastructure change that is automatically signaled
to the EAM view. The same polling mechanism can detect
deleted cloud instances, by comparing the retrieved instance
UUIDs with the UUDIs marked as CURRENT in the central
model. However, it also reveals, that in some cases human
intervention is still necessary. Another case in which human
intervention is needed, is the case when a new instance
is started up, but is not in production mode. This can
only be detected by a human so far. Therefore, we further
investigate on notification mechanisms that allow for quality
assurance of the automated updates via human checks.
VI. R ELATED W ORK
To the best of our knowledge no automated approach
has been documented in literature that enables the coupling
of EAM and underlying IT-infrastructure in general, and
none that enables this automation for infrastructure cloud
in particular. Nonetheless, there exist several works in the
literature which discuss related topics.
Similar to our approach, the work on orthographic mod-
eling by Atkinson et al. [2] describes a single underlying
model with an extensible meta model to which views can
be defined for different stakeholders. However, opposed to
our work the authors focus on software engineering and
model-driven development instead of enterprise architecture.
In their work on federated Enterprise Architecture Fischer et
al. [1] describe a federated approach to EAM with a central
model, for which information is manually gathered. They
see the automation as possible future work. Frank et al. [7]
state that their enterprise modeling language (ITML) can
be transformed into enterprise specific database schemas in
order to built management tools that represent instances from
the runtime in these tools. However, they neither describe
how this integration can be achieved automatically, nor
manually. In a different publication Frank et al. [6] propose
a modeling language to define Key Performance Indicators
that should be calculated from information that has its origin
in the runtime. The automation of this information retrieval
is left as future work. In another publication Holmes et al.
41
[11] describe a method to create a model–aware service
environment that allows Web–services to communicate with
a model repository that contains the model elements that
represent the services. This work is related to our publication
since Holmes et al. try to integrate the modeling environment
with the runtime. Head et al. [10] use the network discovery
tool nmap to elicit runtime information from a company’s
infrastructure to enable quick remote infrastructure manage-
ment (RIM) for specific infrastructure elements.
VII. C ONCLUSION AND F UTURE W ORK
In this contribution we have shown, that the need for
integrating enterprise architecture management with infor-
mation from actually running systems has been identified
both by researchers and practitioners. Enterprise architects
need an up–to–date view on the usage of infrastructure
clouds, in order to oversee e.g. compliance with (privacy)
laws that regulate the storage location of data, such as the
EU Data Protection Directive. As the first step towards
this integration, we present an approach towards automated
integration of the open–source EAM tool iteraplan and
private or public infrastructure cloud. This integration is
achieved via push and pull protocols to and from a central
model, that is also synchronized with a project management
tool to distinguish between planned and unplanned changes
on the cloud infrastructure.
As this work is embedded within a larger project towards
integrating many runtime information sources into an EAM
view, we still face several open issues and multiple areas of
future work.
A. Future Work and Open Issues
Most importantly, we will continue to implement and
evaluate the cloud integration approach described in this
work. We will also consider the usage of generic cloud APIs
and closely observe cloud standardization efforts. We will
also investigate on how the models of Platform as a Service
(PaaS) and Software as a Service (SaaS) can be integrated
into our approach. Another focus of future research will
lie on the central model and how synchronization issues
and metamodel evolution can be handled. The largest effort
will be put into the integration of various other runtime
information sources, e.g., by installing agents on systems
to report performance metrics as well as the status of in-
stalled applications from systems back to the central model.
These agents could, for example, already be pre-installed
on machine images that are started as cloud instances and
support the collection of utilization data.
R EFERENCES
[1] A federated approach to enterprise architecture model main-
tenance. 2.
[2] C. Atkinson and D. Stoll. Orthographic modeling envi-
ronment. LECTURE NOTES IN COMPUTER SCIENCE,
4961:93, 2008.
 Figure 5. UML sequence diagram showing the communication of the different components in a planned and unplanned infrastructure cloud change
process.
[3] S. Bennett, M. Bhuller, and R. Covington. Architectural
strategies for cloud computing, 2009.
[4] M. Breu, R. Breu, and S. Löw. Living on the MoVE:
Challenges for a Living Models Infrastructure. 2010. In
preparation.
[5] R. Breu. Ten principles for living models - a manifesto
of change-driven software engineering. In 4th International
Conference on Complex, Intelligent and Software Intensive
Systems (CISIS-2010), 2010.
[6] U. Frank, D. Heise, and H. Kattenstroth. Use of a domain
specific modeling language for realizing versatile dashboards.
Proceedings of the 9th OOPSLA workshop on domain-specific
modeling (DSM), 2009.
[7] U. Frank, D. Heise, H. Kattenstroth, D.F. Fergusona,
E. Hadarb, and M.G. Waschke. ITML: A Domain-Specific
Modeling Language for Supporting Business Driven IT Man-
agement. dsmforum.org, 2009.
[8] I. Hanschke. Strategic IT Management: A Toolkit for Enter-
prise Architecture Management. Springer, Berlin, Germany,
2010.
[9] T. Harmer, P. Wright, C. Cunningham, and R. Perrott.
Provider-Independent Use of the Cloud, page 465. Springer,
2009.
[10] M. R. Head, A. Sailer, H. Shaikh, and M. Viswanathan.
Taking it management services to a cloud. 2009 IEEE
42
View publication stats
International Conference on Cloud Computing, pages 175–
182, 2009.
[11] T. Holmes, U. Zdun, and S. Dustdar. Morse: A model-
aware service environment. 2009 IEEE Asia-Pacific Services
Computing Conference (APSCC), pages 470–477, 2009.
[12] Larry Klosterboer. Implementing ITIL Configuration Man-
agement. IBM Press, 2007.
[13] N. Kuttner, D. Cohen, M. Farber, R. Fontecilla, and Low J.
Enterprise architecture and cloud computing. Booz Allen.
[14] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman,
L. Youseff, and D. Zagorodnov. The eucalyptus open-source
cloud-computing system. 2009 9th IEEE/ACM International
Symposium on Cluster Computing and the Grid, pages 124–
131, 2009.
[15] Shlomo S. Tagging EC2 Instances Using Security
Groups. online, June 2009. available online:
http://www.shlomoswidler.com/2009/06/tagging-ec2-
instances-using-security 30.html.
[16] Sun Microsystems Inc. Take your business to a higher
level. available online https://www.sun.com/offers/details/
cloud computing primer.xml, 2009.