(Computer Science, Technology and Applications) Frederik L. Sørensen (Editor) - Enterprise Architecture and Service-Oriented Architecture (2020)

COMPUTER SCIENCE, TECHNOLOGY AND APPLICATIONS
ENTERPRISE ARCHITECTURE
AND SERVICE-ORIENTED
ARCHITECTURE
No part of this digital document may be reproduced, stored in a retrieval system or transmitted in any form or
by any means. The publisher has taken reasonable care in the preparation of this digital document, but makes no
expressed or implied warranty of any kind and assumes no responsibility for any errors or omissions. No
liability is assumed for incidental or consequential damages in connection with or arising out of information
contained herein. This digital document is sold with the clear understanding that the publisher is not engaged in
rendering legal, medical or any other professional services.
COMPUTER SCIENCE, TECHNOLOGY
AND APPLICATIONS
Additional books and e-books in this series can be found

on Nova’s website under the Series tab.
COMPUTER SCIENCE, TECHNOLOGY AND APPLICATIONS
ENTERPRISE ARCHITECTURE
AND SERVICE-ORIENTED
ARCHITECTURE
FREDERIK L. SØRENSEN
EDITOR
Copyright © 2020 by Nova Science Publishers, Inc.
All rights reserved. No part of this book may be reproduced, stored in a retrieval system or transmitted
in any form or by any means: electronic, electrostatic, magnetic, tape, mechanical photocopying,
recording or otherwise without the written permission of the Publisher.
We have partnered with Copyright Clearance Center to make it easy for you to obtain permissions to
reuse content from this publication. Simply navigate to this publication’s page on Nova’s website and
locate the “Get Permission” button below the title description. This button is linked directly to the
title’s permission page on copyright.com. Alternatively, you can visit copyright.com and search by
title, ISBN, or ISSN.
For further questions about using the service on copyright.com, please contact:
Copyright Clearance Center
Phone: +1-(978) 750-8400 Fax: +1-(978) 750-4470 E-mail: info@copyright.com.
NOTICE TO THE READER

The Publisher has taken reasonable care in the preparation of this book, but makes no expressed or
implied warranty of any kind and assumes no responsibility for any errors or omissions. No liability is
assumed for incidental or consequential damages in connection with or arising out of information
contained in this book. The Publisher shall not be liable for any special, consequential, or exemplary
damages resulting, in whole or in part, from the readers’ use of, or reliance upon, this material. Any
parts of this book based on government reports are so indicated and copyright is claimed for those parts
to the extent applicable to compilations of such works.
Independent verification should be sought for any data, advice or recommendations contained in this
book. In addition, no responsibility is assumed by the Publisher for any injury and/or damage to
persons or property arising from any methods, products, instructions, ideas or otherwise contained in
this publication.
This publication is designed to provide accurate and authoritative information with regard to the subject
matter covered herein. It is sold with the clear understanding that the Publisher is not engaged in
rendering legal or any other professional services. If legal or any other expert assistance is required, the
services of a competent person should be sought. FROM A DECLARATION OF PARTICIPANTS
JOINTLY ADOPTED BY A COMMITTEE OF THE AMERICAN BAR ASSOCIATION AND A
COMMITTEE OF PUBLISHERS.
Additional color graphics may be available in the e-book version of this book.
Library of Congress Cataloging-in-Publication Data
ISBN:
Published by Nova Science Publishers, Inc. † New York

CONTENTS
Preface vii
Chapter 1 Enterprise Architecture Alignment 1
Peter Filet, Rogier van de Wetering
and Stef Joosten
Chapter 2 Enterprise Architecture Knowledge
Transfer and Organizational Empowerment 41
Klaus Østergaard and Torben Tambo
Chapter 3 Application of SOA with Cloud Computing 75
Farrukh Arslan
Chapter 4 Microservice Architecture 99
Nikolay Mladenov
Index 115
PREFACE
An enterprise architecture is an instrument that focuses on coherence

between business processes, information distribution, and technology
infrastructure of an organization. In this compilation, the authors begin by
creating and subsequently discussing an artifact that provides architects
with the capability of monitoring validity within ArchiMate enterprise
architecture models.
Next, it is suggested that business specialists and enterprise architects
can benefit from collocated training, and that training activities in
enterprise architecture are both one-off training and recurring training,
where the latter is providing a community of practice.
The authors consider ideas that may make it easier for organizations to
realize the potential benefits of service-oriented architectures and cloud
computing, as one of the challenges for software engineers today is
keeping up with the rapid changes in technology.
The major features underlying microservice architecture are examined,
particularly the advantages and the disadvantages of their technologies and
implementation. This analysis also highlights the major capabilities of
microservices in driving future advances in the software and hardware
industries.
Chapter 1 - An Enterprise Architecture (EA) is an instrument that
focuses on coherence between business processes, information distribution,
viii Frederik L. Sørensen
and technology infrastructure of an organization. In practice, the authors

see that architects are not well equipped to manage the interrelationship
between architectural business-, information- and technology-aspects in an
integrated fashion. EA frameworks are mostly informal by nature, and
there is a lack of knowledge and tools to support architects to check
alignment formally. Due to the volume and complexity of holistic
enterprise spanning architecture, it is increasingly challenging for
organizations to maintain overview and coherence of architectural
elements. This research enables automated, rule-based monitoring
consistency and coherence between elements within an EA. It does so by
creating an artifact that provides architects with the capability of
monitoring validity within ArchiMate EA models. The authors validate
models against formalized rules specified in Relation Algebra with which
coherence can be mathematically proven. The authors also plot a set of
applied rules onto a quality framework that calculates an overall alignment
score of an EA model. Every single rule violation that influences the score
is explicitly identified. Monitoring EA quality using formalized rules
enables organizations to manage and control the process of EA change and
thus contributes to Business/IT-alignment.
Chapter 2 - Enterprise Architecture (EA) is becoming increasingly
critical to organizations amid momentum in interest for digital
transformation (DT) essential for strategic corporate agendas. EA has
traditionally largely resided in the strategic planning environments of the
technology management functions of organizations. This has limited the
general understanding of architecture and the insight from business units in
opportunities and limitations of existing and future technological solutions.
In this chapter, it is discussed how initiatives can be taken to bring more
attention to the business units on EA and to incite architectural thinking.
Central is training and coaching of corporate decision makers, strategic
business planners, financial specialists, business developers, line managers
and generally non-IT-profiles in architectural artifacts, structure,
interrelationships, abstract levels and management. Architectural thinking
relates to foundations, structure, sequence, prioritization, and precision in
the formulation of expected outcomes. Key means, relate to conversion.
Preface ix
Conversion from business architecture to technology architecture and vice

versa. Also, conversion from thinking in existing technologies to
technologies of opportunity for digital transformation within existing and
new business models. Consequences of change must be trained carefully as
smaller and larger changes can lead to both success and failure depending
on the quality and resilience of the stipulated architectures. This chapter’s
findings suggest that business specialists and enterprise architects can
benefit from collocated training; that training activities in EA are both one-
off training and recurring training, where the latter is giving a community
of practice adding more to training.
Chapter 3 - One of the challenging jobs for software engineers today is
keeping up with the rapid changes in technology. An important update in
technology is that the software will involve service-oriented architectures
(SOAs) with some norm of cloud computing technology. As more and
more services are available on the Internet and nearly every day, the
authors discover new opportunities to connect these services to create
SOAs. These SOAs will require less custom software in organizations, but
will likely demand more creativity in the selection and assembly of
services. This is a natural evolution of software technology and will be
explained in this chapter. The evolutions brought by these technologies
will require both a basic grasp of the technologies and an effective way to
deal with how these changes will affect the people who build and use the
systems in the organizations. The intent of this chapter is to consider some
ideas and that just might make it easier for the organizations to realize the
potential benefits in SOAs, and cloud computing.
Chapter 4 - Microservice Architecture requires new ways of thinking
and new technologies in software development. It becomes the major
direction of architectural evolution in the field of the software-oriented
architecture. This study presents the causes that generate the evolution in
the software-oriented architecture to the current level of microservices,
which in many cases helps the success of modern applications architectures
and raises the importance of microservice-oriented computing.
The aim of this study is to analyze the major features underlying the
microservice architecture and to research into the advantages and the
x Frederik L. Sørensen
disadvantages of their technologies and implementation. The study focuses

on various strategies applied in software development as conditions for the
successful building of software. The analysis also highlights the major
capabilities of the microservices in driving the future advances in software
and hardware industries.
In: Enterprise Architecture … ISBN: 978-1-53617-588-2
Editor: Frederik L. Sørensen © 2020 Nova Science Publishers, Inc.
Chapter 1
ENTERPRISE ARCHITECTURE ALIGNMENT
Peter Filet, Rogier van de Wetering1, *
and Stef Joosten1

1
Department of Information Sciences,
Open University of the Netherlands,
Heerlen, Limburg, the Netherlands
ABSTRACT
An Enterprise Architecture (EA) is an instrument that focuses on

coherence between business processes, information distribution, and
technology infrastructure of an organization. In practice, we see that
architects are not well equipped to manage the interrelationship between
architectural business-, information- and technology-aspects in an
integrated fashion. EA frameworks are mostly informal by nature, and
there is a lack of knowledge and tools to support architects to check
alignment formally. Due to the volume and complexity of holistic
enterprise spanning architecture, it is increasingly challenging for
organizations to maintain overview and coherence of architectural
*
Corresponding Author’s E-mail: Rogier.vandewetering@ou.nl.
2 Peter Filet, Rogier van de Wetering and Stef Joosten
elements. This research enables automated, rule-based monitoring

consistency and coherence between elements within an EA. It does so by
creating an artifact that provides architects with the capability of
monitoring validity within ArchiMate EA models. We validate models
against formalized rules specified in Relation Algebra with which
coherence can be mathematically proven. We also plot a set of applied
rules onto a quality framework that calculates an overall alignment score
of an EA model. Every single rule violation that influences the score is
explicitly identified. Monitoring EA quality using formalized rules
enables organizations to manage and control the process of EA change
and thus contributes to Business/IT-alignment.
INTRODUCTION
Modern organizations are increasingly served by, and even dependent

on, effective and efficient use of information systems and information
technology (IS/IT). Research shows that the alignment of business and IT
(also called alignment) affects organizational performance (Gerow, Grover,
& Thatcher, 2015; R. Van de Wetering, Mikalef, & Pateli, 2017).
Alignment between business and IT offers value to organizations and
contributes to organizational success (Castellanos & Correal, 2013; Chan
& Reich, 2007; Saat, Franke, Lagerstrom, & Ekstedt, 2010). Therefore, it
is not surprising that within many organizations on (IT) executive-level
understanding of Business/IT-alignment is evolving and the topic gains
priority on the executive agenda (Gerow et al., 2015; Gerow, Thatcher, &
Grover, 2014; Gregor, Hart, & Martin, 2007; Pereira & Sousa, 2005).
However, scholars argue that alignment causes rigidity resulting in
stagnation of maneuverability which is required in response to changes in
the business environment (Gerow et al., 2014; Walraven, Van de Wetering,
Helms, Versendaal, & Caniëls, 2018).
Extant literature shows that Enterprise Architecture (EA) is generally
considered an important instrument to contribute to Business/IT-alignment
(Alaeddini & Salekfard, 2011; Castellanos & Correal, 2013; Gregor et al.,
2007; Kang, Lee, & Kim, 2010; Pereira & Sousa, 2005; Sousa, Pereira, &
Marques, 2004). EA’s can be considered instruments that focus on
Enterprise Architecture Alignment 3
coherence between business processes, information distribution, and

technology infrastructure of an organization. In practice, the proper
interrelationship between these different architectural aspects is not
integrally addressed (Castellanos & Correal, 2013). EAs, especially with
(medium) large enterprises, therefore, quickly become large and complex.
Also, the effort to maintain an EA within an organization is often carried
out by a group of architects, each with their specific area of interest or
specialty (Steenbergen, 2011). EA frameworks are mostly informal of
nature, and widely not validated, and there is a lack of knowledge and tools
to support Enterprise Architects to check this alignment formally
(Castellanos & Correal, 2013; Rogier Van de Wetering, 2019; Wegmann,
Balabko, Lê, Regev, & Rychkova, 2005).
Based on the above, this research aims to enable automated, rule-based
monitoring consistency and coherence between elements within an EA,
aiding architects in achieving alignment. In doing so, we specify an EA
model defined in the ArchiMate modeling language. We validate this EA
model against formalized rules that we define in Relation Algebra. We plot
the set of applied rules on a quality framework that enables calculating the
overall alignment score of an EA model. Underlying scores for quality
factors like completeness and correctness determine alignment’s score.
Using this approach, we identify every single rule violation that influences
the score. Monitoring EA quality using formalized rules makes
inconsistencies and differences in interpretation visible and enables
organizations to manage and control the process of EA change and thus
contributes to Business/IT-alignment.
The contribution of EA to Business/IT-alignment depends on the
quality of the architecture itself in general and the alignment between
architectural domains, aspects, and elements in particular. Although the
quality of EA is considered critical to the effectiveness and ability to
realize the benefits of EA, little research to this end is available (Niemi &
Pekkola, 2013). Several studies show the relevance of interrelations
between aspects, domains and components within an EA (Aier & Winter,
2009; Antunes, Bakhshandeh, Mayer, Borbinha, & Caetano, 2014; Eck,
Blanken, & Wieringa, 2004; Plazaola, Flores, Silva, Vargas, & Ekstedt,
2007), although be it that proposed solutions are diverse. Some studies

show the notion of defining alignment heuristics as a means of managing
the quality of EA, preferably supported by automated tools (Antunes et al.,
2014; Pereira & Sousa, 2005; Sousa et al., 2004). Currently, there is very
little research on effectively monitoring the mathematical correctness of
these relationships, especially when applying changes in the EA.
Several architecture modeling languages and architecture frameworks
have been developed and tested, such as ArchiMate. The extant literature
argues that EA can strengthen the cohesion of business and IT. Many EA
methods, frameworks, and techniques to this end are available, but an
overarching approach is currently lacking in the literature. We observe this
sentiment also in practice. Hence, architects argue, discuss, and suggest a
lot, but provide little to none hard substantiation. If such a sound theory of
architecture exists, it may be assumed that it is efficiently acted upon and
communicated by professionals. So we find a lack of proper theory. A
theory consists of a set of rules, hypotheses, and statements within a joint
context. The context of this research is the practice of Enterprise
Architects. To rise above the usual practice of ‘arguing,” we strive for
more substantiation. We state that tooling is possible that not only aids
architects in automating the manual task that architects need to perform to
ensure coherence, but also provides the substantiation. To achieve this, we
aim to find a set of formal rules that allows a computer to measure
cohesion in EA models.
The purpose of this current research is, to demonstrate in practice that
such tools are possible and useful.
THEORETICAL BACKGROUND
EA Literature
Several definitions of EA are available in the contemporary scientific

literature. In the context of this research, Lankhorst (2005) describes EA as
a ‘coherent whole of principles, methods, and models that are used in the
design and realization of an enterprise’s organizational structure, business

processes, information systems, and infrastructure.’ An EA is typically
described using models, covering a holistic view of an organization. Due to
the complexity of an EA description, many frameworks were developed to
assist in this task (Hinkelmann et al., 2015). Matthes (2011) reports more
than 50 EA frameworks. We focus on the widely used framework TOGAF
(TOG, 2011) that is related to a modeling language and supports automated
processing. It is composed of a set of closely interrelated architectures:
Business Architecture, Information Systems (Application and Data)
Architecture and Technology (IT) Architecture. TOGAF also includes a set
of tools to enable EA teams to picture the present and future state of the
architecture. TOGAF can be used in conjunction with ArchiMate (TOG,
2016).
The ArchiMate standard is based on the ISO/IEC/IEEE 42010 standard
and introduces an integrated language for describing EA’s. ArchiMate fits
into the TOGAF framework as it provides concepts for creating a model
that correlates to its three architecture layers. The ArchiMate modeling
language is based on a formal foundation, which makes it fit for machine
interpretation and thus offers possibilities for automated validation
(Lankhorst, 2005).
Alignment Heuristics
Several studies show the relevance of interrelations between aspects,

domains and components within an EA (Aier & Winter, 2009; Antunes et
al., 2014; Eck et al., 2004; Plazaola et al., 2007). Some studies show the
notion of defining alignment heuristics as a means of managing the quality
of EA, preferably supported by automated tools (Antunes et al., 2014;
Pereira & Sousa, 2005; Sousa et al., 2004). There currently is minimal
scholarship on the matter of effectively monitoring the mathematical
correctness of these relationships, especially when applying changes in the
EA.
The internal EA alignment is described by Sousa et al. (2004) as ‘the

issue of alignment based on the coherency between elements of Business
Architecture, elements of Information Architecture and elements of
Application Architecture. The more elements each of these Architectures
has, the richer and more complex is the concept of alignment because
more rules and heuristics need to be stated to govern the relationship
between these elements. So, to build up alignment, one must first clarify
the elements of each architecture’.
Achieving alignment also requires an understanding of the concept of
misalignment. A Business/IT-alignment model (BITAM) defines the
mappings between three layers of a business system: business models,
business architectures, and IT architectures. Misalignments in BITAM are
defined as improper mappings between the layers (Chen, Kazman, & Garg,
2005). El-Telbany and Elragal (2014) define misalignment as ‘the
continuous efforts, involving management and information systems, of
consciously and coherently detecting and testing for the interrelation of all
components of the business-IT relationship; where a change in one would
instantly influence the other, contributing to the organization’s
performance over time.’ This research focuses on monitoring and
managing the continuous changes in these interrelations. For this, we need
a perceptible and automatically processable, thus formalized, form of
modeling components and its interrelations.
The implementation of alignment heuristics in formalized rules
governs the interrelation between elements within the architectural layers
and aspects. This research focuses primarily on the most broadly applied
ArchiMate layers (Business, Application, and Technology) and all four
aspects.
The Ampersand method is designed to formalize the alignment
heuristics into business rules using the language ADL (“A Description
Language”), based on Relation Algebra, a part of mathematics equivalent
to predicate logic, though it is easier to learn and apply (Grave, Van de
Wetering, & Rutledge, 2018; S. Joosten, 2007; Stef Joosten, 2018;
Michels, Joosten, van der Woude, & Joosten, 2011). Each rule stated in
ADL is a formal representation of a quality aspect of architecture (either
generic of business-specific). The key components for capturing rules

within ADL are architecture components (called concepts) and relations
between these concepts.
Quality Metrics for EA
Niemi and Pekkola (2013) investigated the EA product quality

attributes and defined six quality attributes of EA product quality. That
investigation does not provide proper insight as to what influence each of
the quality attributes has on the overall quality of an EA. Currently, is no
adequate literature available that provides a useful quality model to
determine the relative impact of quality factors on the overall quality.
Hence, we revert to research within the field of data models. The defined
quality attributes show a similarity to the quality attributes that are
proposed by Niemi and Pekkola (2013). Moody and Shanks (2003)
constructed a quality model based on available literature concerning
quality evaluation approaches. They provide a quality model to evaluate
and improve the quality of data models. They defined a total of eight
quality factors, governing both product quality and process quality.
Empirical research on quality differences between novice and expert
models showed that the impact of specific product quality factors on the
overall quality varies. Five out of the eight quality factors are related to
product quality. These quality factors with their contribution to overall
quality are shown in Table 1.
Table 1. Effect of quality factors on overall quality

(Moody & Shanks, 2003)
Quality factor % contribution

Understandability 50.0%
Completeness 36.4%
Correctness 8.9%
Simplicity 3.1%
Flexibility 1.6%
Although unsupported by empirical research results, we assume that

the contribution of quality factors toward data model quality can be
relevant to EA model quality as well. The actual contribution is less
relevant to our research goal. The constructed mechanism to calculate an
overall quality is more important than the outcome itself.
Based on the similarities in definitions of the quality factors by Moody
and Shanks (2003) and the EA product quality attributes by Niemi and
Pekkola (2013), we have transposed the definitions of Niemi and Pekkola
(2013) onto the top three quality factors of Moody & Shanks as shown in
Table 2. Two out of the six quality attributes of Niemi & Pekkola were left
out of scope (Availability and Usefulness) because these do not explicitly
concern EA model quality and are thus less relevant for our research aim.
Table 2. Similarity mapping quality factors and attributes
Quality factor by Quality attribute by

Moody & Shanks Niemi & Pekkola
Understandability Clarity, Holistic view (granularity), Uniformity
Completeness Conciseness, Correctness (not being incomplete), Detailed
information (granularity), Cohesion
Correctness Correctness
We reviewed literature in search of rule candidates that could be

mapped onto one of the three quality factors, as mentioned in Table 2.
Although many rule candidates can be found as alignment heuristics, they
are not always readily translated into Relation Algebra, which could pose a
problem in the empirical part of our research. A solution to this problem is
to apply meta-tagging in the EA model. Another is to discard the rule
candidate.
An EA model is considered adequately aligned if the measure of
alignment reaches an established threshold, as proposed by Castellanos and
Correal (2013) and Aversano, Grasso, and Tortorella (2016). The
applicable threshold needs to be determined for each specific situation.
Aversano et al. (2016) (p. 176 – 179) presented a method to determine
the alignment degree by measuring a set of defined metrics considering
business processes and software systems. A part of their method applied a

semantic analysis to determine the similarity between business process
activities and software components. We employ formalized rules stating
the degree of alignment between the specified architecture components.
With each violation of a rule, the alignment diminishes. Each violation of a
rule impacts rule alignment, quality factor alignment, and overall
alignment.
METHODS
Design Science
Figure 1 shows our research approach. We build on the method of

Doorewaard and Verschuren (2015). The key topics in this model are:
 Formalized EA model;
 Formalized rule model;
 Alignment quality model.
Figure 1. Research approach.

The lower part Figure 1 shows the Design Science Research Methodo-
logy process model (Peffers, Tuunanen, Rothenberger, & Chatterjee,
2007).
This current research explores the possibility of creating a practical,
applicable environment to support automated, rule-based monitoring
consistency and coherence between elements within an EA model. The
practical research method that supports the creation of an innovative
solution to a real-world problem is the Design Science method (Gregor &
Hevner, 2013; Hevner & Chatterjee, 2010).
The Design Science research method is a novel approach within the
field of Information Systems because it combines focus on the creation of
an IT artifact with a high priority on maintaining the relevance of IS
research in the application domain (Hevner & Chatterjee, 2010). The
research activities for the Design Science method are described in a
conceptual framework and follow a set of guidelines to conduct and
evaluate Design Science research, as mentioned in (Hevner & Chatterjee,
2010; Venable, Pries-Heje, & Baskerville, 2014). The Design Science
process consists of six steps, as shown in the lower part of Figure 1.
Applied Alignment Heuristics
We found a limited number of scientific articles that unfold alignment

heuristics in detail. Castellanos and Correal (2013) also referred to Pereira
and Sousa (2005) and Sousa et al. (2004). Different approaches were found
in the literature to define alignment heuristics, although detecting
misalignment is a commonality. Pereira and Sousa (2005) and Sousa et al.
(2004) used a common-sense approach to define the list of alignment
heuristics. This latter approach also resulted in an overlap between the
heuristics. Using a common-sense approach has the risk that heuristics
cannot be applied to different businesses. This research maps the heuristics
onto the quality model that we designed based on Moody and Shanks
(2003) and Niemi and Pekkola (2013).
The applied rule model is constructed, based on the outcomes of the

literature study (i.e., alignment heuristics from the literature transformed
into formalized rules) and enriched based on interviews with EA experts
that are closely involved with the researched cases. Efficacy, instead of
integrality, of the set of rules that is applied to the EA models, is the
primary goal that drives the selection of rules to implement.
The outcome of alignment measurement for each model is not an
absolute indication of the quality of the EA model, but a precise
calculation of the EA model quality to the applied set of rules.
Alignment Calculation
Based on the proposed method by Aversano et al. (2016) and the

quality factor model derived from Moody and Shanks (2003) and Niemi
and Pekkola (2013), rule alignment is calculated as a percentage score by
dividing the number of violations of a rule onto the number of pairs in the
relation that is described by the antecedent part of the rule assertion,
thereby using the following metrics:
#𝑣𝑖𝑜𝑙𝑎𝑡𝑖𝑜𝑛𝑠
𝑅𝑢𝑙𝑒𝐴𝑙𝑖𝑔𝑛𝑚𝑒𝑛𝑡% = 1 −
𝑀𝑎𝑥𝑉𝑎𝑙𝑢𝑒 (#𝑝𝑎𝑖𝑟𝑠 𝑖𝑛 𝑎𝑛𝑡𝑒𝑐𝑒𝑑𝑒𝑛𝑡; 1)
Alignment within a single quality factor (QF) is then the average

RuleAlignment% of all rules applying to the same quality factor:
∑ 𝑅𝑢𝑙𝑒𝐴𝑙𝑖𝑔𝑛𝑚𝑒𝑛𝑡% 𝑤𝑖𝑡ℎ𝑖𝑛 𝑄𝐹
𝑄𝐹𝑎𝑙𝑖𝑔𝑛𝑚𝑒𝑛𝑡% =
#𝑟𝑢𝑙𝑒𝑠 𝑤𝑖𝑡ℎ𝑖𝑛 𝑄𝐹
If no rules exist within a quality factor (#rules within QF equals 0), the
QFalignment% for that quality factor is undefined, which implicitly
increases the relative contribution of other quality factors to the overall
alignment, as shown in the formula below.
We calculate the overall alignment score as the weighted average of

QFalignment%. This calculation can be done for each of the quality
factors:
∑(𝑄𝐹𝑎𝑙𝑖𝑔𝑛𝑚𝑒𝑛𝑡% ∗ 𝑄𝐹𝑐𝑜𝑛𝑡𝑟𝑖𝑏𝑢𝑡𝑖𝑜𝑛%)
𝑂𝑣𝑒𝑟𝑎𝑙𝑙 𝐴𝑙𝑖𝑔𝑛𝑚𝑒𝑛𝑡% =
∑(𝑄𝐹𝑐𝑜𝑛𝑡𝑟𝑖𝑏𝑢𝑡𝑖𝑜𝑛%)
If no rules exist in any of the quality factors, there is no QFalignment%

for any of the quality factors, which renders the Overall Alignment%
undefined. Table 1 shows the contribution of each quality factor
(QFcontribution%). This calculation proposal does not incorporate the
relative weight of individual rules.
Case Studies
The Design science method is focused on developing an artifact that

has relevance to solving a practical problem (monitoring alignment within
an EA model) while ensuring the relation to the scientific foundation such
as theories and methods (Relation Algebra). The Design Science method
does not provide guidelines for collecting research data, but the collected
research data does influence the nature of evaluation (Venable et al., 2014).
In this research, the data set consists of six EA models in ArchiMate
format and alignment heuristics. The heuristics are based on the literature
study.
Two out of the six EA models were provided by organizations that are
active in the public sector. Four models were obtained from an open-
source, i.e., are publicly available, of which one is a reference architecture.
The EA models are:
1. Netherlands Tax & Customs Administration (NTCA)

The program “Regie modernisering IV-Landschap” (Directing
modernization IT landscape) aims to guide IT initiatives while
maintaining cohesion. The subprogram “Overzicht & inzicht IV-
landschap” (Overview & Insight IT landscape) governs the

landscape of (business)process-, application- and IT-infrastructure-
landscape. An EA model is provided that concerns the domain
Customs and spans ArchiMate’s business- and application-layer.
Its metrics: 1.987 elements (of which 314 business process
elements, 259 business services, 212 application components, 257
application services) with 6.148 relations. Due to confidentiality
restrictions, the EA model is partially anonymized by renaming
some of the occurrences of concepts (e.g., applications, processes)
without impairing the relations between the elements. The model
was supplied in the ArchiMate Open Exchange File Format.
2. Ministry of Defense Netherlands (MOD-NL)
MOD-NL provided a partial model that contains some few specific
elements from both the business- and application-layer of
ArchiMate. The application layer specifically covered domains
GIV (“Generieke IV” or “General IT”), P&O (“Personeel &
Organisatie” or “Personnel & Organization”) and M&F
(“Materiaal & Financiën” or “Material & Finance”). Its metrics:
2.012 elements (of which 508 business actors, 54 business roles,
1.044 application components, 406 application services) with
1.323 relations. The model was supplied from ARIS as Excel
export.
3. ArchiSurance1
The ArchiSurance Case Study is a (publicly available) fictitious
example developed to illustrate the use of the ArchiMate modeling
language. The Case Study is about an insurance company
(ArchiSurance). This company was formed following a merger of
three (previously) independent firms. The case provides an
architecture of the company and several change scenarios. Its
metrics: 129 elements with 176 relations.
4. ArchiMetal1
The ArchiMetal Case Study is a (publicly available) fictitious
1
ArchiMate model, publicly available on https://github.com/archimatetool/ArchiModels.
example of a manufacturer named ArchiMetal. Through high-level

architecture modeling, the ArchiMate language illuminates the
coherence between an organization, and its processes, applications,
and infrastructure. Its metrics: 569 elements with 760 relations
5. OpenDay1
The OpenDay model is a sample model to demonstrate the
functionality of the Archi modeling tool. Its metrics: 31 elements
with 37 relations
6. European Interoperability Reference Architecture (EIRA)2
The EIRA is a reference architecture model to guide public
administrations and provides interoperable European public
services to other public administrations, businesses, and citizens.
The EIRA defines a set of required capabilities to promote
interoperability as a set of architecture building blocks (ABBs). Its
metrics: 157 elements with 235 relations.
The EA model data for ArchiSurance, ArchiMetal, and OpenDay

typically support the artificial formative nature of evaluation in Design
Science, where the EA model data for MOD-NL, NTCA, and EIRA
support the naturalistic formative nature.
Research Environment
The EA models (except the MOD-NL model) are imported into the
Archi3 tool, so they are stored in a format that can be imported into
Ampersand by the compiler. The MOD-NL model was supplied in Excel
format. This data is imported into Ampersand using Ampersand’s Excel
importer functionality.
2
EU reference architecture model, publicly available on https://joinup.ec.europa.eu/
node/99464.
3
Archi is a free and open source modelling tool to create ArchiMate models and sketches.
Available from https://www.archimatetool.com.
The artifact is built with Ampersand, which itself is developed as an

open-source project and uses the following toolset:
 Haskell tool stack – to compile Ampersand

 Git – to store/retrieve Ampersand source code
 XAMPP – to execute the generated artifact, contains:
˗ Webserver Apache v2.4.25 (Win32) OpenSSL/1.0.2j, PHP
v7.1.1
˗ Database server 10.1.21-MariaDB
˗ Composer – dependency manager for PHP
Figure 2. Ampersand output example.
For each of the EA models, the artifact consists of an Ampersand script

that imports the model and the applied set of rules. Ampersand’s output is
a generated web-based application that can be accessed through a
webserver. The web application shows violations of the applied rules.

Ampersand has much more functionality to view and manipulate model
content, but this functionality was not needed for the implementation of the
artifact in this research. An example of Ampersand’s output (based on the
case for NTCA) is shown in Figure 2.
Translating Alignment Heuristics into ADL
The formal specification in Relation Algebra and Ampersand’s ADL

needs to be constructed to apply rules onto the EA case model. Generic
rule definition is possible when EA models show similarity on the meta-
model level. The ArchiMate standard is open and flexible, which leaves
room for variety in application and interpretation on a semantic level. Ten
rule candidates were translated generically and applied onto five case
models.
Each rule is based on an alignment heuristic that is formulated in
natural language. Alignment heuristic TV065 states: “An APPLICATION
REALIZES AN APPLICATION SERVICE.” A visualization in ArchiMate is shown
in Figure 3.
Figure 3. ArchiMate visualization of rule TV065.
For this alignment heuristic to be translated into ADL, we first need to

decompose its structure and requirements. The concepts APPLICATION
SERVICE and APPLICATION are assumed to be represented in an EA model
by ArchiMate concepts. APPLICATION SERVICES are rendered in ArchiMate
by the concept Application service. The APPLICATION is represented in
ArchiMate by the concept Application Component (Application
collaboration is left out of scope). REALIZES is represented by the Archi-
Mate relation Realization. Implicitly, the alignment heuristic requires that

each application is related to an application service. The relation for this
rule is submitted to the multiplicity constraint that the relationship is to be
total. Graphical visualization of a total relationship is shown in Figure 4.
Total relationship, where concept X represents APPLICATION, concept Y
represents APPLICATION SERVICE, and relation r represents REALIZES.
Relation r consists of a set of tuples that each represent the relation
between an APPLICATION and an APPLICATION SERVICE.
Concept Relation Concept

X r Y
1 a
(1, a)
2 b
(2, c)
c
3 (3, c)
d
4 (4, d)
e
5 (5, e)
Totality relation r:
Each atom in concept X must be related to an atom in concept Y
Figure 4. Total relationship.
The notation of a relation that follows multiplicity constraint total

results in the following:
 in Relation Algebra [X]  r; r˘

 in Ampersand ADL I[X] |- r ; r~
Violations influence overall alignment within an EA model. Each

violation must be identified and used as input for the EA improvement
management process. A violation of rule TV065 is described by the set
difference between the antecedent and the consequent:
 in Relation Algebra [X] \ (r ; r˘)

 in Ampersand ADL I[X] - (r; r~)
A rule must be formulated in a way that violations identify (atoms

within) the concepts that cause the violations. Since rules describe
relations, violations also occur within relations, so each violation takes the
form of a tuple and therefore has a source atom and a target atom.
Translating alignment heuristic TV065 into ADL leads to the
following code segment:
RULE "TV065" : I[ApplicationComponent] |-

realisation[ApplicationComponent*ApplicationService];
realisation[ApplicationComponent*ApplicationService]~
VIOLATION ( TXT "Application Component \'",
SRC naam,
TXT "\' does not realize any Application
Service")
Although the specification for rule TV065 is fairly straightforward,

generic and applicable for almost any ArchiMate model, its actual validity
for the EA model depends on the applied meta-model. For the MOD-NL
case, this resulted in an additional case-specific translation for TV065:
RULE "TV065" : I[ApplicationComponent] |-

association[ApplicationComponent*ApplicationService];
association[ApplicationComponent*ApplicationService]~
VIOLATION ( TXT "Application Component \'",
SRC naam,
TXT "\'does not realize any Application
Service")
All rules specified in ADL are obliged to follow ADL grammar which
has its foundation in Relation Algebra. Therefore, a successful compilation
of an ADL script ensures a syntactically correct specification of a rule,
respecting the Design Science rigor cycle. Needless to say that for a rule to
be semantically correct, verification and validation needs to be in place.

For this research, rule validation is in place, as described in section 5.
For this research, the implemented rules mostly govern cardinality type
rules that concern multiplicity constraints spanning one or two relation(s).
In practice, EA models consist of numerous concepts and relations. Rules
can easily span more than two relations, and probably concern cycles
within the conceptual diagram. The need for a clear and concise meta-
model is essential for describing such an efficacious rule. Examples to this
end, are rule candidates TV060, TV062, and TV064 in the NTCA model.
Ampersand generates a meta-model, based on the content of the model
repository. This meta-model consists of imported relations as well as
several derived or generated relations that are relevant to rule
specifications in ADL. A simplified meta-model, as generated by
Ampersand, is shown in Figure 5.
Relation
source target
ArchiObject
isA
Element
(e.g. BusinessProcess, Tekst
ApplicationService, etc.)
naam
Archimate relation
(e.g. realizes, usedBy, access, etc.)
Figure 5. Simplified meta-model generated by Ampersand.

RESULTS
An overall alignment score within an EA model is calculated using the

outlined method. In Ampersand, the set of rules was applied to the EA case
model. At the individual rule level, Ampersand determines both the size of
the antecedent part of the rule and the number of occurring violations.
Because the Ampersand tool does not possess the capability to make
numerical computations, calculation of the rule score, the quality factor
score, and the overall score was performed in Excel conform the method
above.
For the model of ArchiSurance case, the alignment calculation results
are shown in Figure 6.
Quality Factor: Completeness

QF Contribution: 36,40%
Rule Description Antecedent Violations Score
TV002a Business processes should be supported by a single application 9 0 100,00%
TV002b Business interactions should be supported by a single application 2 0 100,00%
TV008 An information entity is managed by only one application 4 0 100,00%
TV022 Processes that make no access to any entity 9 5 44,44%
TV023 Entities that are not accessed by any process 10 7 30,00%
TV027a Each business process should be supported by at least one 9 8 11,11%
application system
TV027b Each business interaction should be supported by at least one 2 0 100,00%
application system
TV040 A Business Object is realized by 1+ Data Objects 10 0 100,00%
TV042 A Business service is realized by 1+ 6 1 83,33%
(Business Service or Business Process or Business Function or
Business Interaction)
TV043 An Application service is realized by 1+ 3 0 100,00%
(Application Service or Application Process or Application Function or
Application Interaction)
TV057 A Data Object realizes 1+ Business products 4 0 100,00%
TV065 Een applicatie realiseert een applicatie service 10 7 30,00%
Quality factor alignment 74,91%
Weighted QF alignment 27,27%
Overall alignment 74,91%
Figure 6. Alignment measurement result ArchiSurance.
Ampersand generates a web-based application that shows detected

violations. Violations for the ArchiSurance case shown in Figure 7. Rules
that are not mentioned in the overview do not contain any violations and
thus score 100%.
Figure 7. Overview of violations in ArchiSurance.
Each violation notification specifies precisely which tuples in the relation

cause violation of a rule, as shown in Figure 8. This enables the EA
management process to initiate and drive improvement actions.
Figure 8. Detailed view of violations in ArchiSurance (partial).
The number of tuples in the antecedent part of the relationship is

required to calculate the alignment metric of each rule. This number can be
determined within the MySQL database by looking for the number of rows
in the corresponding table. In case the expression for the antecedent spans
more than a single concept, an SQL query can be defined to find the
number. Alternatively, Ampersand can be used to visualize the antecedent
using the INTERFACE statement.
The visualization of a rule violation for rule TV065 – An application
component realizes an application service is shown in Figure 9. ArchiMate
view on Financial Application, by generating a view within Archi for the

application component that triggers the violation, in this case, the
application component financial application.
This particular view shows that the application component financial
application realizes a business service instead of an application service.
ArchiMate itself does not prohibit this type of modeling. ArchiMate allows
many types of relations between components from different architecture
layers; it all depends on the applied meta-model within the organization.
The capability of the designed and developed artifact within this research
is to detect and report anomalies concerning the used set of rules. The
overall alignment calculation provides longitudinal comparison
information to guide the EA management process.
Figure 9. ArchiMate view on Financial Application.

DISCUSSION
Model Alignment Results
Verification of Ampersand Rules

Alignment heuristics aid in monitoring alignment within an EA model.
Usually, both in literature and in the business environment, alignment
heuristics are formulated in natural language that makes sense to real-life
people. To apply the alignment heuristics onto the EA model, they are
translated into formalized rules. There are instruments to bidirectionally
verify the translation process to ensure the correct application of the rule.
In the direction from heuristics to rules, one could apply the structured
method called RuleSpeak®4, which consists of a set of guidelines to
formulate business rules in clear and unambiguous statements in natural
language that can both be understood by the business and translated into a
formalized notation language like ADL. For alignment heuristic TV065,
the translation into RuleSpeak® is shown in Table 3.
Reversely, formalized rules that are specified in ADL need to be
verified to make sure the translation process is done correctly. Verification
of correct translation aids the validation process with stakeholders. A rule
can be translated back into the natural language using a specified
procedure. The result is called a controlled natural language sentence
(CNL-sentence) (Wedemeijer, Joosten, Michels, & Woude, 2014a). To
adequately validate the rule translation, the CNL-sentence can be
compared to the alignment heuristic in RuleSpeak® notation. For the ADL
specification of rule TV065, translation to natural language is shown in
Table 3.
4
RuleSpeak® was developed in 1996 by Ronald G. Ross. Info can be found at
www.rulespeak.com. It is also a topic in the Rule Based Design course that is part of the
Business Process Management & IT education program by the Open University
(Wedemeijer, Joosten, Michels, & Woude, 2014b).
Table 3. Rule translation validation
Type of specification Specification

Alignment heuristic An application realises an application service
RuleSpeak® An application must realize an application service
ADL I[ApplicationComponent] |-
realisation[ApplicationComponent*ApplicationService];
realisation[ApplicationComponent*ApplicationService]~
Relation algebra cApplicationComponent 
 sApplicationService (c realisation s) ꓥ (s realisation~ c)
Controlled Natural For every ApplicationComponent, there exists an
Language ApplicationService such that ApplicationComponent
realization ApplicationService
Mutual Comparison of Model Results

Mutual comparison of alignment scores between researched cases
(benchmarking) does not prove to be useful in the current scale of research.
Only when both the set of rules, as well as the underlying meta-model for
the compared models are equal and at a higher maturity level,
benchmarking might be possible.
What we did find in the results of the various models (as shown in
Appendix 27), was a difference in scores when looking from the
perspective of single- or cross-layer rules. A single layer rule concerns
concepts and relations that span a single ArchiMate layer (e.g., only the
Business layer). A cross-layer rule crosses the boundary between the
Business layer and the Application layer. What we found is that cross-layer
rules show a lower average score (62%) than single layer rules (68%).
Unfortunately, the number of cases used in this research is insufficient to
draw substantiated conclusions from these results. Therefore, more in-
depth research is needed to determine whether this observed difference is
significant. Because, if it is significant, it would mean that Business/IT-
alignment should be judged worse than the current results suggest.
Longitudinal Comparison
The alignment measurement for each of the EA models lacks a point of
reference to be able to interpret and evaluate the absolute results. A
longitudinal comparison with EA models could be beneficial; it requires

EA models over time and a stable set of rules to do so. The results of this
research show that objective snapshot measurements are possible.
Ampersand
Ampersand is an open-source project used in academic research
projects, academic studies, and business application environments. The
primary area of application is the implementation of business rules guiding
the rule-driven generation of information systems. During the development
and execution phase of this research, no indication is found that could
diminish the reliability of the results.
Implications for Practice
Meta-Model as a Foundation under the Set of Rules

For effective modeling and monitoring, an EA model needs to follow
restricted, and unambiguous modeling guidelines. Defining a meta-model
for the EA model is highly recommended, if not essential, while it
explicitly states the way of modeling and thus guides the definition and
development of rules. The ArchiMate standard is based on a meta-model,
but it leaves much room for alternatives in modeling the EA model of an
organization. Without proper guidelines towards modeling EA, architects
are likely to apply the individual interpretation of a situation that needs to
be modeled in concepts and (types of) relations. Such a practice possibly
leads to various models, which makes it more challenging to determine
alignment. The time-to-implement a new rule is concise, it merely requires
formalization of the rule, re-compile the Ampersand script and re-
evaluation of the rules.
Violations as Input for EA Management Process

The results of this study show that monitoring based on the applied
environment accurately measures the validity of the EA model to the
formalized rules. It also indicates explicitly which tuple(s) in the relations
cause violations of the rules. These aids architects in maintaining and

enhancing the coherence within their EA model.
Limitations
Application of EA Quality Factors

Rules in the current set are barely classified to the Quality Factor
‘Understandability’. We found that most rules are repository related, while
the Quality Factor ‘Understandability’ is described in the literature as
relevant to views. Moreover, understandability is, by definition more a
subjective concept. Hence, more research is required to create repository-
or view-based understandability rules. The applied research environment
Ampersand does not (yet) provide means to import and validate EA views.
The classification of rules onto EA quality factors, in general, plays a
limited role in light of this current research. It influences the outcome of
the alignment measurement calculation and can be used to focus on
improvement actions in the EA management process.
Ampersand
Numerical computations are not (yet) possible within Ampersand.
Numerical and date computations might be useful for alignment heuristics
that relate to organization-specific circumstances. The Ampersand
ArchiMate extension, used to import EA models in ArchiMate format, is a
relatively new extension of Ampersand's functionality. Some issues arose
during design and development. However, these issues were all
appropriately solved. There is no indication that prior issues influence the
validity of the results.
FUTURE RESEARCH
The ArchiMate standard allows many types of relations between

concepts, which leads to various ways of modeling EA. A detailed meta-
model is essential to develop a practical set of rules. It is worth the effort to

search for or construct a best-practice or reference meta-model onto which
a generic set of rules can be defined. When such a best-practice or
reference meta-model exists and is applied in organizations, benchmarking
of EA models and EA alignment performance can take place.
The set of EA quality factors is based on literature that originates from
data modeling and is combined with EA quality attributes that are
proposed in EA literature. However, no empirical findings are available to
support the correct mapping of EA attributes onto quality factors, nor do
we have empirical findings that support the correctness of the assumed
contribution of quality factors to overall quality. Concerning the latter,
further explanatory research is needed. Although in this research we chose
to apply field knowledge of data models to classify rules, it is arguable that
classification based on the alignment perspectives of the well-known
Strategic Alignment Model (Gerow et al., 2014; Henderson &
Venkatraman, 1999) could be of value as well.
The quality factor ‘understandability’ has shown to be less practical for
repository-based rules. We presume this quality factor has more relevance
in rules that concern EA views, but further research to this end is needed,
as well as enhancement in the Ampersand environment to support this
research.
This research demonstrates the possibility of monitoring EA alignment
using formalized rules, thus enhancing the quality of EA. Interesting would
be to investigate the presumed relationship between EA quality and the
effectiveness of EA models. As a result of this current research, we now
have an instrument that provides an objective alignment indicator. Our
study outcomes could open up the way to try and find a correlation
between the EA quality indicator and other BITA alignment indicators,
e.g., EA effectiveness, and IT performance.
Suggestions with a more practical nature concern the Ampersand
environment. Loading repository content is mostly done using an ADL
script.
Performance-wise this should be done at runtime by preparing an

adequate import file, as is the case for the MOD-NL case. This procedure
considerably reduces processing time but might require additional effort
for extracting the EA model from the source system.
Ampersand supports generating an application that is capable of
visualizing rule violations. It currently lacks the functionality to aid
alignment measurement by stating the number of pairs in the antecedent
and the number of violation of a rule.
CONCLUSION
As EA models are increasingly becoming more complex, it is no

longer practical to maintain consistency and coherence manually.
Automated support to this end is required. Using formalized rules specified
in ADL, alignment measurement is performed to initiate enhancements.
This study aimed to create an efficient instrument to unambiguously
monitor the correctness of coherence between elements within an EA. In
practice, maintaining coherence within an EA model is a vast and tedious
task of architects. Our work shows that applying an automated IT artifact
to monitor coherence within an EA model, based on formalized rules, is
feasible and useful to architects. Violations of rules are indicators of
misalignment within an EA model on a specific point in time. Longitudinal
application of rules in an iterative improvement process will aid in
monitoring coherence.
Finally, to measure improvements in alignment scores, proper metrics
are needed. To this end, rules are divided into quality factor categories.
Violations on rules are then used to calculate the performance of the rule
and the quality factor it belongs to. That provides a mechanism to
distinguish between rules more accurately.
REFERENCES
Aier, I. S., & Winter, R. (2009). Virtual decoupling for IT/business

alignment–conceptual foundations, architecture design and
implementation example. Business & Information Systems
Engineering, 1, 150-163. doi:10.1007/11576-008-0115-0.
Alaeddini, M., & Salekfard, S. (2011). Investigating the role of an
enterprise architecture project in the business-IT alignment in Iran.
Information Systems Frontiers, 15(1), 67-88. doi:10.1007/s10796-011-
9332-y.
Antunes, G., Bakhshandeh, M., Mayer, R., Borbinha, J., & Caetano, A.
(2014). Using Ontologies for Enterprise Architecture Integration and
Analysis. Complex Systems Informatics and Modeling Quarterly(1), 1.
doi:10.7250/csimq.2014-1.01.
Aversano, L., Grasso, C., & Tortorella, M. (2016). Managing the
alignment between business processes and software systems.
Information and Software Technology, 72, 171-188. doi:10.1016/j.
infsof.2015.12.009.
Castellanos, C., & Correal, D. (2013). A Framework for Alignment of Data
and Processes Architectures Applied in a Government Institution.
Journal on Data Semantics, 2(2-3), 61-74. doi:10.1007/s13740-013-
0021-5.
Chan, Y. E., & Reich, B. H. (2007). IT alignment: what have we learned?
Journal of Information Technology, 22, 297-315.
Chen, H.-M., Kazman, R., & Garg, A. (2005). BITAM: An engineering-
principled method for managing misalignments between business and
IT architectures. Science of Computer Programming, 57(1), 5-26.
Doorewaard, H., & Verschuren, P. (2015). Het ontwerpen van een
onderzoek: Boom Lemma.
Eck, P. v., Blanken, H., & Wieringa, R. (2004). Towards operational
architecture alignment. International Journal of Cooperative
Information Systems, 13(3), 20.
El-Telbany, O., & Elragal, A. (2014). Business-information Systems

Strategies: A Focus on Misalignment. Procedia Technology, 16, 250-
262. doi:10.1016/j.protcy.2014.10.090.
Gerow, J. E., Grover, V., & Thatcher, J. (2015). Alignment's nomological
network: Theory and evaluation. Information & Management.
doi:10.1016/j.im.2015.12.006.
Gerow, J. E., Thatcher, J. B., & Grover, V. (2014). Six types of IT-
business strategic alignment: an investigation of the constructs and
their measurement. European Journal of Information Systems, 24(5),
465-491. doi:10.1057/ejis.2014.6.
Grave, F., Van de Wetering, R., & Rutledge, L. (2018). Strategy-IT
alignment: Assuring alignment using a relation algebra method. Paper
presented at the Eighth International Symposium on Business
Modeling and Software Design, Vienna, Austria.
Gregor, S., Hart, D., & Martin, N. (2007). Enterprise architectures:
enablers of business strategy and IS/IT alignment in government.
Information Technology & People, 20(2), 96-120.
Gregor, S., & Hevner, A. (2013). Positioning and presenting design science
research for maximum impact. MIS Quarterly, 37(2), 19.
Henderson, C., & Venkatraman, N. (1999). Strategic Alignment -
Leveraging IT for Transforming Organizations. IBM Systems Journal,
38(2 & 3), 472-484.
Hevner, A., & Chatterjee, S. (2010). Design Science Research in
Information Systems. 22, 9-22. doi:10.1007/978-1-4419-5653-8_2.
Hinkelmann, K., Gerber, A., Karagiannis, D., Thoenssen, B., van der
Merwe, A., & Woitsch, R. (2015). A new paradigm for the continuous
alignment of business and IT: Combining enterprise architecture
modelling and enterprise ontology. Computers in Industry, 79, 77-86.
doi:10.1016/j.compind.2015.07.009.
Joosten, S. (2007). Deriving Functional Specifications from Business
Requirements with Ampersand. Retrieved from http://citeseerx.ist.psu.
edu/viewdoc/download?doi=10.1.1.118.4137&rep=rep1&type=pdf.
Joosten, S. (2018). Relation Algebra as programming language using the

Ampersand compiler. Journal of Logical and Algebraic Methods in
Programming, 100, 113-129.
Kang, D., Lee, J., & Kim, K. (2010). Alignment of Business Enterprise
Architectures using fact-based ontologies. Expert Systems with
Applications, 37(4), 3274-3283. doi:10.1016/j.eswa.2009.09.052.
Lankhorst, M. M. (2005). Enterprise architecture modelling—the issue of
integration. Advanced Engineering Informatics, 18(4), 205-216.
doi:10.1016/j.aei.2005.01.005.
Matthes, D. (2011). Einführung eines grundlegenden Begriffsverstän-
dnisses. 9-36. doi:10.1007/978-3-642-12955-1_2.
Michels, G., Joosten, S., van der Woude, J., & Joosten, S. (2011).
Ampersand. In H. de Swart (Ed.), Relational and Algebraic Methods in
Computer Science: 12th International Conference, RAMICS 2011,
Rotterdam, The Netherlands, May 30 – June 3, 2011. Proceedings (pp.
280-293). Berlin, Heidelberg: Springer Berlin Heidelberg.
Moody, D. L., & Shanks, G. G. (2003). Improving the quality of data
models: empirical validation of a quality management framework.
Information Systems, 28(6), 619-650. doi:10.1016/s0306-4379(02)
00043-1.
Niemi, E., & Pekkola, S. (2013). Enterprise Architecture Quality
Attributes: A Case Study. 3878-3887. doi:10.1109/hicss.2013.201.
Peffers, K., Tuunanen, T., Rothenberger, M. A., & Chatterjee, S. (2007). A
Design Science Research Methodology for IS research. Journal of
Management Information Systems, 24(3), 34.
Pereira, C. M., & Sousa, P. (2005). Enterprise Architecture - Business and
IT alignment. Paper presented at the ACM Symposium on Applied
Computing.
Plazaola, L., Flores, J., Silva, E., Vargas, N., & Ekstedt, M. (2007). An
approach to associate strategic business-IT alignment assessment to
enterprise architecture. Paper presented at the In Fifth Conference on
Systems Engineering.
Saat, J., Franke, U., Lagerstrom, R., & Ekstedt, M. (2010). Enterprise
Architecture Meta Models for IT/Business Alignment Situations. 14-23.
doi:10.1109/edoc.2010.17.
Sousa, P., Pereira, C. M., & Marques, J. A. (2004). Enterprise Architecture
Alignment heuristics. Microsoft Architects journal, 4 (October
2004), 6.
Steenbergen, M. v. (2011). Maturity and Effectiveness of Enterprise
Architecture. (PhD). Universiteit Utrecht.
The Open Group. (2011). The Open Group Architecture Framework
version 9.1. Retrieved from https://pubs.opengroup.org/architecture/
togaf91-doc/arch/
The Open Group. (2016). ArchiMate 3.0 Specification. Retrieved from
https://pubs.opengroup.org/architecture/archimate3-doc/
Van de Wetering, R. (2019). Dynamic Enterprise Architecture
Capabilities: Conceptualization and Validation. Paper presented at the
Business Information Systems, Seville, Spain.
Van de Wetering, R., Mikalef, P., & Pateli, A. (2017). A strategic
alignment model IT flexibility and Dynamic capabilities: Toward an
assessment tool. Paper presented at the 25th European Conference on
Information Systems (ECIS), Guimarães, Portugal.
Venable, J., Pries-Heje, J., & Baskerville, R. (2014). FEDS: a Framework
for Evaluation in Design Science Research. European Journal of
Information Systems, 25(1), 77-89. doi:10.1057/ejis.2014.36.
Walraven, P., Van de Wetering, R., Helms, R., Versendaal, J., & Caniëls,
M. (2018). Co-evolutionary IS-alignment: a Complex Adaptive
Systems Perspective. Paper presented at the 12th Mediterranean
Conference on Information Systems, Corfu, Greece.
Wedemeijer, L., Joosten, S. M. M., Michels, G., & Woude, J. C. S. P. v. d.
(2014a). Cursusboek Ontwerpen met bedrijfsregels (1st ed.). Heerlen:
Open Universiteit.
Wedemeijer, L., Joosten, S. M. M., Michels, G., & Woude, J. C. S. P. v. d.
(2014b). Werkboek Ontwerpen met bedrijfsregels (1st ed.). Heerlen:
Open Universiteit.
Wegmann, A., Balabko, P., Lê, L. S., Regev, G., & Rychkova, I. (2005). A
method and tool for Business-IT Alignment in Enterprise Architecture.
Paper presented at the CAiSE'05 Forum, Porto, Portugal.
BIOGRAPHICAL SKETCHES
Peter W. Filet
Affiliation: Open University, Netherlands
Education: MSc. Business Process Management & IT, Open University,

Netherlands
Research and Professional Experience: Business architect, CIO advisor
Rogier van de Wetering
Affiliation: Open University of the Netherlands, PhD
Research and Professional Experience: 15 years
2005-2015: Manager Strategy & Operations at Deloitte Consulting

2015-2017: Assistant Professor Information Sciences, Faculty of
Management, Science, and Technology
2017-now: Associate Professor Information Sciences, Faculty of
Sciences
Professional Appointments: Associate Professor Information Sciences,

Faculty of Sciences
Publications from the Last 3 Years:
1. Van de Wetering, R. 2019. “Enterprise Architecture Resources,

Dynamic Capabilities, and their pathways to Operational Value. In
Proceedings of the International Conference on Information
Systems, Munich, Germany, 15-18 December, 2019.
2. Van de Wetering, R., Besuyen, M. (2019). How IT-enabled
dynamic capabilities add value to the development of innovation
capabilities: an empirical investigation. Accepted for publication
to the Encyclopedia of Organizational Knowledge, Administration,
and Technologies.
3. Van de Wetering, R., Mikalef, P., Krogstie, J. (2019). Strategic
value creation through big data analytics capabilities: A
configurational approach. Accepted for publication in the
Proceedings of 21st IEEE Conference on Business Informatics, July
15-17, 2019, Moscow, Russia.
4. Van de Wetering, R. 2019. “Dynamic Enterprise Architecture
Capabilities: conceptualization and validation,” Business
Information Systems, W. Abramowicz and R. Corchuelo (eds.),
Cham: Springer International Publishing, to appear.
5. Mikalef, P., Van de Wetering, R., Krogstie, J. (2019). From Big
Data Analytics to Dynamic Capabilities: The Effect of
Organizational Inertia. Accepted for publication in the
Proceedings of the Pacific Asia Conference on Information
Systems (PACIS 2019), 8-12 July, Xi’an, China.
6. Van de Wetering and Versendaal (2019). Flexible collaboration
infrastructures and healthcare information exchange in hospitals:
an empirical resource-based perspective. Accepted for publication
in the International Journal of Networking and Virtual
Organisations.
7. Walraven, P., Van de Wetering, R., Versendaal, J., & Caniëls, M.
(2019). Using a co-evolutionary is-alignment approach to
understand EMR implementations. Accepted for publication in the
Proceedings of the 27th European Conference on Information

Systems (ECIS), June 8-14, Stockholm, Sweden.
8. Kemena, T., Van de Wetering, R., Kusters, R. (2019). The impact
of IT human capability and IT flexibility on IT-enabled dynamic
capabilities. Accepted for publication in the Proceedings of the
32nd Bled eConference – Humanizing Technology for a Sustainable
Society, June 16 - 19, 2019, Bled, Slovenia.
9. Pattij, M., Van de Wetering, R., Kusters, R. (2019). From
Enterprise Architecture Management to Organizational Agility:
The Mediating Role of IT Capabilities. Accepted for publication in
the Proceedings of the 32nd Bled eConference – Humanizing
Technology for a Sustainable Society, June 16 - 19, 2019, Bled,
Slovenia.
10. Doe, J., Van de Wetering, R., Honyenuga, B.Q., Versendaal, J.
(2019). Validating the firm technology adoption model (F-TAM).
Best Paper Award! To appear in the Proceedings of the 12th
IADIS International Conference Information Systems, Utrecht, the
Netherlands
11. Van de Wetering and Bos (2019). Toward a fitness landscape
model of firms’ it-enabled dynamic capabilities. Accepted for
publication in Encyclopedia of Organizational Knowledge,
Administration, and Technologies.
12. Carvalho, J. V., Rocha, Á., van de Wetering, R., & Abreu, A.
(2019). A Maturity model for hospital information systems.
Journal of Business Research, 94, 388-399.
13. Van de Wetering, R. (2018). IT-Enabled Clinical Decision
Support: An Empirical Study on Antecedents and Mechanisms.
Journal of Healthcare Engineering, 2018, 10. doi:10.1155/
2018/6945498.
14. Tarenskeen, D., Hoppenbrouwers, S., Van de Wetering, R. (2018) .
Reflections on Using an Architecture Model for Matching Existing
Applications to a Radical Business Requirements Change: a Case
Study. In Proceedings of The 11th IFIP WG 8.1 working
conference on the Practice of Enterprise Modelling (PoEM),

Vienna, Austria, 31 October - 2 November, 2018.
15. Doe, J., Van de Wetering, R., Honyenuga, B.Q., Versendaal, J.,
Boateng, R. (2018). Delphi Panel Discussion of F-TAM: Industry
Experts and Academic Perspectives. In Proceedings of the
International Conference on Technology, Innovation,
Entrepreneurship and Education, London, Great Britain,
September 4, 2018.
16. Tarenskeen, D., Van de Wetering, R., Bakker, R. (2018).
Unintended effects of dependencies in source code on the
flexibility of IT in organizations. In Proceedings of the Federated
Conference on Computer Science and Information Systems,
Poznań, Poland, 9 - 12 September, 2018.
17. Van de Wetering, R., Mikalef, P., Krogstie, J. (2018). Big data is
power: business value from a process oriented analytics capability.
In Proceedings of the 21st International Conference on Business
Information Systems (BIS), Berlin, Germany, July 18-20, 2018.
18. Van de Wetering, R. (2018). Enhancing clinical decision support
through information processing capabilities and strategic IT
alignment. In Proceedings of the 21st International Conference on
Business Information Systems (BIS), Berlin, Germany, July 18-20,
2018.
19. Van de Wetering, R. (2018). IT infrastructure capability and health
information exchange: The moderating role of hospital-wide
electronic medical records. In Proceedings of the 21st
International Conference on Business Information Systems (BIS),
Berlin, Germany, July 18-20, 2018.
20. Walraven, P., Van de Wetering, R., Helms, R., Versendaal, J., &
Caniëls, M. (2018). Co-evolutionary IS-alignment: a Complex
Adaptive Systems Perspective. In Proceedings of the 12th
Mediterranean Conference on Information Systems, Corfu,
Greece, 28-30 September, 2018.
21. Grave, F., Van de Wetering, R., Rutledge, L. (2018). Strategy-IT
alignment Assuring alignment using a relation algebra method. In
Proceedings of the Eight International Symposium on Business

Modeling and Software Design. Vienna, Austria.
22. Van de Wetering, R., Versendaal, J. (2018). How a flexible
collaboration infrastructure impacts healthcare information
exchange. In Proceedings of the 31th Bled eConference Digital
Transformation – Meeting the Challenges, Bled, Slovenia, June 17
- 20, 2018.
23. Van de Wetering, R., Versendaal, J., Walraven, P. (2018).
Examining the relationship between a hospital’s IT infrastructure
capability and digital capabilities: A resource-based perspective. In
Proceedings of the Twenty-fourth Americas Conference on
Information Systems (AMCIS).
24. Mikalef, P., Van de Wetering, R, Krogstie, J. (2018). Big Data
enabled organizational transformation: The effect of inertia in
adoption and diffusion. In Proceedings of the 21st International
Conference on Business Information Systems (BIS), Berlin,
Germany, July 18-20, 2018.
25. Van de Wetering, R., Mikalef, P., & Pateli, A. (2018). Strategic
Alignment between IT Flexibility and Dynamic Capabilities: An
Empirical Investigation. International Journal of IT/Business
Alignment and Governance (IJITBAG), 9(1), 1-20.
26. Mikalef, P., Krogstie, J., Van de Wetering, R, Pappas, I. (2018).
Stage model for uncovering inertia in big data analytics adoption.
In Proceedings of the 22nd Pacific Asia Conference on
Information Systems (PACIS), Yokohama, Japan, June 26-30,
2018.
27. Mikalef, P., Krogstie, J., Van de Wetering, R., Pappas, I., &
Giannakos, M. (2018). Information Governance in the Big Data
Era: Aligning Organizational Capabilities. In Proceedings of the
51st Hawaii International Conference on System Sciences
(HICSS), Waikoloa Village, Hawaii, United States, Jan 3-6, 2018.
28. Van de Wetering and R, Mikalef (2017). The effect of strategic
alignment of complementary IT and dynamic capabilities on
competitive performance. In Lecture Notes in Business
Information Processing, W. Abramowicz, R. Alt, and B. Franczyk,

Editors. 2017, Springer, Cham.
29. Van de Wetering, R., Mikalef, P., & Helms, R. (2017). Driving
organizational sustainability-oriented innovation capabilities: a
complex adaptive systems perspective. Current Opinion in
Environmental Sustainability, 28, 71-79.
30. Doe, J., Van de Wetering, Honyenuga, B.Q., Versendaal, J., R.,
(2017). Toward Firm Technology Adoption Model (F-TAM) in a
Developing Country Context. In the Proceedings of the 14th
European Mediterranean & Middle Eastern Conference on
Information Systems, Coimbra, Portugal.
31. Van de Wetering, R., Mikalef, P., & Pateli, A. (2017). How
strategic alignment of IT flexibility, a firm's networking capability,
and absorptive capacity influences firm innovation. In Proceedings
of the 10th Mediterranean Conference on Information Systems
(MCIS), Genoa, Italy, September 4-5, 2017.
32. Van den Heuvel, R., Trienekens, J., Van de Wetering, R., & Bos,
R (2017). Toward a framework of characteristics for CNOs, to
support Business/IT-alignment. Paper accepted for presentation at
the 18th IFIP Working Conference on Virtual Enterprises.
33. Van de Wetering, R., Mikalef, P., & Pateli, A. (2017a). Managing
firms’ innovation capabilities through strategically aligning
combinative IT and dynamic capabilities. In Proceedings of the
Twenty-third Americas Conference on Information Systems
(AMCIS). Boston, United States, August 10-12, 2017.
34. Van de Wetering, R., Mikalef, P., & Pateli, A. (2017b). A strategic
alignment model for IT flexibility and dynamic capabilities:
toward an assessment tool. In Conference Proceedings of the
Twenty-Fifth European Conference on Information Systems
(ECIS), Guimarães, Portugal.
35. Van de Wetering, R. (2016). Modeling Alignment as a Higher
Order Nomological Framework. In W. Abramowicz, R. Alt, & B.
Franczyk (Eds.), Lecture Notes in Business Information
Processing (Vol. 263): Springer, Cham.
36. Van de Wetering, R., & Bos, R. (2016). A meta-framework for

Efficacious Adaptive Enterprise Architectures. In W. Abramowicz,
R. Alt, & B. Franczyk (Eds.), Lecture Notes in Business
Information Processing (Vol. 263): Springer, Cham.
37. Mikalef, P., Pateli, A., & van de Wetering, R. (2016). IT flexibility
and competitive performance: The mediating role of IT-enabled
dynamic capabilities. In Proceedings of the 24th European
Conference on Information Systems (ECIS), Istanbul, Turkey, June
12-15, 2016.
38. Van der Valk, R, Helms, R., van de Wetering, R., Bex, F.J.; and
Corten, R., “Feeling Safe? Privacy controls and online disclosure
behavior” (2016). Research-in-Progress Papers. 51. http://aisel.
aisnet.org/ecis2016_rip/51.
39. Van den Heuvel, R., Trienekens, J., van de Wetering, R., & Bos, R
(2016). Business/IT-alignment adaptation in dynamic networked
environments. In Proceedings of the 17th IFIP Working
Conference on Virtual Enterprises.
Stef Joosten
Affiliation: Open University of the Netherlands, PhD
Research and Professional Experience: 30 years
Professional Appointments:
 Full Professor (part time 20%) Open University of the Netherlands

(NL),
 Management Consultant, Ordina (NL),
 Vice-chair Board of Supervision, Careaz (NL).
1. Stef Joosten, Sebastiaan Joosten, Type Checking by Domain

Analysis in Ampersand, Sept. 2015.
2. Tarenskeen, Bakker, Joosten, Applying the V Model and Axiomatic
Design in the Domain of IT Architecture Practice, Dec 2015.
3. Dijkstra, Joosten, Stamhuis, Visser, Beginselen digitaal:
Digitalisering en de beginselen van de strafrechtspleging, Jan
2016.
4. Robert Bakelaar, Ella Roubtsova, Stef Joosten. A Framework for
visualization of changes of Enterprise Architecture. LNBIP 275,
Business Modeling and Software Design, 6th Int. Symposium,
BMSD 2016, Revised Selected Papers, Volume Editor: Boris
Shishkov, Jan 2017.
5. Stef Joosten, Software Development in Relation Algebra with
Ampersand, April 2018.
6. Rutledge, Bouwer, Joosten, Rule Style: Patterns of and Extensions
to Data System User Interface Specification for Business Rule
Violations, July 2019.
Chapter 2
ENTERPRISE ARCHITECTURE KNOWLEDGE

TRANSFER AND
ORGANIZATIONAL EMPOWERMENT
Klaus Østergaard1 and Torben Tambo2

1
IT University of Copenhagen, Copenhagen, Denmark
2
Department of Business Development and Technology,
Aarhus University, Herning, Denmark
ABSTRACT
Enterprise Architecture (EA) is becoming increasingly critical to

organizations amid momentum in interest for digital transformation (DT)
essential for strategic corporate agendas. EA has traditionally largely
resided in the strategic planning environments of the technology
management functions of organizations. This has limited the general
understanding of architecture and the insight from business units in
opportunities and limitations of existing and future technological
solutions. In this chapter, it is discussed how initiatives can be taken to
bring more attention to the business units on EA and to incite
architectural thinking. Central is training and coaching of corporate
decision makers, strategic business planners, financial specialists,
42 Klaus Østergaard and Torben Tambo
business developers, line managers and generally non-IT-profiles in

architectural artifacts, structure, interrelationships, abstract levels and
management. Architectural thinking relates to foundations, structure,
sequence, prioritization, and precision in the formulation of expected
outcomes. Key means, relate to conversion. Conversion from business
architecture to technology architecture and vice versa. Also, conversion
from thinking in existing technologies to technologies of opportunity for
digital transformation within existing and new business models.
Consequences of change must be trained carefully as smaller and larger
changes can lead to both success and failure depending on the quality and
resilience of the stipulated architectures. This chapter’s findings suggest
that business specialists and enterprise architects can benefit from
collocated training; that training activities in EA are both one-off training
and recurring training, where the latter is giving a community of practice
adding more to training.
Keywords: enterprise architecture, learning, skills, competencies,

communities of practice, organizational learning, enterprise architect
INTRODUCTION
Enterprise Architecture (EA) is getting more and more focus in

industrial practice as well as in academia. Among key motivations for this
are the concepts critical to future business strategies like digital
transformation (Bondar et al., 2017) and Industry 4.0 (I4.0)/Industrial
Internet of Things (IIOT) (Enke et al., 2018). EA is the product of the work
done by enterprise architects and establishes a cornerstone in converting
business strategy into workable, corporate solutions balancing existing,
future and transitional resources (Zhang et al., 2018). As there are little full
educational programs solemnly focused on educating enterprise architects,
knowledge, skills and competencies must be transferred in different ways
than formal vocational or academic programme-based training (Hazen et
al., 2017; Mapingire et al., 2018; Sembiring et al., 2013). Companies and
individuals can reach out to many offerings, but skills formation in a more
detailed level is an area less illuminated by research. Some certification
schemes have been developed within or supported by academia, like the
Enterprise Architecture Knowledge Transfer … 43
Carnegie-Mellon’s (CMU, 2018) Enterprise Architecture and

Organizational Design Standards for Education. This suggests a legitimacy
of research training and ongoing skills maintenance and enhancement
(Casas et al., 2017; Fernandez-Sanz et al., 2017). There are not a lot of
studies on how, more precisely, various skills transfer schemes should be
organized and offered in order to establish sufficient knowledge
empowering ongoing enterprise architecture initiatives. In this picture,
there are not just enterprise architects, but also the EA empowerment of the
organization. It must be assumed that organizational stakeholders with a
certain level of insight in EA will be better stakeholders than those with no
insight. This leads to a combined organizational and stakeholder
perspective of skills and training in EA as well as maintenance of the
actual skill level alongside qualifying discussion of EA as a management
construct (Wagner et al., 2015; Argote et al., 2003).
Commonly, in the literature and in EA frameworks, a number of skill
and qualification baselines are stipulated (CMU, 2018). Baselines are, in
general, very ambitious and reflect a sophisticated level of general and
specific knowledge and behavioral traits (The Open Group, 2018).
Baselines are often so ambitious that they can soberly question how an
individual, professional will cater to such a breadth and depth. This is
embossing the perception, or even myth, of proficient enterprise architects
as rare, costly and with no clear methodology, except brilliant personal
skills, for achieving relevant success. However, little is said about how a
company should reach this point, and what the consequences are in case of
companies not having adequate skills among employees and specialists.
Can a company start a digital transformation project without enterprise
architects, without certified staff in the selected EA framework, and
without a digital architectural mindset?
Enterprise architects are typically recruited from the IT department, the
business development department or from other high-level technological
support functions throughout the company (Thönssen and von Dewitz,
2018; El-Mekawy et al., 2015). Enterprise architects can have backgrounds
as IT specialists or corporate generalists (Casas et al., 2017). To support
and sustain digital transformation and similar agendas of complex,
contemporary enterprises, this chapter claims a need for broader corporate

engagement in EA processes (Schwer et al., 2018). An engagement
matching the general trend towards digital enterprises exists where digital
elements pervasively are solidly placed in all business processes and
infrastructural elements. Learning and skills transfer and maintenance is
critical to this pervasiveness.
To obtain a broader reach of EA, the aim of this chapter is to
investigate learning processes of EA in companies and organizations. The
purpose is to distill a set of guiding principles for learning processes and
skills formation of EA to enterprise architects, business managers, and the
business and technology specialists that need to consider and relate to
enterprise architecture. Using empirical material on around 1200
participants in a range of EA training and certification schemes and events,
execution, impact and influence is researched and discussed.
METHODOLOGY
The methodology of this chapter is qualitative, case-based,

interpretivistic and socially-inspired (Walsham, 1995). Although some
contributing quantitative background data are presented for highlighting
the empirical context. The methodology is in line with general principles of
information systems research methods emphasizing case-based learning
(Lee, 2011). Case-based research is central provided that research
principles of rigor are verifiable and are sought with appropriate
documentation (Baskerville and Wood-Harper, 1998).
This chapter is aimed at framing EA training. This chapter is not
seeking a major impact analysis study. Impact analyses are complex as
many factors are influencing them. These factors include market trends,
general technology readiness, corporate structures and then to availability
of sufficient, EA skilled resources. Rather, this chapter is contrasting
general assumptions of that the quality of enterprise architecture is first and
foremost enabled by highly skilled and highly experienced individuals.
Data is collected longitudinally from EA training activities conducted

from 2010 to 2019. Research artefacts and data collection scoping is listed
in Table 1. Competencies are included in several EA frameworks, the
research artefacts in Table 1 are positively regarded also in the light of EA
artefacts such as a training curriculum, a summer school curriculum or the
adherence to certain standardization organizations (Gong and Janssen,
2019).
Data is managed, such as training materials, participants list,
participants roles, and evaluation materials. The amount of data is high due
to the longitudinal character of the research. E.g., it encompasses 1200
students although a relative amount are recurring. The count of
organizations is also well over 100 on both trainer and participants’ sides.
The viewpoint on data is subsequently that even though the data is a
quantity, the academic interpretation is qualitative.
Table 1. Research artefacts and data collection approach
Research artefacts Data collection scoping

Training objectives Ranges from university courseworks with formal
objectives to professional training with more concise
statements
Training content Content lists, presentations, in some cases spoken
words from video materials
Organizers Organization and organizational motives included in the
offering
Trainers (speakers, presenters) Experience from CVs, skill-sets, previous training
Participants Lists of profiles found in the empirical section
The organization of the trainers Trainers are both independents but also excused from
major companies, governmental agencies and learning
institutions around
The organization of the participant(s) Some organizations supports participations on
individual basis, other organizations send teams
External stakeholders Certification bodies, like CMU, OMG, The Open
Group, Global Association of Enterprise Architects
THEORETICAL BACKGROUND
As the digital agenda is more and more in the limelight of corporate

strategic processes, architecture is highly critical to assure reason and
transparency in existing and forthcoming technologies. With enterprise

architecture in the delicate role of balancing between business and
technology, the skills required for executing EA are expected to establish a
key role in successful decision making.
Enterprise Architecture Practices
EA is the ‘analysis and documentation of an enterprise in its current

and future state from an integrated strategy, business, and technology
perspective’ (Bernard, 2012). Its quintessence lies in building an
organizing meta-context for the alignment of technology planning and
business planning, with strategic planning as its primary driver (Lankhorst,
2009; Simon, Fischbach, & Schoder, 2014). Bernard (2012) presents EA as
a cubic representation consisting of the dimensions artefacts, segments,
and levels. Artefacts are large organizational entities of value creation.
Segments are cross-cutting components of the enterprise, for example a
human resource database. Levels are hierarchical constructs with the
strategic initiatives of the enterprise at the top (level 1) and technology and
infrastructure as the base layer (level 5). Level 4 is systems and
applications, level 3 data and information, and level 2 products and
services. Fundamental to the EA philosophy is the transition from a
documented present state to an intended future state. The level-based
model serves as an illustration of and support for interrelations within the
enterprise of the distinct technological levels. Each level plays an exclusive
role in ensuring that the operating model of the enterprise, for example
products and services, is a representation of the artefacts required for a
business service and thereby a business model (Gama, Sousa, & da Silva,
2013). Business models are defined from the top level but rely on
distinctive hierarchical dependencies (Iacob, et al., 2014); business models
might define the enterprise architecture, but the enterprise architecture can
also be used in the creation of business models, for example in switching
from delivering physical products to delivering services for these products.
Enterprise architecture is a complex discipline to master. Korhonen

and Molnar (2014) discuss EA as a (fundamental) business capability that
is critical to the overall business creation. Ongoing discussions seek to
capture the maturity of the enterprise in respect to EA and EA governance
(Jahani, Reza Seyyed Javadein, & Abedi Jafari, 2010). In the sense of EA
representing the systems and applications of the enterprise, it is closely
related to (strategic) software systems’ portfolio management and thereby
also decisive in the selection of the technological elements of the
enterprise’s operating model.
EA is discussed in initiatives on inter-organizational relationships
(Tambo T., 2017; Drews & Schirmer, 2014) and technological
interoperability (Guédria, Gaaloul, Naudet, & Proper, 2013). As the EA is
derived from the single organization’s strategy, there are limitations to the
ability to enact technological design in other enterprises, although most
levels of the EA model rely on external relationships anyway, for example
parts from suppliers, products for the market, and data sent to and from
relevant parties. Drews and Schirmer (2014) suggest that EA can be a
positive driver for the creation of business eco-systems.
EA is generically supported by the dominant implementation and
maintenance framework TOGAF (The Open Group Architecture
Framework) (Tambo, Bargholz, & Yde, 2016; The Open Group, 2018).
TOGAF outlines a methodology for implementation starting with the
setting of business objectives and describing the outcome (Searle, 2018;
Rusli & Bandung, 2017) and structures an enterprise from the business,
data, application, and technology architectures, whereby reaching out to
the business surroundings is addressed by the idea of an ‘enterprise
continuum’ (Kearny, Gerber, & van der Merwe, 2016). TOGAF strongly
addresses the enterprises’ ability to adapt and adopt technology from
maturity measurement, stating the readiness, organization, management
buy-in, structuration level, and more, and implementation is considered as
a continuous process known as the architecture development method
(ADM) (Ansyori et al., 2018; Cabrera, Abad, Jaramillo, Gómez, &
Verdum, 2016).
Learning Principles
Information and Communication Technologies (ICT) has always been

training intensive in the sense that specific knowledge is volatile when it
comes to the technology itself with version systems, new version, new
fashions influenced by hype-sensitivity, and general corporate dynamics
(Naveh, 2015; Teräs and Kartoğlu, 2017; Trad and Kalpic, 2014; Luca and
Oliver, 2002). Most learning has traditionally been in a classroom 2 – 5
days with lectures and exercises. Learning is the experienced and
perceived insight brought into the classroom by the students with all sorts
of influencing factors from the outside world. Generally, it is recognized
that strong learning must engage both theory and action in corporate
contexts. A student in a learning context is not only one person or one
single skill. The person represents a breadth of numerous competencies
that will act together in a training session. The multiple skill enactment is
described by Brix (2019) as ambidexterity, although with an eye for
defining the specific form of ambidexterity in the dichotomy in exploration
and exploitation. Etsiwah et al. (2019) addresses that learning processes
must address a broader corporate landscape than otherwise anticipated and
address both blue- and white-collar workers.
Fernandez-Sanz et al. (2017) is presenting a comparative study of ICT
competency frameworks namely the e-Competence Framework e-CF (EN
16234-1:2016), ESCO (European Skills, Competences and Occupations
classification) and the European ICT BOK. A consolidated framework is
presented with eSkills Match that serves for navigation in the landscape of
ICT competencies stressing self-assessment, job competency profiling and
individual/collective development opportunities. It is evident from the
study that there is a strong dynamic between competencies and jobs,
meaning a migration both in and out of areas like enterprise architect. On
enterprise architecture, the study establishes EA as a competency rather
than a job. The study is not assuming any specific learning methodology,
just learning objectives.
Key EA frameworks are differently oriented towards skills and
competencies. In applying broad-based EA frameworks, staffing of
enterprise architects is however pointed as critical for successful EA

initiatives. Handley et al. (2019) discuss how a specific known EA
initiative can be staffed optimally with proficient enterprise architects by
forecasting the training needs of existing personnel versus attracting
experts. In line with this is Hazen et al. (2017) presenting findings on EA
strategic orientation and EA assimilation. This is leading to improved firm
performance with an argument revolving around understanding EA as a
shared firm-level and individual competency establishing uniqueness of the
firm.
Learning principles must be based on mutual processes between the
actors in focus. Centralized competencies can well serve as a baseline, but
individual persistence is the actual driving force, however Lee and Choi
(2003) insist on presence of enablers for knowledge processes.
Systematics of EA Learning
Mardis et al., (2018) are providing a seminal study in the alignment

between ICT, industry needs and the area of professional requirements and
educational opportunities notably pinpointing a balance between “hard”
and “soft” skills being difficult to measure, but important for the relevance
of jobroles. Ansouri et al. (2018) are ranking skills, learning, learning
culture, training and certification as one of the lowest ranked factors in EA
implementation. This contradicts most other contributors stating learning
and skills are significantly higher. Azevedo et al. (2015) suggest
Department of Defense’s Architectural Framework’s (DoDAF) concept of
“doctrine, organization, training, material, leadership and education,
personnel and facilities” highlighting the human factor on the execution
level as the key success factor.
Banaeianjahromi (2018) ranks a range of human issues as a part of
both success and failure in EA implementation but emphasizes a
dichotomous view on the human side both being able to promote EA but
also to dampen and inhibit EA initiatives dependent on training, insight,
management and engagement.
Tambouris et al. (2012) define EA learning as broad-based covering a

vast range of competencies, skills, knowledge and attitudes. Marcao et al.
(2019) suggested game-based approaches for optimal learning within EA.
A core base in this research is the CMU certification framework
(CMU, 2018). The CMU framework is specifically oriented on training of
enterprise architects. Four levels of skills and experience are defined by
CMU(2018) as:
 Beginning Architect (0 – 2 years of experience)

 Mid-Level Architect (3 – 5 years of experience)
 Senior Architect (6 – 10 years of experience)
 Chief Architect (10+ years of experience)
Twelve Knowledge and Skills Areas (KSA) are defined to constitute

the overall body of knowledge. The areas are:
1. Fundamental Concepts and Practices

2. Implementing Concepts and Methods
3. Architecture for Startups, Mergers & Acquisitions
4. Auditing the Maturity and Value of Architecture Programs &
Projects
5. Using Architecture to Support Risk Management & Security
6. Government Enterprise Architecture Concepts and Methods
7. Enterprise Architecture Consulting Concepts and Practices
8. Big Architecture - Very Large Scale Implementations
9. Modeling, Analysis, and Documentation Skill Building
10. Agile Architecture for 90-Day Rapid Business Improvement
11. Post-Certificate Architecture Refresher Seminar
12. Using Architecture in Create and Respond to Organizational
Disruption
Each of the KSAs has 12 sub-areas. To illustrate the principles, but not
reproduce more than necessary, area 9 is composed of these sub-areas:
9.1 Communicating Documentation Value to Stateholders

9.2 Developing Strategic Plans and SWOT Analyses
9.3 Developing and Using Operational Scenarios
9.4 Business Process Modeling
9.5 Data Modeling - Entities and Objects
9.6 Data Modeling - Warehouses and Marts
9.7 Application Modeling - Enterprise Service Buses and APIs
9.8 Network Modeling - Voice, Data, Video, and Mobile
9.9 Depicting Cloud Environments and Services
9.10 Depicting Security Control Sets and Solutions
9.11 Developing Overview Diagrams for Management
9.12 Using Documentation Tools and Repositories
Interesting is the use of common terms that for the broadest range of
technology and business professionals of modern enterprises is
recognizable or can be used in the instructional situation for bridging
between students’ founding knowledge and the desired knowledge.
EMPIRICAL STUDIES OF SKILLS TRANSFER
To establish a sound foundation for disruptive digital business, Sousa

and Rocha (2019) define a multi-skill, learning model revolving around the
clusters of innovation skills, leadership skills, and management skills. In
this section, a series of EA learning activities is presented. These are all
supporting architectural thinking and addressing professional profiles
aspiring to work with EA, respectively already being EA professionals.
The learning activities are done is association with universities, but are not
necessarily reflecting curricular training.
The current study is encompassing a longitudinal approach to learning
processes of EA dating back to 2010 and as of 2019 are still ongoing, see
Table 2.
Summer School
From 2010 – 2019 an annual summer school on Enterprise

Architecture has been conducted addressing IT, IS, business development
and management professionals alongside university students. The overall
format has been, lecturing Monday or Tuesday to Thursday or Friday
making it 3 – 5 days long. The participants (non-speakers) have been
distributed e.g., as 15 students from a programme in engineering
management, 15 students from a programme in IT management, and 60
practitioners. There have been around 20 speakers during the week.
 Days have been organized either as blended approaches of industry

cases or thematically. Thematic days have been e.g.,
Table 2. List of EA training activities
Event name Year Audience Participants Event Intended

started accumulated outline outcome
(/ended)
Summer 2010- Industry 700 3 – 5 full Inspiration for
School ongoing professionals, days in practitioners.
university August EA mindset
students thinking for
students.
Municipal 2017 – Public 200 2 full Inspiration
administration 2019 administration days and
training professionals empowerment
Executive 2013- General 300 12 Certification
master ongoing industry weeks,
university professionals one half
training day per
week
 “Academic day” covering contemporary research and recent

master and PhD thesis presentations.
 “Manufacturing day” of manufacturing companies presenting in a
context where most other presenters are not representing typical
physical manufacturing.
 “Pharma day” of pharmaceutical companies and regulators
presenting.
 “Governmental day” of public sector presentations or presentations

from vendors to the public sector.
Presenters have been selected to constitute a holistic picture of EA.

This can lead to learnings on EA in relationship to adjoining disciplines
such as:
 Portfolio management
 Investment planning
 Agile methods
 IT infrastructure
 Business strategy
 Business and digital transformation
 Top level management interaction
 Decision making and organizational behavior theory
 Visual and representational methods
 Reporting, analytics and big data approaches
Trend analysts, futurists and strategic consultancies have also been

presented to give accounts of probable development directions. Presenters
have been approximately 2/3 local contributors from key industries around
the course venue, and 1/3 international presenters with either professional
EA knowledge profiles or IT industrial trend researchers. Most presenters
present pro bono. Broadly, half of the presenters are recurring and half are
replaced from year to year to balance between known content and new
content.
An exemplary weekly program could look like Table 3.
Many practitioners have participated several times. Companies and
departments have sent practitioners on a recurring basis. Some
participants’ satisfaction measurements have been done although not fully
structured. On a 1 – 5 Likert scale, the practitioners turns out with a rating
of 4.3. Recurring participants are regarded as an index of an overall
positive satisfaction.
Table 3. Weekly program of EA summer school (example)
Monday Tuesday Wednesday Thursday Friday

Morning 1 Contemporary Analysts Current EA and The
academic status view banking EA portfolio impact of
of EA issues selection and agility on
management EA
Morning 2 Key Municipal Banking seen Governmental Human
community case from auditors key guidelines dimensio
issues from EA EA view ns of EA
conferences
Afternoon Governmental Design Analysts view Financial EA Smart
1 frameworks philosophies and innovation cities and
EA
Afternoon Academic Organization Practical EA Frameworks Conclusi
2 presentations al faces and in current presentation ons
from master interfaces of issues in
students final EA banking
dissertation
Municipal Training
The association of Danish municipalities (abbreviated KL) is pursuing

a strong digital strategy. A subsidiary has also been set up to assist
municipalities in architecture, design, standards, some specialist shared
services, project support and tendering and purchasing processes of
services from private IT vendors.
The KL organization entered with an EA consultant to create greater
awareness on EA in municipal processes and processes involving
municipalities and their external stakeholders. The awareness initiative is
done as EA training. A number of EA training sessions were conducted
throughout 2018 and 2019. Most municipalities have sent employees to
participate. In Table 4 the occupancy of the participants are summarized
and simplified. There were 237 participants with a majority of IT
professionals but with a reasonable representation from business
development functions.
The learning agenda has gone through a number of steps, simplified in

the following list:
1. Enterprise Architecture guiding your Digital Transformation

2. EA as the program that bridge the gaps between Strategic goal and
Business vision
3. EA as the program for the Journey from Strategy and Business
vision to Enterprise Design
4. Implications of Business ecosystems on enterprise architecture and
vice versa
5. Implications of software ecosystems on enterprise architecture and
vice versa
6. Enterprise architecture enabling agility of business & agility of the
architecture
7. The four pillars of Enterprise Architecture: Architecture
governance, Business Architecture, Information Architecture and
Application Architecture
8. Enterprise Architecture moved out of IT and away from the CIO
Table 4. Participants summary of municipal EA training
Business consultant 42
CEO 4
CIO 13
Citizens services manager 18
IT and digitalisation consultant 67
IT Architect 33
Operations specialists 26
Project and program manager 34
237
9. Trends and EA: Agile, Robots, Data-governance, Customer

journey and GDPR
This can be conducted both as a 1-day and 2-day session. The KL

organization considered the training as a stepping stone on the way to get
EA thinking in place in the municipal sector. Not that this hasn’t been
there, but the ongoing transfer for system responsibilities to vendors,
private operators, and national shared service-centres are continuously
changing the local EA. No test, certification or evaluation was intended.
The importance of the outcome was awareness and local EA mindsets for
empowering future projects of dialogue.
Certification Training
Within a university programme in IT Management, a course is offered

in EA following the CMU guidelines and leading to a certification. The
course objectives are formulated as follows:
“The student must, at the end of the course, be able to:
 Explain the background and content of a number of key issues

within enterprise architecture.
 Explain and compare the essential concepts of enterprise
architecture, including the framework and artefacts and their
interdependencies.
 Evaluate the architecture maturity, governance and strategy in an
enterprise.
 Search for more information, for example, scientific literature,
reports, specifications and use this information in methodology
and argumentation.”
Course content is presented below in Table 5 with content on the left

side and the pedagogics of the teacher on the right side.
Below, in Table 6, are the participants’ satisfaction measured over a
recent span of years.
The satisfaction level is relatively high. Notable is the question on a

future job profile which soared over the later years suggesting an increased
interest in companies for EA whereas a slump might have existed around
2015 before the Digital Transformation hype took momentum.
The number of certified students from 2013 – 2019 was approximately
300. The university is the IT University of Copenhagen.
Table 5. University certification course content, annotated
Stated content and learning style Teaching pedagogic motivation

The course provides a basic introduction to Establish fundamentals by and large based on
enterprise architecture (business and IT students’ existing IT qualifications
architecture) based on internationally Assure the students of the adherence to CMU
recognized models, methods and frameworks.
The course learning objectives follow
Carnegie Mellon University’s Enterprise
Architecture Knowledge and Skills Areas
(levels 1.0 and 2.0).
This course examines the overall enterprise The students must consider the enterprise
architecture process from strategic planning to before technology and exercise insight into
the specific architecture work in the areas of top-level corporate processes
business architecture, information
architecture, solution architecture and
technical architecture.
The interplay between architecture process This section draws lines from EA to key
implementation and operational processes is disciplines of the students of both their
discussed. Themes such as IT governance, professional experience and their academic
performance management, benchmarking and core knowledge. The support disciplines
ROI will be analysed from an architecture serves as relating to less abstract or practical
perspective. Service Oriented Architecture contexts
(SOA) and key concepts such as cloud and
micro services will be examined at a strategic
level. Course participants are also introduced
to management of services and infrastructure,
value-based development, and business
process management (BPM).
ANALYSIS AND DISCUSSION
Typologies of professional learning range from individual coaching to

broad plenary presentation-style conferences and to classroom styles of
one-way lecturing blended with exercises.
Coaching is intensive and expensive, and speaking to a large audience

is more unpredictable in respect to individual gains, but is less costly. All
of the above mentioned learning processes have “classroom presentations”
as their backbone of knowledge transfer. In general, the classroom
elements have been supplemented with exercises in smaller groups.
Impact Analysis
Impact analyses of extensive skills transfer processes are often

disputable when it comes to impact measurements (Fernandez-Sanz et al.,
2017; Azevedo et al., 2015). Who should measure, and what should be
measured? And what are potential biases in a measurement process (Hazen
et al., 2017). The learning activities above, address a wide range of
professionals both being or aspiring to be enterprise architects, also
addressing future specialists who will join in EA processes of the
enterprise in a smaller or larger extent.
Table 6. Participants satisfaction measurements 2013-2019

2013
2014
2015
2016
2017
2018
2019
0..fully disagree, 6..fully agree

Overall conclusion: I am happy about 4.86 5.06 4.67 4.44 5.21 5.00 4.94
this course
I see a close correlation between the 5.08 4.81 4.71 4.72 5.27 5.00 4.78
course topics and the intended
learning outcomes
I sense a close correlation between the 5.00 5.00 4.83 4.38 5.47 5.22 4.94
intended learning outcomes and the
test form
I think the course is relevant for my 5.00 4.81 4.42 5.00 5.07 5.22 5.50
future job profile
I am satisfied with my effort on this 4.29 4.25 3.92 4.40 4.79 5.00 4.72
course
Table 7. Derived learning objectives progression of architects and organisation
EA and enterprise architect competency engagement profile

Non role Infrequent Advisory Full engagement Core role
Comparable TOGAF 0 Nil 1 Background 2 Awareness 3 Knowledge 4 Expert
skill level
Distinct enterprise No enterprise Carry out enterprise Assume enterprise Junior enterprise Senior enterprise
architect job and architect job roles architect task from time to architect roles on ad architect architect
competency roles time hoc basis
Organizational EA EA knowledge not Infrequent EA Ad hoc interaction Junior business Senior business
competencies present in profile responsibilities with enterprise specialist role specialist role
architects
In a further impact analysis, it is necessary to understand the detailed

relationship between job roles and competency profile before and after
training. In this, a range of EA competency profiles can be identified. See
Table 7. It is not obvious to operate a distinction between the
organizational knowledge on architecture and enterprise architects. The
CMU framework is obviously designated to the training of enterprise
architects. The training activities train more students not labelled as
enterprise architects than architects. This is clearly seen in the municipal
training. Very few enterprise architects are present, and very few
municipalities employ enterprise architects at a larger scale. So, knowledge
and skills must be expected to exist more in the organization at large than
in a designated team of enterprise architects. Although, there has to be an
intimacy between architects, the business and especially business and
technology specialists with an architectural proficiency. In the remainder
of this discussion, it is assumed that the organizational body-of-knowledge
on enterprise architecture is as important, or more important, than the
actual presence of a strong team of enterprise architects.
From the training activities above, a dynamics among enterprise
architects is noticed. Architects can diffuse into adjacent fields ranging
from management to specialist roles dependent on current agendas in the
enterprise. E.g., if data privacy and cybersecurity is taking dominance, then
the architects might have reassigned responsibilities, thus eroding the
impact of training.
The matter of organizational EA competencies seems essential as
enterprise architects are assumed scarce, expensive and obviously without
omniscient in all business aspects (Nithithanatchinnapat and Joshi, 2019).
The major count of participants in the training has been business and
technology managers and specialists seeking to heighten EA competencies
to be optimal domain partners to enterprise architects. This suggests an
alternative style of impact of EA training: A set of skills and abilities to
distill strategic needs and interpret business processes into an EA context.
In contrast to the CMU Knowledge and Skills Area (KSA), an
organizational proficiency of EA is suggested as operable.
Critical View
In this study we have found several positions defining enterprise

architects as sole leaders and proponents of EA in enterprises characterized
by very extensive skills in human, technology and business aspects at large
(Tambouris et al., 2012). We see this as conflicting with enterprise
architects as a scarce resource and the enterprise architects opportunities to
relevantly reach out to the organization. A contradicting position would be
to sufficiently empower the organization. The presented learning cases
have enterprise architects as the typical and central audience. It is clearly
indicated from the data collection that most participants insist on obtaining
enterprise architecture knowledge rather than assuming the title of
enterprise architect.
The training of enterprise architects is critical to support the EA
processes of the enterprise. The training of non-architects is widely
expected to have a benefit in improving architectural processes. Few
bachelor or master study programmes are offered specifically in EA, so in
general, should EA be learned as a skill in professional development? This
also indicates a broad diversity of background of enterprise architects.
Recorded in the training processes are typical groups of:
 Senior IT professionals
 Business development officers
 Business architects
Smaller groups include tactical financial officers and engineers broadly

from e.g., service development organizations or quality management. The
large group of senior IT professionals might both come from technology
positions and from general positions of project management, service
management, portfolio management and planning.
In Figure 1, it is illustrated how EA initiatives in enterprise consist of
two – suggested – balances. A balance between the specialized, individual
of the enterprise architect, and organizational and community based skills
and competencies residing among broader ranges of non-architects. The
other balance is between initiating training such as a certification, and the

maintenance of skills and discussions stated here as initiating training
versus recurring training. Where the municipal and the certification
program above are initiating, the summer school is more recurring training.
The community-styled organizational approach is not clearly laid out
in assessment and readiness metrics, but is suggested to be considered.
Likewise with actionability of EA as an organizational construct of shared
learning rather than an architects training. Obviously, participation needs
to be qualified, but bringing domain knowledge to enterprise
transformation seems attractive. Analogous approaches are found in agile
development methods using product owners and business owners to
represent domain knowledge in ICT projects.
CONCLUSION
In this chapter we have identified two fundamentals of industrial

learning for EA knowledge dissemination: recurring and one-off. Together
with this we have realized that training and certification in EA can address
architects as well as business (development) specialists in the same room.
The recurring learning process is forming a professional community of
practice (Nicolini et al., 2016). The recurring learning process is moreover
offering a learning dualism between situated learning processes and the
thematics presented professional events such as the Summer School.
This chapter is not postulating a specific learning methodology that
stands out. Much more, there is a clear indication that the learning
processes are configurable to evolving conditions of the organization.
Learning is an assemblage of people, processes, needs and systems.
Therefore should one-way classroom teaching be a building block between
many other building blocks?
Figure 1. Individual vs organizational learning.
As suggestions for further research, the impact of training-acquired

skills and non-training-acquired skills must be studied in the enterprise
architects work-processes, thus evaluating the possibility to train good
enterprise architects, or if it is still to take a high level of seniority to be a
good enterprise architect. In the line of the findings on organizational
empowerment, it is definitely interesting to research the impact of training-
acquired skills and non-training-acquired skills for the architectural
awareness in the organization away from enterprise architects. As several
authors also suggest, EA processes can be “non-IT,” so if the organization
can improve processes without complex, greenfield IT projects, there
would be a great benefit. This could happen e.g., if shadow systems are
eliminated, if communication processes are streamlined, and common
terminologies and process models are used. Finally, it would also be
interesting to gain more evidence of the quality of output from EA
processes where proficient enterprise architects are interacting with a
organization with a high insight into architectural thinking. This could
furthermore entail use of EA knowledge as EA awareness as potential
augmentation or even a replacement for readiness assessments such as
otherwise defined by TOGAF.
REFERENCES
Ansyori, R., Qodarsih, N. & Soewito, B. (2018). A systematic literature

review: Critical Success Factors to Implement Enterprise Architecture.
Procedia Computer Science, 135, 43-51.
Argote, L., McEvily, B. & Reagans, R. (2003). Managing knowledge in
organizations: An integrative framework and review of emerging
themes. Management science, 49(4), 571-582.
Azevedo, C. L., Iacob, M. E., Almeida, J. P. A., van Sinderen, M., Pires, L.
F. & Guizzardi, G. (2015). Modeling resources and capabilities in
enterprise architecture: a well-founded ontology-based proposal for
ArchiMate. Information systems, 54, 235-262.
Baskerville, R. & Wood-Harper, A. T. (1998). Diversity in information
systems action research methods. European Journal of information
systems, 7(2), 90-107.
Bernard, S. A. (2012). An introduction to enterprise architecture.
AuthorHouse.
Bondar, S., Hsu, J. C., Pfouga, A. & Stjepandić, J. (2017). Agile digitale
transformation of enterprise architecture models in engineering
collaboration. Procedia Manufacturing, 11, 1343-1350.
Brix, J. (2019). Ambidexterity and organizational learning: revisiting and
reconnecting the literatures. The Learning Organization.
Cabrera, A., Abad, M., Jaramillo, D., Gómez, J. & Verdum, J. C. (2016).
Definition and implementation of the Enterprise Business Layer
through a Business Reference Model, using the architecture
development method ADM-TOGAF. In Trends and Applications in
Software Engineering; Springer: Berlin, Germany, pp. 111–121.
Casas, L., Sánchez, M. & Villalobos, J. (2017, April). Creating Virtual
Enterprises to Strengthen IT Architects’s Training. In International
Conference on Computer Supported Education (pp. 154-178).
Springer, Cham.
CMU. (2018). Enterprise Architecture and Organizational Design
Standards for Education. Knowledge and Skills Area (KSA) Version
6.0. Carnegie-Mellon University.
Drews, P. & Schirmer, I. (2014). From Enterprise Architecture to Business

Ecosystem Architecture: Stages and Challenges for Extending
Architectures beyond Organizational Boundaries. In Proceedings of
the 18th International Enterprise Distributed Object Computing
Conference Workshops and Demonstrations, Ulm, Germany, 1–2
September, pp. 13–22.
El-Mekawy, M., Rusu, L. & Perjons, E. (2015). An evaluation framework
for comparing business-IT alignment models: A tool for supporting
collaborative learning in organizations. Computers in Human
Behavior, 51, 1229-1247.
Enke, J., Glass, R., Kreß, A., Hambach, J., Tisch, M. & Metternich, J.
(2018). Industrie 4.0–Competencies for a modern production system:
A curriculum for learning factories. Procedia Manufacturing, 23, 267-
272.
Etsiwah, B., Hecht, S. & Hilbig, R. (2019). An Interdisciplinary
Exploration of Data Culture and Vocational Training. In Weizenbaum
Conference (p. 7). DEU.
Fernández-Sanz, L., Gómez-Pérez, J. & Castillo-Martínez, A. (2017). e-
Skills Match: A framework for mapping and integrating the main
skills, knowledge and competence standards and models for ICT
occupations. Computer Standards & Interfaces, 51, 30-42.
Gama, N., Sousa, P. & da Silva, M. M. (2013). Integrating enterprise
architecture and IT service management. In Building Sustainable
Information Systems; Springer: Boston, MA, USA, pp. 153–165.
Gong, Y. & Janssen, M. (2019). The value of and myths about enterprise
architecture. International Journal of Information Management, 46, 1-
9. ‘
Handley, H. A., Vance, E. & Heimerdinger, D. (2019). A Human Resource
Framework for Enterprise Architectures. IEEE Engineering
Management Review, 47(1), 86-93.
Hazen, B. T., Bradley, R. V., Bell, J. E., In, J. & Byrd, T. A. (2017).
Enterprise architecture: A competence-based approach to achieving
agility and firm performance. International Journal of Production
Economics, 193, 566-577.
Iacob, M. E., Meertens, L. O., Jonkers, H., Quartel, D. A., Nieuwenhuis, L.

J. & van Sinderen, M. J. (2014). From enterprise architecture to
business models and back. Softw. Syst. Model., 13, 1059–1083.
Jahani, B., Javadein, S. R. S. & Jafari, H. A. (2010). Measurement of
enterprise architecture readiness within organizations. Bus. Strategy
Ser., 11, 177–191.
Kearny, C., Gerber, A. & van der Merwe, A. (2016). Data-driven
enterprise architecture and the TOGAF ADM phases. In Proceedings
of the International Conference on Systems, Man, and Cybernetics,
Budapest, Hungary, 9–12 October, pp. 4603–4608.
Korhonen, J. J. & Molnar, W. A. (2014). Enterprise architecture as
capability: Strategic application of competencies to govern enterprise
transformation. In Proceedings of the 16th Conference on Business
Informatics (CBI), Geneva, Switzerland, 14–17 July, pp. 175–182.
Lankhorst, M. (2009). Enterprise Architecture at Work; Springer:
Dordrecht, The Netherlands; Heidelberg, Germany; London, UK.;
New York, NY, USA.
Lee, A. S. (2011). IS research methods: inclusive or exclusive?. Journal of
Information Technology, 26(4), 296-298.
Lee, H. & Choi, B. (2003). Knowledge management enablers, processes,
and organizational performance: An integrative view and empirical
examination. Journal of Management Information Systems, 20(1), 179-
228.
Luca, J. & Oliver, R. (2002). Developing an Instructional Design Strategy
To Support Generic Skills Development. In Winds of change in the sea
of learning: Charting the course of Digital Education. Proceedings of
the 19th Annual Conference of the Australasian Society for Computers
in Learning in Tertiary Education. Auckland, New Zealand, 8-11
December 2002.
Mapingire, K., van Deventer, J. P. & van der Merwe, A. (2018).
Competencies and skills of enterprise architects: a study in a South
African telecommunications company. In Proceedings of the Annual
Conference of the South African Institute of Computer Scientists and
Information Technologists (pp. 154-163). ACM.
Marcão, R. P., Pestana, G. & Sousa, M. J. (2019). Performing Enterprise

Architectures Through Gamified Business Models. In Handbook of
Research on Business Models in Modern Competitive Scenarios (pp.
232-246). IGI Global.
Mardis, M. A., Ma, J., Jones, F. R., Ambavarapu, C. R., Kelleher, H. M.,
Spears, L. I. & McClure, C. R. (2018). Assessing alignment between
information technology educational opportunities, professional
requirements, and industry demands. Education and Information
Technologies, 23(4), 1547-1584.
Naveh, G., Even, A., Fink, L. & Berman, S. (2015). Information
Technology Education in a Digital Factory Learning Environment.
Intelligent Automation & Soft Computing, 21(4), 659-672.
Nicolini, D., Scarbrough, H. & Gracheva, J. (2016). Communities of
practice and situated learning in health care. The Oxford Handbook of
Healthcare Management, 255-278.
Nithithanatchinnapat, B. & Joshi, K. D. (2019). A global view of what
fixes information technology skills shortage: Panel data analyses of
countries’ human and technology resources. Journal of Global
Business Insights, 4(1), 59-77.
Rusli, D. & Bandung, Y. (2017). Designing an enterprise architecture (EA)
based on TOGAF ADM and MIPI. In Proceedings of the International
Conference on Information Technology Systems and Innovation,
Bandung, Indonesia, 23–24 October, pp. 38–43.
Schwer, K., Hitz, C., Wyss, R., Wirz, D. & Minonne, C. (2018). Digital
maturity variables and their impact on the enterprise architecture
layers. Problems and Perspectives in Management, 16(4), 141-154.
Searle, S. (2018). The Benefits of Enterprise Architecture for Library
Technology Management: An Exploratory Case Study. Information
Technology and Libraries (Online), 37(4), 27.
Sembiring, J., Triono, R. E. & Chair, M. S. (2013). Designing IT personnel
hard competencies model in the enterprise architecture case study:
forestry research and development agency of Indonesia. Procedia
Technology, 11, 877-881.
Simon, D., Fischbach, K. & Schoder, D. (2014). Enterprise architecture

management and its role in corporate strategic management. Inf. Syst.
e-Bus. Manag., 12, 5–42.
Sousa, M. J. & Rocha, Á. (2019). Skills for disruptive digital business.
Journal of Business Research, 94, 257-263.
Tambouris, E., Zotou, M., Kalampokis, E. & Tarabanis, K. (2012).
Fostering enterprise architecture education and training with the
enterprise architecture competence framework. International Journal
of Training and Development, 16(2), 128-136.
Tambo, T. (2017). Enterprise Architecture beyond the Enterprise:
Extended Enterprise Architecture Revisited. In International
Conference on Enterprise Information Systems; SCITEPRESS Digital
Library: Setúbal, Portugal, pp. 381–390.
Tambo, T., Bargholz, J. & Yde, L. (2016). Evaluation of TOGAF as a
Management of Technology Framework. Int. Assoc. Manag. Technol.,
25, 1–17.
Teräs, H. & Kartoğlu, Ü. (2017). A grounded theory of professional
learning in an authentic online professional development program.
International Review of Research in Open and Distributed Learning,
18(7).
The Open Group (2018). The TOGAF® Standard, Version 9.2. San
Francisco.
Thönssen, B. & von Dewitz, M. (2018). A Label is not enough–Approach
for an Enterprise Architecture Role Description Framework. Procedia
Computer Science, 138, 409-416.
Trad, A. & Kalpic, D. (2014). The selection and training framework for
managers in business innovation and transformation projects. Recent
advances in mathematical methods, mathematical models and
simulation in science and engineering, 94.
Wagner, P., Prinz, C., Wannöffel, M. & Kreimeier, D. (2015). Learning
factory for management, organization and workers’ participation.
Procedia CIRP, 32, 115-119.
Walsham, G. (1995). Interpretive case studies in IS research: nature and
method. European Journal of information systems, 4(2), 74-81.
Zhang, M., Chen, H. & Luo, A. (2018). A systematic review of business-IT

alignment research with enterprise architecture. IEEE Access, 6,
18933-18944.
BIOGRAPHICAL SKETCHES
Klaus Østergaaard
Affiliation: IT University of Copenhagen.
Education: Master in IT Management
Research and Professional Experience: 10 years of experience in

information systems studies, teaching and consulting.
Professional Appointments: Lecturer
Østergaard, K. (2018) “Better Customer-journeys and Architecture on

small resources – how do we do it?” Intersection conference 2018
Strategic Enterprise Design. Prague
Østergaard, K. (2018) Enterprise Architecture Introduction for Danish
Municipalities. Copenhagen.
Østergaard, K. (2018) Tailored Enterprise Architecture Introduction for
Municipalities of Copenhagen. Copenhagen.
Østergaard, K. (2019) Delivering better Customer-journeys and
Architecture with limited resources – how do we do it? Enterprise
Architecture Conference Europe. London.
Østergaard, K. (2019) Delivering better Customer-journeys and

Architecture with limited resources – how do we do it? Building
Business Capability conference. Hollywood, FL
Østergaard, K. (2019) Enterprise Architecture Introduction for Danish
Municipalities. Copenhagen.
Municipalities of Copenhagen. Copenhagen.
management at Municipalities of Copenhagen. Copenhagen.
T.T. Hildebrandt & Østergaard, K. (2018) Technology Understanding
introduction. Danish Agency for the Court of Justice. Copenhagen.
Validity of Business Strategy as Driver in Technology Management – A
Critical Discussion Tambo, T. & Østergaard, K., 11 Jun 2015,
Proceedings of International Association for Management of
Technology Conference. Cape Town: International Association for
Management of Technology (IAMOT), Vol. 24. p. 1-13 13 p. 66
Torben Tambo
Affiliation: Department of Business Development and Technology,

Aarhus University.
Education: MSc Engineering.
Research and Professional Experience: 17 years of experience in

information systems development, design, architecture and
management in manufacturing and supply chain industries. 10 years of
experience in research engineering management, enterprise
architecture and information systems.
Professional Appointments: Head of Studies in Technology-based

Business Development.
1. Hidden Waste Factors in LEAN Management: Towards Improved

Shop-floor Communication and Management
2. Nilsson, A., Brobak, T. T. E., Jørgensen, N. D., Larsen, M. K.,
Damhus, R. D., Mathiasen, J. B. & Tambo, T., 15 Nov 2019,
Proceedings for the 15th European Conference on Management
Leadership and Governance. Reading, UK: Academic
Conferences and Publishing International, Vol. 15. p. 1-9 9 p. An
agile knowledge sharing platform for risk management in SMEs
3. Brasen, L., Grooss, O. F., Præstegård, R. T., Clausen, P. & Tambo,
T., 6 Sep 2019, European Conference on Knowledge Management
1. p. 1-10 10 p. Impact of enterprise architecture-based complexity
assessment on ppm: Multitrack segmentation
4. Bojsen, T. B. & Tambo, T., 14 Aug 2019, p. 1-12. 12 p. Factors
and Motives in Practitioners’ Decision Making in Industrial
Sourcing: Local Versus Global Perspectives
5. Boda, R., Mathiasen, J. B. & Tambo, T., 19 Jun 2019, p. 1-12. 12
p. Internet of packaging: Artifactual representation for bridging
between digital marketing and physical retailing
6. Lydekaityte, J. & Tambo, T., 1 Jun 2019, (Accepted/In press)
Encyclopedia of Organizational Knowledge, Administration, and
Technologies, 1st Edition. Khosrow-Pour, M. (ed.). 1 ed. Hershey,
USA: IGI global, Vol. 1. p. 1-10 10 p. Technological Capabilities
of Printed Electronics: Features, Elements and Potentials for
Smart Interactive Packaging
7. Lydekaityte, J. & Tambo, T., 12 Apr 2019, (Accepted/
In press). Project management using scaled agile framework (safe)
– a critical review and implications for management of technology
8. Tambo, T. & Koumaditis, K., 10 Apr 2019. Smart and interactive
packaging – on long term studies and technological enablers in
retailing of consumer packaged goods (CPG)
9. Tambo, T. & Lydekaityte, J., 10 Apr 2019, Proceedings of the
28th International Association for Management of Technology
Conference. Jain, K., Sangle, S., Gupta, R., Persis, J. & R, M.

(eds.). Mumbai: Excel India Publishers, Vol. 28. p. 82-94 12
p. 7. An efficiency evaluation of radar‐based obstruction lights
controlling at a wind turbine test site
10. Jørgensen, L. D., Tambo, T. & Xydis, G., 2019, In : Wind Energy.
22, 4, p. 576-586 11 p. Digital services governance: IT4IT™ for
management of technology
11. Tambo, T. & Filtenborg, J., 2019, In : Journal of Manufacturing
Technology Management. Technological Capabilities of Printed
Electronics: Features, Elements and Potentials for Smart
Interactive Packaging
12. Lydekaityte, J. & Tambo, T., 2019, 2019 Proceedings of PICMET
'19: Technology Management in the World of Intelligent
Systems. Enlightened Designers from the Dark
13. Tambo, T., 31 Dec 2018, In : Scandinavian Journal of Information
Systems. 30, 2, p. 63-68 6 p., 9. Smart Packaging: Definitions,
models and packaging as an intermediator between digital and
physical retail product management
14. Lydekaityte, J. & Tambo, T., 9 Nov 2018, (Submitted)
Proceedings of the 7th Nordic Retail Wholesale Conference.
Reykjavik, Iceland: Nordic Retail and Wholesale Association, Vol.
7. p. 1-10 10 p. Connected stores, connected brands, connected
consumers, connected goods: On business model ecosystems in
Internet of Packaging
15. Lydekaityte, J. & Tambo, T., 1 Nov 2018, (Submitted)
Proceedings of the 41st Meeting of the Wireless World Research
Forum. Business Perspectives of Smart Interactive Packaging:
Digital Transformation of Brand’s Consumer Engagement
16. Lydekaityte, J. & Tambo, T., 15 Oct 2018, Proceedings of the 8th
International Conference on Internet of Things. Santa Barbara:
Association for Computing Machinery, p. 1-4 4 p. A Risk
Management Framework for Implementation of Emerging
Technologies
17. Christensen, J. A., Søndergaard, K., Serwanski, L., Bojsen, T. B.

& Tambo, T., 21 Sep 2018, Proceedings of the 13th European
Conference in Innovation and Entrepreneurship. Aveiro, Portugal:
Academic Conferences and Publishing International, Vol. 13. p. 1-
10 10 p. Business Process Management, continuous improvement
and enterprise architecture: In the jungle of governance
18. Tambo, T. & Clausen, N. D., 6 Aug 2018, Nordic Contributions in
IS Research - 9th Scandinavian Conference on Information
Systems, SCIS 2018, Proceedings. Springer, p. 41-54 14 p.
(Lecture Notes in Business Information Processing, Vol.
326). PLM or ERP, the chicken or the egg: Towards an enterprise
level master data management approach for improving innovation
and supply chain collaboration
19. Tambo, T., 23 Apr 2018, Towards Sustainable Technologies and
Innovation: 27th Annual Conference of the International
Association for Management of Technology. Nunes, B.,
Emrouznejad, A., Bennett, D. & Pretorius, L. (eds.). Birmingham,
UK: International Association for Management of Technology
(IAMOT), Vol. 27. p. 1-15 15 p. 168 IT Service Management
Architectures
20. Tambo, T. & Filtenborg, J., Jan 2018, Encyclopedia of Information
Science and Technology. Fourth Edition ed. Hershey, PA, USA:
IGI global, p. 1-12 12 p. Enterprise Architecture for a Facilitated
Transformation from a Linear to a Circular Economy
21. Laumann, F. & Tambo, T., 2018, In: Sustainability. 10, 11, p. 1-16
16 p. Energy harvesting through piezoelectricity - technology
foresight
22. Laumann, F., Sørensen, M. M., Hansen, T. M., Lindemann, R. F. J.
& Tambo, T., 25 Aug 2017, In : Energy Procedia. 142, p. 3062-
3068 7 p. Comparison of Conventional Closed-Loop Controller
with an Adaptive Controller for a Disturbed Thermodynamic
System
23. Alphinas, R. A., Hansen, H. H. & Tambo, T., 31 May 2017, 2017
Evolving and Adaptive Intelligent Systems (EAIS 2017) . IEEE,
Vol. 10. p. 1-7 7 p. (EVOLVING AND ADAPTIVE

INTELLIGENT SYSTEMS. 2017. (EAIS 2017), Vol. 1). IT4IT™
as a Management of Technology framework: Perspectives,
implications and contributions
24. Tambo, T. & Filtenborg, J., 18 May 2017, Proceedings of the 26th
Conference of International Association for Management of
Technology. Vienna: International Association for Management of
Technology (IAMOT), Vol. 26. p. 1-14 14 p. Enterprise
Architecture beyond the Enterprise: Extended Enterprise
Architecture Revisited
25. Tambo, T., 29 Apr 2017, Proceedings of the 17th International
Conference on Enterprise Information Systems (ICEIS).
SCITEPRESS Digital Library, Vol. 17. p. 381-390 10 p. Business
Process Management Notation (BPMN) as Lingua Franca in
Virtual Communities
26. Tambo, T., 1 Apr 2017, Advances in Business and Management.
Nelson, W. D. (ed.). Hauppauge, NY, USA: Nova Science
Publishers, Vol. 11. p. 1-21 21 p. Theoretical Perspectives of
Enterprise Architecture for Technological Transformation
27. Tambo, T., 1 Jan 2017, In : Journal of Enterprise Architecture. 12,
4, p. 18-31 14 p. Wireless waste monitoring and smart water
management: Analyzing corporate foresight for internet-of-things
28. Asmussen, S., Jensen, F. S., Soltani, P. & Tambo, T., 1 Jan 2017,
In: Proceedings of the European Conference on Innovation and
Entrepreneurship, ECIE. p. 58-67 10 p.
Chapter 3
APPLICATION OF SOA
WITH CLOUD COMPUTING
Farrukh Arslan*
School of Electrical and Computer Engineering, Purdue University,
West Lafayette, IN, US
ABSTRACT
One of the challenging jobs for software engineers today is keeping
up with the rapid changes in technology. An important update in
technology is that the software will involve service-oriented architectures
(SOAs) with some norm of cloud computing technology. As more and
more services are available on the Internet and nearly every day, we
discover new opportunities to connect these services to create SOAs.
These SOAs will require less custom software in organizations, but will
likely demand more creativity in the selection and assembly of services.
This is a natural evolution of software technology and will be explained
in this chapter. The evolutions brought by these technologies will require
both a basic grasp of the technologies and an effective way to deal with
how these changes will affect the people who build and use the systems
*
Corresponding Author’s E-mail: farslan@purdue.edu.
76 Farrukh Arslan
in the organizations. The intent of this chapter is to consider some ideas

and that just might make it easier for the organizations to realize the
potential benefits in SOAs, and cloud computing.
Keywords: SOA, web service, cloud computing
INTRODUCTION
A service-oriented architecture is a way to design, implement, and

assemble services to support or automate business functions. An SOA is
built using a collection of services that communicate with each other. The
communication can involve either simple data passing or it could involve
two or more services coordinating some activity. A service is a software
and hardware. One or more services support or automate a business
function. Most often, the intent is that a service can be used in multiple
ways (often referred to as reusability). There are two types of services:
atomic and composite. An atomic service is a well-defined, self-contained
function that does not depend on the context or state of other services. A
composite service is an assembly of atomic or other composite services.
Service within a composite service may depend on the context or state of
another service that is also within the same composite service. What does
this mean for software development? It means fewer people writing
software and more organizations buying software or renting access to
software rather than building it.
There is more to the architecture of an SOA than described here. There
are issues such as the granularity of services, loose coupling,
composability, and more that need to be considered when designing a
service-oriented architecture. Concepts related to these issues are described
later in this chapter.
Application of SOA with Cloud Computing 77
Figure 1. SOA Basics.
SERVICE-ORIENTED ARCHITECTURE OVERVIEW
SOA is a way to design, implement, and assemble services to support

or automate business functions. SOA is not a new concept. The first SOA
for many people was in the 1990s with the use of Microsoft’s DCOM or
Object Request Brokers (ORBs) based on the CORBA specification.4 The
basic idea goes back even further to the concept of information hiding that
creates an interface layer above underlying systems. The key to SOA is the
identification and design of services. The idea is that services should be
designed in such a way that they become components that can be
assembled in multiple ways to support or automate business functions. It is
not necessarily easy to properly identify and design services. When done
well, the services allow an organization to quickly assemble services—or
modify the assembly of services—to add or modify the support or
automation of business functions. Here are the basic concepts related to
services:
Atomic Service
An atomic service is a well-defined, self-contained function that does

not depend on the context or state of other services. Generally, an atomic
service would be seen as fine-grained or having a finer granularity.
78 Farrukh Arslan
Composite Service
A composite service is an assembly of atomic or other composite

services. The ability to assemble services is referred to as composability.
Composite services are also referred to as compound services. Generally, a
composite service would be seen as coarse-grained or having a larger
granularity.
Loosely Coupled
This is a design concept where the internal workings of one service are
not “known” to another service. All that needs to be known is the external
behavior of the service. This way, the underlying programming of service
can be modified and, as long as external behavior has not changed,
anything that uses that service continues to function as expected. This is
similar to the concept of information hiding that has been used in computer
science for a long time.
So, what exactly does a service-oriented architecture look like? Let’s
start with a service provider. Any given service provider could provide
multiple services. Multiple services are represented in Figure 2 by the
small circles. Services are code—running on an underlying computer
system—that provide computing as well as access and updates to stored
data.
Figure 2. Services in a service provider.

Services are assembled to support or automate business functions.

Figure 3 illustrates the assembly of services. This represents an SOA. Web
services are used to connect the services in an SOA. The services in an
SOA can come from any service provider (which, as mentioned earlier, can
also be a service consumer). So, in a given SOA, the services might be
from internal systems along with any number of external systems
accessible anywhere on the Internet.
This is illustrated in Figure 3. It is easy to imagine that you can
reassemble the same services with other services to achieve different
functionality. This ability to change the assembly of services is one way
that an SOA can quickly adapt to changing business needs. It is also easy
to imagine the number of available services quickly expanding to some
unmanageable number. That is one reason why governance is important.
Governance applies a structure and control over an organization’s use of
services.
Figure 3. Services in an SOA.

80 Farrukh Arslan
CLOUD COMPUTING
We discussed services and how Web services are used to connect

services. When you place those services in a data center and connect to
them over the Internet, you have the basis of cloud computing. The advent
of relatively inexpensive hardware (servers and storage) along with the
growing availability of high-speed Internet connections made it possible to
develop large data centers that can be located almost anywhere in the
world. There is more, however, to cloud computing, and this content
provides basic information about it. This also describes ways that
organizations of any size can use a service-oriented architecture (SOA) that
takes advantage of cloud computing and why most organizations likely
will, as a result, experience a blurring of internal and external services. The
also finishes with descriptions of the types of clouds and categories of
cloud providers.
Organizations might find that moving more to the cloud greatly
simplifies their internal systems. In all likelihood, it is possible to find
multiple service providers in the cloud for the same type of service. This
creates a dynamic environment, where cloud computing providers compete
on features or innovations that are independent of the connections.
Competition could be on pricing, content, or other features that allow for
highly customized interactions. Organizations will be affected by
additional services becoming available in the cloud. It can be difficult for
an internal development group in some organizations to compete with a
cloud computing provider that can recoup development costs by having
many more customers than any internal development organization could
imagine. The external provider can achieve better products at a lower cost
because of specialization. Internal development organizations may,
therefore, shift to doing less development. The emphasis internally may
shift to making all the connections work properly and integrating new
services that might give an organization a competitive edge.
The use of an SOA with cloud computing is not limited to large
organizations. In fact, this architecture represents an opportunity for small-
and medium-size organizations. Many services are provided on some type
of fee-for-use basis, which will make them economical for organizations of

almost any size. Other services are provided at no cost. The cloud provides
software and hardware resources via the Internet. The connections into the
cloud are often referred to as application programming interfaces (APIs).
Previously, Figure 2 illustrated the basics of service-oriented
architecture. That same architecture can be used with cloud computing.
Figure 4 illustrates a similar SOA, this time with various combinations of
cloud computing. A service provider can be in any type of cloud or be an
internal service. Similarly, a service consumer can be a service within any
type of cloud or be an internal service. The services provided in the cloud
come from multiple organizations. These organizations are referred to as
cloud providers. As a result, the cloud has multiple services provided by
multiple cloud providers.
Figure 4. SOA basics with various combinations of cloud computing.
A cloud provider usually strives to ensure the high-availability of its

infrastructure. Some cloud providers have the building blocks to create
services: software tools, database management systems, hardware, backup-
services, and so on. Other cloud providers have suites of services such as
counting, CRM, document management, and many more. Furthermore,
some cloud providers that have suites of services, also provide tools to
customize the suites to meet particular business needs. Cloud providers
often price their infrastructure and services on a demand basis.
For example, you could pay by transaction or by the amount of storage
on-you are using. Some cloud providers have the capability to scale up
dynamically for such things as peak transaction loads or unexpected higher
82 Farrukh Arslan
storage requirements. The cloud usually allows organizations to avoid

significant upfront costs since you only pay for what you use as you use it.
Whether you intend to build your own services in the cloud or use a cloud
provider’s services, you need to consider issues of security, software tools,
and software infrastructure, along with the hardware infrastructure.
Security is often a major concern if using a public cloud because it is a
shared environment.
Types of Clouds
Typically, a public cloud provider allows multiple organizations to

provide multiple types of services (often referred to as multitenancy). The
location for the underlying data center could be almost anywhere in the
world (often referred to as location independence). The underlying
hardware is usually chosen by the cloud provider and not the users of the
service (here you will likely find virtualization and device independence).
The public cloud can also be described as an external cloud when viewed
from within a given organization.
A community cloud is more restricted than a public cloud. The
restriction is to a “community”. The restriction could be based on an
industry segment, by general interest, or by whatever way a group might be
defined. These clouds could be multi-tenanted. The underlying data center
might be provided by a third party or by one member of the community. A
private cloud is restricted to one organization. Most often that organization
is the single-tenant—that is unless the organization might want to host a
private, multi-tenanted cloud for various internal segments or units of the
organization. The data center for private clouds is managed by the
organization. This can also be called an internal cloud.
A virtual private cloud involves some type of partitioning to ensure
that the private cloud remains private. Typically, a virtual private cloud
provider allows the definition of a network similar to a traditional network.
Within such a network, it is possible to have systems such as database
management systems, business information (BI)/analytics systems,
application servers, and so on. A hybrid cloud is the combination of any of

the above. In reality, this is a somewhat ambiguous term since an
organization might have a private cloud and use the public cloud. That
could be seen as a hybrid cloud or it could be simply using two types of
clouds.
Categories of Cloud Providers
Infrastructure as a Service (IaaS)

This contains the physical and virtual resources used to build the
cloud. These cloud providers provision and manage the physical
processing, storage, networking, and hosting environment.
Figure 5. Cloud computing stack: IaaS, PaaS, and SaaS.

84 Farrukh Arslan
This is the data center or, in some cases, the data centers. Pricing is
often based on the resources used.
Platform as a Service (PaaS)

This provides a complete computing platform. These cloud providers
provision and manage cloud infrastructure as well as provide development,
deployment, and administration tools. Here you will find the features that
make a platform: operating systems, web servers, programming language,
database management systems, and so on. This is where the provider might
provide elasticity: the ability to scale up or scale down as needed. You will
also find some level of reliability provided by the software platform. For
example, some type of fault tolerance might be provided for the database
management system. When the organization wanted to move to a virtual
private cloud, it most likely looked for a PaaS cloud provider that provides
the software and tools to support existing systems. Pricing can be on many
dimensions. For example, pricing could take into account the type of
database management system, the level of activity, the amount of storage,
and the computational time/resources used. Software as a Service (SaaS):
This provides complete software systems. SaaS is a common way to
provide applications such as email, calendars, CRM, social networks,
content management, documentation management, and other office
productivity applications. SaaS is also known as “on-demand software”.
Pricing is often on per user basis, either monthly or yearly. SaaS cloud
providers are what most people mean when they refer to “the cloud”. They
provide the services and related data that can be used directly or combined
in some way with other SaaS providers or with your own unique data and
services.
Force Field Analysis to Service-Oriented Architectures (SOAs)
This section applies the force field analysis to service-oriented

architectures (SOAs). It starts with analyses of integration techniques that
preceded SOAs. It then applies force field analysis to the enterprise service
bus (ESB), which is often used in SOAs. Toward the end of the section, the
analyses are combined into a force field analysis of SOAs using Web
services. This analysis shows many driving forces for adopting an SOA. It
also shows that, over time, many technical restraining forces will diminish
and the remaining restraining forces will be typical business and design
issues. One early integration technique was for an organization to adopt
enterprise-wide software. This worked sometimes. When it did, however,
usually it was successful only for a short period. The obvious appeal of
adopting standard software is that everyone uses the same software. This
means that the entire organization uses the same data definitions,
semantics, and formats for exchanging data. Often, this worked best for
organizations that were small and were putting a new set of systems in
place. Nevertheless, standardizing systems software often runs into
problems, too. There are long-term restraining forces, such as mergers and
acquisitions, that can come into play. Even a new, small organization can
acquire another organization that uses an entirely different system, and
integration problems begin.
This approach has a mergers and acquisitions restraining force for a
similar reason as seen in trying to establish standard data element
definitions. The other organization can easily use different software. It is
also common in larger organizations that some departments have different
software needs. It is rare that you can find “one size fits all” software.
Another downside is that adopting a complete set of software systems from
a single vendor makes your organization dependent on that single vendor.
As soon as you move away from that vendor’s products, you might be back
into common integration issues. For organizations that have existing
systems, adopting standard software can mean a mass conversion to the
new software. This is often problematic and should be seen as a restraining
force. Finally, it is often the case that the product doesn’t provide all the
functionality that is needed. Of course, every example has a
counterexample. There are some industries where mergers and acquisitions
are commonplace. You will see organizations in those industries adopting
common, industry-wide software packages so that it will be easier for one
organization to be acquired or merged with another organization. So,
86 Farrukh Arslan
mergers and acquisitions can also be a driving force. The 1990s saw the
introduction of object request brokers (ORBs). The two best-known ORBs
were the Object Management Group’s Common Object Request Broker
Architecture (CORBA) specification and Microsoft’s Distributed Common
Object Model (DCOM). (CORBA is still around in various forms. DCOM
is now a part of Microsoft’s .NET.). ORBs are middleware that is one way
to exchange data among two or more systems. These systems could be
from multiple vendors. In fact, an ORB could be one way to integrate
systems from two organizations when a merger or acquisition occurred. An
ORB hides the complexity of the communication between two or more
systems. They provide a means for applications to communicate with each
other.
The original specifications for CORBA and DCOM, however, dealt
with how to get data from one place to another. There were no specific
requirements for the format of the data transmitted in the messages. The
restraining forces related to data for an ORB are:
1. Different semantics in data sources

2. Semantic translation
3. Lack of industry-standard definitions
Advances in industry standards such as XML mitigated all these

restraining forces. In fact, using XML makes for a more flexible system
because of the tagged record structure of XML. This also mitigated the
restraining force related to the brittleness of fixed record formats.
The mergers and acquisitions restraining force diminishes since an
ORB would be one way to deal with the multiple systems resulting from a
merger or acquisition. There was a perception in the industry that neither
CORBA nor DCOM were widely adopted and that using one or the other
or both was too complex for many programmers. Whether the perceived
lack of industry adoption or inherent complexity was actually true is
irrelevant at this point. These perceptions are seen as restraining forces.
Web services have just the opposite perception—they are seen as easy to
adopt widely by industry and easy for most programmers to use.
Perception, in this case, might well be the reality. The very nature of
creating interoperable, networked resources means that there could be a
negative impact on operational systems when requests come in through an
ORB. Many operational systems have not been designed to receive
indeterminate or unexpected processing requests. These requests
sometimes can have a negative impact on the performance of those
systems. So, the effect on operations systems can be a restraining force if
up-to-the-moment processing of those requests is needed. An enterprise
data warehouse EDW is one of the oldest and most successful ways to
integrate and consolidate data from multiple systems. Commonly, it
involves extracting data from existing systems and loading it into a single,
central location to form an EDW. Using an EDW can be complementary to
using ORB or Web services. the easier exchange of data as a driving force
is replaced with easier access to enterprise-wide data. This data is loaded
from existing systems using various techniques that extract, transform, and
load (ETL) the data in the EDW. Using ETL techniques means there is
usually less impact on operational systems because the extracts of data
from these systems could be done at a time convenient for the operational
system. This minimal impact on operational systems is a significant
driving force. Easier access to enterprise-wide data also allows the use of
business intelligence (BI)/analytics software to find patterns or new
business opportunities based on a wealth of data that could be stored in an
EDW. Most of the restraining forces are issues with the semantics or
meaning of the data and the standardization of data definitions. Not
surprisingly, these issues are similar to those involved with attempts at
adopting standard data elements when existing data definitions are
different.
Over time, however, these restraining forces have become weaker for
two reasons:
1. A subset of the software industry is devoted to the development of

ETL software.
88 Farrukh Arslan
This software generally simplifies the development of the data

extractions from existing systems, any semantic translation or
transformation, and the loading of the data into the EDW.
2. More industry standards have become available: Initially, efforts

were related to electronic data interchange (EDI) and more
recently to Web services.
Additional restraining forces include problems related to what data to

store in the EDW and the delay or latency in getting data into the EDW.
The issue of what data should be stored in an EDW will likely always
remain a restraining force. The strength of this restraining force will vary
by organization. The delay or latency of data is the result of performing
data extracts at times convenient to the operational systems. Consequently,
the very latest data is not always available in the EDW. To some
organizations, this is no problem. Others, however, may find this a
significant restraining force. The redundancy of data also can be seen as a
restraining force. Whenever data exists in more than one location, it is
possible that the data will have different values for various reasons. This
could result, in part, from the latency of data mentioned earlier. For
example, the value of an account balance may be updated by the
operational system but not forwarded to the EDW until some later date. At
a given point in time, you could see two different values for the same
account when looking at the EDW and the operational system.
Data quality issues are potentially a restraining force because much
depends on the quality of the data available. If data to be stored in the
EDW is lacking in quality, there are options available for improving its
quality. Changes could be made to improve data quality at the time it is
entered. For existing data, the quality could be improved at the source. If
that is not possible, the ETL software used to load data could be used to
improve the quality of the data. Sometimes this is called data cleansing.
This, of course, assumes the quality can be improved in some way that
lends itself to programming. Data quality is a significant topic and you are
encouraged to study it further if this is potentially a restraining force for
your organization. Finally, the brittleness of fixed record exchanges is a

maintenance issue. If the EDW is changed in some way, it could create a
need to change some or all the ETL programs. Because of the nature of
fixed record exchanges, there is always a chance that not all ETL programs
would be updated and the wrong data would be extracted.
Figure 6. Possible connections for internal systems.

90 Farrukh Arslan
As a result, the transform and load portion could fail or the wrong
portion of the record could be inappropriately transformed and loaded into
the EDW, resulting in essentially a corrupted EDW. This brittleness
problem is being addressed by the tagged record structure of XML or
name/value pairs. The tagged structure significantly reduces the chance of
corrupting the data in the EDW and also presents the opportunity to reduce
maintenance costs related to ETL programs. So, as a restraining force, the
brittleness of fixed records will be reduced. Many of the restraining forces
will be reduced because of efforts related to industry-standard semantic
vocabularies and Web services.
ADOPTING A SERVICE-ORIENTED ARCHITECTURE
Often when integrating systems, there is also a need to propagate data

among internal systems. For example, if a customer’s address is changed in
one internal system, you would want that change to appear as soon as
possible in other internal systems. Propagating data changes, however, can
lead to complexity because of the possible number of connections among
internal systems. If each internal system were directly connected to the
other internal systems you could have up to 10 possible connections. Of
course, if you need to propagate an update, such as a customer address, to
multiple systems, you could end up in a situation where every system
potentially may need to communicate with every other internal system. A
good solution to this problem is to add a message router to internal
systems, as shown in Figure 6. Such routers have been around for some
time. They are also known as application routers. There are various ways a
router could know the other internal systems that need to receive a certain
type of update. The individual internal systems would not need to know
who receives such updates. As a result, the number of interconnections is
reduced, as shown in Figure 6. A message router usually needs to
transform the data in some way to match the format of the data expected by
the receiving system. Figure 6 shows examples of such transformations.
Internal system A at the left is sending data in tagged XML format.
Internal system B at the right expects a tagged XML format but expects the
tags to be different. For example, instead of the tag <name> in system A,
system B expects the data to be tagged with <customer>. The tags for
phone and postal code data also are different. Finally, system C expects a
fixed record format. This fixed-format is shown at the bottom in Figure 6.
Figure 7. ESB with adapters for existing software systems.
These transformations do not occur automatically. Some type of

adapter is needed to transform the data in the messages. Adapters also need
to transform instructions that may be needed for communication. Some
example instructions are starting a transaction, ending a transaction, getting
query results, and so on. The use of Web services and the development of
SOAs created a need for a router that worked with Web services and that
had adapters for various existing systems. Those capabilities are provided
by an ESB. The term bus reflects the analogy of a computer hardware
bus—a common architecture in computer design that uses standard
92 Farrukh Arslan
connections. A computer bus makes it easier to transfer data and

instructions among a computer’s subsystems. Similarly, an ESB makes it
easier to transfer data and instructions among various software systems:
services, business processes, applications, legacy systems, BI/analytics
software, and so on.
An ESB can play multiple roles. As a router, an ESB monitors, logs,
and controls the routing of messages among services and systems. An
ESB’s adapters enable the transformation and conversion of protocols and
messages. The adapters ensure that the message vocabulary used within the
ESB is the organization’s standard semantic vocabulary. The delegation of
routing, protocol conversion, and message transformation to an ESB gives
services and other software systems a convenient way to easily plug into a
bus system. There is no standard feature list for an ESB. If you are
considering an ESB, be sure that it provides all the features you need.
Figure 7 depicts an ESB with adapters for existing software systems. Most
of the restraining forces are the issues with the semantics or meaning of the
data and the standardization of data definitions that have been discussed
earlier. Message routing, like EDW, needs to deal with semantic
translation and this is shown as a restraining force. Over time, however,
these restraining forces have become weaker as more industry standards
become available. Additional restraining forces include problems related to
what data to route and the delay or latency in getting data updates
distributed to various internal systems. The issues of what data to route and
the delay of getting data updates distributed will likely always remain
restraining forces. Data quality issues similar to EDW can occur with
message routing. Obviously, it can be potentially disastrous to route poor-
quality data. With message routing, however, you do not have the option of
data cleansing used in conjunction with ETL software. The quality of data
needs to be improved at the source for existing data and at the point of
entry for new data. Finally, the brittleness of fixed record exchanges is a
maintenance issue. If the format of the record going to the message router
is changed, it could create a problem. Because of the nature of fixed record
exchanges, there is always a chance that the wrong data is routed. This
brittleness problem is addressed by the tagged record structure of XML or
name/value pairs. Such a structure significantly reduces the possibility of

corrupting data routed by the ESB and presents an opportunity to reduce
maintenance costs related to message routing programs. So, as a restraining
force, the brittleness of fixed records will be reduced over time. Web
services adapters for packaged software provided by vendors also reduce
costs of development. The adapters allow Web services connections with
internally developed systems or packaged software. The arrow depicting
the restraining force of development cost, however, is not shown as gray
since there still can be other significant development costs related to an
ESB. An ESB can work with EDWs and existing middleware solutions
such as an ORB. This is shown in Figure 7. The ESB would have adapters
that, in turn, would connect to the EDW and ORB. Note that the ORB is
represented as a bus much like an ESB and that it is labeled as “ORB
services”. This is because an ORB provides communication for services
much like an ESB.
Web services, middleware integration (i.e., ORB services), data
warehousing, and an ESB can all work together to support a service-
oriented architecture. Figure 7 shows these technologies. The drive to use
Web services is reducing technical change issues. This makes moving to an
SOA technically easier. Essentially, each organization must decide if it
makes business sense to create an SOA using Web services. If it does, then
there are design issues that need to be addressed.
Adoption of Cloud Computing with SOA
This section provides force field analyses for adopting two types of
cloud providers: software as a service (SaaS) and platform as a service
(PaaS). Towards the end, the analyses will be combined with the analysis
of service-oriented architectures (SOAs). It will be shown that using cloud
computing generally increases the number of technical driving forces for
adopting an SOA. Cloud computing also increases the strength of some of
the existing technical driving forces for adopting an SOA. Some of the
forces affecting the adoption of SaaS are similar to adopting any software
94 Farrukh Arslan
package. There are restraining forces such as the service that might not do
everything that is needed and you may feel uncomfortable depending on a
particular service. It would be reasonable to be concerned whether the
service provider will keep up with new features or capabilities needed for
effective use of a CRM service, for example. Also, conversion to a new
system, whether in the cloud or not, can be a restraining force. The first
one is security. Security is often one of the biggest concerns when
considering a move to a cloud provider. Security is a driving force as well.
The reality is that major cloud providers might be more secure than a data
center run by your organization. Cloud providers can hire the best security
people because security is so important and the security provided is usually
cutting edge. Cloud providers certainly can be targets for security attacks,
but all this really does keep the security as high as possible. Since the data
centers for major cloud providers are so big, they can keep equipment and
software up to date because of economies of scale. Availability or uptime
of service and the Internet is similar to security. Just like security, cloud
providers have the equipment and expertise to maximize availability and
Internet availability will continue to improve. Both security and
availability of restraining forces will diminish over time, effectively
increasing security and availability as driving forces for the adoption of
SaaS like a CRM service. Mergers and acquisitions might be a restraining
force if the organizations use different services or a system for something
like CRM. On the other hand, organizations might use the same service.
Another option is that some industries may quickly move to common
semantic vocabulary, making a merger or acquisition less of a restraining
force. In fact, related diminishing restraining forces, such as different
semantics in data sources, semantic translation, and standards are still
evolving. These are all related to standards.
A new driving force is the lower initial investment in software and
hardware since SaaS does not require the same upfront investment as a
data center. With SaaS, such costs are paid for on an incremental basis as
an ongoing cost (another driving force). Also, services with a SaaS cloud
provider usually have application programming interfaces (APIs) as well
as applications. Both make it easier for exchanging data. The applications
and APIs mean that data from the service can be accessed/updated from a
mobile device as well as systems running in your data center. At one point,
the organization decided to store its enterprise data in the cloud instead of
in a data warehouse. The organization built the new data store using a PaaS
provider. Storing data in the cloud accommodated storage needs changing
over time as well as changing the use/analysis of the data over time. Cloud
computing provides such elasticity. This way, an organization only pays
for what it uses. With cloud computing, it is not necessary for an
organization to invest in the hardware and software needed to handle peak
use. Let’s assume a database management system was used in the cloud
and that organization wrote custom software around the database
management system. Also, assume the PaaS provider has business
intelligence (BI)/analytics software that works with the database
management system. The organization saw remarkable growth in the
amount of data it maintains. To handle that amount of data, it chose a big
data solution offered by a PaaS provider. Big data is a somewhat fuzzy
term that refers to large and complicated data sets that may not be easily
managed by traditional database management systems. A big data solution
offered by a PaaS provider might be a NoSQL database management
system. There are a variety of NoSQL database management systems on
the market. Most are designed to work with big data. The driving forces
include easier access to enterprise-wide data, reduced maintenance costs,
reduced brittleness using tags or name/value pairs, minimal effect on
operational systems, and the use of BI/analytics. Just as in adopting a SaaS,
there are driving forces of the lower initial investment in software and
hardware and ongoing cost on an incremental basis. The PaaS cloud
provider manages the hardware and provides the software.
Figure 8 shows the cloud computing providers for the CRM service
and the big data store. The CRM service is from a public SaaS cloud
provider. The big data store along with the BI/analytics uses a virtual
private PaaS cloud provider. The remaining internal systems are the same
The PaaS includes tools to help develop, manage, and analyze the data in
big data stores. It provides an enterprise service bus (ESB) that is
optimized for the big data store and the BI/analytics software. The Internet
96 Farrukh Arslan
is represented by the horizontal shaded area. Web services are shown as a

black line within the shaded area.
Figure 8. Internal systems with cloud computing.
This represents that Web services protocols (SOAP, REST, JSON,

etc.) are a subset of the protocols that can be used on the Internet. Note the
adapters aligned with the big data, BI/analytics, and the CRM in the cloud.
They are needed because those services use a somewhat different semantic
vocabulary. the enterprise data warehouse was replaced with a big data
store. So, the restraining forces for adopting an enterprise data warehouse
have been reworded for storing big data: deciding what data to store and
delays in getting data to the data store. Two business issues have been
added: dependence on cloud-based services and conversions to use cloud-
based services. A legal issue was added concerning contractual issues with
the cloud provider. There is a new possible design restraint of Internet
speed. Security and availability (uptime) are both diminishing restraining
forces and driving forces, as described for both SaaS and PaaS earlier in
this chapter. In addition to security and availability (uptime), other new
driving forces related to cloud computing are a lower initial investment in
software and hardware, ongoing cost on an incremental basis, and the
possibility of using a standard semantic vocabulary. Some of the driving
forces related to SOAs are likely made stronger with cloud computing;
they are reduced development time, reduced maintenance costs,
availability of external services, and the availability of applications and
APIs for easier exchange of data. Over time, the remaining restraining
forces will be typical business, legal, and design issues. Adding cloud
computing generally increases the number of technical driving forces for
adopting a service-oriented architecture. Cloud computing also increases
the strength of some of the existing technical driving forces for adopting an
SOA.
CONCLUSION
This chapter used force field analysis to show how various forces drive
or restrain the adoption of services from two representatives SaaS and
PaaS cloud providers. The SaaS cloud provider was a CRM service and the
PaaS cloud provider had a platform supporting big data and BI/analytics.
The major finding of this analysis is that using cloud computing generally
increases the number of technical driving forces for adopting an SOA.
Cloud computing also increases the strength of some of the existing
technical driving forces for adopting an SOA.
98 Farrukh Arslan
REFERENCES
Adler, Mike. An Algebra for Data Flow Diagram Process Decomposition,

IEEE Transactions on Software Engineering, 14(2), Feb. 1988.
Bridges, William. Managing Transitions: Making the Most of Change.
New York: DeCapo Lifelong Books, 2009.
Fielding, Roy Thomas. Architectural Styles and the Design of Network-
based Software Architectures, doctorial, available at www.ics.uci.edu/
~fielding/pubs/dissertation/rest_arch_style.htm.
Humphrey, Watts S. Why Big Software Projects Fail: The 12 Key
Questions. Cross-Talk: The Journal of Defense Software Engineering,
March 2005.
Humphrey, Watts S. Multi-year study of 13,000 programs conducted by
the Software Engineering Institute, Carnegie Mellon. Mentioned in
“Why Software Is So Bad ... and What’s Being Done to Fix It,”
Charles C. Mann, MSNBC Technology Review, June 27, 2002.
Koch, Christopher. The New Science of Change, CIO Magazine, Oct.
2006.
Lewin, Kurt. Field Theory in Social Science. New York: Harper and Row,
1951.
Peter Mell and Timothy Grance. The NIST Definition of Cloud Computing:
Recommendations of the National Institute of Standards and
Technology, NIST Special Publication 800-145, September 2011,
pg. 2.
Rock, David, and Jeffrey Schwartz. The Neuroscience of Leadership,
strategy + business, Summer 2006.
Reviewed by: Bilal Wajid, PhD, University of Management and

Technology. Lahore, Pakistan
Chapter 4
MICROSERVICE ARCHITECTURE
Nikolay Mladenov
Bulgaria
ABSTRACT
Microservice Architecture requires new ways of thinking and new

technologies in software development. It becomes the major direction of
architectural evolution in the field of the software-oriented architecture.
This study presents the causes that generate the evolution in the software-
oriented architecture to the current level of microservices, which in many
cases helps the success of modern applications architectures and raises
the importance of microservice-oriented computing.
The aim of this study is to analyze the major features underlying the
microservice architecture and to research into the advantages and the
disadvantages of their technologies and implementation. The study
focuses on various strategies applied in software development as
conditions for the successful building of software. The analysis also
highlights the major capabilities of the microservices in driving the future
advances in software and hardware industries.

Corresponding Author’s E-mail: mladenov1@hotmail.com.
100 Nikolay Mladenov
Keywords: microservices, microservice architecture, service-oriented

architecture, protocols, fault tolerance
1. INTRODUCTION
The Microservice Architecture (MSA) is an improved version of the

Service-Oriented Architecture (SOA), which has evolved continuously in
order to reflect the technological advances and the software development
practice in designing and building modern applications.
The Service-Oriented Architecture (SOA) is an architectural style for
building software, which uses services in software applications. Services
have interfaces to operate and software applications use these interfaces to
apply their logic according to software requirements.
2. HISTORY AND EVOLUTION OF

THE SERVICE-ORIENTED ARCHITECTURE
If we compare the SOA with the earlier architectures, we will see that
20 years ago, the earlier architectures were strictly monolithic, which
means that they consisted of one single monolithic application. The
monolithic architecture was good to relatively small-sized applications.
Their logic was very tightly coupled, that is, if one function or method was
changed in the code, there was a significant chance that it would affect the
other parts of the application too. So if new developers started working and
developing, they first needed to understand how all parts of the built
software worked together.
Around the year of 2000 with the further development of the networks,
developers started developing loosely coupled and distributed applications,
so the applications were split into logical units and pieces called services,
and the services could exchange data over the improved networks. This
architecture was called service-oriented architecture (SOA).
Microservice Architecture 101
The key advantage of the SOA over the other software architectures
was that it applied internationally agreed principles in developing software.
Thus, the SOA did not suffer from incompatibilities arising from the
technology evolution and from the enormous variety of software vendors
with their different proprietary technologies.
Another key advantage of the SOA and its successors was the use of
the web service protocols as a central point for building the ways how the
services communicate with each other, as well as with the other
components of the applications. Still, the services in the SOA should not be
always web services, but the web services fit very well to the SOA
principles and goals.
However, the logical pieces were still quite large and often incorrectly
used and some vendors used proprietary tight coupling again. In the earlier
SOA applications, business logic was separated from data access providing
methods to fetch lists of data or to implement logic. Such systems were
still tightly coupled and thus, distributed computing and distributed logic
along with tight coupling, made things rather worse than better, so these
SOAs started losing popularity. Additionally, the communication between
the components was mostly done via the heavyweight XML language. The
web services required a considerable amount of processing and hardware
resources to transfer the data of an application built on the SOA principles
and this hindered communications between services.
Around the year of 2010, the term microservices came up with their
simplicity in the SOA implementation of decoupled applications.
Microservices make the front end of the applications become independent
from the data sources and they may fetch data from different sources and
from other completely separated services. One microservice may provide a
list of required data, while another one may provide access to the data by
using other interfaces at the cost of lower use of hardware and network
resources. The Microservice Architecture appeared as an improved SOA,
which kept all the advantages of the earlier SOA along with the SOA
improvements, such as the benefits from the introduction of the lightweight
RESTful web services. REST (Representational State Transfer) is an
architectural style of a web service architecture that transfers
representations of resources from a server to a client. The lightweight

communication protocol REST makes the microservices very flexible,
secure and fault-tolerant in large and complex applications. One of the
REST advantages is that it mostly uses the lightweight JavaScript Object
Notation (JSON) for representing the data. On the other hand, the
microservices are an excellent fit to communication protocols, because
they can have HTTP endpoints to exchange the REST data in the JSON
format. Emerging high-performance protocols, such as gRPC and HTTP/2,
enable faster communication and lower loads on the networks than REST.
Ingeno (2018) confirms that the gRPC was designed by Google, it is still
an open source and hopefully, it will help future technology advances.
gRPC serializes and compresses data and may replace REST in the
development of microservices in the near future. Therefore, the lightweight
microservices and the communication protocols make the MSA excellent
for building applications for mobile devices and for Internet of Things
devices, since they have lower processing capabilities and are very
sensitive to network performance. In this context, the history of SOA and
MSA simply follows the technological advances and evolution.
3. ADVANTAGES AND DISADVANTAGES OF MSA
Using microservices makes sense if they have benefits in comparison

with the other architectures. The first advantage of the MSA is that one
microservice should do only one specific task and it doesn’t depend on the
other microservices. It may simply receive the client request and return the
requested data. It should be possible to develop and deploy a microservice
independent from all other parts of an application. If a microservice is
called correctly, but it fails, then the whole application does not have to fail
either and the design and the implementation provide ways to avoid
disaster.
In addition, new developers don’t have to understand the whole
application to add a new microservice with new requirements. Services can
be developed and deployed by completely independent teams, which have
to negotiate the contract on how microservices have to communicate with

each other. Certainly, microservices should communicate using standard
HTTP actions to benefit from the REST and HTTP advantages. However,
the microservices may be developed with the language that does the given
task best, for example, one can use Go for one microservice and Java for
other microservices. All these advantages of the microservices present
them as autonomous and resilient units of the main application.
On the other hand, one disadvantage of the microservices is that their
use may lead to possible code redundancies, for example using the same
algorithms or logic in several microservices and thus, the code will be
simply copied to the new microservices. Another drawback is that it is
harder to roll out new versions of current microservices, because the built
microservices may depend on each other and their new versions may
require new contracts and dependencies. For example, updating
dependencies of one microservice might bring about crashes in another
microservice.
Microservices may be harder to test, because if microservices are
dependent, one or more of them should be mocked. Additionally,
microservices depend largely on the network layer, so in fact they are
distributed and thus, a failure in the network layer will affect the whole
application and the other layers. The microservice networking location
may become an issue also, if the microservice depends on its dynamic IP
address from an external host or from a cloud provider.
Microservices applications are harder to monitor end to end and thus,
if one microservice fails, it should be replaced on time without stopping
the whole application and this feature needs to make sure that
microservices are resilient to failures. Weaker resilience may become the
weak point of failure for the whole application.
4. MSA WITH SERVICE REGISTRY
The service registry is one of the ways to clear most of above-

mentioned disadvantages of the microservices and of the MSA. Upon
splitting the individual units of the application into microservices, each

logical unit will have its own autonomous microservice. In between the
main application and the microservices, a service registry will be added
and the service registry’s main goal is to know where to find the
microservices’ infrastructure and locations and to provide also some load
balancing and failure management of crashed microservices.
The service registry will keep track of available microservices and will
provide communication to access them. It is the starting design point
before starting building the very microservices. The service registry uses
the name, the version, the ip address and the port of every microservice to
locate it. Those are the parameters that contain the REST-based dynamic
routes of the microservices.
In addition, the service registry may require more logic, such as
timeout and expiration of the used microservices. More logic is included in
the methods for registering and deregistering the microservices with
arguments such as a name, a version, an IP, a port, a unique registry key,
etc. for every applied microservice. Thus, every microservice will be
uniquely identified by its key as a data structure containing unique data.
Additional logic may check for every microservice whether it is already
initialized or not. For example, if it is not initialized, it will be added to the
service registry and if it is initialized, the service registry will be updated
and the microservice will be removed from the service registry.
The registration route can be coded as an instance of a class in the
application. The final result may return a key object formatted in JSON or
XML. The testing may be implemented as setting the debugger to go along
the whole logic with break points as usual. For example, PUT requests may
be implemented according to the used REST API and they should update
the location data of the microservice. SOAP-based microservices will
execute actions on a database server to retrieve the data from it, while the
RESTful microservices use the URL to access the data directly. The
RESTful microservices use http or https protocols, with the only allowed
actions being POST, GET, PUT, and DELETE. POST creates the resource,
GET reads it, PUT updates it and DELETE deletes it.
The created or updated microservice instance may have a connection, a

request, an IP address and a port. For local testing the ip address is the
localhost. The route will contain the registry path to the service name and
its version and port. The debugger will display all the variables from the
service’s class structure. After making sure that everything works well, the
break point will be removed and the application will continue working.
Thus, a basic registry is built and this service registry is necessary to
register all services in the application. Other versions of the microservice
architecture may contain many service registries implemented in different
programming languages and the service registries themselves may be
implemented as separated microservices, working with independent
database resources etc.
Next, the service registry should make a route to remove a
microservice, for instance, when the service is stopped. One or more
deregistering methods in the service registry class can be implemented for
this purpose with a name, a version, an IP and a port as constructor
parameters. The service that will be removed will be identified by its
unique key. For example, the unique key may be composed of a
combination of its parameters, such as its name, its version etc. Finally, the
delete method or action will erase the microservice from the service
registry structure and its unique key will be returned. The same testing
logic may be implemented as setting the debugger to go along the whole
logic with break points like in the registration process.
The service registry keeps one of the main advantage of the
microservices, that is, the microservies don’t depend on each other and the
consumer of the microservice doesn’t need to store the URL of the
microservice and to become tightly coupled. The service registry also
clears one of the disadvantages of the microservices related to its dynamic
IP address. A microservice instance should simply register to the service
registry when starting with its location and should de-register when
shutting down.
Clearing the service registry is very important to be implemented, so
that a specific version of the service can be requested. This can be very
useful if it is needed to roll out a new version of a service or to run it in
parallel to the old ones and to submit the new version to the caller. There
are various versioning schemes. All the versioning schemes will need at
least one service registry, one caller and different versions of the
microservices to be built in order to choose which service should become
operative. For example, one service may have more than one instances
with more than one different versions. In this case, the caller will request
only one specific version of this service and it will be returned by the
service registry. If there are more than one services that match the request,
load balancing logic is needed to be applied, so that the requests can be
distributed over all available microservices. Load balancing will enable the
service registry to return the different versions of one microservice. The
choice made by the load balancing may be a random one or according to
some logic applied in the source code of the application. The load
balancing may be implemented with a random function that randomly
returns the appropriate candidate on a random basis.
Handling dependency hell for different versions may require more
logic to the service registry for management of semantic versions. To
query the registry for various versions of one microservice, additional
methods may implement the logic needed to return the required service
according to its version. The route for the appropriate version of the
service will be called from the service registry. If a microservice with a
suitable version is not matched, then an error status “not found” will be
returned. Additional JSON or XML information data may be returned too.
Testing should create different instances of the services with different
versions and different ports, so that the microservices will be checked if
they don’t interfere with each other. The versioning shows how the service
registry clears another issue with the dependency hell and proves that the
pretty simple logic of the microservices generates a lot of flexibility and
power to the built application.
If a microservice shuts down itself with no chance to deregister,
various issues may come up. In this case additional rules should be
implemented, so that every service deregister itself on its own from the
service registry. For example, if a service is not working for ten seconds, it
may be considered expired. A new method will implement the cleanup of

the expired services from the service registry according to their timeout.
5. MSA WITH SYNCHRONOUS COMMUNICATION
Suppose that the service registry is ready and operational to register

and deregister microservices. Then, it is time to design and develop the
microservices. One approach is to split the individual components into
microservices and each component will have its own microservice. The
individual microservices may be identical to the service registry described
above. Every microservice will have a RESTful interface and thus, it will
need routes and endpoints. A route will be necessary for each of the main
methods implemented in the service class and this route will provide the
requested data to the application users. The communication implemented
on the REST transport protocol with HTTP endpoints is a synchronous
communication and it is the common and the preferred one to
microservices. Such a synchronous communication layer will provide
additional resilience against outages.
However, the list of the transfered data may grow fast and more and
more network bandwidth will be needed to transfer all data. Obviously,
this solution has its limits and it is not feasible in the long run without the
operation of a service registry. That is why it is crucial that the active
services are registered and the inactive services are unregistered on time
when they are terminated, so that the hardware resources are saved and
used rationally. Also, the routes should be filled with logic after the service
is registered in the service registry on startup.
To register a service, the address of the service registry is needed first.
Second, the service name and version are needed. The route for registering
a service is already created in the service registry. The respective source
code for the startup of the service may be completed with new code and
logic, such as sending signals to the registry to make sure that the service
will not be removed. The basic functions of every microservice are
implementation of http requests and responses, transformations of requests
and responses into JSON data and message interchange formats, as well as
protection against cross-site request forgery and similar attacks. The PUT
action will be invoked by the service registry and another method will set
the interval for the service’s signal. Good practice is also if the
microservice doesn’t use a fixed port, but should randomly choose one.
Deregistering microservices will happen when they are terminated.
The service’s start and end may differ according to its environments, such
as the type of the operating systems where the application resides and
operates. Deregistering a microservice may become a very complicated
process because it should contain all options and exceptions when the
microservice ends. On one hand, the microservice may shut down correctly
after returning the response, as it was mentioned above. On the other hand,
it may fail and then its timeout will help it expire. The DELETE action will
be invoked by the service registry and another method will set the interval
for the service cleanup. However, the cleanup event may cause exceptions
and they should be handled too accordingly. For example, pressing
CTRL+C or killing the process manually may terminate the service and
should be processed by the cleanup event. Testing it will update the service
registry with the manual termination of the process and its exception. Other
cases with exceptions and time intervals may also be added and they will
depend on the operating system and the application requirements.
One of the approaches to add the logic is to implement the
microservice logic from a data source such as a file or a table from a
database server. The most important principle is the separation between
logic, data and view, so that they can be easily updated or changed. The
class for every service will get populated with the data from the data
source and its methods will make transfer of the data according to the
defined routes in the service logic. Most of the logic will request the data
from the data sources and insert it in data structures, which then can be
used by the presentation layer of the application. Testing the logic with
many scenarios will return the data according to the requests in the route.
The next stage in building the microservices architecture is to integrate
every service in the application.
Integrating a microservice in the main application involves two stages.

Firstly, the application makes a call on the service registry to get the
address of the microservice and secondly, the application makes http calls
on that microservice. Calling the service registry and then calling the http
address of the microservice can be implemented by two methods. The first
one will search the service registry by the service name and if the
microservice is avalaiblle, it will return the response with the requested
location data according to the service’s name. The second one will make
the call on the microservice and return the response with its data according
to its route. After the integration of the microservice is completed, the
microservice will be ready to register itself and then the application will be
ready to use that microservice.
RESTful microservices are useful because all resources, such as
images, text etc. may be retrieved as a response from such services.
Adding the respective routes for the resources will help the service return
the corresponding resource according to a given path as an argument. The
http call on the service was already implemented as mentioned earlier and
the same logic may be applied for the resources. The only difference is that
the response type will be of a type of a stream if the resource is an image
or it is simply a binary file.
Splitting the monolithic application into microservices highlights the
underlying principle in the microservices architecture. In this way all the
functionality related to certain domains will be separated into individual
microservices. Every microservice operates completely on its own and it
can be tested and extended independently of the main application. Thus,
one of the major points underlying the microservices architecture will be
achieved successfully.
The synchronous communication of microservices, based on the REST
and on HTTP protocols, provides a communication layer to the main
application in order to generate additional resilience against outages.
Circuit breaking and caching are other approaches to increase fault
tolerance and harden the resilience if a service fails.
The monolithic application was successfully split into microservices.
Let us suppose that the maintenance of the application is handed to other
developers. They decide to implement a new version of one microservice

fixing a small bug, but this makes the application unresponsive. If one of
the microservices fails, the application which calls the same service will
hang too. The user’s request will stop too. Even worse, then another user
enters and sends a request to the application and consequently to the
microservice. Later many users join the trouble and send unsuccessful
requests. The computing memory and the other hardware and network
resources are exhausted and the issue amplifies. The faulty endpoint may
bring the whole website down. We agree that the applied microservices
architecture should be fault-tolerant and resilient against such problems.
The microservices’ failures are not rare events and we understand that
the website may hang unresponsive if a faulty microservice is on.
Therefore, the microservices and the application should be built in such a
way that they all will keep running even in this worst-case scenario. One
way to solve it is the so-called circuit breaker. Microservice circuit
breakers look like electrical circuit breakers. They can be either in a closed
or in an open state. In the closed state, circuit breakers are allowed to make
requests to the server and can connect to the microservice. In the open
state, they are not allowed to connect, are not able to communicate with the
microservice and finally return back to the client caller immediately with
error messages. One event that changes the behavior of the circuit breaker
is the number of failures or the number of the failed attempts to send a
request to the microservice. As long as the request succeeds, certainly the
circuit breaker should stay in its closed state. Also, a threshold should be
defined as the accepted number of failures and if the threshold is not
exceeded, the state will remain closed. If a failure occurs and the threshold
is reached, the circuit breaker will change its state to an open one. In a
default cool-down interval of time, the circuit breaker will enter a half-
open state which means that a testing request may be sent to the service. If
this request succeeds, the circuit breaker will get back to the closed state
and the failure counter will be reset. If the testing request fails again, then
the circuit breaker will go back to the open state and the cool-down period
is resumed or renewed or increased depending on the logic until a new
half-open state is reached following the time expiration of the open state.
The circuit breaker may be implemented as a component of the

monolithic application, inside the service registry or even as a service on
its own. The circuit breaker will have to make http requests and calls. The
constructor of the circuit breaker will contain its states, failure thresholds,
cool-down times and request timeouts. A special function will create a
state object for a given endpoint as an argument. Other methods will
handle all possible events and exceptions.
One way to make the request to the service from the circuit breaker is
to simply reuse the http call service method from the service
implementation that was discussed earlier. The endpoint will get the http
verb request as an argument which means that it will be set to either a GET
value or to a POST value. More details on the circuit breaker and
additional design patterns from the MSA are presented in Udantha’s paper
(2019).
The circuit breaker will certainly help avoid disaster on the whole
infrastructure. However, the resources may be blocked for a long time and
the web page will continue loading empty. Still, the goal will be to keep
the impact as low as possible to users. A simple cache to bridge the
outages may help in the case when the microservice fails. A cache key will
identify an endpoint and may be independent of the IP address and of the
port, because the endpoint should return some result regardless of the state
of the individual service instance it is running on. For example, only the
path may be kept without the IP address and without the port. Thus, the
circuit breaker will keep the past state of the resources and reload them
without the need of writing the call on the service to succeed. Still, if the
cache is empty, then the circuit breaker will not help and it will prevent
only the infrastructure from breaking down. The drawback of the cache
approach is that the microservice should work at least once, so that the
cache will be populated. This cache failure can be avoided too, for
example, by running another daemon microservice over time intervals to
save the cache of recent updates. Thus, the application is resilient to a large
number of issues and the cache will help to minimize the impact on the
user.
Working with images as streams may block their caching. Therefore,

the caching of images will require the use of file system logic, cloud
storage and functionality, so that the caching of streams may be feasible. If
the images are not cached, they may be saved locally as streams in the file
system at their first load of the application and then if the service fails, they
will be read as streams again. A cache key for the corresponding file name
is also a better option than the string representation of the file name to
avoid name duplicates. In this way the application images become resilient
to the services failures too.
Certainly, all approaches mentioned above have their advantages and
disadvantages. For example, a weak point of failure may be the service
registry and if it fails, the application won’t work. This issue can be solved
by providing several instances of the service registry that maintain their
entries in the database. The main application will then search for all
instances and will find the one that is online. Also, the page may fail, if
there is no matching service found, but basically this issue may be solved
because an unlimited number of instances for one service can exist at the
same time. This provides a high degree of fault tolerance, even if the
service gets updated.
6. MSA WITH ASYNCHRONOUS COMMUNICATION
The asynchronous communication with microservices adds additional

level of abstraction and robustness to the microservices operations. The
Advanced Message Queueing Protocol (AMQP) is the asynchronous
messaging protocol used mostly by the microservices. It applies queues as
data structures and they receive, store and send data according to custom
formats, requirements and security instead of posting data directly to the
respective service.
One goal of the microservices architectures is to avoid the tight
coupling. It is hard to uncouple requests and put data on the web instantly
but when it comes to posting data to a microservice, it can be obtained by
the help of an intermediary microservice, which will remove any
dependency between the caller and the receiving service. Queues are a
common way to accomplish that and their basic principle of operation is
very simple. Basically queues provide a way to handle messages between
microservices in asynchronous an orderly ways. A queue may also serve as
an intermediary microservice between the application and another service.
The message can be published to the queue and the messages will
accumulate in the queue. Several messages may enter the queue instantly
without failures and finally everything will end up on the queue. When
another microservice requests the messages, it then can consume the
messages from this queue and later finishes its operation orderly,
acknowledging to other microservices that it received all the messages
successfully and without any loss. Thus, the messages will be removed
safely from the queue. There are several queuing systems available, such
as the ones used on the AWS, Google Cloud etc. They use the RabbitMQ
as a widely known queuing framework and it may be used, so that
resources can be published and consumed. Its advantage is that it can be
installed and used on all popular and widely used operating systems,
RabbitMQ is one of the most widely used and reliable message
brokers. It can be used to receive messages from web forms, other services
etc. RabbitMQ will require a library which can communicate with it. The
Amqplib library is one example for a library dependency needed to the
RabbitMQ operations. Adding a message to RabbitMQ queue will be
implemented by a method. The method will use a channel to communicate
and the messages will reach the queue and stay until they are received by
the waiting service. The messages should be formatted as JSON or XML
according to the requirements of the implemented RabbitMQ queue.
The posted messages to the queue will be consumed by the
corresponding microservice. The consumer microservice creates a safe
channel to the RabbitMQ too and it may start consuming the messages
from the queue. Next, it parse them from the JSON format to strings and
finally, it will acknowledge the receipt from the queue and add the entries
to the database or to a file.
The major benefit from the asynchronous communication is that the
microservices should not rely on the caller responding quickly or at all.
Thus, designing microservices architectures with asynchronous

communication capabilities will ensure even higher degrees of loose
coupling, reliability and fault tolerance.
CONCLUSION
The Microservice Architecture is considered one of the best software

architectures for building modern applications. It is important to know how
it evolves over time from the SOA and with the waves of technological
revolution.
Certainly, the MSA is not the perfect architecture. It has its advantages
and disadvantages which were discussed earlier. Indeed, some of its
disadvantages are inherited from its predecessors and are really hard to
handle. Still, one of its major benefits is that it improves continuously and
hopefully, with future technological innovations, the MSA will have its
significant place in helping the software developers build robust and
reliable modern applications.
REFERENCES
Ingeno, Joseph - Software Architect’s Handbook, ch. 8: Architecting

Modern Applications, Packt Publishing, 2018.
Udantha, Madhuka - Dzone’s Guide to Design Patterns for Microservices,
https://dzone.com/articles/design-patterns-for-microservices-1, 2019.
INDEX
business model, ix, 6, 42, 46, 66, 72

A
business processes, vii, 1, 3, 5, 9, 29, 44, 60,
92
access, 76, 78, 87, 95, 101, 104
business strategy, 30, 42
acquisitions, 85, 86, 94
businesses, 10, 14
agility, 54, 55, 65
ambidexterity, 48
application component, 13, 21, 22 C
architect, 33, 42, 48, 59, 61, 63
architecture design, 29 caching, 109, 112
assessment, 31, 32, 38, 62, 71 candidates, 8, 16, 19
assimilation, 49 case studies, 68
asynchronous communication, 112, 113 case study, 67
automate, 76, 77, 79 certification, 42, 44, 49, 50, 56, 57, 62
awareness, 54, 56, 63 classification, 26, 27, 48
classroom, 48, 57, 62
cleanup, 107, 108
B
cloud computing, v, vii, ix, 75, 76, 80, 81,
93, 95, 96, 97, 98
bandwidth, 107
coherence, vii, 1, 3, 4, 10, 14, 26, 28
benchmarking, 24, 27, 57
collaboration, 16, 34, 37, 64, 73
benefits, 3, 101, 102, 114
communication, 63, 76, 86, 93, 101, 102,
brittleness, 86, 89, 92, 95
104, 107, 109, 114
building blocks, 14, 62, 81
communities, 42
business environment, 2, 23
communities of practice, 42
business function, 76, 77, 79
community, vii, ix, 42, 54, 61, 62, 82
116 Index
competencies, 42, 45, 48, 49, 50, 59, 60, 61, enterprise architecture, v, vii, viii, 1, 2, 29,
65, 66, 67 30, 31, 32, 33, 34, 35, 39, 40, 41, 42, 44,
complexity, viii, 1, 5, 71, 86, 90 46, 48, 50, 52, 55, 56, 57, 60, 61, 64, 65,
computing, vii, ix, 75, 76, 78, 80, 81, 84, 93, 66, 67, 68, 69, 70, 71, 73, 74
95, 96, 97, 99, 110 environment, 10, 25, 26, 27, 80, 82, 83
conceptualization, 34 environments, viii, 25, 39, 41, 108
conference, 36, 69, 70 evolution, ix, 99, 101, 102
cost, 80, 81, 93, 94, 97, 101 execution, 25, 44, 49
curriculum, 45, 65 external relations, 47
cybersecurity, 60 extracts, 87, 88
D F
data center, 80, 82, 84, 94 fault tolerance, 84, 100, 109, 112, 114
data collection, 45, 61 financial, viii, 22, 41, 61
data set, 12, 95 flexibility, 32, 35, 36, 38, 39, 106
data structure, 104, 108, 112 force, 49, 84, 85, 86, 88, 92, 93, 94, 97
database, 21, 46, 81, 82, 84, 95, 104, 105, foundations, viii, 29, 42
108, 112, 113
database management, 81, 82, 84, 95
G
decision makers, viii, 41
Department of Defense, 49
Germany, 34, 36, 37, 64, 65, 66
distributed applications, 100
governance, 47, 55, 56, 57, 72, 73, 79
distributed computing, 101
guidelines, 10, 12, 23, 25, 54, 56
distribution, vii, 1, 3
guiding principles, 44
E H
economies of scale, 94
health, 36, 67
education, 23, 49, 68
health care, 67
educational opportunities, 49, 67
health information, 36
educational programs, 42
history, 102
employees, 43, 54
host, 82, 103
empowerment, 43, 52, 63
human, 35, 46, 49, 61, 67
engineering, 29, 52, 64, 68, 70
enterprise architect, v, vii, viii, 1, 2, 4, 29,
30, 31, 32, 33, 34, 35, 39, 40, 41, 42, 43, I
44, 45, 46, 48, 49, 50, 52, 55, 56, 57, 58,
59, 60, 61, 63, 64, 65, 66, 67, 68, 69, 70, improvements, 28, 101
71, 73, 74 independence, 82
individuals, 42, 44
Index 117
industry, 49, 52, 67, 82, 85, 86, 87, 88, 90, microservices, vii, ix, x, 99, 100, 101, 102,
92 103, 104, 105, 106, 107, 108, 109, 110,
information exchange, 34, 37 112, 113, 114
information processing, 36 mobile device, 95, 102
information technology, 2, 67 modelling, 14, 30, 31
infrastructure, vii, viii, 1, 3, 5, 13, 14, 36, models, vii, viii, 2, 4, 7, 11, 12, 14, 15, 16,
37, 46, 53, 57, 81, 82, 84, 104, 111 19, 24, 25, 26, 27, 28, 31, 46, 57, 63, 64,
integration, 31, 84, 85, 93, 109 65, 68, 72
intelligence, 87, 95
interface, 77, 107
N
interoperability, 14, 47
interrelations, 3, 5, 6, 46
natural evolution, ix, 75
issues, 26, 49, 54, 56, 76, 82, 85, 87, 88, 92,
networking, 38, 83, 103
93, 97, 106, 111
numerical computations, 20
L O
landscape, 12, 35, 48
obstruction, 72
languages, 4
operating system, 84, 108, 113
leadership, 49, 51
operations, 87, 112, 113
learning, 42, 44, 45, 48, 49, 50, 51, 55, 57,
opportunities, viii, ix, 41, 48, 61, 75, 87
58, 59, 61, 62, 63, 64, 65, 66, 67, 68
organizational behavior, 53
learning culture, 49
organizational learning, 42, 63, 64
learning outcomes, 58
learning process, 44, 48, 51, 58, 62
P
M participants, 44, 45, 52, 53, 54, 56, 57, 60,
61
management, viii, 6, 17, 21, 22, 26, 31, 41,
pharmaceutical, 52
43, 47, 49, 51, 52, 53, 54, 57, 60, 61, 65,
platform, 71, 84, 93, 97
66, 68, 70, 71, 72, 73, 74, 81, 84, 95,
portfolio, 47, 54, 61
104, 106
portfolio management, 47, 61
manufacturing companies, 52
potential benefits, vii, ix, 76
mathematical methods, 68
principles, 4, 44, 49, 50, 101
measurement, 11, 20, 24, 26, 28, 30, 47, 58
professional development, 61, 68
Mediterranean, 32, 36, 38
professionals, 4, 51, 52, 54, 58, 61
messages, 86, 91, 92, 110, 113
programming, 31, 78, 81, 84, 88, 94, 105
methodology, 43, 44, 47, 48, 56, 62
programming languages, 105
microservice architecture, v, vii, ix, 99, 100,
project, 15, 25, 29, 43, 54, 61
101, 105, 114
protocols, 92, 96, 100, 101, 102, 104, 109
118 Index
public administration, 14 specialization, 80

public sector, 12, 53 specific knowledge, 43, 48
public service, 14 specifications, 19, 56, 86
stakeholders, 23, 43, 45, 54
standardization, 45, 87, 92
R
strategic management, 68
strategic planning, viii, 41, 46, 57
relevance, 3, 5, 10, 12, 27, 49
structure, viii, 5, 16, 42, 79, 86, 90, 92, 105
reliability, 25, 84, 114
requirements, 16, 49, 67, 82, 86, 100, 102,
108, 112, 113 T
resilience, ix, 42, 103, 107, 109
resources, 42, 44, 64, 67, 69, 70, 81, 83, 84, technical change, 93
87, 101, 105, 107, 109, 110, 111, 113 technological advances, 100, 102
response, 2, 108, 109 technological revolution, 114
routes, 104, 107, 108, 109 technology, vii, viii, ix, 1, 3, 35, 41, 44, 46,
rules, viii, 2, 3, 4, 6, 9, 11, 12, 15, 16, 18, 47, 48, 51, 57, 60, 61, 67, 70, 71, 72, 73,
19, 20, 22, 23, 24, 25, 26, 27, 28, 106 75, 101, 102
telecommunications, 66
testing, 6, 104, 105, 110
S
training, vii, viii, 41, 42, 44, 45, 48, 49, 50,
51, 52, 54, 55, 56, 60, 61, 62, 63, 68
scholarship, 5
transformation, viii, 37, 41, 42, 43, 53, 62,
school, 45, 52, 54, 62
64, 66, 68, 88, 92
science, 12, 30, 64, 68, 78
transformations, 90, 91, 107
security, 82, 94, 97, 112
translation, 18, 23, 24, 86, 88, 92, 94
semantics, 85, 86, 87, 92, 94
service provider, 78, 79, 80, 81, 94
service-oriented architecture, vii, ix, 75, 76, V
77, 78, 80, 81, 84, 90, 93, 97, 100
services, iv, ix, 13, 16, 46, 54, 55, 57, 72, validation, 5, 19, 23, 24, 31, 34
75, 76, 77, 78, 79, 80, 81, 82, 84, 85, 86, visualization, 16, 17, 21, 40
88, 90, 91, 92, 93, 94, 96, 97, 100, 101, vocabulary, 92, 94, 96, 97
105, 106, 107, 109, 112, 113
skills, 42, 43, 44, 46, 48, 49, 50, 51, 57, 58,
W
60, 61, 63, 64, 65, 66, 67, 68
software, vii, ix, x, 9, 29, 47, 55, 75, 76, 81,
waste, 74
82, 84, 85, 87, 88, 91, 92, 93, 94, 95, 97,
web, 15, 20, 76, 84, 101, 111, 112, 113
99, 100, 101, 114
web service, 76, 101
software as a service, 93
solution, 8, 10, 57, 90, 95, 107
specialists, vii, viii, 41, 43, 44, 55, 58, 60,
62

(Computer Science, Technology and Applications) Frederik L. Sørensen (Editor) - Enterprise Architecture and Service-Oriented Architecture (2020)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

(Computer Science, Technology and Applications) Frederik L. Sørensen (Editor) - Enterprise Architecture and Service-Oriented Architecture (2020)

Uploaded by

Copyright:

Available Formats

COMPUTER SCIENCE, TECHNOLOGY AND APPLICATIONS

Additional books and e-books in this series can be found

NOTICE TO THE READER

Library of Congress Cataloging-in-Publication Data

Published by Nova Science Publishers, Inc. † New York

An enterprise architecture is an instrument that focuses on coherence

and technology infrastructure of an organization. In practice, the authors

Conversion from business architecture to technology architecture and vice

disadvantages of their technologies and implementation. The study focuses

ENTERPRISE ARCHITECTURE ALIGNMENT

Peter Filet, Rogier van de Wetering1, *

and Stef Joosten1

An Enterprise Architecture (EA) is an instrument that focuses on

elements. This research enables automated, rule-based monitoring

Modern organizations are increasingly served by, and even dependent

coherence between business processes, information distribution, and

2007), although be it that proposed solutions are diverse. Some studies

Several definitions of EA are available in the contemporary scientific

design and realization of an enterprise’s organizational structure, business

Several studies show the relevance of interrelations between aspects,

The internal EA alignment is described by Sousa et al. (2004) as ‘the

generic of business-specific). The key components for capturing rules

Quality Metrics for EA

Niemi and Pekkola (2013) investigated the EA product quality

Table 1. Effect of quality factors on overall quality

Quality factor % contribution

Although unsupported by empirical research results, we assume that

Table 2. Similarity mapping quality factors and attributes

Quality factor by Quality attribute by

We reviewed literature in search of rule candidates that could be

business processes and software systems. A part of their method applied a

Figure 1 shows our research approach. We build on the method of

Figure 1. Research approach.

Applied Alignment Heuristics

We found a limited number of scientific articles that unfold alignment

The applied rule model is constructed, based on the outcomes of the

Based on the proposed method by Aversano et al. (2016) and the

Alignment within a single quality factor (QF) is then the average

We calculate the overall alignment score as the weighted average of

If no rules exist in any of the quality factors, there is no QFalignment%

The Design science method is focused on developing an artifact that

1. Netherlands Tax & Customs Administration (NTCA)

landschap” (Overview & Insight IT landscape) governs the

example of a manufacturer named ArchiMetal. Through high-level

The EA model data for ArchiSurance, ArchiMetal, and OpenDay

The artifact is built with Ampersand, which itself is developed as an

 Haskell tool stack – to compile Ampersand

Figure 2. Ampersand output example.

For each of the EA models, the artifact consists of an Ampersand script

webserver. The web application shows violations of the applied rules.

Translating Alignment Heuristics into ADL

The formal specification in Relation Algebra and Ampersand’s ADL

Figure 3. ArchiMate visualization of rule TV065.

For this alignment heuristic to be translated into ADL, we first need to

Mate relation Realization. Implicitly, the alignment heuristic requires that

Concept Relation Concept

Figure 4. Total relationship.

The notation of a relation that follows multiplicity constraint total

 in Relation Algebra [X]  r; r˘

Violations influence overall alignment within an EA model. Each

 in Relation Algebra [X] \ (r ; r˘)

A rule must be formulated in a way that violations identify (atoms

RULE "TV065" : I[ApplicationComponent] |-