Softw Syst Model (2014) 13:825–841
DOI 10.1007/s10270-012-0252-1
REGULAR PAPER
Automatic data collection for enterprise architecture models
Hannes Holm · Markus Buschle ·
Robert Lagerström · Mathias Ekstedt
Received: 5 July 2011 / Revised: 9 April 2012 / Accepted: 21 May 2012 / Published online: 23 June 2012
© Springer-Verlag 2012
Abstract Enterprise Architecture (EA) is an approach used
to provide decision support based on organization-wide mod-
els. The creation of such models is, however, cumbersome as
multiple aspects of an organization need to be considered,
making manual efforts time-consuming, and error prone.
Thus, the EA approach would be significantly more prom-
ising if the data used when creating the models could be
collected automatically—a topic not yet properly addressed
by either academia or industry. This paper proposes network
scanning for automatic data collection and uses an exist-
ing software tool for generating EA models (ArchiMate is
employed as an example) based on the IT infrastructure of
enterprises. While some manual effort is required to make
the models fully useful to many practical scenarios (e.g., to
detail the actual services provided by IT components), empir-
ical results show that the methodology is accurate and (in its
default state) require little effort to carry out.
Keywords Enterprise architecture ·
Automatic data collection · Network scanning
1 Introduction
In recent years, Enterprise Architecture (EA) has become an
established discipline for business and software system man-
agement [1]. EA describes the fundamental artifacts of busi-
ness and IT as well as their interrelationships [1–5], typically
through dimensions such as business, application, technol-
Communicated by Prof. Richard Paige.
H. Holm (B) · M. Buschle · R. Lagerström · M. Ekstedt
Industrial Information and Control Systems,
Royal Institute of Technology, 100 44 Stockholm, Sweden
e-mail: hannesh@ics.kth.se
ogy and information [4]. Architecture models constitute the
core of the approach and serve the purpose of making the
complexities of the real world understandable and manage-
able [5]. EA ideally aids the stakeholders of the enterprise to
effectively plan, design, document, and communicate IT and
business related issues [6].
As these models are intended to provide reliable manage-
ment support it is imperative that they capture all the aspects
of an organization which are of relevance. Thus, the mod-
els often grow very large and contain several thousands of
entities and an even larger number of relationships between
these entities. The creation of such large models is often
both costly and time consuming, as various stakeholders are
involved and many different pieces of information have to be
gathered. During the creation process, the EA models are also
likely to become (partly) outdated [7]. Consequently, in order
to provide the best possible support, it needs to be ensured
that EA models both are holistic and reflect the organizations
current state.
Automatic data collection for model instantiation would
be preferable as this could mean a reduced modeling effort
and possibly an increased quality of the collected data. In
current EA initiatives, few approaches regarding data collec-
tion for the instantiation of models are proposed. In the most
wide-spread EA frameworks, little discussion regarding data
collection is available [2–4]. In the EA tools community,
there are some approaches that are somewhat applied. That
is, to either import models from third party software or allow
usage of SQL queries (or similar) in order to load information
from databases [8,9]. Both approaches however assume that
the modeled data is already available and updated (e.g., in
third party applications or databases). As the main problem
generally is to collect this data in the first place and these
approaches have this as a pre-condition, significant manual
effort is still required. In the research community, the focus
123
826
has been on proposing methods and principles for model
creation and maintenance [10–13]. None of these academic
initiatives have, however, yet resulted in actual implementa-
tion of automatic data collection for EA modeling, and none
have validated their proposed approaches.
This paper proposes the integration of network scanners
and EA tools in order to assist the data collection pro-
cess, especially for infrastructure assets, in EA modeling and
maintenance. The contribution presented in this paper is two-
fold. First, to show that integrating an EA modeling tool with
a network scanner can provide automatic data collection for
the modeling process. Second, to show that the information
in these models are correct in respect to the reality it is sup-
posed to model.
A pilot study of the proposed approach can be found in
[14]. This pilot study features automatic model generation
using network scanning for a more specific EA metamodel,
focusing on cyber security analyses. This pilot study some-
what illustrates the usefulness of the proposed approach for
an EA metamodel closely related to the metamodel of the
scanner. However, it does not thoroughly explore the reli-
ability or validity of the approach, or how useful it is for a
more general EA metamodel. This work explores the use-
fulness of the approach for a more general EA metamodel,
exemplified using ArchiMate, the arguably most wellknown
EA metamodel. The analysis cover multiple key areas of
EA modeling: (i) the comprehensiveness of the approach in
terms of covered ArchiMate concepts, (ii) how the ambigu-
ity in ArchiMate is handled, (iii) how much effort that can
be saved compared to manual modeling, (iv) how generated
models can be maintained, (v) how accurate gathered data
are, and (vi) the validity of the approach for EA metamodels
in general.
Empirical data collected through an experiment estimates
the accuracy and effort required to generate EA models
through the proposed approach. Aspects not statistically stud-
ied are discussed accordingly. The Enterprise Architecture
Analysis Tool [15] was extended in order to enable model
transformation between automated network scanning and the
ArchiMate metamodel.
The remainder of this paper is structured as follows: Sect. 2
presents related work. In Sect. 3 enterprise architecture meta-
models are introduced and the metamodel of the Archi-
Mate language is described. The following Sect. 4 presents
the concept of network scanners. Next, in Sect. 5 a map-
ping between the ArchiMate metamodel entities and network
scanner elements is proposed. The approach is studied by
analyzing empirical data from an experiment, as presented
in Sect. 6. This section also contains the actual instantia-
tions made through the approach. Section 7 discusses the
advantages and shortcomings of the approach, and guide-
lines for practical usage of it. Finally, Sect. 8 concludes the
paper.
123
H. Holm et al.
2 Related works
In the enterprise architecture community, there are few ini-
tiatives focusing on the data collection process for model
instantiation and maintenance. Among the most well-known
frameworks, data collection is almost completely left to the
modeler to handle. Some tool vendors provide support for
data collection. However, in most cases, it is required that the
needed information is compiled somewhere else, implying
that the data must be collected by someone at some point in
time. In the academic EA community, most researchers have
put their focus on deriving principles and designing methods
for model creation and maintenance. No researcher claims
to have the focus on automatic data collection. Regarding
automated network scanners, there is no previous work that
has estimated their accuracy in terms of finding software and
computer user accounts.
2.1 EA frameworks
There are many frameworks presenting and discussing EA
modeling [2–4]. However, none of these describe and discuss
the data collection process used when creating the architec-
ture models. No practical help is presented in these frame-
works regarding the data collection for as-is models or for
updating already existing models (maintaining the architec-
ture).
2.2 EA tools
In current EA tools, some approaches addressing automatic
data collection can be found. The most common way is to
import models that are made in third party software. For
example, BizzDesign Architect [8] can import data from
office applications and with this data instantiate models.
Thereby, the automation aspect actually means that data is
reused and does not need to be manually entered if it is already
available. The interpretation of data documented in the third
party software can however be resource- and time consum-
ing, thus contradicting parts of the purpose with automatic
data collection.
Troux [9], for example, allows the usage of SQL queries
in order to load information from databases. This approach
focuses on the extraction of the data model and process
descriptions, thereby the automatic creation of the informa-
tion architecture as well as the business architecture.
Both approaches assume that the data entered, in the
third party applications or databases, is already available and
updated. However, this data still needs to be manually col-
lected in the first place before it can be used. Thus, both
BizzDesign Architect and Troux can automatically instanti-
ate models, but not automatically collect the information in
the organization.
Automatic data collection for enterprise architecture models
MooD Business Architect [16] is another enterprise archi-
tecture modeling tool on the market. This tool has a com-
ponent called Synchronization Activation Technology that
enables import and export of data between architecture mod-
els and various data sources, for example, Microsoft Excel,
Microsoft SQL Server, and ODBC compliant databases.
However, all connections between architecture models and
data sources need to be deployed and managed manually.
Sousa et al. [10] presents the Blueprint Management
System (BMS), a software tool and methodology, used for
collecting architecture information. The tool collects data
from IT projects plans. This approach thus aims to pro-
vide automatic data collection for architecture models. The
approach is however still time consuming. Since the data doc-
umentation process still needs to be formalized according to
their specific format.
ARIS Business Architect for SAP [17] supports the reuse
and import of SAP process models out of the SAP Solution
Manager. This is similar to the method proposed in the pres-
ent paper as no manual interpretation of SAP data is needed
to generate EA models. An issue for the approach is how-
ever that not all organizations use SAP Solutions Manager.
In addition, the SAP process model does only cover cer-
tain parts of the complete enterprise architecture; while other
aspects of EA, such as infrastructure, are not considered. The
method proposed in the present paper can be applied to next
to any organization and involves collection of, in particular,
infrastructure assets. Thus, the method used by ARIS Busi-
ness Architect can be seen as a potential complement to the
proposed approach.
There are other IT management tools, such as Configu-
ration Management Data Bases (CMDBs) [18,19], available
that like scanners can collect information in an organization.
If these where to be integrated with an EA tool, the combi-
nation could be used for instantiating architectural models.
2.3 EA methods and principles
Buckl et al. [13] presents a Wiki-based approach to enter-
prise architecture documentation and analysis. According to
Buckl et al. companies who start an enterprise architecture
initiative usually do not have a pre-defined information model
for this. Many companies start with regular spreadsheets or
similar. Instead, Buckl et al. propose a Wiki-based approach
for collecting and sorting the information needed for enter-
prise architecture management. The main benefit with the
Wiki-approach is that the data collection is distributed but
still managed formally. Although the Wiki-based approach
proposed seems interesting there is still a need for data col-
lection to provide input to the Wiki.
In [12], an approach for handling change is proposed. The
approach is called Living Models and it is based on theories
of model based software development and enterprise archi-
827
tecture management. The idea is to connect IT management,
System Operation, and Software Engineering. According to
the author, three major research challenges have to be met in
order to materialize this: (i) provide a coherent view of the
quality status of the systems. (ii) Keep track of the quality
status as the systems evolve over time. (iii) Support the col-
laboration of stakeholders for achieving the necessary quality
level. Enterprise architecture models can be used to achieve
the first of the three challenges. Automatic data collection
would be appropriate for the second challenge. In the paper,
Breu presents ten principles that are crucial for Living Mod-
els. Principle no. 2—Close Coupling of Models and Code
states: “Models are generated out of the code (e.g. archi-
tecture models)”. This would mean automatic generation of
models at some architecture levels. Furthermore, Principle
no. 3—Bidirectional Information Flow between Models and
Code, focus on the idea that information from code can be
used to build models as well as information in models can
be used to generate code. Throughout the ten principles pat-
terns and metamodel elements are discussed supporting these
ideas. However, there is no tool today that can implement and
use these principles yet.
In [20], the focus is on the design of the enterprise architec-
ture. The main result is a framework for engineering driven
EA design and a software tool implementation of this frame-
work. There is no however description of the data collection
process for the instantiation of models. The design of EA in
[20] essentially concerns deriving the metamodel needed for
an enterprise. The software tool implementation proposed
is a tool incorporating the framework and metamodel. In
[21], the focus is on model maintenance and the main finding
reported in this publication is a discussion of the shortcom-
ings of existing model maintenance approaches. The authors
present a federated approach to deal with these shortcomings.
However, there is no discussion regarding the data collection
part of model maintenance.
2.4 Accuracy of automated network scanners
There is, to the authors knowledge, no previous work that has
studied the accuracy of automated network scanners’ regard-
ing the detection of software and user accounts. There are
however two studies on the topic of detecting vulnerabilities.
That is, Holm et al. [22] analyzed how many existing true vul-
nerabilities that are properly detected by scanners, and how
many non-existing vulnerabilities that are falsely reported by
them. In another study, Holm [23] also analyzed how many
vulnerabilities that would be removed if one would follow all
guidelines provided by vulnerability scanners’ (oftentimes
thousands of pages). None of these studies, however, evaluate
the scanners’ accuracy in terms of finding software and user
accounts—an objective of great importance towards measur-
ing the value of the proposed approach.
123
828
2.5 Analysis and conclusions
The EA frameworks available today, such as TOGAF and
the Zachman framework, provide very little data collection
support. The research initiatives have ideas and suggestions
for principles and methods regarding data collection support,
but none has implemented these ideas in any EA modeling
tool. When it comes to available EA modeling tools some,
like Troux and BizzDesign Architect, help the instantiation
of models based on data already existing in other softwares
or data bases. Thus, these do not help in collecting data in
the organization, they rather make use of data already avail-
able in other tools. Comparable to network scanners, CMDBs
also collect information about applications and their rela-
tions. However, we are aware of no approach that has inte-
grated a CMDB tool with an EA modeling tool. The only
comparable work found is the Blueprint Management Sys-
tem (BMS) that collects data from IT project plans in an orga-
nization. It is however unclear how accurate that the retrieved
information is and how the information in these IT project
plans is gathered and entered in the first place. For organi-
zations using SAP systems, Aris Business Architect can aid
in the collection and modeling on a business process level.
Thus, covering some of the EA layers and not the same layers
as covered by the scanner and tool presented in this paper.
These two might thus be complements to each other in order
to provide a more complete EA model.
3 Enterprise architecture metamodels
A main concept in enterprise architecture is the metamodel
which acts as a pattern for the instantiation of the architec-
tural models. In other words, a metamodel is a description
language used to create models [2,4,6,24].
Most EA tools have a built-in metamodel that guide the
modelers what elements to instantiate. Some tools allow
the users to change and define their own metamodels. In
research, there are several metamodels proposed. Lankhorst
[4] have probably published the most well-known and wide-
spread metamodel, called ArchiMate. There is also a set of
metamodels proposed focusing on different aspects of archi-
tectural analysis, e.g. modifiability [25], system quality anal-
ysis [26], interoperability [27], dependency analysis [28], and
business value analysis [29].
3.1 The ArchiMate metamodel
In this paper, the automatic data collection approach using
network scanners is instantiated with the ArchiMate meta-
model since it is an open, independent, and general model-
ing language for enterprise architecture. The primary focus
of ArchiMate is to support stakeholders how to address
123
H. Holm et al.
concerns regarding their business and the supporting IT
systems. ArchiMate is extensively presented in [4] and is
partly based on the ANSI/IEEE 1471-2000, Recommended
Practice for Architecture Description of Software-Intensive
Systems, also known as the IEEE 1471 standard [30]. The
Open Group accepted the ArchiMate metamodel as a tech-
nical standard [31] and as a part of The Open Group Archi-
tecture Framework (TOGAF) in 2009 [2].
The ArchiMate metamodel consists of three layers; the
Business layer, the Application layer and the Technology
layer. Where the technology supports the applications, which
in turn support the business. Each layer consists of a number
of entities and defined entity relationships.
The entities in each layer are categorized into three aspects
of enterprise architecture: (i) The passive structure—mod-
eling informational objects. (ii) The behavioral structure—
modeling the dynamic events of an enterprise. (iii) The active
structure—modeling the components in the architecture that
perform the behavioral aspects.
Figure 1 presents the ArchiMate metamodel. An overview
of the different types of relations in the language can be found
in Fig. 2; the entities utilized in the paper are described in
Sect. 5.2. For detailed descriptions, cf. [4].
4 Automated network scanning
An automated network scanner is an appliance or software
system that is used for scanning the architecture of a network
and reporting information regarding the network architec-
ture through TCP and UDP [32]. Network scanning involves
assessing which hosts are active on the network, what operat-
ing systems they use, what services they run, what application
clients that are installed and any users that have privileges
on the devices. Any device connected to the scanned net-
work can be probed; it does not matter if it is, for example, a
printer or a PC. Table 1 describes an overall list of the infor-
mation provided by a network scanner. Three major types
of data relevant for ArchiMate modeling can be collected:
(i) computer hardware and IP addresses, (ii) user accounts
present on a computer system, and (iii) software present on
a computer system. Such software includes operating sys-
tems or firmware, application servers (i.e., end-points), and
application clients. A few example signatures include Win-
dows XP SP2, SAP GUI 7.1 (the client for accessing SAP
applications), Oracle WebLogic Server Node Manager 10.3
and Apache HTTP Server 2.2. The signatures do however
unfortunately not always provide the correct results, which
in practice means that, e.g., Windows 2000 Service Pack 4
can be identified as Windows XP Service Pack 1 and Apache
Web-server 2.2.3 as Apache Web-server 2.0.0. Thus, it is of
importance to evaluate how accurate these estimates are.
Automatic data collection for enterprise architecture models 829

Information aspect Behavior aspect Structure aspect

Product Value

Represen- Contract Business Business

Business
Meaning tation Service Collaboration
Interface
Event

Business object Business

process/ Business role Business
function
Actor

Business
Application

Application Application Application

Service Interface Collaboration

Data Object
Application Application
Function/ Component
Interaction

Application

Technology

Infrastructure Infrastructure
Service Interface

Artifact Node Communication

path

System Software Device Network

Information aspect Behavior aspect Structure aspect

Fig. 1 The ArchiMate metamodel in the notation that was suggested in [4]

Fig. 2 An overview of Specialization Assignment Used by Association

relations available in the the
ArchiMate metamodel [4] Composition Realization Flow Junction

Aggregation Triggering Access

A network scan can be either authenticated or unauthen-
ticated. During an authenticated scan the scanner is given
authentication parameters (i.e., credentials) of systems to
enable more detailed and presumably also more accurate
scans. Authenticated scans are typically less disruptive on
deployed services as they do not need to probe as much
and thus are less intense. However, it is not always the
case that credentials are readily available for the individ-
ual(s) performing a scan and it can be seen as intrusive
as the systems’ local files are probed. This study assess

123
830
Table 1 The output of
automated scans Attribute
System information
MAC address
IP address
User information
User accounts on system
Software
Operating system type and version
Application server (i.e. end-point) port, protocol, type and version 80, HTTP, Apache HTTP Server 2.2.1
Application client type and version
the capability of both authenticated and unauthenticated
scans.
5 A framework for automatic EA model generation
In order to enable generation of EA models there is a need
to map, or relate, the metamodel of the data collection tool
(automated network scanning) to the chosen EA metamodel
(in this case ArchiMate). This chapter describes the method-
ology for relating ArchiMate to automated network scanning
and the aspects of the ArchiMate metamodel that are possi-
ble to instantiate. The data quality of an automated network
scanner is studied in Sect. 6.3. Other aspects of importance
towards the reliability and validity of the proposed approach
are discussed in Sect. 7.
5.1 Methodology for integrating ArchiMate and automated
scanning
The methodology for mapping the output of an automated
network scan and the ArchiMate metamodel involves two
parts: (i) a means of relating the metamodels, and (ii) a tool
for conducting the chosen translation.
The means of relating the metamodels during this project
was through manual effort by the researchers. The guidelines
of the ArchiMate metamodel [4] and the NeXpose scanner
[33] were utilized for this purpose (cf. Sect. 6). However, as
automated scanners have the same general content the trans-
lation process would be next to identical for any scanner.
An existing software tool1 [15] was extended to enable
a means of model transformation—automatically generating
models based on a chosen mapping. This tool consists of two
parts to be used in succession. The first component allows
the definition of metamodels (1 in Fig. 3). These metamodels
can either describe a certain system quality of interest or be
1 The software tool can be downloaded at http://www.ics.kth.se/eat.
123
H. Holm et al.
Example
000C290326CC
173.18.3.1
John Doe
Windows XP SP2
Adobe Reader 9.0
Fig. 3 The extension of the EA tool to enable the mapping presented
in Sect. 5
a general-purpose enterprise architecture metamodel such as
the one described in Sect. 3. EA models representing specific
scenarios are created utilizing the constraints defined in the
chosen metamodel (e.g., ArchiMate, 2 in Fig. 3).
The tool allows the definition of viewpoints as suggested
by [4]. Thereby subparts of the model can be formatted and
processed in so called views. They help to focus on the infor-
mation that is relevant for a certain domain or stakeholder
and hide aspects that are not important. As the metamodel of
ArchiMate is used, viewpoints are created according to the
layers and aspects that are specified in [4].
To use the results gained from an automated scanning
an extension of the tool was necessary. Automated network
scanning allows results to be exported into XML files (4 in
Fig. 3). The XML files are structured according to a schema
definition file (XSD) (3 in Fig. 3). The possibility to create
mappings between XSD files and metamodels (5 in Fig. 3)
was added in the tool in order to automatically instantiate
the metamodel based on a scanner’s XML files (6 in Fig. 3).
Figure 3 visualizes the discussed extension.
Automatic data collection for enterprise architecture models
Fig. 4 Definition of the mapping within the tool; the ArchiMate metamodel can be found to the left, the XSD describing NeXpose reports to the
right, and the specified mapping in the center
Each scanner has a slightly different way of denominating
concepts in the XSD, however, the main characteristics of a
XSD stay the same. Part of the XSD utilized by the scanner
NeXpose can be seen in Fig. 5. The model transformation is
carried out through specifying what aspects of the XSD that
should be mapped to what concepts in ArchiMate. Figure 4
illustrates how the mapping specification is done within the
tool. Once a mapping has been specified the scanner output
is parsed using the Document Object Model and thereaf-
ter queried using a self-developed algorithm. Based on the
result of the querying, the instantiated EA model is created.
An example translation, utilized in the present study, is given
in Sect. 6.1.
5.2 Translated concepts
The key characteristic in terms of translating contents of
the XSD and XML to the ArchiMate metamodel is that of
ambiguity. That is, the concepts of ArchiMate are, as other
enterprise architecture metamodels, possible to interpret in
many different ways. As a consequence, one type of map-
ping can be useful for one purpose and useless for another.
For example, some enterprises might not be interested in
modeling software such as Adobe Reader and Apache Web-
server, or computer system accounts such as “John Doe”.
Such an enterprise might only need data about larger appli-
cations such as SAP Solution Manager and Oracle Enterprise
831
Manager, and departments rather than computer user
accounts. Manual effort is needed to fulfill this type of
scenario. Naturally, more complex requirements need more
manual work for specifying the ruleset of the model trans-
formation.
The rest of this section describe the concepts of the Archi-
Mate metamodel that can be mapped to the output of an auto-
mated network scanner. The translation is due to the purpose
of this study carried out through the viewpoint of ArchiMate.
ArchiMate relations can be derived to connect all entities
modeled except business actors; the scanner’s metamodel
relates business actors to devices and system softwares, and
as ArchiMate prescribes relating business actors to services
this study does not consider it an adequate representation of
ArchiMate’s metamodel.
A Business Actor is an organizational entity capable of
(actively) performing behavior [4]. A scanner collects all user
accounts of computer systems. It is possible to relate these
different actors to, for example, departments. However, such
a mapping would naturally require additional effort from the
modeler performing the translation.
An Application Component is a modular, deployable, and
replaceable part of a system that encapsulates its contents
and exposes is functionality through a set of interfaces [4].
A scanner collects data on various application components
such as different ERP system modules and application clients
such as Adobe Reader.
123
832 H. Holm et al.

<xsd:complexType name="nodesType ">

<xsd:sequence>
<xsd:element name="node" type="nodeType " maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="nodeType ">
<xsd:sequence>
<xsd:element name="names" type="namesType " minOccurs="0"/>
<xsd:element name="fingerprints" type="fingerprintsType" minOccurs="0"/>
<xsd:element name="software" type="softwareType " minOccurs="0"/>
<xsd:element name="tests" type="testsType "/>
<xsd:element name="endpoints" type="endpointsType " minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="address" type="xsd:string"/>
<xsd:attribute name="status" type="nodeType_statusType "/>
<xsd:attribute name="hardware-address" type="xsd:string" use="optional"/>
</xsd:complexType>
<xsd:complexType name="namesType ">
<xsd:sequence>
<xsd:element name="name" type="xsd:string" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="fingerprintsType">
<xsd:sequence>
<xsd:element name="os" type="osType " maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="osType ">
<xsd:attribute name="certainty" type="xsd:string"/>
<xsd:attribute name="device-class" type="xsd:string" use="optional"/>
<xsd:attribute name="vendor" type="xsd:string"/>
<xsd:attribute name="family" type="xsd:string"/>
<xsd:attribute name="product" type="xsd:string"/>
<xsd:attribute name="version" type="xsd:string" use="optional"/>
<xsd:attribute name="arch" type="xsd:string" use="optional"/>
</xsd:complexType>

Fig. 5 An excerpt of the NeXpose XSD

An Application Interface declares how a component can
connect with its environment [4]. If a scanner finds an Appli-
cation Component running on an end-point (i.e., a port) it
will provide information about how it communicates (e.g.,
type of protocol).
A System Software is a software environment for specific
types of application components and data objects that are
deployed on it in the form of artifacts [4]. A scanner iden-
tifies several types of system software such as web servers
and operating systems.
An Infrastructure Interface is a point of access where the
functionality offered by a node can be accessed by other
nodes and application components [4]. A network scanner
details the protocol (e.g., SMTP) and port (e.g., 25) which a
software end-point utilizes. It is also used to relate an oper-
ating system the software employed on it.
A Device is a physical computational resource upon which
artifacts may be deployed for execution [4]. A network scan-
ner provides information about the hardware address and IP
address of a system.
A Network is a physical communication medium between
two or more devices [4]. As network scanners provide data
regarding IP addresses of computer systems it is possible to
detail networks.
All categories of the ArchiMate Structural aspects are thus
possible to map, and one of three parts of the metamodel’s
Behavioral aspects. All but one of these entities (System Soft-
ware) belong to the Structural aspects—which also is quite
logical, considering that an automated scanner only gathers
information available through remote queries on a computer
network.
6 Empirical study of the proposed approach
This section describes how the proposed approach was tested
through an experiment on an actual network. Due to the ambi-
guity of the ArchiMate metamodel (cf. Sect. 5.2) there is a
need to define the actual translation that is employed. The
translation which is used for the empirical study is described

123
Automatic data collection for enterprise architecture models
Table 2 Mapping of ArchiMate
entities and the output of ArchiMate entity
automated scans
Business actor
Infrastructure interface
System software (end-point)
Application component
System software (OS)
Device
Network
in Sect. 6.1. Section 6.2 provide details regarding the exper-
imental setup. Section 6.3 analyzes the reliability of the pro-
posed approach. Sections 6.4 and 6.5 provide descriptive
results about the models created during authenticated and
unauthenticated scans of the network. The scanner NeXpose
[33] was chosen as it has demonstrated good results in previ-
ous tests [22]. However, as almost all scanners have very sim-
ilar network scanning methodologies and signatures (built on
Nmap [34]) we believe that this study should be indicative of
the accuracy of other available automated network scanners
as well.
6.1 An example translation
This paper provides an example mapping that illustrates the
usefulness of the proposed approach. The exemplified trans-
lation covers all ArchiMate related information that a scanner
can provide, given that the a minimal manual effort is utilized
to perform the translation. That is, there has been no manual
effort conducted to, for example, detail any services provided
or to relate computer user accounts into groups. As a conse-
quence, it can be seen as a general type of mapping which
requires very little effort to perform. There was no focus
placed on more enterprise-critical systems such as ERP sys-
tems simply because this was not available in the experiment
network. The translation between scanner output (XML) and
ArchiMate input was handled through the software tool pre-
sented in Sect. 5.1, but any model transformation tool capable
of translating XML to ArchiMate concepts would suffice.
A summary of the utilized mapping can be seen in Table 2.
This mapping was made from the perspective of the Arch-
iMate metamodel as the purpose of the study is to evaluate
how enterprise architecture modeling can benefit from auto-
mated network scanning. Six different ArchiMate entities can
be automatically generated based on this framework, namely:
Business Actor, Infrastructure Interface, System Software
(Operating System and end-point), Application Component,
Device, and Network. Relations can be instantiated to con-
nect all entities except business actors, for reasons described
in Sect. 5.2.
833
Scanner output Example scan output
User account John Doe
Application protocol HTTP, FTP, SMTP
Application server Apache Web-server 2.2.3
Application client Adobe Reader 9.0
Operating system Windows XP SP2
IP, MAC addresses 172.18.1.3, 000C290326CC
A range of IP addresses 172.18.1.*
A Business Actor is translated as a user account on a com-
puter system. An application server is translated to a System
Software (end-point). An Application Component is mod-
eled as an application client residing on a scanned system
(for example, Adobe Reader 7.0). A System Software (OS) is
seen as the actual operating system employed on the probed
system. An Infrastructure Interface is modeled as the appli-
cation protocol of a System Software (end-point). It is also
needed to relate different Application Components to System
Software (OS). That is, a scanner does not detail the spe-
cific Infrastructure Interfaces between different Application
Components and System Softwares (OS)—but it is needed to
connect them. A Device is described through its IP and MAC
address. A Network is a range of IP addresses found during
the scan. For example, if the scanner finds IPs 172.18.3.2,
172.18.3.5 and 173.18.4.5 then two Network entities would
be instantiated—172.18.3.* and 172.18.4.*.
A more detailed version of the mapping between the
NeXpose XSD and the ArchiMate implementation in the
software tool used for the model transformation (cf. Sect. 5.1)
can be seen in Table 3. For example, a Device is instanti-
ated by the XSD concept “node (nodeType)”, denominated
through two of the attributes of this concept; “address” and
“hardware-address”. An overview of all relations instanti-
ated can be seen in Table 4. The directions of the relations
are described through their source entities and target entities,
using both ArchiMate terminology and NeXpose XSD ter-
minology. The reader is referred to Sect. 3 for information
about these types of relations.
6.2 The experimental setup
The main experimental setup was designed by the Swedish
Defence Research Agency with the support of the Swed-
ish National Defence College. The environment was set to
describe a simplified critical information infrastructure at a
small electrical power utility and was composed of 20 phys-
ical computer servers running a total of 28 virtual machines,
divided into four network segments. Various operating sys-
tems and versions thereof were used in the network, e.g.,
123
834 H. Holm et al.

Table 3 The implemented

ArchiMate NeXpose XSD
mapping between entities
Business Actor test (testType)
Name id
Free Text key
Name status
Required cifs-acct-password-never-expires
Infrastructure Interface endpoint (endpointType)
Name protocol
Name port
System Software fingerprint (service_fingerprint_Type)
Name product
Name From Parent service->name
Free Text –
Name version
Application Component fingerprint (fingerprintType)
Name product
Free Text –
Name version
System Software os (osType)
Name product
Free Text –
Name version
Device node (nodeType)
Name address
Free Text –
Name hardware-address
Infrastructure Interface fingerprint (fingerprintType)
Name product
Free Text –
Name version

Table 4 The implemented

mapping describing ArchiMate relation Source Target
relationships
Assignment Device System software
node (nodeType) fingerprint (service_fingerprint_Type)
Assignment Device System software
node (nodeType) os (osType)
Used by Application component Infrastructure interface
fingerprint (fingerprintType) fingerprint (fingerprintType)
The first row of each section Used by Infrastructure interface System software
show the related ArchiMate fingerprint (fingerprintType) os (osType)
concepts; the second the
Used by Infrastructure interface System software
corresponding NeXpose XSD
concepts endpoint (endpointType) fingerprint (service_fingerprint_Type)

123
Automatic data collection for enterprise architecture models
Windows XP SP2, Debian 5.0 and Windows Server 2003
SP1. Each host had several different network services oper-
ating, e.g. web-, mail-, media-, remote connection- and file
sharing services. More information about the environment
can be found in [35,36].
6.3 Data quality provided by the scanner
Accuracy is something of great importance towards the
reliability of the proposed approach. If the output from an
automated network scanner is erroneous then the resulting
generated EA model(s) will not be reliable. Some aspects
can however be more important than others. For instance, it
is typically of great importance that the correct applications
and systems are identified; but it might not be important that
their actual version numbers are correct.
This study assesses the accuracy of Devices, System Soft-
wares, Application Components and Infrastructure Inter-
faces. The accuracy of Business Actors was unfortunately
not possible to study due to that the virtual images of the stud-
ied systems were mistakenly manipulated before many users
had been manually logged. However, the difference between
the number of generated Business Actors during authenti-
cated (cf. Sect. 6.4) and unauthenticated (cf. Sect. 6.5) scans
display the relative difference between the two scan types.
Also, the accuracy of the Network entity was not assessed as
all the Devices in the network were part of the same LAN—
thus only generating a single Network entity (with relations
to all devices). Several important concepts not available in
the current ArchiMate metamodel were also analyzed: as
it can be valuable for enterprises to know the versions of
their software (e.g., for patch management), the accuracy
of System Software versions and Application Component
versions were also assessed. All Devices, System Softwares
(OS), System Software (end-point) and Infrastructure Inter-
faces in the experimental setup were analyzed. Studied client-
side Application Components were however selected from
the entire pool of available software clients through simple
random sampling as there were too many to study all such
components.
An accurate assessment is one that is correct, i.e., if a
system has the System software Windows XP with Service
Pack 2 and it is identified as Windows XP Service Pack 1
then it will be accurate in terms of System Software (OS), but
inaccurate in terms of System Software (OS version). Thus,
the accuracy of the different variables are the mean values
of independent sequences of correct/incorrect (0/1) answers.
These characteristics make it reasonable to assume binomial
distributions, fulfilling the requirements for performing two-
tailed hypotheses testings of the assessed results. When a
p value is mentioned in this chapter it refers to results from
two-tailed hypothesis tests [37]. The p value is used to
explain the statistical difference between sources of data,
835
and a p-value of less than 0.05 is a commonly used refer-
ence value for claiming that there is a significant difference
between the compared sources of data. A p value of less than
0.05 implies that there is less than 5 % probability that the
assessed differences between two or more sources of data are
due to random variation.
As can be seen in Table 5, authenticated scanning is
equally accurate or more accurate than unauthenticated scan-
ning in all aspects. Application Components show extremely
significant differences due to that client-side software (the
tested type of Application Component) cannot be assessed
without giving the scanner credentials. The authenticated
scan is also clearly better suited for assessing version num-
bers of System Software, but fairly similar when it comes to
the type of System Software. The statistical tests support this
assessment; there were significant differences when assess-
ing System Software (OS version) ( p = 0.0089) and System
Software (end-point version) ( p < 0.001) but no significant
differences for System Softwares (OS) (100 % for both types
of scans) and System Software (end-point) ( p = 0.27).
6.4 Model created using an authenticated scan
An authenticated automated scan was performed on the archi-
tecture described in Sect. 6.2 using NeXpose. The resulting
model consists of 110 Application Components, 335 Infra-
structure Interfaces, 890 Business Actors (the large major-
ity of these actors on the server systems, e.g. a dns server,
a web server and a mail server), 28 Devices, 195 System
Softwares (of which 28 for operating systems), 1 Network,
and 679 relations between them. These entities and relations
were instantiated through the mapping described in Sect. 5.
Figure 6 graphically illustrates the result for one of the sys-
tems (172.18.2.15). While the complete model is too large
to display in the paper, the interested reader is welcome to
receive it through contact with the authors.
6.5 Model created using an unauthenticated scan
The generated model from an unauthenticated automated
scan can be seen in Fig. 7 (the Device 172.18.2.15). The
resulting model consists of 227 Infrastructure Interfaces, 106
Business Actors, 28 Devices, 198 System Softwares (28 of
which were operating systems), 1 Network, and 462 relations
between them. As for the model generated by the authenti-
cated scan, the interested reader is welcome to contact the
authors. While the accuracy of Business actors could not be
evaluated, it is clear that the authenticated scan is much more
potent in this aspect (890 compared to 106 generated Busi-
ness Actors).
123
836
Table 5 Accuracy of unauthenticated and authenticated scans for different types of automatically assessed ArchiMate related data
Variable Accuracy unauth. (%)
Device 100.00
System software (OS) 100.00
System software (OS version) 62.50
Infrastructure interface 89.66
System software (end-point version) 67.33
Application component 0.00
Application component (version) 0.00
a Not possible to compute
7 Discussion
This chapter critically examines the applicability of the
approach proposed in this paper.
Automated network scanning can only instantiate a subset
of all the entities in common EA metamodels It is true that one
only can assess a subset of the entities that are of relevance
for an EA model. Most of the entities in the structural aspects
in the ArchiMate metamodel are however possible to gener-
ate. Furthermore, the IT part of an EA model are often the
most labour-intensive to model due to the large multiplicities
involved (e.g., all software in an office LAN) and an auto-
mated scan alleviates most of the manual work required to
do this. Thus, it can be seen as a potent way to save resources
in terms of modeling.
Automated network scanning can only identify software
that it has signatures for If an organization has deployed soft-
ware that is not commercial-of-the-shelf, the scanner will not
be able to correctly identify them (as there are no signatures
to identify them). At best, such a software will be denoted as
“unknown” by the scanner; at worst, it will be identified as
the wrong product. To manage this type of scenario, there is
a need to manually model these types of software.
Automated network scanning provides too detailed infor-
mation EA is typically seen as a tool for understanding the
“big picture”; whereas network scanners mainly collect data
on IT infrastructure components. Thus, much of the infor-
mation provided by scanners would be omitted by many
EA initiatives. For example, some enterprises might want
to generate models describing only enterprise applications
such as SAP Solution Manager and Oracle Enterprise Man-
ager rather than all infrastructure assets. An important task
for such enterprises when employing automated scanning for
generation of EA models is thus to delimit the information
provided by the scanner. Luckily, as software are uniquely
identified in the scanner output it is very simple and requires
little effort to add a filter that describes what software to
model, and what software not to model. We believe that this
constitutes an advantage for the proposed approach; it can
satisfy a range of user needs, from those whom only might
123
H. Holm et al.
Accuracy auth. (%) p value Samples
100.00 a 28
100.00 a 28
100.00 0.0089 28
91.38 0.66 116
92.00 <0.001 110
100.00 <0.001 48
100.00 <0.001 48
want to model the most enterprise significant concepts to
those who require very detailed views of their architectures
(e.g., when the EA goal is to manage IT cost or IT security).
Naturally, more complex architecture models also require
more focus on useful model viewpoints.
Ambiguity A challenge for the individual(s) performing
the translation between scanner output and EA metamodel
input is the general ambiguity of EA metamodels. That is, one
concept can be interpreted many different ways. An example
of this property is the ArchiMate concept Business Actor.
This entity can, for example, describe either an individual or
a department. An automated scanner finds Business Actors
on a level of accounts on computer systems, an abstraction
level that typically imply an individual rather than a depart-
ment. As noted in the previous paragraph, it is possible to
customize the output of a scanner; for example, to relate dif-
ferent individuals to departments. However, more complex
requirements need more manual effort to implement.
How much time can be saved using this approach?
Närman et al. [38] presents a study on data quality using
ArchiMate in which 20 entities (Application Components,
Application Services, Business Processes and Data Objects)
and 19 relations were instantiated. One task in their study was
to measure how much time it took to perform this modeling.
A comparison of these results and the results from modeling
through automated scanning (both authenticated and unau-
thenticated) can be seen in Table 6. The time necessary for
deploying and tuning the scanner, and the time required to
perform the mapping, are not part of this table as we did not
formally capture them; however, we estimate that the deploy-
ment and tuning of the scanner took about 2 h, and that the
model mapping required approximately 3 h. Notable is that
the majority of the effort required to manage these aspects
correspond to their deployment: once a scanner has been
deployed and tuned only minor effort is typically required
to re-tune it for future scans. Similarly, future changes of a
metamodel typically require minor effort compared to the
first mapping.
Although a simple comparison such as this is highly infor-
mal and too simplistic (e.g. different entities and relations
Automatic data collection for enterprise architecture models
Fig. 6 A node in the model
generated by an authenticated
scan
require various effort to model and effort does not likely
scale linearly with entities/relations), it clearly highlights the
applicability of automatic modeling—it is simply less time-
consuming than manual modeling. A notable limitation of the
current implementation of the proposed approach is however
that the result from a new scan cannot be appended to a pre-
837
vious one; each new scan generates a completely new model.
This is an issue which we aim to address in the future.
Automated network scanning only generates models rep-
resenting single points in time This problem is however pres-
ent also for manual approaches—but in a much more evident
way as it is more resource demanding and thus unlikely to be
123
838 H. Holm et al.

Table 6 Comparison of modeling effort in hours (hh) and minutes (mm)

for the proposed approach and results by Närman et al. [38]
Variable Time Entities Relations
(hh:mm)

Modeling by Närman et al. [38] 5:12 20 19

Modeling using an authenticated scan 3:08 1,558 679
Modeling using an unauthenticated scan 1:23 558 462

carried out as often. Updating a model through an automated

Fig. 7 node in the model generated by an unauthenticated scan
scan could in theory, given a network such as the one in this
study, be carried out every second (unauthenticated) or third
(authenticated) hour.
Data quality of an automated scan The quality provided
using automated scanning seems to be very high in general.
However, the best results are provided through authenticated
scanning as it is difficult to identify users and not possible
to identify client-side application components (e.g., Adobe
Reader) with unauthenticated scanning. Additionally, soft-
ware version assessments are significantly more accurate
( p < 0.01) with this type of scan. One must furthermore
keep in mind that also manual data collection suffers from
data quality problems.
How can “the rest” of ArchiMate’s metamodel be auto-
matically generated? A few other practically applicable ways
to automatically generate models are presented in Sect. 2.
We believe that these approaches show that the EA research
field is beginning to grasp the importance of resource-effec-
tive generation and maintenance of models. The current
approaches are already able to instantiate (if correctly imple-
mented) much of the EA metamodel concepts. However,
there are still ample work that need to be carried out. The
proposed approaches (including ours) all have several draw-
backs and instantiated models need to be interpreted with
care.
Generalizing the approach to other EA metamodels The
proposed approach have been tested both against a general
EA metamodel (ArchiMate) and a more specific EA meta-
model for cyber security analysis [14]. Both studies show
sound results, and as such there is no reason to believe that
automated network scanning cannot be used to gather data
also for other EA metamodels (e.g., [2,3]).
Automated network scanning can cause denial of service
issues Sometimes scanners affect the services they probe.
It happened in the study presented in this paper when a
Debian 5.04 firewall was configured with many unneces-
sary services running. In order to scan this device and its
subnets without disruptions all non-critical services had
to be removed. Thus, automated scanning should be used
with care in environments with high availability require-
ments. Valuable non-redundant IT assets with high availabil-
ity requirements should be delimited from scans and instead
be manually modeled.

123
Automatic data collection for enterprise architecture models
Validity and reliability of the field test The network archi-
tecture tested was a virtual environment. Using a virtual
environment can decrease performance, among other things
packet loss. This problem is however mainly evident in very
large virtual environments and not small subnets as evaluated
in this study, and should thus be a minor issue [39–41]. This
study can only evaluate the automated scanners ability to
assess the entities in the studied network architecture, which
only covers a very small amount of the operating systems,
external-, and local application services that are currently
available on the market. The different products implanted
in the network architecture were however of diverse nature.
Thus, we believe that this study gives a good hint towards
the general accuracy of an automated network scan. A short-
coming of the experiment is that it did not evaluate the effort
required to specify large scale applications and application
suits such as customer relationship management systems,
geographical information systems, and asset management
systems. This delimitation was chosen as there were no such
systems in place in the experiment network. In terms of accu-
racy this delimitation should have a very minor influence;
there is no reason to believe that there is a difference in accu-
racy for such components compared to what was addressed
during the experiment. The required effort depends much
on the requirements by the modeler. That is, it would not
take more than a minute’s effort to only generate ArchiMate
concepts for e.g. the vendor SAP; whereas relating different
user accounts to departments might be very time consuming
(depending on the amount of users and departments).
8 Conclusions
This paper proposes a method for automatic generation of
EA models with respect to the complex IT architectures
of enterprises. A previous study tested the approach on an
EA metamodel for cyber security analysis [14]. The pres-
ent study mapped the metamodel of ArchiMate to the output
of automatic network scanners. The proposed method was
empirically investigated through studying several different
variables: (i) how reliable results the method provides, (ii)
how much of the metamodel context that is captured and (iii)
how resource efficient the proposed method is. The proposed
method offers reliable results, especially when the scanner
is given system credentials. The generated entities can rep-
resent different ArchiMate interpretations, depending on the
stated requirements (cf. Sect. 5).
There are several implications of this study, of which the
arguably most important are: This study clearly displays
the need for, and applicability of, automatic data collec-
tion for EA models. Furthermore, it provides both academia
and industry with a readily available model transformation
tool for the purpose of automatic generation of EA models
839
(cf. Sect. 5.1) capable of reducing large amounts of effort.
As an automated network scanner is used by most organi-
zations and some scanners are available for free (e.g. [34])
the required resources to implement the proposed approach
should be small.
8.1 Future work
There are however some issues with the proposed approach
that should be further researched. Different enterprises (and
environments) will likely require various degrees of man-
ual effort in terms of specifying the mapping and manag-
ing generated models. One method for decreasing the effort
for the modeler could be to create a set of common default
mappings that could be more easily manipulated to suit the
needs of different contexts. Another option could be to have
a detailed guide for usage of the model (some foundations
for such a guide could be the contents of Sect. 7). We believe
that the optimal solution lies with a mix of these methods,
but that it depends on the general requirements of differ-
ent enterprises and the manual effort needed to fulfill these
requirements. That is, if most enterprises have a few key
requirements that need major effort to manage, it would be
beneficial to have default mappings that fulfills these needs.
Similarly, if the requirements by each enterprise are unique,
most effort should be spent to specify a user-friendly guide
for mapping. In future work we aim to analyze these aspects
through case studies at different enterprises.
In terms of future work for automatic generation of EA
models in general, there are various aspects that are of impor-
tance. A number of significant topics have been discussed in
this paper: (i) how comprehensive the approach is (e.g., in
terms of covered ArchiMate concepts), (ii) how the transla-
tion is managed (e.g., in terms of ambiguity), (iii) how much
effort that is required (and can be saved), (iv) how generated
models can be maintained, and (v) how accurate the gath-
ered data are. Future work should focus on aspects that are
cumbersome to model and maintain manually, yet available
to collect with little effort in most enterprises. As a first step
to enable such work, a collection of commonly required data
that are cumbersome to model should be compiled. This col-
lection could then be used to identify the key areas in terms
of automatic data collection support. As discussed in the pre-
vious paragraph, it could also enable default mappings that
could significantly improve the usability of existing solutions
such as MooD Business Architect [16].
Future work would also benefit from mapping to a holis-
tic data collection methodology. A common standard would
enable comparisons of different approaches in terms of, for
example, EA metamodel comprehensiveness, data sources,
and actors required to involve when gathering and maintain-
ing data. Unfortunately, there are no such accepted standard
123
840
as of yet. While a methodology such as Living Models
[12,42] (cf. Sect. 2.3) could become a standard for catego-
rization of automatic data collection methods, it (and others
like it) is currently not tailored for categorizations. Thus,
future research should also address categorization of data
collection methods for EA models.
References
1. Ross, J.W., Weill, P., Robertson, D.: Enterprise Architecture As
Strategy: Creating a Foundation for Business Execution. Harvard
Business School Press, Boston (2006)
2. The Open Group: The Open Group Architecture Framework
(TOGAF), version 9, The Open Group (2009)
3. Zachman, J.A.: A framework for information systems architecture.
IBM Syst. J. 26, 276–292 (1987)
4. Lankhorst, M.M.: Enterprise Architecture at Work: Modelling,
Communication and Analysis, 2nd edn. Springer, Berlin (2009)
5. Winter, R., Fischer, R.: Essential layers, artifacts, and dependencies
of enterprise architecture. J. Enterp. Archit. 3, 7–18 (2007)
6. Kurpjuweit, S., Winter, R.: Viewpoint-based meta model engineer-
ing. In: Enterprise Modelling and Information Systems Architec-
tures (EMISA 2007)
7. Aier, S., Buckl, S., Franke, U., Gleichauf, B., Johnson, P.,
Närman, P., Schweda, C., Ullberg, J.: A survival analysis of appli-
cation life spans based on enterprise architecture models. In: 3rd
International Workshop on Enterprise Modelling and Information
Systems Architectures, Ulm, Germany, pp. 141–154 (2009)
8. BiZZdesign: BiZZdesign Architect. http://www.bizzdesign.com
(2011). Accessed on March 2011
9. Troux Technologies: Metis. http://www.troux.com/products/
(2011). Accessed on March 2011
10. Sousa, P., Lima, J., Sampaio, A., Pereira, C.: An approach for cre-
ating and managing enterprise blueprints: a case for it blueprints,
Advances in Enterprise Engineering III. Lecture Notes Bus. Inf.
Process. 34, 70–84 (2009)
11. Hafner, M., Winter, R.: Processes for enterprise application archi-
tecture management. In: Proceedings of the 41st Hawaii Interna-
tional Conference on System Sciences, pp. 396–406 (2008)
12. Breu, R.: Ten principles for living models—a manifesto of change-
driven software engineering. In: International Conference on Com-
plex, Intelligent and Software Intensive Systems, pp. 1–8 (2010)
13. Buckl, S., Matthes, F., Neubert, C., Schweda, C.M.: A wiki-based
approach to enterprise architecture documentation and analysis.
In: 17th European Conference on Information Systems, pp. 1–13
(2009)
14. Buschle, M., Holm, H., Sommestad, T., Ekstedt, M., Shahzad, K.:
A tool for automatic enterprise architecture modeling. In: Proceed-
ings of the CAiSE Forum 2011, pp. 25–32 (2011)
15. Buschle, M., Ullberg, J., Franke, U., Lagerström, R., Sommes-
tad, T.: A tool for enterprise architecture analysis using the PRM
formalism. In: CAiSE2010 Forum PostProceedings, pp. 108–121
(2010)
16. MooD International: MooD Business Architect. http://www.
moodinternational.com/ (2012). Acessed on March 2012
17. Software AG: ARIS for SAP. http://www.softwareag.com/corpo
rate/products/aris_platform/aris_implementation/aris_sap (2011)
18. Lokomo Systems AB: OneCMDB. http://www.onecmdb.org
(2011)
19. FrontRange Solutions: FrontRange CMDB. http://www.front
range.com/cmdb.aspx (2011)
123
H. Holm et al.
20. Aier, S., Kurpjuweit, S., Saat, J., Winter, R.: Enterprise archi-
tecture design as an engineering discipline. AIS Trans. Enterp.
Syst. 1(1), 36–43 (2009)
21. Fischer, R., Aier, S., Winter, R.: A federated approach to enter-
prise architecture model maintenance. Enterp. Modell. Inf. Syst.
Archit. 2(2), 14–22 (2007)
22. Holm, H., Sommestad, T., Almroth, J., Persson, M.: A quantita-
tive evaluation of vulnerability scanning. Inf. Manage. Comput.
Secur. 19(4), 231–247 (2011)
23. Holm, H.: Performance of automated network vulnerability scan-
ning at remediating security issues. Comput. Secur. 31(2), 164–
175 (2012)
24. Johnson, P., Ekstedt, M.: Enterprise Architecture—Models and
Analyses for Information Systems Decision Making, Studentlit-
teratur (2007)
25. Lagerström, R., Johnson, P., Ekstedt, M.: Architecture analysis
of enterprise systems modifiability—a metamodel for software
change cost estimation. Softw. Qual. J. 18, 437–468 (2010)
26. Närman, P., Johnson, P., Nordström, L.: Enterprise architecture: a
framework supporting system quality analysis. In: Proceedings of
the International Annual Enterprise Distributed Object Computing
Conference, pp. 130–142 (2007)
27. Ullberg, J., Lagerström, R., Johnson, P.: A framework for service
interoperability analysis using enterprise architecture models. In:
IEEE International Conference on Services Computing, pp. 99–107
(2008)
28. Franke, U., Flores, W.R., Johnson, P.: Enterprise architecture
dependency analysis using fault trees and bayesian networks. In:
Proceedings of 42nd Annual Simulation Symposium (ANSS), pp.
209–216 (2009). http://www.scs.org
29. Gustafsson, P., Höök, D., Ericsson, E., Lilliesköld, J.: Analyzing
IT impacts on organizational structure—a case study, In: Port-
land International Center for Management of Engineering and
Technology (PICMET) Conference Proceedings, pp. 3197–3210
(2009)
30. IEEE: 1471–2000—IEEE Recommended Practice for Architec-
tural Description for Software-Intensive Systems (2000). http://
standards.ieee.org
31. The Open Group: ArchiMate 1.0 Specification (2009). http://www.
opengroup.org/archimate
32. Manzuik, S., Pfeil, K., Gold, A., Gatford, C.: Network security
assessment: from vulnerability to patch, Syngress (2006)
33. Rapid7: Nexpose. http://www.rapid7.com (2011)
34. Network mapper: Nmap. http://nmap.org (2011)
35. Hammervik, M., Andersson, D., Hallberg, J.: Capturing a cyber
defence exercise. In: Proceedings of the Symposium on Technol-
ogy and Methodology for Security and Crisis Management, p. 36
(2010)
36. Geers, K.: Live fire exercise: preparing for cyber war. J. Homeland
Secur. Emerg. Manage. 7(1), 74 (2010)
37. Warner, R.: Applied statistics: from bivariate through multivariate
techniques. Sage Publications, Inc, Thousand Oaks (2008)
38. Närman, P., Holm, H., Johnson, P., König, J., Chenine, M.,
Ekstedt, M.: Data accuracy assessment using enterprise architec-
ture. Enterp. Inf. Syst. 5(1), 37–58 (2011)
39. Ye, K., Jiang, X., Chen, S., Huang, D., Wang, B.: Analyzing and
modeling the performance in xen-based virtual cluster environ-
ment. In: 2010 12th IEEE International Conference on High Per-
formance Computing and Communications, IEEE, pp. 273–280
(2010)
40. McDougall, R., Anderson, J.: Virtualization performance: per-
spectives and challenges ahead. ACM SIGOPS Oper. Syst.
Rev. 44(4), 40–56 (2010)
41. Wang, G., Ng, T.: The impact of virtualization on network perfor-
mance of amazon ec2 data center. In: INFOCOM, 2010 Proceed-
ings IEEE, IEEE, pp. 1–9 (2010)
Automatic data collection for enterprise architecture models 841

42. Farwick, M., Agreiter, B., Breu, R., Ryll, S., Voges, K., Hanschke, tainability, IT-management, also he is a co-author of the book Enterprise
T.: Automation processes for enterprise architecture management. Architecture: Models and Analyses for Information Systems Decision
In: 2011 15th IEEE International Enterprise Distributed Object Making. Robert is a partner and consultant at Management Doctors, an
Computing Conference Workshops, IEEE, pp. 340–349 (2011) IT-management consultancy firm.

Mathias Ekstedt is Associate

Author Biographies
Hannes Holm is a PhD stu-
dent at the department of Indus-
trial Information and Control
Systems at the Royal Insti-
tute of Technology (KTH) in
Stockholm, Sweden. He received
his MSc degree in management
engineering at Luleå Univer-
sity of Technology. His research
interests include enterprise secu-
rity architecture and cyber
security regarding critical infra-
structure control systems.
Professor at the Royal Institute
of Technology (KTH) in Stock-
holm, Sweden. His research
interests include systems and
enterprise architecture modelling
and analyses with respect to
information and cyber security,
in particular for the domain of
Power system management. He
is the manger of the program
IT Applications in Power System
Operation and Control within the
Swedish Centre of Excellence in
Electric Power Engineering and
technical coordinator of the EU FP7 project VIKING. He is the foun-
der of the architecture network at the Swedish Computer Society. He
received his MSc, PhD, and Docent from the Royal Institute of Tech-
nology in 1999, 2004, and 2010, respectively.

Markus Buschle received his

MSc degree in computer sci-
ence at TUB, Berlin Institute
of Technology, Germany. He is
currently a PhD student at the
department Industrial Informa-
tion and Control systems at the
Royal Institute of Technology
(KTH) Stockholm, Sweden. His
research focuses on the tool
based performance of enterprise
architecture analysis.

Robert Lagerström received

his PhD degree in Industrial
Information and Control Sys-
tems in 2010 and his MSc
degree in Computer Science in
2005, both at the Royal Insti-
tute of Technology (KTH) in
Stockholm, Sweden. His topic
of research as a PhD student
was Enterprise Architecture and
software systems maintainabil-
ity. In 2010–2011, Robert was an
Industrial Post-Doc at ABB Cor-
porate Research and currently he
is working as an assistant profes-
sor at KTH. At KTH Robert is responsible for the course “IT Manage-
ment with Enterprise Architecture II, case studies”. In addition to that he
supervises master thesis and PhD students. Robert has written a number
of academic publications in the field of enterprise architecture, main-

123