Enterprise architecture and service-oriented architecture 9781536176100, 1536176109

Table of contents :
Contents
Preface
Chapter 1
Enterprise Architecture Alignment
Abstract
Introduction
Theoretical Background
EA Literature
Alignment Heuristics
Quality Metrics for EA
Methods
Design Science
Applied Alignment Heuristics
Alignment Calculation
Case Studies
Research Environment
Translating Alignment Heuristics into ADL
Results
Discussion
Model Alignment Results
Verification of Ampersand Rules
Mutual Comparison of Model Results
Longitudinal Comparison
Ampersand
Implications for Practice
Meta-Model as a Foundation under the Set of Rules
Violations as Input for EA Management Process
Limitations
Application of EA Quality Factors
Ampersand
Future Research
Conclusion
References
Biographical Sketches
Chapter 2
Enterprise Architecture Knowledge Transfer and Organizational Empowerment
Abstract
Introduction
Methodology
Theoretical Background
Enterprise Architecture Practices
Learning Principles
Systematics of EA Learning
Empirical Studies of Skills Transfer
Summer School
Municipal Training
Certification Training
Analysis and Discussion
Impact Analysis
Critical View
Conclusion
References
Biographical Sketches
Chapter 3
Application of SOA with Cloud Computing
Abstract
Introduction
Service-Oriented Architecture Overview
Atomic Service
Composite Service
Loosely Coupled
Cloud Computing
Types of Clouds
Categories of Cloud Providers
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Adopting a Service-Oriented Architecture
Conclusion
References
Chapter 4
Microservice Architecture
Abstract
1. Introduction
2. History and Evolution of the Service-Oriented Architecture
3. Advantages and Disadvantages of MSA
4. MSA with Service Registry
5. MSA with Synchronous Communication
6. MSA with Asynchronous Communication
Conclusion
References
Index
Blank Page

Citation preview

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: [email protected].

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 Peter Filet, Rogier van de Wetering and Stef Joosten

Chapter 2

Enterprise Architecture Knowledge Transfer and Organizational Empowerment Klaus Østergaard and Torben Tambo

1

41

Chapter 3

Application of SOA with Cloud Computing Farrukh Arslan

75

Chapter 4

Microservice Architecture Nikolay Mladenov

99

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 oneoff 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 … Editor: Frederik L. Sørensen

ISBN: 978-1-53617-588-2 © 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: [email protected].

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,

4

Peter Filet, Rogier van de Wetering and Stef Joosten

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

Enterprise Architecture Alignment

5

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.

6

Peter Filet, Rogier van de Wetering and Stef Joosten

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

Enterprise Architecture Alignment

7

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 Understandability Completeness Correctness Simplicity Flexibility

% contribution 50.0% 36.4% 8.9% 3.1% 1.6%

8

Peter Filet, Rogier van de Wetering and Stef Joosten

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 Moody & Shanks Understandability Completeness Correctness

Quality attribute by Niemi & Pekkola Clarity, Holistic view (granularity), Uniformity Conciseness, Correctness (not being incomplete), Detailed information (granularity), Cohesion 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

Enterprise Architecture Alignment

9

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.

10

Peter Filet, Rogier van de Wetering and Stef Joosten

The lower part Figure 1 shows the Design Science Research Methodology 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).

Enterprise Architecture Alignment

11

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.

12

Peter Filet, Rogier van de Wetering and Stef Joosten

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 opensource, 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-

Enterprise Architecture Alignment

13

landschap” (Overview & Insight IT landscape) governs the landscape of (business)process-, application- and IT-infrastructurelandscape. 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.

14

Peter Filet, Rogier van de Wetering and Stef Joosten 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.

Enterprise Architecture Alignment

15

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

16

Peter Filet, Rogier van de Wetering and Stef Joosten

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 metamodel 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-

Enterprise Architecture Alignment

17

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

(1, a)

a

2

b (2, c)

3

c

(3, c)

d

(4, d)

4

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:

18

Peter Filet, Rogier van de Wetering and Stef Joosten  

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

Enterprise Architecture Alignment

19

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 metamodel 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, ApplicationService, etc.)

naam

Archimate relation (e.g. realizes, usedBy, access, etc.)

Figure 5. Simplified meta-model generated by Ampersand.

Tekst

20

Peter Filet, Rogier van de Wetering and Stef Joosten

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: QF Contribution: Rule TV002a TV002b TV008 TV022 TV023 TV027a TV027b TV040 TV042

TV043

TV057 TV065

Completeness 36,40% Description Antecedent Violations Business processes should be supported by a single application 9 0 Business interactions should be supported by a single application 2 0 An information entity is managed by only one application 4 0 Processes that make no access to any entity 9 5 Entities that are not accessed by any process 10 7 Each business process should be supported by at least one 9 8 application system Each business interaction should be supported by at least one 2 0 application system A Business Object is realized by 1+ Data Objects 10 0 A Business service is realized by 1+ 6 1 (Business Service or Business Process or Business Function or Business Interaction) An Application service is realized by 1+ 3 0 (Application Service or Application Process or Application Function or Application Interaction) A Data Object realizes 1+ Business products 4 0 Een applicatie realiseert een applicatie service 10 7 Quality factor alignment Weighted QF alignment

Overall alignment

Score 100,00% 100,00% 100,00% 44,44% 30,00% 11,11% 100,00% 100,00% 83,33%

100,00%

100,00% 30,00% 74,91% 27,27% 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%.

Enterprise Architecture Alignment

21

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

22

Peter Filet, Rogier van de Wetering and Stef Joosten

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.

Enterprise Architecture Alignment

23

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).

24

Peter Filet, Rogier van de Wetering and Stef Joosten Table 3. Rule translation validation

Type of specification Alignment heuristic RuleSpeak® ADL

Specification An application realises an application service An application must realize an application service I[ApplicationComponent] |realisation[ApplicationComponent*ApplicationService]; realisation[ApplicationComponent*ApplicationService]~

Relation algebra

cApplicationComponent 

Controlled Natural Language

 sApplicationService (c realisation s) ꓥ (s realisation~ c) For every ApplicationComponent, there exists an 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 indepth research is needed to determine whether this observed difference is significant. Because, if it is significant, it would mean that Business/ITalignment 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

Enterprise Architecture Alignment

25

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 reevaluation 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

26

Peter Filet, Rogier van de Wetering and Stef Joosten

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 repositoryor 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-

Enterprise Architecture Alignment

27

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.

28

Peter Filet, Rogier van de Wetering and Stef Joosten

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.

Enterprise Architecture Alignment

29

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-0119332-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-0130021-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 engineeringprincipled 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.

30

Peter Filet, Rogier van de Wetering and Stef Joosten

El-Telbany, O., & Elragal, A. (2014). Business-information Systems Strategies: A Focus on Misalignment. Procedia Technology, 16, 250262. 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 ITbusiness 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.

Enterprise Architecture Alignment

31

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ändnisses. 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.

32

Peter Filet, Rogier van de Wetering and Stef Joosten

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.

Enterprise Architecture Alignment

33

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

34

Peter Filet, Rogier van de Wetering and Stef Joosten

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

Enterprise Architecture Alignment

8.

9.

10.

11.

12.

13.

14.

35

Proceedings of the 27th European Conference on Information Systems (ECIS), June 8-14, Stockholm, Sweden. 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. 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. 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 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. 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. 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. 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

36

Peter Filet, Rogier van de Wetering and Stef Joosten

15.

16.

17.

18.

19.

20.

21.

conference on the Practice of Enterprise Modelling (PoEM), Vienna, Austria, 31 October - 2 November, 2018. 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. 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. 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. 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. 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. 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. Grave, F., Van de Wetering, R., Rutledge, L. (2018). Strategy-IT alignment Assuring alignment using a relation algebra method. In

Enterprise Architecture Alignment

22.

23.

24.

25.

26.

27.

28.

37

Proceedings of the Eight International Symposium on Business Modeling and Software Design. Vienna, Austria. 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. 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). 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. 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. 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. 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. 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

38

Peter Filet, Rogier van de Wetering and Stef Joosten

29.

30.

31.

32.

33.

34.

35.

Information Processing, W. Abramowicz, R. Alt, and B. Franczyk, Editors. 2017, Springer, Cham. 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. 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. 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. 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. 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. 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. 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.

Enterprise Architecture Alignment

39

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).

40

Peter Filet, Rogier van de Wetering and Stef Joosten

Publications from the Last 3 Years: 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.

In: Enterprise Architecture … Editor: Frederik L. Sørensen

ISBN: 978-1-53617-588-2 © 2020 Nova Science Publishers, Inc.

Chapter 2

ENTERPRISE ARCHITECTURE KNOWLEDGE TRANSFER AND ORGANIZATIONAL EMPOWERMENT Klaus Østergaard1 and Torben Tambo2 1

2

IT University of Copenhagen, Copenhagen, Denmark 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,

44

Klaus Østergaard and Torben Tambo

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.

Enterprise Architecture Knowledge Transfer …

45

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 Training objectives

Training content Organizers Trainers (speakers, presenters) Participants The organization of the trainers

The organization of the participant(s) External stakeholders

Data collection scoping Ranges from university courseworks with formal objectives to professional training with more concise statements Content lists, presentations, in some cases spoken words from video materials Organization and organizational motives included in the offering Experience from CVs, skill-sets, previous training Lists of profiles found in the empirical section Trainers are both independents but also excused from major companies, governmental agencies and learning institutions around Some organizations supports participations on individual basis, other organizations send teams 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

46

Klaus Østergaard and Torben Tambo

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 Knowledge Transfer …

47

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).

48

Klaus Østergaard and Torben Tambo

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 Architecture Knowledge Transfer …

49

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.

50

Klaus Østergaard and Torben Tambo

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. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

Fundamental Concepts and Practices Implementing Concepts and Methods Architecture for Startups, Mergers & Acquisitions Auditing the Maturity and Value of Architecture Programs & Projects Using Architecture to Support Risk Management & Security Government Enterprise Architecture Concepts and Methods Enterprise Architecture Consulting Concepts and Practices Big Architecture - Very Large Scale Implementations Modeling, Analysis, and Documentation Skill Building Agile Architecture for 90-Day Rapid Business Improvement Post-Certificate Architecture Refresher Seminar 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:

Enterprise Architecture Knowledge Transfer …

51

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.

52

Klaus Østergaard and Torben Tambo

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

Summer School

Municipal administration training Executive master university training

 



Year started (/ended) 2010ongoing

Audience

Participants accumulated

Event outline

Intended outcome

Industry professionals, university students

700

3 – 5 full days in August

2017 – 2019

Public administration professionals General industry professionals

200

2 full days

300

12 weeks, one half day per week

Inspiration for practitioners. EA mindset thinking for students. Inspiration and empowerment Certification

2013ongoing

“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.

Enterprise Architecture Knowledge Transfer … 

53

“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.

54

Klaus Østergaard and Torben Tambo Table 3. Weekly program of EA summer school (example)

Morning 1

Morning 2

Afternoon 1 Afternoon 2

Monday Contemporary academic status of EA

Tuesday Analysts view

Wednesday Current banking EA issues

Thursday EA and portfolio selection and management Governmental key guidelines

Friday The impact of agility on EA Human dimensio ns of EA

Key community issues from EA conferences Governmental frameworks

Municipal case

Banking seen from auditors EA view

Design philosophies

Analysts view

Financial EA and innovation

Practical EA in current issues in banking

Frameworks presentation

Smart cities and EA Conclusi ons

Academic presentations from master students final dissertation

Organization al faces and interfaces of EA

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.

Enterprise Architecture Knowledge Transfer …

55

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 CEO CIO Citizens services manager IT and digitalisation consultant IT Architect Operations specialists Project and program manager

42 4 13 18 67 33 26 34 237

9. Trends and EA: Agile, Robots, Data-governance, Customer journey and GDPR

56

Klaus Østergaard and Torben Tambo

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.

Enterprise Architecture Knowledge Transfer …

57

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 The course provides a basic introduction to enterprise architecture (business and IT architecture) based on internationally 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 architecture process from strategic planning to the specific architecture work in the areas of business architecture, information architecture, solution architecture and technical architecture. The interplay between architecture process implementation and operational processes is discussed. Themes such as IT governance, performance management, benchmarking and ROI will be analysed from an architecture perspective. Service Oriented Architecture (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).

Teaching pedagogic motivation Establish fundamentals by and large based on students’ existing IT qualifications Assure the students of the adherence to CMU

The students must consider the enterprise before technology and exercise insight into top-level corporate processes

This section draws lines from EA to key disciplines of the students of both their professional experience and their academic core knowledge. The support disciplines serves as relating to less abstract or practical contexts

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.

58

Klaus Østergaard and Torben Tambo

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.

2019

2017

2016

2015

2018

Overall conclusion: I am happy about this course I see a close correlation between the course topics and the intended learning outcomes I sense a close correlation between the intended learning outcomes and the test form I think the course is relevant for my future job profile I am satisfied with my effort on this course

2014

2013

Table 6. Participants satisfaction measurements 2013-2019

0..fully disagree, 6..fully agree 4.86 5.06 4.67 4.44 5.21

5.00

4.94

5.08

4.81

4.71

4.72

5.27

5.00

4.78

5.00

5.00

4.83

4.38

5.47

5.22

4.94

5.00

4.81

4.42

5.00

5.07

5.22

5.50

4.29

4.25

3.92

4.40

4.79

5.00

4.72

Table 7. Derived learning objectives progression of architects and organisation

Comparable TOGAF skill level Distinct enterprise architect job and competency roles Organizational EA competencies

EA and enterprise architect competency engagement profile Non role Infrequent Advisory 0 Nil 1 Background 2 Awareness

Full engagement 3 Knowledge

Core role 4 Expert

No enterprise architect job roles

Junior enterprise architect

Senior enterprise architect

Junior business specialist role

Senior business specialist role

EA knowledge not present in profile

Carry out enterprise architect task from time to time Infrequent EA responsibilities

Assume enterprise architect roles on ad hoc basis Ad hoc interaction with enterprise architects

60

Klaus Østergaard and Torben Tambo

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.

Enterprise Architecture Knowledge Transfer …

61

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

62

Klaus Østergaard and Torben Tambo

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?

Enterprise Architecture Knowledge Transfer …

63

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 trainingacquired 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.

64

Klaus Østergaard and Torben Tambo

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.

Enterprise Architecture Knowledge Transfer …

65

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, 267272. 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). eSkills 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, 19. ‘ 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.

66

Klaus Østergaard and Torben Tambo

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), 179228. 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.

Enterprise Architecture Knowledge Transfer …

67

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.

68

Klaus Østergaard and Torben Tambo

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.

Enterprise Architecture Knowledge Transfer …

69

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 Publications from the Last 3 Years: Ø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.

70

Klaus Østergaard and Torben Tambo

Ø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. Østergaard, K. (2019) Tailored Enterprise Architecture Introduction for Municipalities of Copenhagen. Copenhagen. Østergaard, K. (2019) Tailored Enterprise Architecture Introduction for 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.

Enterprise Architecture Knowledge Transfer …

71

Publications from the Last 3 Years: 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

72

Klaus Østergaard and Torben Tambo

10.

11.

12.

13.

14.

15.

16.

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 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 Tambo, T. & Filtenborg, J., 2019, In : Journal of Manufacturing Technology Management. Technological Capabilities of Printed Electronics: Features, Elements and Potentials for Smart Interactive Packaging Lydekaityte, J. & Tambo, T., 2019, 2019 Proceedings of PICMET '19: Technology Management in the World of Intelligent Systems. Enlightened Designers from the Dark 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 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 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 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

Enterprise Architecture Knowledge Transfer …

73

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. 110 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. 30623068 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,

74

Klaus Østergaard and Torben Tambo

24.

25.

26.

27.

28.

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 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 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 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 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 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.

In: Enterprise Architecture … Editor: Frederik L. Sørensen

ISBN: 978-1-53617-588-2 © 2020 Nova Science Publishers, Inc.

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: [email protected].

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.

Application of SOA with Cloud Computing

79

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 smalland medium-size organizations. Many services are provided on some type

Application of SOA with Cloud Computing

81

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, backupservices, 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 of SOA with Cloud Computing

83

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

Application of SOA with Cloud Computing

85

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.

Application of SOA with Cloud Computing

87

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

Application of SOA with Cloud Computing

89

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.

Application of SOA with Cloud Computing

91

Internal system B at the right expects a tagged XML format but expects the tags to be different. For example, instead of the tag in system A, system B expects the data to be tagged with . 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 poorquality 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

Application of SOA with Cloud Computing

93

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 serviceoriented 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

Application of SOA with Cloud Computing

95

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

Application of SOA with Cloud Computing

97

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 cloudbased 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 Networkbased 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

In: Enterprise Architecture … Editor: Frederik L. Sørensen

ISBN: 978-1-53617-588-2 © 2020 Nova Science Publishers, Inc.

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 softwareoriented 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: [email protected].

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

102

Nikolay Mladenov

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

Microservice Architecture

103

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 abovementioned disadvantages of the microservices and of the MSA. Upon

104

Nikolay Mladenov

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.

Microservice Architecture

105

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

106

Nikolay Mladenov

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

Microservice Architecture

107

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

108

Nikolay Mladenov

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.

Microservice Architecture

109

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

110

Nikolay Mladenov

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 halfopen 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.

Microservice Architecture

111

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.

112

Nikolay Mladenov

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

Microservice Architecture

113

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.

114

Nikolay Mladenov

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 A access, 76, 78, 87, 95, 101, 104 acquisitions, 85, 86, 94 agility, 54, 55, 65 ambidexterity, 48 application component, 13, 21, 22 architect, 33, 42, 48, 59, 61, 63 architecture design, 29 assessment, 31, 32, 38, 62, 71 assimilation, 49 asynchronous communication, 112, 113 automate, 76, 77, 79 awareness, 54, 56, 63

B bandwidth, 107 benchmarking, 24, 27, 57 benefits, 3, 101, 102, 114 brittleness, 86, 89, 92, 95 building blocks, 14, 62, 81 business environment, 2, 23 business function, 76, 77, 79

business model, ix, 6, 42, 46, 66, 72 business processes, vii, 1, 3, 5, 9, 29, 44, 60, 92 business strategy, 30, 42 businesses, 10, 14

C caching, 109, 112 candidates, 8, 16, 19 case studies, 68 case study, 67 certification, 42, 44, 49, 50, 56, 57, 62 classification, 26, 27, 48 classroom, 48, 57, 62 cleanup, 107, 108 cloud computing, v, vii, ix, 75, 76, 80, 81, 93, 95, 96, 97, 98 coherence, vii, 1, 3, 4, 10, 14, 26, 28 collaboration, 16, 34, 37, 64, 73 communication, 63, 76, 86, 93, 101, 102, 104, 107, 109, 114 communities, 42 communities of practice, 42 community, vii, ix, 42, 54, 61, 62, 82

116

Index

competencies, 42, 45, 48, 49, 50, 59, 60, 61, 65, 66, 67 complexity, viii, 1, 5, 71, 86, 90 computing, vii, ix, 75, 76, 78, 80, 81, 84, 93, 95, 96, 97, 99, 110 conceptualization, 34 conference, 36, 69, 70 cost, 80, 81, 93, 94, 97, 101 curriculum, 45, 65 cybersecurity, 60

enterprise architecture, v, vii, viii, 1, 2, 29, 30, 31, 32, 33, 34, 35, 39, 40, 41, 42, 44, 46, 48, 50, 52, 55, 56, 57, 60, 61, 64, 65, 66, 67, 68, 69, 70, 71, 73, 74 environment, 10, 25, 26, 27, 80, 82, 83 environments, viii, 25, 39, 41, 108 evolution, ix, 99, 101, 102 execution, 25, 44, 49 external relations, 47 extracts, 87, 88

D

F

data center, 80, 82, 84, 94 data collection, 45, 61 data set, 12, 95 data structure, 104, 108, 112 database, 21, 46, 81, 82, 84, 95, 104, 105, 108, 112, 113 database management, 81, 82, 84, 95 decision makers, viii, 41 Department of Defense, 49 distributed applications, 100 distributed computing, 101 distribution, vii, 1, 3

E economies of scale, 94 education, 23, 49, 68 educational opportunities, 49, 67 educational programs, 42 employees, 43, 54 empowerment, 43, 52, 63 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, 44, 45, 46, 48, 49, 50, 52, 55, 56, 57, 58, 59, 60, 61, 63, 64, 65, 66, 67, 68, 69, 70, 71, 73, 74

fault tolerance, 84, 100, 109, 112, 114 financial, viii, 22, 41, 61 flexibility, 32, 35, 36, 38, 39, 106 force, 49, 84, 85, 86, 88, 92, 93, 94, 97 foundations, viii, 29, 42

G Germany, 34, 36, 37, 64, 65, 66 governance, 47, 55, 56, 57, 72, 73, 79 guidelines, 10, 12, 23, 25, 54, 56 guiding principles, 44

H health, 36, 67 health care, 67 health information, 36 history, 102 host, 82, 103 human, 35, 46, 49, 61, 67

I improvements, 28, 101 independence, 82 individuals, 42, 44

Index industry, 49, 52, 67, 82, 85, 86, 87, 88, 90, 92 information exchange, 34, 37 information processing, 36 information technology, 2, 67 infrastructure, vii, viii, 1, 3, 5, 13, 14, 36, 37, 46, 53, 57, 81, 82, 84, 104, 111 integration, 31, 84, 85, 93, 109 intelligence, 87, 95 interface, 77, 107 interoperability, 14, 47 interrelations, 3, 5, 6, 46 issues, 26, 49, 54, 56, 76, 82, 85, 87, 88, 92, 93, 97, 106, 111

L landscape, 12, 35, 48 languages, 4 leadership, 49, 51 learning, 42, 44, 45, 48, 49, 50, 51, 55, 57, 58, 59, 61, 62, 63, 64, 65, 66, 67, 68 learning culture, 49 learning outcomes, 58 learning process, 44, 48, 51, 58, 62

117

microservices, vii, ix, x, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 112, 113, 114 mobile device, 95, 102 modelling, 14, 30, 31 models, vii, viii, 2, 4, 7, 11, 12, 14, 15, 16, 19, 24, 25, 26, 27, 28, 31, 46, 57, 63, 64, 65, 68, 72

N natural evolution, ix, 75 networking, 38, 83, 103 numerical computations, 20

O obstruction, 72 operating system, 84, 108, 113 operations, 87, 112, 113 opportunities, viii, ix, 41, 48, 61, 75, 87 organizational behavior, 53 organizational learning, 42, 63, 64

P M management, viii, 6, 17, 21, 22, 26, 31, 41, 43, 47, 49, 51, 52, 53, 54, 57, 60, 61, 65, 66, 68, 70, 71, 72, 73, 74, 81, 84, 95, 104, 106 manufacturing companies, 52 mathematical methods, 68 measurement, 11, 20, 24, 26, 28, 30, 47, 58 Mediterranean, 32, 36, 38 messages, 86, 91, 92, 110, 113 methodology, 43, 44, 47, 48, 56, 62 microservice architecture, v, vii, ix, 99, 100, 101, 105, 114

participants, 44, 45, 52, 53, 54, 56, 57, 60, 61 pharmaceutical, 52 platform, 71, 84, 93, 97 portfolio, 47, 54, 61 portfolio management, 47, 61 potential benefits, vii, ix, 76 principles, 4, 44, 49, 50, 101 professional development, 61, 68 professionals, 4, 51, 52, 54, 58, 61 programming, 31, 78, 81, 84, 88, 94, 105 programming languages, 105 project, 15, 25, 29, 43, 54, 61 protocols, 92, 96, 100, 101, 102, 104, 109

118

Index

public administration, 14 public sector, 12, 53 public service, 14

R relevance, 3, 5, 10, 12, 27, 49 reliability, 25, 84, 114 requirements, 16, 49, 67, 82, 86, 100, 102, 108, 112, 113 resilience, ix, 42, 103, 107, 109 resources, 42, 44, 64, 67, 69, 70, 81, 83, 84, 87, 101, 105, 107, 109, 110, 111, 113 response, 2, 108, 109 routes, 104, 107, 108, 109 rules, viii, 2, 3, 4, 6, 9, 11, 12, 15, 16, 18, 19, 20, 22, 23, 24, 25, 26, 27, 28, 106

S scholarship, 5 school, 45, 52, 54, 62 science, 12, 30, 64, 68, 78 security, 82, 94, 97, 112 semantics, 85, 86, 87, 92, 94 service provider, 78, 79, 80, 81, 94 service-oriented architecture, vii, ix, 75, 76, 77, 78, 80, 81, 84, 90, 93, 97, 100 services, iv, ix, 13, 16, 46, 54, 55, 57, 72, 75, 76, 77, 78, 79, 80, 81, 82, 84, 85, 86, 88, 90, 91, 92, 93, 94, 96, 97, 100, 101, 105, 106, 107, 109, 112, 113 skills, 42, 43, 44, 46, 48, 49, 50, 51, 57, 58, 60, 61, 63, 64, 65, 66, 67, 68 software, vii, ix, x, 9, 29, 47, 55, 75, 76, 81, 82, 84, 85, 87, 88, 91, 92, 93, 94, 95, 97, 99, 100, 101, 114 software as a service, 93 solution, 8, 10, 57, 90, 95, 107 specialists, vii, viii, 41, 43, 44, 55, 58, 60, 62

specialization, 80 specific knowledge, 43, 48 specifications, 19, 56, 86 stakeholders, 23, 43, 45, 54 standardization, 45, 87, 92 strategic management, 68 strategic planning, viii, 41, 46, 57 structure, viii, 5, 16, 42, 79, 86, 90, 92, 105

T technical change, 93 technological advances, 100, 102 technological revolution, 114 technology, vii, viii, ix, 1, 3, 35, 41, 44, 46, 47, 48, 51, 57, 60, 61, 67, 70, 71, 72, 73, 75, 101, 102 telecommunications, 66 testing, 6, 104, 105, 110 training, vii, viii, 41, 42, 44, 45, 48, 49, 50, 51, 52, 54, 55, 56, 60, 61, 62, 63, 68 transformation, viii, 37, 41, 42, 43, 53, 62, 64, 66, 68, 88, 92 transformations, 90, 91, 107 translation, 18, 23, 24, 86, 88, 92, 94

V validation, 5, 19, 23, 24, 31, 34 visualization, 16, 17, 21, 40 vocabulary, 92, 94, 96, 97

W waste, 74 web, 15, 20, 76, 84, 101, 111, 112, 113 web service, 76, 101