Thesis Nha-Lan Nguyen - SOA

Explaining Service-Oriented
Architecture (SOA) maturity
through challenges
experienced by SOA
adopters: A multiple-case
study
Master Thesis Supply Chain Management
Rotterdam School of Management
Erasmus University Rotterdam
Nha-Lan Nguyen
418707
lanni.nln@gmail.com
Supervisors RSM Erasmus University:
Coach: dr. Jan van Dalen
Co-reader: prof. dr. ir. Hennie Daniels
Date: 15-08-2015

A thesis submitted for the fulﬁlment of requirement of the degree of MSc Supply Chain
Management

Preface
Foreword
This master thesis was written as part of the Supply Chain Management Master at Rotter-
dam School of Management, Erasmus University. Though no direct link to supply chain
management is evident in the topic of this thesis, this study explores one of the most im-
portant facilitators for companies to reach business agility. This thesis has allowed me to
combine my passions for supply chain management and IT.
I would like to take this opportunity to express my gratitude towards everyone who made
this master thesis possible.
First of all, I would like to thank my thesis-supervisor dr. Jan van Dalen for his helpful
feedback and guidance throughout the process and prof. dr. ir. Hennie Daniels for co-
reading this thesis.
I also want to thank my friends at GLOMIDCO, especially Marcel van der Perk, for
inspiring me to gain deeper insights into the challenges of Service-Oriented Architectures
and for helping me with evaluating the companies interviewed.
Last, but not least, I want to thank my parents and my brother for believing in me and
supporting me unconditionally. Their endless love and encouragement motivated me to
write this thesis and stick it out until the very end!
Disclaimer
The copyright of the master thesis rests with the author. The author is responsible for its
contents. RSM is only responsible for the educational coaching and cannot be held liable
for the content.
i

Executive summary
This research explores how Service-Oriented Architecture (SOA) maturity levels of SOA
adopters can be explained through the challenges that these organizations experience. A
suitable maturity model has been sought for and an identification model for the SOA
challenges has been developed.
Using these models, ten influential companies operating in the Dutch transport, on-
line retail, chemical production, non-profit and financial sectors were interviewed and
evaluated on their SOA maturity levels and the challenges that they experienced. A cross-
case analysis over these findings has led to relationships between certain challenges and
the maturity levels to become evident.
This research found that SOA maturity levels of organizations can be explained through
the presence or lack of: a roadmap for SOA, top management support, a suitable business
environment, SOA governance, tangible results of SOA, enough in-house SOA knowl-
edge, organizational commitment, and an effective and strict definition of SOA principles
and standards.
Challenges that have been found to have no relationship to the maturity of the organi-
zations interviewed included: the lack of a SOA vision, the underestimation of financial
resources, the lack of business-and-IT alignment, and the lack of control over business
processes.
Also, the analysis found that no evident relationship between maturity and sectors was
present among the cases. The organizations in the online-retail sector, however, do seem
to have a close match, which can be explained through their similar need of high business
agility to compete with each other.
This research has succeeded in laying the basis for further research in the relationship
between SOA challenges and SOA maturity levels by gaining insights through real-life
experiences.
iii

Contents
1 Introduction 1
1.1 The need for agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 The Service-Oriented Architecture (SOA) response . . . . . . . . . . . . 1
2 Research Objective & Research Questions 3
2.1 Problem statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Reaping the beneﬁts of a Service-Oriented Architecture . . . . . 3
2.1.2 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Research objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 Research outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1 Theoretical part . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.2 Practical part . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3 Theoretical Background 6
3.1 Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1 What is Service-Oriented Architecture? . . . . . . . . . . . . . . 6
3.1.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 Premises of Service-Oriented Architecture . . . . . . . . . . . . . . . . . 7
3.2.1 Loosely coupling . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Agility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Reusability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4 Business Process Management and Redesign . . . . . . . . . . . 10
3.2.5 The value of Service-Oriented Architecture . . . . . . . . . . . . 10
3.3 Service-Oriented Architecture implementation & adoption . . . . . . . . 11
3.3.1 SOA maturity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2 SOA in The Netherlands . . . . . . . . . . . . . . . . . . . . . . 13
3.4 Enterprise-level challenges . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 Lack of a SOA vision and roadmap . . . . . . . . . . . . . . . . 14
3.4.2 Lack of top management support . . . . . . . . . . . . . . . . . . 15
3.4.3 Underestimation of ﬁnancial resources needed for a SOA . . . . . 15
3.4.4 An incompatible environment . . . . . . . . . . . . . . . . . . . 16
3.4.5 Lack of governance . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5 Business-level challenges . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.1 Lack of tangible results . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.2 Low organizational commitment . . . . . . . . . . . . . . . . . . 17
3.5.3 Lack of business-and-IT alignment: conceptual gap . . . . . . . . 18
3.5.4 Lack of business process control . . . . . . . . . . . . . . . . . . 19
v

CONTENTS
3.6 Technical-level challenges . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1 Non-adherence to SOA principles . . . . . . . . . . . . . . . . . 19
3.6.2 Underestimated complexity of Service-Oriented Architecture . . . 20
4 Methodology and Research Design 21
4.1 Multiple-case study methodology . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Philosophical underpinnings . . . . . . . . . . . . . . . . . . . . 21
4.2 Unit of analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1 Primary data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2 Secondary data . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.4 Theoretical framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 Data analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5.1 Computer-assisted qualitative data analysis software (CAQDAS) . 24
4.5.2 Pattern Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.5.3 Within-case analysis and cross-case analysis . . . . . . . . . . . 26
4.6 Data credibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5 Analysis 28
5.1 Within-case analysis: SOA maturity . . . . . . . . . . . . . . . . . . . . 28
5.1.1 Peter Appel Transport . . . . . . . . . . . . . . . . . . . . . . . 28
5.1.2 NEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.1.3 Belastingdienst . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.4 AkzoNobel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.1.5 ABN AMRO Clearing . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.6 Transavia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.7 Bol.com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.8 Coolblue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.9 Nationale Nederlanden . . . . . . . . . . . . . . . . . . . . . . . 41
5.1.10 KLM – Air France . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1.11 Maturity levels per sector . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Identifying SOA challenges . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.3 Explaining SOA maturity through challenges experienced . . . . . . . . . 59
5.3.1 SOA vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.2 Roadmap for SOA . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.3 Top management support . . . . . . . . . . . . . . . . . . . . . . 60
5.3.4 Nature of business environment . . . . . . . . . . . . . . . . . . 60
5.3.5 Financial resources for SOA . . . . . . . . . . . . . . . . . . . . 61
5.3.6 Governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.7 Business-and-IT alignment . . . . . . . . . . . . . . . . . . . . . 62
5.3.8 Organizational commitment to SOA . . . . . . . . . . . . . . . . 63
5.3.9 Tangible results of SOA . . . . . . . . . . . . . . . . . . . . . . 64
5.3.10 Control over business processes . . . . . . . . . . . . . . . . . . 65
5.3.11 Deﬁnition of SOA principles and standards . . . . . . . . . . . . 66
5.3.12 SOA knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.13 Additional strengtheners of SOA . . . . . . . . . . . . . . . . . . 67
vi

CONTENTS
6 Main findings, Discussion, Limitations & Conclusion 69
6.1 Main findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.1.1 Research aim: defining SOA maturity . . . . . . . . . . . . . . . 69
6.1.2 Research aim: identifying SOA challenges . . . . . . . . . . . . 69
6.1.3 Research aim: explaining maturity through challenges . . . . . . 70
6.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2.1 Unsupported propositions . . . . . . . . . . . . . . . . . . . . . 73
6.2.2 Supported propositions . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Limitations & Future research . . . . . . . . . . . . . . . . . . . . . . . 75
6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
vii

List of Tables
4.1 Interviewees categorized by sector . . . . . . . . . . . . . . . . . . . . . 23
4.2 Propositions based on previous literature . . . . . . . . . . . . . . . . . . 25
5.1 Maturity levels per sector . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.2 Identifying SOA challenges . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.1 Results: explaining SOA maturity through challenges . . . . . . . . . . . 71
viii

List of Figures
2.1 Research Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1 The difference between traditional and service-oriented architectures . . . 8
4.1 Theoretical framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 CAQDAS Retrievals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
ix

Chapter 1
Introduction
1.1 The need for agility
When Information Technology (IT) was first introduced as a necessity to enterprises, it
served mainly the purpose of storage and processing capacity for data in the form of
monolithic systems without any business logic. As organizations grew and the amount of
enterprise applications increased, the need for business logic to allow these applications to
communicate with each other rose (Birekul and Dogerliogl, 2011). In the monolithic ar-
chitecture, however, making changes to the applications in response to changing business
environments is quite complex, expensive and time consuming (Choi, Nazareth, and Jain,
2010). The monolithic architecture is robust, slow and difficult to maintain as information
volumes grow along with the organizations.
As enterprises find themselves in ever-increasing dynamic and global business envi-
ronments, they start to depend more and more on IT capabilities. Nowadays, the expec-
tations of enterprise IT are high when it comes to enhancing business agility, as organi-
zations aim to respond to changing business conditions in a timely and flexible manner
(Choi, Nazareth, and Jain, 2010). Because of these dynamics in the business conditions,
organizations need to be able to perform changes in their IT applications as often as
changes in their volatile environments occur.
On top of that, the nature of information has changed in the past decade, being in-
creasingly networked, digital and coming in huge volumes. In these ever-changing busi-
ness environments obtaining data from a single source is no longer sufficient, leading to
an increasing need for information integration (Devi et al., 2014). Business-to-business
partners within a supply chain now need to align their information streams to get a real-
time response to the continuous changes in the market using inter-organizational systems
(Haki and Forte, 2010).
1.2 The Service-Oriented Architecture (SOA) response
Enterprise Architecture (EA) is the discipline and practice in which a holistic view of
business-and-IT-alignment and all other aspects of the organization is taken. This holistic
view addresses the need for a high degree of business agility using IT, allowing the orga-
nization to move quickly into new markets, react timely to competitor moves and change
their business strategies responsively (MacLennan and Van Belle, 2014).
Service Oriented Architecture (SOA) is an enterprise architecture that has become
1

CHAPTER 1. INTRODUCTION
most prevalent for building computer systems that enhance the ability of IT to effectively
and efﬁciently respond to the rapidly changing business environment, which in turn en-
ables the organization to react to these changes in a timely manner (Choi, Nazareth, and
Jain, 2010).
Aside from agility, SOA offers a loosely coupled architecture that forms as a means to
redesign business processes to achieve a more efﬁcient execution of these processes, pro-
motes the reuse of developed IT assets, decreases development project time, risk and IT
costs and increases business-and-IT alignment (Hirschheim, Welke, and Schwarz, 2010).
This can all be achieved because this architecture is focused around ‘services’.
2

Chapter 2
Research Objective & Research
Questions
2.1 Problem statement
2.1.1 Reaping the benefits of a Service-Oriented Architecture
Despite optimistic predictions for Service-Oriented Architecture (SOA) implementation
and adoption, many practitioners are still experiencing the process in a hesitant manner
(Lee, Shim, and Kim, 2010). Though many organizations have invested a vast amount of
money in a SOA, the benefits claimed by the SOA paradigm are not always reaped (Choi,
Nazareth, and Jain, 2010). Especially conclusive proof in terms of increased business
value of SOA is hard to come by. Leading to organizations being unable to mature in their
SOA capabilities.
Many organizations do not reap these benefits and previous literature has written about
most of the challenges that organizations face when adopting a SOA. These challenges
are mostly related to human dynamics and the way that the organization envisions the
role of the SOA within the company. When an organization decides to embark on the
SOA journey, a number of managerial decisions need to be made, ranging from strategic
decisions to invest in the technology, to tactical decision concerning buy-versus-build to
operational issues addressing the selection, integration and implementation of services
(Choi, Nazareth, and Jain, 2010). All these areas form possible pitfalls for the successful
adoption of a SOA.
SOA only reaps maximum benefits when the conditions are right (Krafzig, Banke, and
Slama, 2005). SOA is an architectural style, which means that once a company decides
to choose for this approach, the entire IS organization is affected as well as the way that
the company responds to changes in business. Compared to SOA, the adoption of the
monolithic legacy systems causes a much more limited impact (Choi, Nazareth, and Jain,
2010).
It is important to realize that organization and environmental conditions and situations
vary highly across each organization that decides to adopt a SOA and that challenges
are thus all dependent on the interplay between the organizational internal and external
environment, its users and the technology (Choi, Nazareth, and Jain, 2010).
3

CHAPTER 2. RESEARCH OBJECTIVE & RESEARCH QUESTIONS
2.1.2 Contribution
The lack of perceived benefits reaped by adopters of Service-Oriented Architecture (SOA),
through the many challenges experienced, has cast a negative daylight on SOA as a solu-
tion to the need for business agility for companies. However, these challenges are often
not related to the SOA maturity of an organization. Modelling these challenges and turn-
ing them into lessons learned, however, enables us to gain insight in how these challenges
affect organizations across different maturity levels. This is a gap in the literature that
has not been covered yet and therefore forms an opportunity for this research to create
insightful contributions.
2.2 Research objective
The research objective of this study is gain insights into how the challenges that Service-
Oriented Architecture (SOA) adopters experience affect their SOA maturity level.
2.3 Research questions
To achieve the research objective, three research questions are formulated. These research
questions are related to how to measure the maturity of a Service-Oriented Architecture
(SOA) adopter, how to identify the challenges that the adopter experiences, and how the
maturity can be explained by these challenges.
The SOA maturity of an organization is used as an indicator of the degree to which
the architecture is successfully implemented and adopted to. Though many maturity mod-
els exist based on technical factors, this research aims to find a maturity model where
the application of SOA throughout the organization and the way that the architecture is
perceived by key stakeholders are key measurements. This study does not aim to find a
strict maturity model in which the organizations are strictly divided, but rather a high-
level model so that merely a ranking of the organizations can be found. The research
will thus aim to answer this first research question by searching for a suitable maturity
model to measure SOA success. Research question 1 is therefore formulated as: How can
the maturity of organizations that have implemented a Service-Oriented Architecture be
measured?
The second research questions relates to how to identify challenges in organizations
that have implemented and adopted to SOA. To answer this question a theoretical frame-
work of commonly experienced challenges will be sought for. Research question 2 is
therefore formulated as: How can the challenges of Service-Oriented Architecture be iden-
tified?
The third and last research question combines the answers of the first two questions to
find a link between how the challenges that SOA adopters experience influence their SOA
maturity level. The answer to this question aims to explain an organization’s maturity
by the challenges that it experiences. The last research question is formulated as: How
can maturity levels of organizations that have adopted a Service-Oriented Architecture
be explained through the challenges that they experience?
4

CHAPTER 2. RESEARCH OBJECTIVE & RESEARCH QUESTIONS
2.4 Research outline
This research is divided into two parts, namely the theoretical and the practical part.
Figure 2.1: Research Model
2.4.1 Theoretical part
Based on scientific articles that are published in different journals, news articles and
books, a literature review has been conducted. These sources were all obtained from the
university library and the Internet. In this theoretical part a suitable model to measure the
maturity level of a Service-Oriented Architecture (SOA) adopter will be defined. After
that, based on the literature, twelve areas of challenges that are commonly experienced
by adopters of Service-Oriented Architecture are defined. These twelve areas in turn form
the base for the theoretical model that is used to guide the rest of the research.
2.4.2 Practical part
The twelve areas of challenges are tested qualitatively through the practical part of this
research. For this part, interviews were conducted with practitioners and experts of the
Service-Oriented Architecture (SOA) domain of ten different companies. The extent to
which the practitioners have experienced these challenges within the contexts of the or-
ganizations are tested against the theoretical model developed in the literature review. As
a result of the analyses, the SOA maturity of each company will be explained through the
challenges that each company experiences.
5

Chapter 3
Theoretical Background
3.1 Service-Oriented Architecture
3.1.1 What is Service-Oriented Architecture?
Not one uniform definition has been given for the Service-Oriented Architecture (SOA)
and previous literature shows that many definitions exist.
Birekul and Dogerliogl (2011) define SOA as “a new way of designing and imple-
menting enterprise software in which a services platform is created consisting of many
services that are elements of business processes that can be combined and recombined
into different solutions and scenarios, as determined by business needs”. Choi, Nazareth,
and Jain (2010) elaborate on this definition with the emphasis on SOA as a facilitator to
the business needs and see SOA as “an approach for building systems that enhances IT’s
ability to efficiently and effectively respond to the rapidly changing business environment
and enables organizations to respond to these changes in a timely manner”. MacLennan
and Van Belle (2014) define SOA in a more technical perspective. These researchers de-
scribe SOA as “the favored architectural style to provide organizational agility, to improve
applications adaptability and systems interoperability, and to allow the reuse of legacy as-
sets”.
In this study the definition by Touzi et al. (2009) will be used. In this definition the
importance of both the business perspective as well as the technical perspective is em-
phasized. In their study they define SOA as “the architectural style that supports loosely
coupled services to enable business flexibility in an interoperable, technology-agnostic
manner. SOA consists of a composite set of business-aligned services that support a
flexible and dynamically re-configurable end-to-end business processes realization using
interface-based service descriptions”. In the next few sections the concept of ‘services’,
the premises of SOA and the challenges of SOA will be discussed, through which a com-
plete understanding of SOA and its challenges can be achieved.
3.1.2 Services
With Service-Oriented Architecture (SOA), integration is achieved through software in-
terfaces. These interfaces are called ‘services’ (Touzi et al., 2009). Services form a key
concept of the SOA paradigm. Even though many definitions of the characteristics of ser-
vices in early literature were stressed from the technical perspective, recent publications
have taken on a wider business perspective by looking at the high-level architectural im-
6

CHAPTER 3. THEORETICAL BACKGROUND
pacts of the services paradigm (MacLennan and Van Belle, 2014). This study will also
take on this latter perspective of services. Highly technical details of the SOA paradigm
are not part of the scope of this study, as the focus will mainly be on the challenges of
implementing and adopting to SOA on a high level.
A service is defined as a discrete piece of functionality of the enterprise that is per-
ceived as: atomic and self-contained by the person that uses the service, also known as
the service consumer (Touzi et al., 2009). Each service performs a piece of business func-
tionality, such as ‘check order statuses’ or ‘handle payment’. These services can be seen
as Lego parts that represent pieces of business functions and can be put together, added,
removed and recomposed to build complete business processes.
Each service has a set of messages as input and output which enable communication.
A specified structure makes up each message and it often consists of a complex business
object, such as a ‘purchase order’ or ‘invoice’ (Choi, Nazareth, and Jain, 2010).
Within an organization that has adopted SOA, functions are thus separated into distinct
services, which are made accessible over a network by the developers so that any user
can combine and reuse them in the production of business applications (Choi, Nazareth,
and Jain, 2010). Services can communicate with each other by coordinating an activity
between multiple services or by passing data from one to another.
One of the main principles of SOA is that users can access these services and use them
without any knowledge of their underlying platform implementation. With the help of
open standards, SOA enables solutions to be designed that are portable and interoperable
using existing systems (Birekul and Dogerliogl, 2011). In a SOA, enterprise applications
are built as a combination of services that are loosely coupled and interoperable. As a
more efficient use of IT assets is promoted through this architecture, a long-term decrease
in total costs of ownership, developer’s costs and maintenance costs will occur.
The premises of SOA will make the concept of services more concrete and easier to
understand. Also, figure 3.1 shows the difference between a traditional monolithic archi-
tecture and a service-oriented architecture.
3.2 Premises of Service-Oriented Architecture
The SOA principles form the foundation to align business models with technical solutions
to ensure the execution of the business models and to quickly respond to business needs
(MacLennan and Van Belle, 2014). This study identifies four main premises of the SOA,
namely: a distributed architecture through loosely coupling, agility through business-and-
IT alignment, services reusability and business process management/redesign.
3.2.1 Loosely coupling
In monolithic architectures, autonomous systems are connected to each other in a tight,
point-to-point manner. A Service-Oriented Architecture (SOA) describes the collabora-
tion between these autonomous systems in a completely different way, namely through a
loosely coupled architecture (Touzi et al., 2009). An architecture that is loosely coupled
has its connections, or services, plugged in via a mediator. This mediator is a key compo-
nent of a SOA and is called an Enterprise Service Bus (ESB). This means that whenever
a change needs to be made on one of the connected systems, think of a new Enterprise
Resource Planning (ERP) system or a version update of a current system, only one con-
nection needs to be changed: the connection between that specific system and the ESB.
7

Figure 3.1: The difference between traditional and service-oriented architectures
(a) Service-Oriented Architecture
(b) Traditional Monolithic Architecture
8

All applications are connected to the ESB, to do this Enterprise Application Integration
(EAI) is performed.
In a monolithic architecture, changes would need to be made in all the point-to-point
connections that lead back to this one system. This is an inefficient way to use information,
as the business units are not integrated. As duplications of data will occur, higher costs will
be incurred for the handling as well as for the volumes. As mentioned before, applying
any changes to these monolithic systems is costly, time-consuming and complex (Choi,
Nazareth, and Jain, 2010). Legacy systems are too latent to enable the organizations to
respond quickly to changes in the environment, which is something that organizations
cannot afford any more in these dynamic economies. There is thus an increasing need for
companies to re-engineer information systems (Li et al., 2007).
3.2.2 Agility
Nowadays, increasing globalization, competitiveness and innovations are inherent to our
business environments (MacLennan and Van Belle, 2014). The fast-paced developments
in modern economies require an increased degree of agility within companies. Agility
can be defined as the ability to recognize the changing business circumstances and react
to them by reconfiguring operations, processes and business relationships as quickly as
possible. Service-Oriented Architecture (SOA) supports this agility as it enables changes
to be made quickly to IT applications in response to changing business conditions (Choi,
Nazareth, and Jain, 2010).
To survive in contemporary business environments, a company should integrate busi-
ness functions into one system to efficiently use information technology and share this
data with its customers and suppliers (Lee, Siau, and Hong, 2003). The Information Sys-
tem (IS) capabilities of an organization heavily affect the likelihood of successful infor-
mation exchange with partners as well as between systems within the organization (Touzi
et al., 2009).
As became clear earlier, SOA is based on the fundamental idea that an information
system is no more than a collection of services that are easily connectible, connected
and reused in order to provide a desired business solution. Because of these characteris-
tics, increased business-and-IT alignment can be achieved in an organization that adopts
the SOA (MacLennan and Van Belle, 2014). A new approach is employed in which an
“on-demand” IT environment comes into existence, in which IT ultimately supports the
business in its needs and requirements to respond to changes in the business environment
to keep the organization competitive in the market (Choi, Nazareth, and Jain, 2010).
The adoption of an SOA is different from other IT adoptions, as this is an architectural
style that affect the entire IS organization and how it responds to changes in business. SOA
can serve as a means to align a company’s IT strategy with its business strategy, which
in turn again increases a firm’s agility. This agility increases opportunities to be seized in
terms of an increase in market position and revenue, but also in technical aspects, such as
a decrease in time-to-market values and overall cost reductions through reuse of IT assets
(Birekul and Dogerliogl, 2011).
3.2.3 Reusability
The reusability of services form a big motivation for companies to implement a SOA
(Touzi et al., 2009). As individualized products are formed through combinations of stan-
9

dard modules, or services, the advantages of customizing products at a mass scale can
be reaped (Birekul and Dogerliogl, 2011). The reuse of IT assets and services leads to
decreases in developers’ costs, total costs of ownership and maintenance costs.
The fact that using something that has already been built is faster and cheaper than
using something that needs to be built from scratch explains this decrease in costs. Not
only do the costs of development go down, the development speed also goes up. This
leads to more productivity and efficiency.
3.2.4 Business Process Management and Redesign
As the need for agility increases, the need for business processes to be able to adjust to
these changes at a high speed increases as well. This can only be achieved when business
processes are well defined and up-to-date. In general, there is a high tension between the
pace at which the business of an organization needs to change and the pace at which IT is
able to do it. Changes in strategies and business goals tend to change faster than changes
in the IT landscape. A Service-Oriented Architecture (SOA) facilitates in mitigating the
frictions between business and IT interests. In their book, Schipper (2010) describe the
role of a Service-Oriented Architecture in combination with Business Process Manage-
ment (BPM). SOA is a good match with BPM, as both concepts take on the holistic view
of serving the business effectively through standardized processes. As BPM structures
business processes within a company, SOA captures these into smaller components (ser-
vices) and enables the company to combine, distract, add and recombine these to change
business processes when needed.
3.2.5 The value of Service-Oriented Architecture
From the IT perspective, Service-Oriented Architecture (SOA) thus offers a newer way to
deal with issues such as reusability, but also for issues with maintenance and enterprise
application integration. SOA enables monolithic legacy systems integration in a way that
these can be used in an agile manner. The SOA principles promote standardization of data
representation and the loosely coupled services compose a well-structured IT architecture.
This increased Information System (IS) agility enables IT to support the business in a
timely manner with solutions that are close to the business requirements.
From the managerial perspective, SOA provides a way to serve their internal or ex-
ternal customers better by, for example, locate IT-services to improve visibility across
organizational data and more efficient business process execution. Increased flexibility,
time-to-market and productivity are all metrics that attract management to the adoption
of SOA.
Lastly, from the enterprise perspective, SOA enables realignment of the organization’s
structure to achieve a better flow of, and increased visibility into and control over, end-to-
end value streams, adding value for both the suppliers and customers (Hirschheim, Welke,
and Schwarz, 2010). Business requirements are defined as services directly, rather than
translating business requirements into lower-level IT requirements to develop a service
(Hirschheim, Welke, and Schwarz, 2010). The business needs are thus directly aligned
with the IT execution, resulting into a shift in which IT administrators will be work-
ing more closely with business units to develop services and redesign business processes
to achieve the organizational goals. Barriers are brought down with SOA, bringing an
enterprise-wide access to functional capabilities, which were previously distributed over
10

the different business units (Hirschheim, Welke, and Schwarz, 2010).
3.3 Service-Oriented Architecture implementation & adop-
tion
Though Service-Oriented Architecture (SOA) does seem like a suitable response to the
need for agility, practice shows that many organizations that have adopted SOA have not
reaped the benefits as prominently as they could. SOA is a paradigm which affects the
way that a company responds to business change, as well as in the company’s information
system organization (Choi, Nazareth, and Jain, 2010). It is therefore complex in its imple-
mentation and adaptation as many stakeholders, with possible conflicting interests, need
to be aligned. Compared to SOA, the adoption of the monolithic legacy systems causes a
much more limited impact (Choi, Nazareth, and Jain, 2010).
Many of the challenges experienced are related to human dynamics and the way that
the organization envisions the role of the SOA within the company. When an organization
decides to embark on the SOA journey, a number of managerial decisions need to be
made, ranging from strategic decisions to invest in the technology, to tactical decision
concerning buy-versus-build to operational issues addressing the selection, integration
and implementation of services (Choi, Nazareth, and Jain, 2010). All these areas form
possible pitfalls for the successful adoption of a SOA.
The SOA adoption process is said to have a high adoption barrier, meaning that it is not
easy to implement as many organizations cannot afford to give up on short-term benefits
when project management goals and the necessity to follow the SOA design principles
conflict with each other (Choi, Nazareth, and Jain, 2010). Small businesses rarely adopt
SOA for their IT infrastructure, as tangible benefits are unlikely to be yielded for them.
The high adoption barrier thus gives organizations that have adopted SOA a competitive
advantage of innovation in the long run if executed in the right way (Choi, Nazareth, and
Jain, 2010).
Before the challenges will be discussed, it is important to understand how the success
of a certain SOA implementation and adoption can be measured in terms of the SOA
maturity of an organization.
3.3.1 SOA maturity
One of the main goals of this study is to find a Service-Oriented Architecture (SOA)
maturity model that takes into account the role that a SOA plays within the organization
and how it is perceived. As opposed to most SOA maturity models, the model that this
research aims to find is one that is not fully technically oriented and merely gives a sense
of the extent to which an organization is mature in its SOA implementation and adoption.
This is because the result of this research will provide insights in how specific challenges
influence the SOA maturity of the organizations studied. When taking on a too detailed
maturity model to measure SOA success, no room is left to fit in the new findings. An
important criticism is that SOA maturity models are often too technically-oriented as
these models only present one part of a broader enterprise maturity model (Meier, 2006).
One of the most used maturity models is the one by The Open Group Service Inte-
gration Maturity Model (OSIMM) (OpenGroup, 2013). This model incorporates seven
11

dimensions, namely: business, organization & governance, method, application, archi-
tecture, information, and infrastructure & management. These dimensions are evaluated
across seven maturity levels, namely: silo, integrated, componentized, service, compos-
ite services, virtualized services, and dynamically re-configurable services. Though this
model has certain dimensions that suits this research, the highly technical dimensions and
descriptions of each maturity level are not within the scope of this research.
A maturity model that does, however, fully suits this research is one by Mircea and
Andreescu (2012). Mircea and Andreescu (2012) stress the importance of an analysis of
Service-Oriented Architecture maturity level in an organization to achieve a successful
adoption. Organizations often implement SOA in an incremental manner, in which initia-
tion is achieved by small projects in only one or several departments of an organization.
Once these projects have proven to be successful, a superior level of SOA maturity in the
organization is likely to follow. Mircea and Andreescu (2012) describe the SOA maturity
by classifying six stages, which take into account the lining up of the SOA strategy with
the business strategy and the localization of SOA at organizational level: initiation, exper-
imenting, integration, standardization, self-managed, and adaptive. Within these stages,
parts of other maturity models support the same characteristics and dimensions and will
be described per stage.
In stage 1 (initiation), minimum knowledge of SOA and its aspects is present in the
company. There is also a minimum interest for SOA at management level, and the archi-
tecture is mainly used for a specific project without any business involvement. The ’initial
stage’ as defined by the maturity model of Hirschheim, Welke, and Schwarz (2010) is
comparable to this level. Hirschheim, Welke, and Schwarz (2010) describe this stage in
which SOA is hidden for the business and in which only minor adaptation of current soft-
ware methods occurs. Sonic Software Corp. (2005) adds that in this stage the Enterprise
Service Bus (ESB) is introduced as middleware to connect the services across applica-
tions.
In stage 2 (experimenting), information and business capabilities are exposed as a
service within a department and then outside the department. A certain Return on In-
vestment (ROI) is achieved through the SOA benefits. Hirschheim, Welke, and Schwarz
(2010) identifies the benefits at this stage as those of service reuse and standardization of
data and resources. Hirschheim, Welke, and Schwarz (2010) also recognizes that the SOA
is mostly used on project-level for several projects.
In stage 3 (integration), SOA expands from one to several departments as a facili-
tator for cooperation and process improvements. The architecture is mainly centered on
business units and is only understood by a part of the IT staff and management. In this
level, Hirschheim, Welke, and Schwarz (2010) adds, the standardization of data and re-
sources enables the organization to start thinking about business process (re)design. Sonic
Software Corp. (2005) describes two ways to reach this business process improvement,
namely through focussing on improving internal processes or through improving pro-
cesses with third parties.
Stage 4 (standardization), is characterized by the extension of SOA at the organiza-
tional level to facilitate to cooperation and business process improvement, but still lack the
integration. Business processes are more and more aligned to technology by the organiza-
tion to obtain the benefits of reuse of services and improved speed in which changes can
be made that are imposed by the business environment. Hirschheim, Welke, and Schwarz
(2010) defines this stage as the ’defined stage’ in which business process redesign can be
done through services.
12

In stage 5 (self-managed), SOA is integrated at organizational level and enables or-
ganizations to respond proactively to changes in the market and environment. Organi-
zational performance is also measured in terms of SOA indicators, which measure the
positive impact of the architecture on the company. Hirschheim, Welke, and Schwarz
(2010) named this stage as the quantitatively managed stage’ in which indeed agility and
flexibility is achieved. Not only are there intra-organizational service definitions, but also
inter-organizational service definitions to third parties.
Lastly, in stage 6 (adaptive), SOA has become a fundamental for all operations in-
ternal and with business partners and for business management. Mircea and Andreescu
(2012) speak of a service-oriented enterprise at this stage. In this situation, everything is a
service and the enterprise is a service, which creates new space for agility and innovation
in the company. In this stage, the continuous improvements in achieving the company’s
goals and objectives are measured in terms of an ROI. Hirschheim, Welke, and Schwarz
(2010) adds that autonomic systems, a strong sense of ’service thinking’ throughout the
organization, value-chain optimization and a strong governance over SOA are all present.
In their study, Mircea and Andreescu found that many organizations find themselves
in the first stages of SOA maturity. To analyze the problems, different levels of analy-
sis have been defined in this study. As a means of deeper analysis, these stages defined
by Mircea and Andreescu (2012) will be used to divide the cases into maturity classes.
The challenges that are described in previous literature are divided into enterprise-level,
business-level and technical-level issues. For each challenge a proposition is posed. These
propositions will guide towards the creation of a theoretical framework for this research.
3.3.2 SOA in The Netherlands
The Netherlands, though a small country, ranks seventh on the global ICT Development
Index 2013 by the ITU, the United Nations specialized agency for information and com-
munication technologies. It is therefore interesting to investigate the stance on Service-
Oriented Architecture in a country that is mature in ICT as this. In the Netherlands,
Service-Oriented Architecture (SOA) is a word that is perceived mostly as a buzzword
and a hype (Heur, 2009). According to Ram Menon, the marketing manager of Tibco,
one of the largest developers of SOA software, the word ‘SOA’ should no longer be used
on management level. He claims that SOA has become a “fashion word” and it is asso-
ciated with the many negative views on it due to wrong interpretations and expectations.
However, many large organizations that operate in The Netherlands do have a Service-
Oriented Architecture and companies especially in the financial and telecom industries
(Heur, 2009), one can say that working within the SOA paradigm has long ago rooted in
the ICT culture of many large Dutch organizations (Hulsman, 2010).
This research aims to find out the extent to which this paradigm has shifted within
these organizations. To do this, representatives of ten large companies operating in The
Netherlands have been interviewed. These companies have adopted SOA to an extent and
come from different sectors, namely: transport, online retail, financial services, non-profit
and chemicals production.
13

3.4 Enterprise-level challenges
3.4.1 Lack of a SOA vision and roadmap
Companies often decide to invest in a Service-Oriented Architecture (SOA) without real-
izing and understanding all the implications of their decisions (MacLennan and Van Belle,
2014). SOA is a paradigm that requires long-term vision and commitment for its benefits
to be reaped. Committing to an implementation of a SOA without a clear vision, strat-
egy and transition plan, therefore, often leads to dissatisfaction after investing in many
companies. For a successful SOA a conceptual SOA vision, various SOA policies and
governance and enabling behavior are important (Birekul and Dogerliogl, 2011).
Birekul and Dogerliogl (2011) go as far as saying that SOA should transform orga-
nizational structures to be effective. For a SOA to be effective, it needs to become the
overarching technology within an organization and it needs to take on the role to trans-
form the organizational structure and the way that the organization behaves internally. The
researchers found that many organizations embark on a SOA project without considering
the option to re-designing the business as a first step. Leaving out this step, Birekul and
Dogerliogl (2011) believe that the greatest value of SOA is disregarded.
In practice, however, the initiation of a SOA implementation often originates from
an IT perspective, without business involvement. Though the implementation might seem
successful for that certain IT project, it is very likely that it is not aligned with the business
goals of the company, leading to growing costs of IT without any return on investment for
the company (Galinium and Shahbaz, 2012). Strong planning in projects in both technical
and business perspectives is needed to avoid this situation.
According to Kontogiannis, Lewis, and Smith (2008) the development of a service
strategy that aligns with the organization’s business drivers, context and application do-
main is a key success factor in an ideal SOA adoption setting. In their study, they designed
a model in which three essential spaces are outlined for a successful SOA within an or-
ganization, namely: the problem space, the planning space, and the solution space. In
the problem space the characteristics of the organization in terms of business drivers and
strategy constraints are present. The planning space needs to take into account the problem
space and state a SOA strategy. This SOA strategy explains how the business problems
from the problem space are going to be addressed using SOA. Lastly, the solution space
is where the outcomes of the SOA strategy are executed. During the process, changes and
improvements are made to the planning space, with the ultimate goal of aligning with the
problem space, e.g. the business’ drivers.
Many researchers have found that clear goal-setting based on business value, defining
a SOA roadmap and a strong alignment between business strategy and SOA strategies are
key success factors for successful SOA adoption (Lee, Shim, and Kim, 2010). A roadmap
is a plan on high level for building a SOA in an organization. It includes the goals and
milestones that are set, which usually correspond to the maturity model (Koumaditis,
Themistocleous, and Rupino Da Cunha, 2013). On this challenge the following proposi-
tions are posed:
P1: The lack of a SOA vision has a negative impact on the SOA maturity of an orga-
nization.
P2: The lack of a roadmap has a negative impact on the SOA maturity of an organiza-
14

tion.
3.4.2 Lack of top management support
A successful Service-Oriented Architecture (SOA) can only be implemented when the
right decisions are made early on in the process (Feig, 2007). Top management support
should therefore be highly involved in defining the SOA strategy and matching it to strate-
gic business plans to have a successful SOA adoption (MacLennan and Van Belle, 2014).
A high maturity in SOA initiatives is demonstrated when there is a high level of top man-
agement involvement. Top management needs to understand the impacts that SOA will
bring to the enterprises in terms of changes in technology, culture and the structure of the
organization (Birekul and Dogerliogl, 2011).
P3: The lack of top management support has a negative impact on the SOA maturity
of an organization.
3.4.3 Underestimation of financial resources needed for a SOA
There is a common misconception that Service-Oriented Architecture (SOA) is a ready-
made architecture for a system that can be bought and implemented off the shelf, that the
SOA standards and technology guarantee interoperability and that legacy integration is
easily achieved (MacLennan and Van Belle, 2014). Misconceptions such as these lead to
organizations to greatly underestimate the complexity and the effort required to success-
fully implement a SOA and adopting to it (Choi, Nazareth, and Jain, 2010). An investment
needs to be made for a SOA, like any other technology adoption. Regarding the human re-
sources and the financial resources needed, the adoption of SOA is often underestimated.
This investment needs to be allocated to the software, training and acquisition of staff,
and other complementary investments (MacLennan and Van Belle, 2014). Many orga-
nizations that transform from the traditional architecture to SOA still allocate budgets
in silos at project, group or department level. SOA, however, requires capabilities to be
shared through services and that these are reused. For a SOA to be successful, financial
resources must thus be allocated on enterprise-wide assets, rather than locally to depart-
ments and projects (Birekul and Dogerliogl, 2011). When these financial issues are not
addressed, the likelihood of duplicated services and infrastructure to appear is high. The
reusability of these services are in turn likely to be used only for individual projects, rather
than across departments (Birekul and Dogerliogl, 2011).
A thorough examination of all cost types are usually done before implementing a
software solution (Koumaditis, Themistocleous, and Rupino Da Cunha, 2013). SOA mi-
gration adds up to huge amounts of funds, of which the returns are difficult to reap on the
short term. When budgeted carefully, can prominently contribute to SOA adoption and
implementation. However, when budgeted poorly, with a lack of insight and foresight on
the required amount of funds, organizations can end up wasting money on aspects and
components of the SOA which are not the right investments to guarantee a long-term suc-
cess for its SOA (Galinium and Shahbaz, 2012).
P4: The underestimation of financial resources needed for a SOA implementation influ-
ences on the SOA maturity of an organization.
15

3.4.4 An incompatible environment
The success of a SOA adoption is perceived by organizations in terms of benefits reaped.
Choi et al. (2010) found in their study that organizations that operate in a relatively sta-
ble environment the traditional monolithic IT architecture suffices to close the gap be-
tween business and the IT applications and processes supporting them. These organiza-
tions are unlikely to experience the advantage of a SOA-based infrastructure as prominent
as claimed possible. For organizations in stable environments the need for agility is less
and aside from cost savings, no increased business value is likely to become evident.
Organizations that operate in volatile environment, where competitive intensity and
changes in business processes are needed to be made more often to respond to the envi-
ronment, will experience the benefits of a SOA more prominently. Not only are the same
cost savings through integration and IT asset reuse experienced, the gap between business
processes and the IS support for them closes much faster in a SOA-based infrastructure.
The need for agility thus plays a role in the success of a SOA adoption. However,
companies operating in relatively stable environments invest in a SOA and are dissatisfied
with the result, as benefits start to decrease over time (MacLennan and Van Belle, 2014).
In situations where the appropriateness of a SOA adoption is questionable, or where it
is not successfully adopted, the benefits erode quickly (Choi, Nazareth, and Jain, 2010).
Previous studies have shown that a for SOA project at divisional level the need for agility
plays less of a motivation than for those projects at enterprise level (Birekul and Dogerli-
ogl, 2011). SOA projects that are on divisional levels within organizations that operate in
a fairly stable environment are thus less likely to reap the claimed benefits as prominently
as those of organizations operating in volatile environments.
P5: A stable business environment has a negative influence on the SOA maturity level
of an organization
3.4.5 Lack of governance
Effective Service-Oriented Architecture (SOA) governance models are important to suc-
cessful SOA implementations. Governance refers to an overall plan that: ensures compli-
ance with internal and external regulations and evaluates services concerning their capa-
bility, security and strategic business alignment (Koumaditis, Themistocleous, and Rupino
Da Cunha, 2013).
Like top management involvement, governance demonstrates a high level of maturity
in SOA initiatives (MacLennan and Van Belle, 2014). SOA governance is necessary to be
able to assure that different development teams will focus on the fulfillment of one uni-
form SOA vision (Birekul and Dogerliogl, 2011). It also allows organizations to control
the lifecycle of services and monitor the progress of SOA initiatives, for example in the
form of a maturity test (Koumaditis, Themistocleous, and Rupino Da Cunha, 2013).
Organization and governance challenges are often considered to be most complex, as
they require an entire company to undergo changes in their methods, means of commu-
nication and cooperating, and methods of reporting relationships (MacLennan and Van
Belle, 2014).
P6: The lack of governance has a negative impact on the SOA maturity level of an or-
ganization.
16

3.5 Business-level challenges
3.5.1 Lack of tangible results
In the research of Koumaditis, Themistocleous, and Rupino Da Cunha (2013), 41% of
the Service-Oriented Architecture (SOA) implementers surveyed, experienced SOA to be
delivering less benefits than expected. Another 17% stated that they are ready to give
up on the use of SOA in the organization. According to Ricadela (2006), 24% of the
273 tech-pros surveyed stated to have implemented SOA and experienced that the project
did not meet the expectations. Of those, 55% claimed that SOA had only made their IT
environments more complex, 41% said it cost more than expected and 35% said that
they failed to reach the expected level of integration. This shows that there is still a large
amount of organizations who do not seem to be able to experience prominent benefits
from their SOA projects.
An explanation for this lack of tangible results of SOA is that organizations expect
the benefits to be reaped on a short term by implementing a big change that costs a lot
of money. For SOA to be successfully benefited from, however, incremental implementa-
tion should be done. This incremental approach takes time and SOA projects are usually
undertaken over a number of years. Long-term commitment is therefore highly important
to see these through (McKenzie, 2006). (Beack, 2006) describes taking a long view and
implementing incrementally is an essential way to go in the implementation and adop-
tion of SOA. SOA does not offer a quick solution to IT and business challenges that have
been around for a long time. Rather, it is a long-term strategy with benefits that cannot
be reaped within a short amount of time. To prevent disappointments from occurring,
this long-term vision must be communicated throughout the whole organization and to
its stakeholders. Top management support is important in assuring the commitment to the
long-term plan (Beack, 2006).
The all-at-once approach to a SOA implementation has proven to be largely ineffective
according to experts (Conz, 2007). The incremental approach means that an organization
needs to start out in a gradual fashion, in which smaller scale projects are initiated first to
build the core infrastructure, skills and fundamental knowledge needed before larger and
more critical projects are initiated (Beack, 2006). This enables the organization to learn
from experience and to improve its approach bit by bit. In this way, the risk of failing a
critical project is mitigated and the benefits of SOA will manifest over time.
In the incremental approach, the key is to realizing that business value comes from
the business solution provided by SOA to the business (Conz, 2007). When starting out
by building the services that were most needed by the business, the results became more
tangible. Slowly increasing the amount of services in the organization will eventually lead
to organization-wide SOA adoption.
P7: An intangible nature of the benefits of SOA has a negative impact on the SOA maturity
of an organization.
3.5.2 Low organizational commitment
As has become clear, adopting a Service-Oriented Architecture (SOA) requires more hu-
man and financial resources than many companies expect. For a SOA to be successful,
organization-wide commitment is needed. The people and roles are expected to be influ-
enced by SOA transformation. The responsibility for the development of SOA specific
17

skills, the encouragement of sharing and reusing services and the creation of group re-
sponsibility for SOA governance are issues that need to be addressed (Birekul and Doger-
liogl, 2011).
The introduction of SOA usually comes from a group of enterprise architects, who
will need to need to explain the SOA philosophy to the rest of the company. Therefore,
aside from developers, also managers, stakeholders, project managers, business analysts
and assurance teams need to be trained in SOA and it impacts on the organization (Birekul
and Dogerliogl, 2011).
As good as this sounds, very often organizations consist of highly heterogeneous busi-
ness teams or units, which all have different requirements and internal cultures. These
business units very often end up acting as isolated departments who act on their own,
making it difficult to collaborate within the SOA (Birekul and Dogerliogl, 2011). Chang-
ing a culture in an organizations is extremely difficult and often not possible.
When an organization fails to foster a culture in which information and resource shar-
ing is common practice across departments, the alignment of (conflicting) requirements
and goals for the SOA becomes a tough task.
P8: A low level of organizational commitment negatively influences the SOA maturity
of an organization.
3.5.3 Lack of business-and-IT alignment: conceptual gap
In companies where functional business units work as standalone teams, very often busi-
ness and IT are not well aligned. Where the business does not understand the complex
software designs, IT does not understand fully what the objectives and goals are of the
business strategy and what the processes are that support these objectives. This discrep-
ancy is often referred to as the “conceptual gap” (Krafzig, Banke, and Slama, 2005).
Especially when such an IT implementation as complex as Service-Oriented Architecture
(SOA) is introduced, this gap is prominently present.
As stated before, within the SOA paradigm, it is important for the SOA strategy to
align with the organization’s business strategy to enable successful SOA adoption (Mircea
and Andreescu, 2012). To achieve this alignment, it is important for the business stake-
holders to be involved, as they may interpret and clarify the models for the IT developers
and making sure that the congruence of the SOA implementation on the long-term is
maintained. It is often the responsibility of the enterprise architects or the IT department
to spread the SOA knowledge to gain organization-wide understanding and commitment.
(Linthicum, 2007) stresses the importance of the focus on understanding in a SOA
project. Each situation is different and there are no hard-and-fast rules that can be applied
to each SOA project. It is therefore important to understand the objectives of the business
first and how its success is defined. SOA is supposed to support the business in achieving
its goals, therefore the business should be leading in the IT strategy (Emadi and Hanza,
2013).
P9: The lack of alignment between business and IT negatively affects the SOA maturity
of an organization.
18

3.5.4 Lack of business process control
Though Service-Oriented Architecture (SOA)’s main promise is to improve business pro-
cesses with the use of the architecture, challenges are experienced in this facet as well.
The level at which business processes are documented within an organization and the
complexity of these processes are both factors that play a role in the extent to which
SOA is able to improve these business processes (Mircea and Andreescu, 2012). In con-
temporary business environments where globalization, digitalization and complexity of
interaction with partners play a big role, business processes have made a transition from
those pertaining a) to local departments, b) to interdepartmental processes between dif-
ferent business units of the organization, c) to organizational networks from the same
country or even across countries (Mircea and Andreescu, 2012).
When a business processes and their understanding are well-documented, services
can be well designed and implemented. In organizations where this documentation level
is low, combined with a high level of complexity in these processes, challenges and prob-
lems in achieving a successful SOA occur and often lead to the decision of companies to
give up (Mircea and Andreescu, 2012).
To facilitate this, business models are used to represent the components of the busi-
ness, and the relationships among the processes (Oliveira et al., 2012). The model eases
the alignment of business requirements with the IT support that it needs to be developed,
while keeping the organizational strategic vision in mind. It ensures congruence in rele-
vant information, in a way that developers as well as analysts understand the requirements
from the business can be built into an application.
P10: The lack of control over business processes influences the SOA maturity level of
an organization.
3.6 Technical-level challenges
3.6.1 Non-adherence to SOA principles
Very often building an application according to Service-Oriented Architecture (SOA) de-
sign principles leads to longer design time without yielding benefits compared to tradi-
tional ways of building. Like with any new IT, the learning curve associated in the be-
ginning of the SOA adoption also adds to the time that passes before a new application
is released. This leads to organizations being unable to discover the promised long-term
SOA benefits in the short term. As a result, quite often shortcuts are made in speed-to-
market decisions and performance issues. Long-term IT benefits are traded off against
short-term, tangible returns for the business. Pressures coming from the business and a
lack of technical SOA knowledge are factors that cause this non-adherence to SOA prin-
ciples (Choi, Nazareth, and Jain, 2010).
An effective and strict SOA policy on design and its management process is identified
as an important way to ensure adherence to SOA principles (Lee, Shim, and Kim, 2010).
P11: The lack of effective and strict definitions of SOA principles and standards nega-
tively impacts the SOA maturity of an organization.
19

3.6.2 Underestimated complexity of Service-Oriented Architecture
Lastly, quite often the complexity of the technology of Service-Oriented Architecture
itself is underestimated. Adopting and implementing SOA requires a lot of technical
knowledge and a thorough knowledge of the underpinning philosophy. Companies that
are unable to keep up with the complexity, often tend to give up on the adoption of the
architecture.
P12: The lack of knowledge in the ﬁeld of SOA and services negatively inﬂuences the
SOA maturity of an organization.
Propositions on each challenge are given in table 4.2.
20

Chapter 4
Methodology and Research Design
This research aims to understand the dynamics within companies that operate in The
Netherlands, which cause challenges in the implementation and adoption of a Service-
Oriented Architecture (SOA). A better understanding of how companies experience these
challenges in real-life will be sought for. This understanding will then be used to explain
how the challenges influence the SOA maturity levels at which different companies find
themselves. As a result, this study aims to find explanations for SOA maturity levels based
on the challenges experienced by SOA adopters.
4.1 Multiple-case study methodology
The success of the implementation and adoption of a Service-Oriented Architecture (SOA)
has been proven to be highly dependent on different factors that involve unpredictable hu-
man dynamics. As the benefits of an SOA are often thought of to be intangible, it is safe
to say that companies are likely to experience these differently. Therefore a qualitative
multiple-case study has been chosen as the research methodology of this study.
This methodology is strong in answering ‘how’ and ‘why’ questions in real-life con-
text, it is suitable for situations in which the behavior of those people involved cannot
be manipulated, it emphasizes the importance of the contextual conditions of the phe-
nomenon under study and the boundaries are not clear between the phenomenon and its
context. (Yin, 1994) has defined these characteristics as the most suitable situation to
apply a multiple-case study research methodology on.
4.1.1 Philosophical underpinnings
The philosophical underpinnings of case studies originate from the constructivist paradigm.
According to constructivists the truth is dependent on each individual’s perspective and
is therefore relative. Within this paradigm, the subjective human creation of meaning is
important, but it does not necessarily reject some notion of objectivity (Baxter and Jack,
2008). Constructivism is built upon the premise of reality being dependent on social dy-
namics of each situation. The case study method therefore focuses on understanding the
relationships and dynamics that play a role within single settings (Eisenhardt, 1989). To
enable the researcher to better understand the participant’s actions in a specific case, the
participant describes his view of reality. This approach enables close collaboration be-
tween the researcher and the participant (Baxter and Jack, 2008).
21

CHAPTER 4. METHODOLOGY AND RESEARCH DESIGN
To further explain the methodology employed, the unit of analysis, the means of data
collection, the data collected, the preliminary conceptual model, the data analysis ap-
proach and the credibility of the data of the research will be discussed in the next sections.
4.2 Unit of analysis
The unit of analysis of this study is the experiences of representatives of ten organizations
that operate in The Netherlands, which implemented and maintain a Service-Oriented
Architecture (SOA) for their IT landscapes. These ten organizations are selected across
different sectors and interviews with representatives have been conducted, as will be ex-
plained in the next section.
4.3 Data collection
4.3.1 Primary data
To obtain a complete image of the experiences of the companies that have implemented
and maintain a Service-Oriented Architecture (SOA), the people that are closest to the
coordination of it were interviewed. In-depth interviews formed the primary means of
data collection for this research. This technique enables a vivid picture of the participant’s
perspective and experience on the topic to be elicited. While conducting the interviews,
the participant was regarded as the expert on the topic and the researcher was considered
the student. Not only does this method enable the researcher to capture the participant’s
perspective, it also enables the researcher to understand how the participant interprets and
orders the world (Mack et al., 2005).
The structure of the interview is based on the theoretical framework. This framework
combines previous literature into an overview of the most commonly experienced chal-
lenges by companies that have a Service-Oriented Architecture (SOA). Causal explana-
tions were paid attention to during the interviews and active probing the participant for
his or her experience regarding the connections and relationships that they see between
particular phenomena, beliefs and events. The interviews were recorded and transcribed.
The transcripts are available on request and have been seen by the thesis supervisor. All
participants have expressed their consents regarding the usage of the information that they
have given during the interviews.
Case selection
In this research quota sampling has been used to design the sample (cases). In quota sam-
pling the amount of cases and the characteristics of the participants to be interviewed are
predefined. This research aims to better understand the challenges that companies as a
whole experience with the implementation and maintenance of a Service-Oriented Archi-
tecture (SOA). As a source of distinction, the ten cases comprise a sample of companies
operating in The Netherlands that come from different sectors, namely: transport, finan-
cial services, (chemicals) production, non-profit and online retail.
To answer the research questions posed, in-depth interviews were conducted with rep-
resentatives of different organizations that operate in The Netherlands. When sending out
22

Table 4.1: Interviewees categorized by sector
Sector Company Interviewee Function
Online Re-
tail
Coolblue Victor Welling Developer Evangelist
Bol.com Martin Schijf Team Manager Architecture
Peter Paul v/d
Beek
IT Architect SCM
Transport Transavia Reda Saad IT Architect
Rene Rab Business & IT Architect
KLM - Air France Mirjam v/d
Wolf
Head Enterprise & SOA Architects
Peter Appel Transport Gert-Jan Neeft Business Analyst
Financial
Services
Nationale Nederlanden Jeroen
Jansen van
Roosendaal
Integration Specialist
ABN AMRO Clearing Patrick Blok Enterprise Architect
Production Akzo Nobel Dolf Moonen Manager Enterprise Architecture
Thomas
Ratliff
Head Integration & ESB
Non-proﬁt NEN Sjoerd Feen-
stra
Head IT Regie
Belastingdienst Lourens
Riemens
Lead IT Architect
23

requests to organizations for an interview on this topic, the response rate was unexpect-
edly high. Out of the 29 sent out e-mails, 14 were responded to in which representatives
agreed to an interview. As 4 of them were unable to meet before the thesis deadline, only
10 interviews were conducted. This shows that the topic of this study is highly under in-
terest of current SOA adopters, as they identify themselves in the challenges posed, and
that there is a need for new insights to improve the SOA adoption.
The people within companies that are usually occupied with the solutions of these
challenges regarding the IT architecture are often Chief Information Officers (CIOs),
Chief Technical Officers (CTOs), Enterprise Architects (EA) or IT Architects. In table
4.1 an overview of companies interviewed per sector and the interviewee of each com-
pany is presented. 7 out of the 10 interviews were conducted with a single interviewee,
whereas 3 interviews were conducted with two interviewees. The interviews with multiple
interviewees did not bring any significantly different responses.
4.3.2 Secondary data
Secondary research has been conducted to an even more complete scope of this research
in the form of a literature review. In this literature review multiple scientific articles and
books have been analyzed and interpreted. The review serves as a foundation of this re-
search and motivated this study by identifying the gaps in the existing scientific literature.
Propositions
Based on the literature review, propositions have been made to guide the rest of the study
(Table 4.2). Each of these propositions form a relationship between a challenge of SOA
and the successful implementation and adoption of SOA. These relationships guide the
interviews and are compared to the results obtained through the responses of the inter-
viewees. The aim is to predict similar results (literal replication) or predict contrasting
results but for predictable reasons (theoretical replication). These proposition are high-
level, a more thorough explanation of each of the challenges can be found in chapter 3.
4.4 Theoretical framework
To form the theoretical framework of this study, all the challenges that are posed by previ-
ous literature are combined. These challenges form the propositions, to which the results
will be tested during analysis of the data. Figure 4.1 displays the theoretical framework.
4.5 Data analysis
4.5.1 Computer-assisted qualitative data analysis software (CAQDAS)
To perform data analysis, a computer-assisted qualitative data analysis software (CAQ-
DAS) is used, namely RQDA. RQDA is a package, of R programming, that enables qual-
itative data analysis in the form of a software application. This tool offers some basic
functionality when it comes to coding qualitative data. Not only does it aid in coding and
categorizing these codes, it also allows for attributions to be allocated to cases to enable
in depth analysis on different levels of data. Figure 4.2 shows the steps undertaken within
24

Table 4.2: Propositions based on previous literature
Proposition Formulation
1 The lack of a SOA vision has a negative impact on the SOA ma-
turity of an organization.
2 The lack of a roadmap has a negative impact on the SOA maturity
of an organization.
3 The lack of top management support has a negative impact on the
4 The underestimation of financial resources needed for a SOA im-
plementation influences on the SOA maturity of an organization.
5 A stable business environment has a negative influence on the
SOA maturity level of an organization.
6 The lack of governance has a negative impact on the SOA matu-
rity level of an organization.
7 An intangible nature of the benefits of SOA has a negative impact
on the SOA maturity of an organization.
8 The lack of organizational commitment negatively influences the
9 The lack of alignment between business and IT negatively affects
the SOA maturity of an organization.
10 The lack of control over business processes influences the SOA
maturity level of an organization.
11 The lack of effective and strict definitions of SOA principles and
standards negatively impacts the SOA maturity of an organiza-
tion.
12 The lack of knowledge in the field of SOA and services negatively
influences the SOA maturity of an organization.
RQDA.
4.5.2 Pattern Coding
To analyze the data in a reliable and consistent manner, the interviews have been recorded,
transcribed and coded. The transcripts were imported into RQDA and were coded case by
case. First-level coding was done first in the form of descriptive coding, also known as
topic coding. In this method of coding, the topics of the data is summarized in words
or short phrases. The topics are a form of meta-data of the actual content. The primary
goal of these descriptive codes is to assist the researcher to convey the experiences of
the participants in a summarizing manner (Saldaña, 2012). These codes formed topic-
related segments of data, after which second-level coding could be applied. These codes
amounted up to 86 descriptive codes, facilitated by RQDA.
In secondary coding, patterns were sought for. Pattern codes are explanatory codes that
signal an important, reoccurring theme, construct or explanation. It lays the foundation for
25

Figure 4.1: Theoretical framework
cross-case analysis by grouping the descriptive codes into common themes and directional
processes (Miles, Huberman, and Saldaña, 2013). Pattern coding enables the reduction of
large amounts of data into smaller analytic units. It also helps the researcher to gain a
better understanding of local incidents and interactions.
To do this the 86 descriptive codes obtained from the primary coding were divided
into 18 categories. These categories include the 12 challenges that were posed from the
theoretical framework, some general company-specific codes, and new emerging themes
that were not included in the theoretical framework. RQDA facilitates the categorizing
of the codes, making it easy to retrieve the responses of the interviewees per category or
code.
4.5.3 Within-case analysis and cross-case analysis
The within-case analysis is presented by presenting the results on the predefined proposi-
tions of each case in a table. This serves as a short summary of what has been said on each
of the propositions in each of the companies’ interviews, allowing the reader to become
thoroughly familiar with each case’s outcomes. The results will be briefly discussed in
the form of case descriptions. These will explain the role that the Service-Oriented Ar-
chitecture currently plays at each company and how mature they are in implementing and
adopting to it.
Consequently cross-case analysis will be performed. This part of the analysis will
present categories and dimensions that emerged from the pattern coding. For every cat-
egory, within-group similarities and differences as well as inter-group similarities and
differences will be sought for. Using RQDA the maturity and the industry in which each
company operates could be attributed to each of the interviews. This enabled increased
analysis depth on different analysis levels across the cases.
26

Figure 4.2: CAQDAS Retrievals
4.6 Data credibility
One of the central concerns of researchers is the external validity of the data collected in
multiple-case studies. The extent to which the findings across cases can be generalized
and how the data can be highly biased are main reasons for this concern (Campbell et al.,
1999). It is important to realize that multiple-case studies are an improvement over single-
case studies. This research has a sample consisting of ten cases of renowned organizations.
This relatively large sample size improves the extent to which generalizability can be
achieved.
The internal validity is concerned with the extent to which the reported findings ac-
curately reflect the concept under investigation (Campbell et al., 1999). To assure the
internal validity, this research has made sure to explore the challenges that organizations
experience regarding the implementation and maintenance of a Service-Oriented Archi-
tecture from multiple perspectives. Triangulation of data sources contributes for a large
part, by searching for explanations of similarities and differences across the cases in pre-
vious scientific literature and interviews. To do this, potentially important constructs from
the literature have been identified and have been measured explicitly in the interviews.
Several of these constructs indeed emerged as related to the challenges of implementing
and maintaining a Service-Oriented Architecture, which then formed strong, triangulated
measures.
Cases have been carefully selected and a SOA expert has defined the SOA maturity
levels together with the researcher.
27

Chapter 5
Analysis
5.1 Within-case analysis: SOA maturity
The within-case analysis consists of the results from the conducted interviews, presented
in a table with experiences from each company on each challenge as posed in the theo-
retical framework. In the case descriptions the main themes of the interviews will be pre-
sented in relation to the challenges experienced in implementing and adopting a Service-
Oriented Architecture (SOA). After that, each company is evaluated on its current stance
in SOA adoption, according to the maturity model of Mircea and Andreescu (2012). Ev-
ery company will be assigned a maturity level, and the extent to which this maturity can
be generalized across the different sectors will be evaluated.
5.1.1 Peter Appel Transport
Peter Appel Transport is one of the largest trucking company of The Netherlands in the
retail and foodservices. The company owns 600 trucks, which are spread out over 40
locations in The Netherlands. The organization has three offices and 1200 employees.
Gert-Jan Neeft has the function of business analyst within the company. He is close to
Peter Appel, the CEO, and together they often pursue knowledge in innovations to stay
competitively strong.
Currently Peter Appel Transport has invested in an Enterprise Service Bus (ESB)
from a logistics automating expert company. This ESB integrates certain enterprise ap-
plications, such as an Enterprise Resource Planning (ERP) system and an application to
manage the administration of the fleets. These applications are now able to exchange data
through services. The third party is entirely responsible for the governance and mainte-
nance of the ESB.
The reason why Peter Appel Transport invested in the ESB is because in 2012 a new
transport management system was introduced. After implementing and developing this
system, the need for data exchange between different applications arose: “at a given
moment, we saw that we needed different types of connections to retrieve relevant in-
formation, such as customer details, truck information, so we thought ‘right now we are
retrieving everything one on one, there must be a better solution’”.
In this company there is no specific vision about the Service-Oriented Architecture
(SOA). The ESB happened to be a solution to their integration problem, but there is lim-
ited knowledge about the philosophy or methodology behind SOA. Gert-Jan did, however,
show eagerness to learn about the benefits that SOA can bring and what the methodology
28

CHAPTER 5. ANALYSIS
behind it was. After having explained to him what SOA is in detail, he commented: “we
are currently thinking a few steps ahead. In terms of business processes, we are currently
redesigning them but not yet to IT.”
Gert-Jan explained the need for agility: “we started thinking about how we are go-
ing to serve our customers better in the future. We don’t have to be the smartest or the
strongest, but we want to be able to adjust to changes very quickly”. Gert-Jan gave one
of its biggest customers as an example: “one of our biggest clients has announced to
cut down the amount of transport companies that it is willing to work with to distribute
their goods from currently 26 to only around 6. The market is therefore very dynamic,
the customer demands for us to grow and innovate as fast as they do”. Aside from the
market dynamics, operational dynamics also form a source of the need for agility. “Before
you came, I read in the newspaper that the weather is going to be very good next week,
well that is going to impact us greatly. The customers, so the supermarkets and whole-
salers, anticipate on the weather by setting discounts on barbecue sets and soft drinks for
that week. Meaning that we will need to transport bigger volumes and adjust our truck
allocation to it. Those things thus affect us on operational level”.
Aside from the need for agility, the culture of the company also is a fit with the SOA
philosophy. Gert-Jan tells about how the company values innovation as a key component
of their strategy: “the profit margins in the transport sector are minimal, investing in
innovations is therefore quite difficult. However, we want to stay ahead of the game in the
market, so it will be worth it”.
Currently the organization is undergoing a transformation, in which business pro-
cesses will be defined on paper. As to the roadmap of the company regarding SOA Gert-
Jan says: “we indeed really want to go towards the use of those services to manage our
business processes, however we are still in our very first steps to integrate our systems”.
Gert-Jan highlights the complexity that he perceives when it comes to SOA: “I think it is
a pretty complex topic. I think it is very abstract and we heard about it and we are looking
into it. Knowing where we stand and where we can go, however, is quite difficult”.
Taking into consideration that Peter Appel Transport has only just begun deepening
its knowledge in SOA, one can say that they are very immature in the implementation
and adoption. The fact that the main motivation for the company to start with a SOA was
because of the need of a certain project to have applications integrated also shows that
there is little interest in the company on all levels to adopt to SOA on organizational level.
Based on the maturity model of Mircea and Andreescu (2012), Peter Appel Transport will
be assigned a maturity level of 1.
5.1.2 NEN
NEN is short for “NEderlandse Norm” and is a non-profit organization that is responsible
for the development of norms. Norms are agreements that are made voluntarily between
market parties about the quality and safety of their products, services and processes. As a
neutral party, NEN keeps track of which norms are needed and facilitates the collaboration
of interest parties to finance and develop these norms. Aside from developing the norms,
NEN also publishes the norms that are of effect in The Netherlands on different matters.
There are over 1500 norms that are specifically made for The Netherlands and a lot more
that are imposed on The Netherlands from European or World-wide organizations, such
as ISO.
Sjoerd Feenstra is head of IT direction. Sjoerd is responsible for the IT operations at
29

CHAPTER 5. ANALYSIS
NEN that take care of the generic part, namely: the office automation, the network- and
infrastructure, the data centers, the enterprise systems and applications of organization-
wide domains, document management and the Enterprise-Service Bus (ESB).
Currently the Service-Oriented Architecture exists out of an ESB, which functions as
a means of transport and to retrieve data from different sources. “The ESB is also used
as a means for external systems of our partners, for instance ISO. We use it to retrieve
information from them. By now every exchange of data is done via the ESB within the
company”. It is thus clear that integration is quite complete, however they are currently
migrating from an old ESB to a new ESB.
Aside from the migration, Sjoerd explains that the next step in the SOA will be to
optimize the data model: “we want the meta-data model to become leading within the or-
ganization. In this way we can have a healthy starting point, where our business processes
can be guided from. So we aim for standardization within NEN”.
Market dynamics are the main motivation for NEN to design its IT-landscape in a
service-oriented manner. The need for agility comes from the fact that norms apply to
every part of the society. Being able to respond quickly to market opportunities is thus
important. Sjoerd explains: “the construction norms form a great source of income for us
for instance. Therefore we were affected together with this sector during the crisis. There
are more opportunities in society, but we need to be able to respond to them quickly. The
earthquakes in Groningen, for instance, also ask for normalization. In the political world
is another example of where opportunities arise. Our infrastructure needs to be prepared
for these.” The need for mobile applications is another trend that Sjoerd identifies in which
having a SOA will play an important role when it comes to agility. “Imagine developing
an app in which a picture can be uploaded of a screw in a bridge and retrieving all the
norms that are related to it from the app. This enables the consumer to see when the screw
needs to be replaced and other types of norms. That is where we can add a lot of value”.
Sjoerd does have a clear vision on SOA, namely that SOA is a purely technical concept
that brings flexibility and agility. “When designing a services such that it can be used in
different applications, then reuse can be achieved”.
He does not believe that SOA brings business-and-IT alignment. Within NEN a cul-
ture is created in which a practical and pragmatic approach is used to find out what the
business wants and which role IT can play in achieving those goals. “Asking the business
what they want and where the problems are. Then we throw everything on one big pile
and takes steps from there. There is thus a direct connection between business and IT”.
He elaborates on the culture: “the IT team likes thinking along and contributing to the
business. The best part is to design your infrastructure in such a way that it is able to
answer business questions that have not been posed yet”.
Within the organization business process management is not yet automated. Currently
they are renewing the processes of the publishing department, with less waste and more
flexibility. Regarding defining the business processes and its requirements across business
users Sjoerd says: “we do see that there are some different blood types within the organi-
zation, but if you do it right and when people agree on the way in which processes need
to be designed, then it will all be fine”. Sjoerd deals with complexity in a specific way: “I
always deal with complexity by removing it. Because once it is removed, there is no longer
a need to deal with it. For example, from the very beginning I told my key stakeholders
that we are going to do this SOA migration as simple and standard as possible. They did
adhere to that”.
Though the plan of implementing SOA is well-defined and prepared, the time needed
30

CHAPTER 5. ANALYSIS
for it was underestimated in the project at NEN. “In the project phase, we already thought
about the governance phase that follows after the implementation. We did reserve budget
and time for that in the business case”, however when it comes to time reserved Sjoerd
commented: “finding the time to actually execute the project plan is difficult. I think we
were too ambitious, which has led to us being stuck. We were supposed to be done with
the migration by now, unfortunately we’re not”.
As Sjoerd and his team are still busy with defining a common data model, no stan-
dardization is present yet. Because they are not done yet, no technical benefits are reaped.
Defining the data model sometimes brings difficulties with it: “in the data model we want
to have everything as structured as possible. It is complex, takes a lot of labor and assur-
ing its integrity is quite difficult”.
Currently NEN is exposing its data and retrieving external data via de ESB. The com-
pany is currently defining a data model, which is needed to enable business process man-
agement and further integration to facilitate cooperation on an organizational level (level
4). At this moment, SOA only serves as a means for cooperation and process improve-
ments across several departments (level 3). The company will therefore be given a matu-
rity level of 3, with a movement towards level 4.
5.1.3 Belastingdienst
The Belastingdienst is the governmental organ that is responsible for levying and col-
lecting the taxes, customs rights and the excise duties for The Netherlands. Within the
Belastingdienst there are several business domains, namely: customs, taxes, benefits, col-
lecting and the Belastingtelefoon. Each of these domains have their own IT department.
Lourens Riemens and his department are responsible for the horizontal coordination
of all these separate IT departments. His responsibility is to ensure the business domains
have everything they need when it comes to technology. He concerns himself with the
standards, prescriptions, and needed components to facilitate the customer domains.
When asking Lourens about the role of Service-Oriented Architecture (SOA) within
the organization, Lourens responded: “I think that for a big part we do not follow a SOA
yet”. The organization deals with a very large IT-landscape with 1100 different applica-
tions, 400 big and 700 smaller ones, each with different lifecycles, characteristics and a
lot of redundancy. This growth has been exponential as the organization grew. As the or-
ganization is divided into different business domains that all value their autonomy, there
is no awareness of the need of a structured architecture.
The current role of SOA is servicizing existing applications, so that data can be re-
trieved from these applications in a structured way. Also several datasets are exposed
through services, these data sets are utilized most throughout the organization. Lastly,
whenever a new application is built, it is done according to the SOA architecture style.
Regarding the environment in which the Belastingdienst operates, Lourens says: “there
is a need for agility that is a result of the regulations. Brussel, for instance, is busy with
changing laws from national level to European level. To do this, many systems and the
communication between them need to be adjusted. Luckily these projects are communi-
cated long beforehand so that we can anticipate on them. The need for agility is more
critical when it comes to enabling the Belastingdienst to communicate with other govern-
mental bodies. There is a growing need for that. Lastly, on the customer side, we see the
shift to mobile applications. That is also something that we need to be able to offer our
consumers through increased agility”.
31

CHAPTER 5. ANALYSIS
Though the need for agility is evident, the SOA implementation and adoption goes
too slow according to Lourens: “when it comes to sharing data through services, it will
be no big of a challenge. Building functionalities, however, is something that we have not
done yet at all. From our entire IT-landscape, I think only 5% can be classified as SOA.
This is because SOA cannot just be employed on project level, it should be adopted on an
organization-wide level”. One of the main reasons why the implementation and adoption
goes so slow is because of the allocation of resources within the organization: “we spend
about 85% of our resources and priorities on keeping the current architecture running.
That leaves only 15% for real innovations, leading to this to go so slow”. Because of this
distribution of resources, the organization finds itself in a vicious circle: “on one hand
we need such a large amount of resources to keep everything running, on the other hand
we wouldn’t be needing this much resources if we innovated and implemented a SOA
organization-wide to gain efficiency and lower maintenance costs”. This also results in a
lack of SOA knowledge throughout the organization. Though many trainings have been
given to get developers on the SOA level, still only 5% of the architecture is SOA, so not
100% is trained.
It seems, however, easier said than done. The organization is too project-oriented:
“the interest of the projects are leading, especially the product owners who only aim at
achieving business results. This is why there is too little attention and interest in the need
for SOA on an organization-wide level”. There is a big conceptual gap between business
and IT, as the requirements are often nog communicated clearly from the business to
IT. But there are also some drivers coming from the business that might increase the
awareness of the importance of SOA, namely the agile methodology that the organization
employs and the need for business process management. “I see that agile is definitely
an accelerator for SOA. The same goes for business process management (BPM). BPM
forces you to work within the SOA principles. As many people from the business want
BPM to support their business process, the interest in SOA also grows”.
Where Lourens sees the biggest potential trouble is in the control side of SOA: “the
coordination is incredibly difficult. My fear is that it will only get more complex when
SOA is fully implemented”. Aside from that, Lourens identifies the culture as another big
challenge: “it is hard to push through a fundamental change. Keeping it up and adhering
to it. There seems to be not enough time for that within our organization”.
As SOA has not become a commodity within the Belastingdienst, even after 10 years
after first introducing it, it becomes clear that the organization is not quite as mature as
they could have been by now. The organization has cut up the landscape into smaller com-
ponents on paper, however no implementation on an organization-wide level is present.
Information and business capabilities are exposed as a service within departments and
outside the departments. Reusibility in certain datasets is achieved, however both tech-
nical and business agility is not achieved yet. Based on this analysis, the Belastingdienst
will be valued with a maturity level of 2 according to the maturity model of Mircea and
Andreescu (2012).
5.1.4 AkzoNobel
AkzoNobel is a Dutch multinational that operates in the markets of specialty chemicals,
decorative paints, and performance coatings. The company is active in more than 80 coun-
tries all over the world and has around 47,000 employees.
This interview was conducted with two representatives from the company, namely
32

CHAPTER 5. ANALYSIS
Thomas Ratliff and Dolf Moonen. Thomas is responsible for all the integration within
AkzoNobel and the Enterprise Service Bus (ESB). Dolf is the manager of Enterprise
Architecture within the company.
Currently the role of SOA within AkzoNobel entails mostly integration. In their IT
landscape there are many different enterprise applications that still need to be integrated
with each other: “what we believe we should do is put a strong integration layer, using the
Enterprise Service Bus (ESB), as that is essential to gaining more agility and flexibility
on top”. Until now, out of 1100+ applications, about 200-300 have been exposed through
services that are constantly reused by the organization. For AkzoNobel it is mainly about
improving operational efficiencies and effectiveness. With so many systems in their orga-
nization that need to communicate with each other, the need for transparent information
that can support different business decision processes is increasing. “I think it is also re-
lated to where we are in terms of maturity. There is still significant work to do at the
bottom. About 80% of our spend is there at the system of records”. Also, many external
companies that need to be integrated into the supply chain. Making the customers happier
by being closer aligned with them through information retrieved is the goal aimed for
right now.
IT is not seen as a competitive advantage within AkzoNobel: “Except for in our niche
areas, such as the Color department, we want to have software that is as standard as pos-
sible. That is driven from the top, that used to be different, but now we want to do it simple
and standard. Which forces us into the standard packages. We are therefore not very into
the technical details of the software anymore”. The organization uses technology to make
things easier, but are not “cutting edge”. AkzoNobel operates in a relatively stable indus-
try, there seem to be no quick-shifts that impose any volatility in the environment. The
focus is on costs within AkzoNobel and IT is seen as a cost, rather than an investment.
When it comes to integration, however, Thomas and Dolf do see opportunities in
certain upcoming trends, namely the shift to mobile applications, which need services
to facilitate the development, and the servitization of the organization’s business model.
“Another area where I see the potential is, as we see radical changes in business models.
Today we sell cans of paint, you don’t want a can with paint, rather you want your house
or room redone, you want a new atmosphere, so what you need is maybe somebody who
has an expertise in interior designing, someone who is good at painting etc. and you want
to have it all in one single stop. As a company we want to move towards that”. To make
that move, the tools need to be put into the hands of the people who will perform those
services. A lot of different information needs to be combined: “Examples are everything
from information and formulation systems to various pricing systems and other sorts of
information system that contains either video or audio clips describing colors. So all these
data repositories will need to be visited to collect data and be presented in a way that that
person can then quickly and efficiently do their job”.
When it comes to business-and-IT alignment, Thomas and Ratliff agree that there is
little of it: “Because of the way that we were seen. As we centralized, we created even
more distance. IM used to be part of the business and now they are just one big central
department. So we have functions in our new IM organization that focus on the business-It
relationship, but they are not selling the SOA concept. They are conveying the message of
the business telling us that it needs to be faster and cheaper”.“Because of the way that
we were seen. As we centralized, we created even more distance. IM used to be part of the
business and now they are just one big central department. So we have functions in our
new IM organization that focus on the business-It relationship, but they are not selling the
33

CHAPTER 5. ANALYSIS
SOA concept. They are conveying the message of the business telling us that it needs to be
faster and cheaper”. There is thus little awareness, let alone support, from the business for
the implementation and adoption to SOA. The business is very fragmented, so the requests
that come in at the Information Management department are all very heterogeneous and
hard to align. “For instance within the SCM there are 20 different ways of calculating
the OTIF, so you can imagine that the rest of the business process cannot be aligned if
the metrics aren’t even the same. We come from a very decentralized structure, we are
centralizing now, a long long road ahead”.
Thomas and Dolf bring forward that following SOA dogmatically and rigidly is not
the way to go for them. “As SAP introduced SOA as the next big thing a few years ago,
the general hype was to go for SOA all the way. As it turned out to be not as booming
and spectacular as expected, it cooled down. I mean, the technology is here to stay, but it
should only be used where necessary. I can imagine that companies that are very innova-
tive and that need to react to many changes in the market are more likely to adopt SOA.
For us, to be frank, it sounds a bit boring, but AkzoNobel is not that kind of company. We
should make sure that things are done right and efficiently”.
SOA challenges that the organization experiences most are the maturity, governance
and the communicating of SOA to the business. The speed at which the bottom is being
harmonized does not match up with the speed at which the need for agility from the
business is growing. “Year on year there has been a number put on costs as we grow in
services, the average amount of costs per projects has dropped dramatically. And there
are some other metrics, but the need for governance and tighter control will eventually
lead to more accurate numbers”.
Based on this analysis of the company, the AkzoNobel is valued a SOA maturity level
of 3 in the maturity model of Mircea and Andreescu (2012). Currently SOA does serve as
a facilitator for cooperation and process improvements across several departments. The
organization is mainly occupied with integrating the systems of records still. As the orga-
nization experiences difficulties with standardizing, no real increased business agility is
achieved. Benefits are reaped mainly in the form of increased efficiency and cost reduc-
tions.
5.1.5 ABN AMRO Clearing
ABN AMRO Clearing clears over 16 million trades per day and covers 90 of the world’s
leading exchanges across Europe, the Americas and Asia Pacific. Their international net-
work provides comprehensive market access to exchange-listed instruments such as op-
tions, futures and stocks, and non-exchange listed instruments such as OTC derivatives,
bonds, warrants etc.
Patrick is an enterprise architect at ABN AMRO Clearing bank. He is an expert in how
SOA has been used on architecture level to facilitate the organization’s business processes.
ABN AMRO Clearing Bank is managed globally from the head office in Amsterdam.
There is a global management team and there are management teams per area (Europe,
Asia Pacific and the US). All three areas have their own IT team that is, again, managed
globally though the architecture department at the headquarters.
Currently, SOA is used mainly on architecture level. In 2007 the organization re-
designed their business model in a service-oriented way. In this model, the organization
was divided into different functional domains. Using this model, they mapped their enter-
prise applications within the borders of each domain. The applications all communicate
34

CHAPTER 5. ANALYSIS
with one another via the Enterprise Service Bus (ESB). The organization aims to decrease
the amount of applications down to 200 applications to facilitate the whole business with
as little redundancy as possible, currently there are around 400 applications. SOA has
been accepted organization-wide as the integration manner. The benefits of integration
are all reaped in terms of high reusibility of IT assets, lower cost of ownership, and lower
maintenance costs. Patrick underlines the importance of standardization to achieve these
benefits: “the standardization is important. We only do innovation in one way and we
have a skilled team in it. Eventually this brings down the costs and it increases the extent
to which it can be monitored”.
The business and IT are well aligned within the organization. IT forms the largest
expense for the organization, which is quite unusual for in this sector. It will enable the
company to move towards the ‘digitization’ of the organization. IT therefore has a promi-
nent place on management level, both globally and locally. IT contributes to the decision
making of the business, Patrick elaborates: “on one hand IT gets challenged in what busi-
ness value they bring and on the other hand IT challenges the business on commercial
proposals”.
The environment in which ABN AMRO Clearing operates is very dynamic, Patrick
explains: “we are in a high-volume business, with around 15 million trades a day and
around 30 million messages that need to be transported”. The need for agility also comes
from internal dynamics: “we have 400 different applications, which are all run by ap-
plication teams who all have their own opinions” Patrick continues: “we are actually 3
regions combined, so the organizational complexity is also very extreme”. The internal
complexity leads to difficulties in finding a balance for SOA to thrive. The organization
wants to work towards global solutions, rather than local IT solutions. As the region of the
U.S. is a result of a merger, they have a different way of working and thinking. They are
less open towards the introduction of SOA as a global solution: “the U.S. department has
a smaller world-view, so they will experience the introduction of SOA as a threat. Though
the road is accepted, it will eventually cut some jobs of the people over there”.
The culture of the bank is also a big mediating factor on the successful adoption of
SOA. Patrick explains: “we have a strong culture of quick-and-dirty solutions. The short-
term is often weighed above the long-term benefits”. The organization hoped to achieve
stricter boundaries between business domains. However, the employees are not very open
to making roles and responsibilities explicit. “This increases the amount of transparency,
as well as the degree to which people can be held responsible for mistakes. So there is
quite some resistance”. This also leads to a challenge when it comes to governance. As
the people do not like to work within certain boundaries, it takes some extra control to
make sure that they do. “It is impossible to keep control over everything. All we can do
is try to convince the people to work within the SOA principles and standards, but we do
not see everything”. So the awareness of the architecture is not very well adopted down
the organization. This, in turn, affects the quality of services and whether one trusts the
quality of the services that has been made by another person.
When it comes to business process management, Patrick says: “in the organization
people are rather application-oriented, rather than process-oriented. Which is a pity, as
the true business value can be found in business processes. But that is a maturity step that
we still need to make”.
Based on this analysis of the main themes of ABN AMRO Clearing, a SOA maturity
level of 3, with a transition towards 4, is given. It can be concluded that the organization
is well advanced in the implementation of SOA when it comes to integration. SOA serves
35

CHAPTER 5. ANALYSIS
as a means to have the 400 applications communicate to each other (level 3). The organi-
zation is still busy with polishing up its IT landscape within the boundaries of the defined
business domains, to eventually facilitate better cooperation and process improvements
between domains (level 4).
5.1.6 Transavia
Transavia Airlines is a Dutch low-budget airline and a wholly owned subsidiary of KLM
– Air France Group. The airline flies mostly within Europe and North-Africa. For this
interview also two representatives of the organization were willing to respond. Reda Saad
and René Rab are both IT architects at Transavia. Where Reda is a more technically
grounded architect, René is more functionally grounded.
Currently the role of SOA within Transavia is solely integration. The entire IT land-
scape has been reorganized and applications are connected through each other through
services. The large monolithic architecture of the company has been transformed to a
Service-Oriented Architecture (SOA). Thought the integration is mostly complete, the
way that the architecture looks like right now is not the way that was intended. The goals,
that were set 6 years ago, have not been reached, and it is mainly due to financial re-
sources, the market, the awareness of the need for SOA, and the dominant character of the
business. The organization has three business domains, namely Commerce, Operational
and Corporate. In the operational domain is where most services can be implemented and
that is where most services are present within the organization.
The environment of Transavia is under most pressure on the commercial side. Keeping
up with the demands of the customer and anticipating on changes in the market are things
that cause this complexity. Transavia aims to become the best ‘digital’ airline. The app and
the website will become more and more important in the future. To facilitate the handling
of this pressure the partners also need to be integrated in the information streams, so that
is also an area that needs to be researched. There is little to no business involvement in
the current role of SOA at Transavia. Though one of the goals that were set when first
implementing SOA was to work towards business process management and to support
the business in creating value, this has not been achieved. Reda and René add: “there
has never been a good business-and-IT alignment. We can only explain what we do to
them to a certain extent, but not enough”. Because of the lack of understanding, the
business exerts pressures on IT, leading to short-term business benefits to outweigh the
long-term benefits of building a SOA in a structured way: “Commerce does not care
about that, money needs to be made. The dynamics are too high that we are not able to
build everything that we want”.
Transavia has introduced agile working which increases the business-and-IT align-
ment. However, this agile methodology has not helped to raise awareness about SOA
within the organization. The information managers are the ones that are supposed to fa-
cilitate the communication between the business and IT. However, Reda and René doubt
the ability of these information managers to do that properly: “I think an information
manager needs a certain amount of technical knowledge, but that is not the case in our
company. Very often do these information managers make commitments towards the busi-
ness, without knowing what kind of impact those commitments will have on the IT side.
The other way around, because of the lack of technical knowledge, information managers
often deform the actual requirements and wishes from the business. This leads to a loss of
time and to the breaking of promises”.
36

CHAPTER 5. ANALYSIS
The benefits of SOA on integration level have been well achieved, such as reusability
of IT assets and speed of development. Reda and René tell about one of the results of
increased developer’s speed: “when connecting the French department to our information
systems, it was done within a few days, where it would normally take weeks to get it
done”.
When asking whether management praised them for that they replied negatively. There
seems to be little management support: “convincing management that implementing a
SOA was very difficult. Especially in the way that the idea needs to be explained, it re-
quires an effective translation to business language to convey the message. SOA forms a
philosophy, rather than a cost. It is very difficult to make it tangible”. The challenge of
trying to convince people throughout the company to join the SOA philosophy is a big
issue in the company: “maybe it is because of the type of company that we are. We come
from an old situation, so the integration challenge needs to be tackled first before gaining
speed”.
Reda and René conclude that they just had a bad start. SOA was initiated within the
company from a drive from IT. The business was not involved from the very beginning.
René continues: “the first projects were done in areas where SOA was not very suitable.
These areas were too complex, leading to failures. A bad name soon was given to the En-
terprise Service Bus (ESB), but the benefits finally start to show now”. SOA is perceived
to be quite complex a technology: “If more time was made available for the architects
to become more experienced with it, through trainings and conferences, then it would be
going a lot better”.
There is a shift towards increased acceptance of SOA, luckily. A new team has been
installed that is responsible for the integration of applications, with an own manager. Also,
the upcoming of APIs increase the awareness of the need for services, as these need SOA
as a foundation to work.
Based on above analysis, a maturity level of 3 according to the model of Mircea and
Andreescu (2012). This is the integration level and SOA facilitates for cooperation and
process improvements. However, there is no business involvement whatsoever, the role of
SOA is mainly focused on reorganizing the previous monolithic architecture. Transavia
needs to tackle the problem of business’ disinterest in the architecture to move to the next
maturity level.
5.1.7 Bol.com
Bol.com is a webshop in The Netherlands and Belgium that was established in 1999. In
2014 Bol.com employed 700 people and had an assortment of over 9 million articles.
For this interview Martin Schijf and Peter Paul van der Beek were asked about the role
of SOA within Bol.com. Martin is team manager of the architecture department. In his
function, he guides 15 architects. Peter Paul is IT Architect in the domain of Supply
Chain management.
When Bol.com was first established it was merely an online bookstore in which about
100.000 articles were sold. Based on this volume the information systems were designed.
However, Bol.com has grown exponentially since and that architecture no longer sup-
ported current volumes. A transition has been made towards a Service-Oriented Archi-
tecture (SOA), as Amazon has done before them. The scalability was the main reason for
the organization to transition to SOA: “where we used to work with only 3 large mono-
lithic systems, we now work with scalable services that enable growth”. Bol.com is still
37

CHAPTER 5. ANALYSIS
in the transition. “We can’t possible close the shop for 3 years to make the transition to
the new architecture, so we do it step-by-step”. Around 5 years ago SOA was first in-
troduced within Bol.com. Currently around 60 services have been implemented and each
year around 20 or 30 services will be added. One of the monoliths has already been ser-
vicized, namely the catalogue. Functionalities that are newly introduced are also built
according to the SOA principles and standards. Martin gives an example: “one of the first
things that was built into a service is the well-known search suggestion function in the
webshop”.
Bol.com works with scrum-teams throughout the organization that are all responsible
for a specific topic, theme or domain from the IT landscape. “An example is the check-out
module. We have a whole scrum-team on that module. They are experts on that domain
and make sure that whenever a new paying method needs to be added, like iDeal has
become a new paying method for our Belgian customers, that they will take care of that”.
On business level there are stakeholders that have an interest in certain modules, and they
will know exactly which scrum-team to address for that. It can thus be concluded that
the business-and-IT alignment at Bol.com is very well organized. “Each scrum-team is
given a service that captures one business process. All services will be designed within
the boundaries of the domain of the scrum-team. Each business process has one business
owner, so the impact of the wishes of the business owner will stay limited to the scope
of the service, enabling the organization to keep growing”. Martin and Peter Paul both
strongly believe that working with scrum teams has accelerated the acceptance of SOA:
“SOA is an implementation that works well with smaller teams, so they fit together per-
fectly”.
When SOA was first implemented there was some resistance, as building a service
always takes longer than just connecting systems without building services. That is a bat-
tle that the architecture department had to overcome. Eventually the need for a service-
oriented architecture became so evident, as systems just stopped working, everyone un-
derstood that building services was the only way to keep operating. Martin and Peter
Paul talk about the adherence to building services in terms of long-term versus short-term
benefits: “As architects it is our job to ensure the scalability and continuity of our IT
landscape. However, we are also flexible to adjust in cases where the time-to-market for
the business is more important than the architecture maintenance at that very moment. In
those cases we choose to develop the business wish quickly so that business value can be
retrieved. However, we reserve time afterwards to replace that solution with a service ac-
cording to the SOA principles and standards”. An example was of this was when PostNL
announced that they started delivering on Mondays too. In that announcement they said:
“Coolblue and Bol.com are joining us!” Bol.com was not aware of this, but they could
not stay behind either as they would then lose from their direct competitor.
When asking how the company makes intangible benefits of SOA tangible, Martin
and Peter Paul explained that each business wish needs to be brought forwards with a
business value attached to it, which they calculate using advanced formulas. This process
is formalized. Based on that, IT is able to estimate the time and cost that it will need
and then the project will be executed. “In this way, decisions on high level can be made
on which projects to do first and which ones not to do at all according to their business
values. The projects will then be divided among the scrum-teams. In this context, IT is
also a stakeholder. Meaning that IT is allowed to say for instance ‘I want to reserve
time to catch up with the work that still needs to be done regarding the test-automation’
and another scrum-team can be reserved for that”. An example of a project that had a
38

CHAPTER 5. ANALYSIS
high priority was the Forecasting Module. This module adds a lot of business value as
it supports better purchasing decisions to be made. As a result, Bol.com indeed saw the
amount of articles in stock decrease and the availability increase. Compared to the huge
amount of articles that is in stock, great costs were saved.
An interesting finding is that Bol.com does not have an Enterprise Service Bus (ESB)
to facilitate the orchestration of the services. Services are connected to each other point-
to-point as an ESB is perceived to just bring extra overhead and to form a bottleneck.
The rationale behind it is: “I think an ESB only adds value when services from outside the
organizations need to be connected to too, because then all communication structures can
be sent to one central point to make it easier internally. We coupled all of our services
to each other. The benefit of this is that not all important data is stored in one place.
We do, however, have made agreements that the way of interfacing is the same for all
services, so all services talk to each other in the same way”. When asking what happens
to the connections whenever an adjustment needs to be made to a service, they explained:
“whenever an adjustment needs to be made to a service, a new version will be developed.
Internally the domains agreed that a service needs to be able to support all connections
for a minimum amount of time. The consumers of the changed service will be told that a
new version is up and that the old one will be removed after 6 months. The scrum teams
that consume that service will then have the time to adjust their services to it.”
One of the main challenges that Bol.com deals with is the matter of governance. The
architecture department is responsible for keeping an eye on the SOA principles, but the
service design is quite difficult to develop. Each scrum team is allowed to design its own
services, but there is no repository in which all meta-data of services can be found. Ev-
ery service has its own owner, and informally everyone in the company knows who is
responsible for which service. “Making rules and standardization are things that we are
not so good at. On one hand we want to have services as generic as possible, but on the
other hand we want to give the scrum-teams the freedom to design their own services.
Very often there is also a lack of knowledge on what a service should look like exactly, so
that is definitely something we can improve”.
Based on the above analysis, it becomes clear that Bol.com is still busy with ser-
vicizing their monolithic systems. There is a high level of business-and-IT alignment
and the boundaries of services in each domain are well defined. SOA is definitely ex-
panded organization-wide as a facilitator for cooperation and business process improve-
ment. However, not having an ESB may cause problems as the amount of services will
also keep increasing. Bol.com finds itself in SOA maturity level 4 according to the matu-
rity model of Mircea and Andreescu (2012).
5.1.8 Coolblue
Coolblue is a shop formula mainly consumer electronics, that is characterized by having
a separate webshop for every product group, with each a Dutch and a Belgian version. In
august 2014 Coolblue had 322 specialized webshops as well as 7 physical shops in the
Benelux. As a representative, Victor Welling was interviewed. Victor was responsible for
the introduction of the microservices-oriented architecture within Coolblue. In his current
function he spreads his knowledge gained from experience both in- and outside of the
developer’s department of Coolblue.
It becomes clear that when talking about the architecture of Coolblue, Victor does not
speak of a Service-Oriented Architecture (SOA), but rather an architecture that is focused
39

CHAPTER 5. ANALYSIS
on microservices. Victor explains the difference: “SOA has an enterprise vibe around
its definition, in which tools and processes become important. I think it is important to
keep things small and simple”. According to Victor’s view, SOA is only partly valuable,
namely in terms of keeping components small and reusibility. SOA is thus seen as a purely
technical concept.
Victor introduced the microservices three years ago. In the old IT landscape of Cool-
blue there was one big application that wrote to a big database. As more and more started
to work in it and as it started to serve more and more purposes, automating the application
and making changes in it became extremely difficult. There was a need for a solution that
enabled the developing speed to increase again. “The way to do this was by cutting up our
landscape into smaller components. We have a back office, where everyone at the office
works in, a front office, which is the website, and multiple datasets that were used by both
the front and back office, such as the catalogue. So we wanted to reuse that dataset, which
led us to the decision to start working with services”.
Within Coolblue IT is seen as an asset, rather than a cost. The use of microservices
is something that has been stimulated purely from the technical perspective, but IT is
ultimately a facilitator and enabler for the business. The need to be able to respond quickly
to changes is mainly felt from the developer’s perspective. This increase in developer’s
speed leads to decreases in developer’s costs. At Coolblue there are 100 developers spread
out over 16 development teams who constantly make changes to the applications. The
salary costs are thus decreased greatly with the introduction of the microservices. “In a
market where profit margins are already minimal, you need to make the most out of it.
The agility and speed to constantly keep up with the changes in the business is essential
to us”.
If the interview was to summarized into one main message it would be “keeping things
small”. Looking back on what Victor had could better, he says: “I think the services were
still not kept small enough. In hindsight we did not cut back the services to their essences
enough”. This is because the motivation of the teams diminish when things aren’t kept
small enough. “Every time a new step was made, a sense of motivation and enthusiasm
is boosted. There is no stronger force than the feeling of positive improvements”. So
sometimes Victor experienced some demotivation from the teams, which led to some
frictions. However, everyone sees the importance of the microservices and there was no
point in time that the demotivation was so strong to make any of the teams give up.
“What is the shortest way to add value to the business, while still working towards a
service-oriented architecture” is the main thought that needs to keep in mind according
to Victor.
When it comes to governance for the service-oriented architecture, no official mech-
anism is in place within Coolblue. The developers mostly depend on peer-review to see
what can be done in a better way. “The benefit of keeping things small is that whenever
something goes wrong the impact won’t be so big. This makes it easier to restore and to
know exactly what went wrong and how to handle it. This is what keeps the speed up. Be-
cause as soon as there is someone who has to keep control over everything with a rubber
stamp, the speed will be decreased tremendously”.
Victor does not believe in business-and-IT alignment brought by microservices: “I
see an important role for the business to communicate their needs, vision and strategy
to IT. It is the role of IT to facilitate these things”. Product owners are the people within
the organization who communicate these needs to IT. To a certain extent IT will be able
to think along with the business in how to actually facilitate it. “If a solution that solves
40

CHAPTER 5. ANALYSIS
today’s problems will lead to problems in 10 years, we prefer searching for a different
solution. Sometimes that means that we will decide to build services now, so that the
speed will be maintained in the future”.
Culture is perceived as an important factor for the successful implementation and
adoption of microservices. “We stimulate people from the business to go and talk to some-
one who builds software. And the other way around when a technical employee is going to
solve a problem for the end user, we encourage him or her to walk up to the end user to see
what the end user needs exactly. In that way maybe even better solutions can be thought
of”. This is a culture that has been cultivated over the years. Coolblue has anticipated
on the growth of the company, in which people tend to start grouping together in their
own domains. Another important part of the cultivated culture is the ability to admit that
something failed. “Starting small and making steps in the right direction is important. At
a certain moment there is a momentum to make more important steps”.
Victor identifies the challenge in conveying the importance of a microservice-oriented
architecture towards the rest of the organization. It is difficult to make people under-
stand who are not confronted with the architecture in their daily work. A huge amount of
thought and knowledge had been invested in this architecture, which cannot be explained
within one PowerPoint presentation. “To communicate to the business and development,
we use comprehensive language, so that everyone understands what we are talking about:
simple and small”. Currently there are about 5 or 6 people within the organization that
understand the architecture thoroughly and who convey this to the rest of the organization.
A lot of time is invested in repeating the message and using different words every time so
that eventually “when I get hit by a bus, the philosophy will still be carried on”.
After having taken a look at Coolblue, it is evident that Coolblue has a clear roadmap.
The microservices-oriented architecture is extended to organizational level, in which busi-
ness processes are supported. Coolblue is still busy with servicizing the systems, as they
have just started. This company will be given a maturity level 4 in the model of Mircea
and Andreescu (2012).
5.1.9 Nationale Nederlanden
Nationale Nederlanden (NN) is one of the biggest Dutch insurance companies. NN used
to be part of the ING Group, but has become part of NN Group since 2013 and has
been completely spun off from ING Group in 2014. Aside from insurances, the company
also offers other types of products such as mortgages. Jeroen Jansen van Roosendaal was
interviewed to represent this company. Jeroen is an integration specialist who has been
involved in integration challenges at Nationale Nederlanden since 2006.
The current role of the Service-Oriented Architecture (SOA) within NN is integra-
tion and business process management. All applications within the IT landscape of NN
have been integrated using services that are defined according to SOA principles and stan-
dards. All these connections go through the Enterprise Service Bus (ESB). Reusibility of
services is the biggest benefit reaped.
The internal dynamics cause some tension within the company. NN is currently fo-
cused on cost reductions, in which many outsourcing projects in India are initiated. But
at the same time NN still wants to be number one in what they do. These things cause an
instable situation to occur for the employees.
Jeroen tells about how SOA has transformed over the past decade. First NN used
IFSA, a certain technology, in which the principles and standards of a service were defined
41

CHAPTER 5. ANALYSIS
on a highly detailed level. Since a few years, NN has migrated from IFSA to a different
supplier of middleware, namely Tibco. Jeroen sees problems on the granularity of the
services now. “Nowadays, many services are built that are not reusable, but rather point-
to-point. They say that it is SOA, but it actually isn’t. My vision is that you should start out
in a functional model in how the organization works and then build services according to
this model”. Jeroen feels like the benefits of SOA are slowly lost. Though Tibco is one of
the biggest suppliers of SOA software, Jeroen sees a difference: “Tibco knowledge is not
the same as SOA knowledge. The standards and principles of the SOA philosophy are lost.
I think that a lot of services are built in the Tibco way, but that the quality of the services
is decreased”.
Nonetheless, there is still quite a strong SOA governance layer. The architecture layer
has defined the principles and standards for the services. There is also a console that
displays failures of services, so that the service management department can guarantee
that both the technical as well as the functional completion is done properly. However,
the IT landscape is too big and too complex to keep control over the highly detailed
properties of the services that are being built.
Despite the problems on the detailed design of services, SOA has become a common
good within NN. The reusability of IT assets is a big benefit that NN has been reaping for
the past years: “we reuse a lot, it is not like a service is ever built twice”. When asking
Jeroen about how mature he thinks NN is, he responds: “compared to other companies
that have adopted SOA, I think we are very mature”. Total cost of ownership, lower main-
tenance costs, developer’s speed are all benefits that are reaped but are so deeply nestled
into the use of SOA that they aren’t mentioned. “We are so used to having those services,
that we no longer stand still to realize how much we benefit from them”.
Judging from this interview, Nationale Nederlanden is given a SOA maturity level
of 4. As they are quite mature, but still lack the highly detailed principles and standards
according which services need to be built throughout the company. When it comes to
SOA, it certainly is there, but the execution is what challenges the company still.
5.1.10 KLM – Air France
KLM – Air France is a Franco-Dutch Airline holding company. It is the result of the
merger in 2004 between Air France and KLM. In 2014 KLM – Air France has trans-
ported 87.3 million passengers. As a representative of this company Mirjam v/d Wolf was
interviewed. Mirjam is head of the SOA program at KLM – Air France. In her function
she was the first one to initiate a SOA project in 2007.
KLM – AF started migrating monolithic legacy systems. During this time an innova-
tion project was started to gain more knowledge into the Service-Oriented Architecture
(SOA). For this project 5 years was reserved to study SOA and what was needed for it to
be implemented within the organization. While this project was going on Mirjam ran a
project to migrate one of the legacy systems to a more sustainable and scalable solution.
Mirjam chose the SOA solution and turned out to become the first within KLM – AF to
initiate SOA. Mirjam says that implementing SOA needs two essential things: “there has
to be a factor, that is driven from business or IT, that increases the need for these kinds
of innovations and there needs to be a certain academic degree applied to it. Because
otherwise, the chances of finding a solution fast that works, but might not be well main-
tainable. A dirty-fix is a hassle forever”. For Mirjam, the most important benefit of SOA is
loosely coupling, so that processes can be composed of smaller components. Reusibility
42

CHAPTER 5. ANALYSIS
is another important benefit, but not one that she puts priority on.
The current role of SOA entails that all legacy systems, except for one, have been ser-
vicised. They develop their own services, but they also consumer them. That is why there
are also some external systems which they communicate with real-time through services.
“I don’t think that we would have such an advanced website and app without SOA”. All
technical and financial benefits of SOA in terms of lower total costs of ownership, lower
maintenance costs, increased developing speed and reusability have all been reaped a long
time ago.
There is a high need for agility within the company. Mirjam describes the environment
in which KLM-AF operates as extremely dynamic and complex. Things such as the attack
on the World Trade Center, and government driven issues such as privacy and security,
are all matters that have huge impact on the IT of an airline. Mirjam gives an example:
“Recently a rule has been introduced from the States which stated that every passenger
list needs to be sent to the TSA, which is the security agency of America. They will scan
that list and as soon as one passenger on board is only a little bit suspicious, they make
the plane turn around. This is something we need to avoid, as it costs a lot of money”.
There is also a need for agility coming from the competitive pressure, the need to keep up
with developing apps, for instance, is what SOA facilitates.
Governance on SOA is also well-structured in the company. The CIO office keeps
track of all the benefits reaped from SOA and what the returns on investment is on the
architecture. The CIO also defines the general SOA principles and standards. “In the CIO
office agreements have been made that there may not be more than three versions of a
service. These are things that were defined in the SOA program and are monitored on
CIO level”. There is also a special Tibco governance team that keeps track of life cycle
management, the realization of the use of the middleware and the operational governance
and monitoring. Whenever a service stops working, they will be the first to know and the
first to solve it.
One of the main challenges of KLM-AF when it comes to SOA is weighing off the
short-term benefits over the long-term benefits. Very often services are developed for a
specific project, rather than in a generic way that it can be reused by other projects as
well. The pressure from the business and projects are often the reasons why quality assur-
ance becomes difficult sometimes: “there will always be a tension over there”. Having
multiple versions of a service also makes it difficult for maintenance to keep track of
which one is the right one. However, the interest of maintenance and keeping data simple
and transparent for the long-term often needs to be weighed out against the need for speed
coming from the business.
The last challenge is the lack of SOA knowledge within the company. Mirjam ex-
plains: “During the SOA innovation program, all guidelines, standards and principles
were already defined. We had already realized a lot of things. After that another half year
was spent on giving trainings throughout the company. However, not everyone did the
training within that half year and the program ended too quickly”. There is thus a portion
of the architects that are not fully up-to-level when it comes to their SOA knowledge.
However, a SOA refreshment training will be given soon introduced again.
Besides from the challenges discussed, SOA has been accepted organization-wide.
“There are only some domains that still have difficulties with accepting it, like HR and
finance. They still work with file transfers and the need for services is much smaller. But
I think they will become important, I mean calling in when you are sick, that is no longer
of this time, right?”
43

CHAPTER 5. ANALYSIS
Based on the analysis above, KLM – Air France is given a SOA maturity level of 5.
Everything is communicated through SOA, even the external systems. SOA is integrated
at organizational level and it enables the organization to respond proactively to changes in
the environment. The positive impact of the architecture on the company is also measured
and a lot of business value is created.
5.1.11 Maturity levels per sector
Table 5.1 shows the maturity levels that each company has per sector. It is interesting to
notice that there is no clear distribution of stages from which can be concluded that a
company that is operating in a certain sector is likely to have a certain maturity level.
First of all, in the transport sector there is a big difference in maturity levels. This can
be explained through the fact that transport is something that has been around for ages.
It has always worked, even without the help of IT. It does become apperent, though, that
the airlines have a higher need for a service-oriented architecture (SOA) than the trucking
company. As became evident from the within-case analysis, Peter Appel Transport does
not need IT as much as the others to continue operating.
A close match can be found in the online retail sector. The fact that both Bol.com
and Coolblue have been assigned a maturity level of 4 can be explained through the fact
that they are direct competitors of each other. In the sector that they are operating, it is
essential to have IT at a high level to stay competitive. These companies are as virtual as
it gets and therefore have IT as a key component in their business strategies.
Within the financial services it can be seen that they cluster around stage 3 and 4.
These companies seem to have implemented and adopted to SOA because of the techni-
cal need to be able to facilitate the core businesses. These organizations work with high
volumes of data and simply need to be able to respond actively within the world of finance.
This is why for both companies, SOA has become a common good.
There is no generalization that can be made across the non-profit cases. NEN seems
to be quite mature in its SOA thinking and experiences relatively harmless challenges, but
has simply not has the time to implement it fully yet. Whereas the Belastingdienst has
had implemented SOA already 10 years ago, but has not had the time, commitment and
resources to implement and adopt to it at all. Both organizations do not have to deal with
competition that will take away their businesses, so a slower implementation and adoption
is a bit more expected and affordable.
Lastly, AkzoNobel is the only case analyzed in the production sector, so no general-
izations can be made.
5.2 Identifying SOA challenges
One of the main research aims of this study was to find a way to identify the challenges
that adopters of a Service-Oriented Architecture (SOA) often experience. This model has
been formulated in the theoretical background and is based on three main levels of anal-
yses, namely: Enterprise level challenges, business level challenges and technical chal-
lenges. Table 5.2 presents each of the challenges on the different levels of analysis, fol-
lowed by the responses of the challenges by the cases.
Table 5.3, summarizes the experiences of the interviewees on each challenge that is
brought forward in previous literature.
44

CHAPTER 5. ANALYSIS
Table 5.1: Maturity levels per sector
45

CHAPTER 5. ANALYSIS
Table 5.2: Identifying SOA challenges
(a) Enterprise Level Challenges
(b) Business Level Challenges
46

CHAPTER 5. ANALYSIS
(c) Technical Level Challenges
47

Table5.3:Responsesofeachcompanyforeachproposition
PeterAppelNENBelastingdienstAkzoNobelTransavia
SOAvisionIntegration,agilityPurelytechnical,a
meanstofindtruth
indatasources,
integration
Puretechnical,
integration,reusability
Integration,small
components,
flexibility,well-
describedservices,
purelytechnical
Integration,reusability,
flexibility,agility
RoadmapAimtoeventually
controlbusiness
processesthrough
services,butthe
systemsstillneed
togetintegrated.
Notyetonpaper,
becauseoflackof
time.Butaclear
pathinmind.
Lifecyclemanagement
oftheSOAcomponents
providepointsforthe
roadmap.
Notpresentyet,
startingtothink
aboutthenextstep
afterintegratingthe
bottomlayer,the
reasontoacceptthis
thesisinterview.
Noroadmapforthenext
stepsdefined.
Management
support
PresentPresentPresent,butonlylocally
implemented.
PresentPresent,butonlyasa
technicalsolutionthat
hasnothingtodowith
thebusiness.
ResourcesNoconflicts
experiencedhere
Earlyoninthe
projectphase,
budgetsandtime
hasalreadybeen
allocatedto
governanceand
training.However,
projectismoving
slowerthan
expected.
Toomuchtimeand
moneyisspenton
keepingthecurrent
systemsrunning
(85%ofbudget)andtoo
littleforinnovations
suchasSOA(15%of
budget),slowingthe
implementationand
adoptiondown.
Difficulttoget
projectfundedand
gaininvestmentfor
it.Underestimation
ofresourcesisa
recognizedproblem.
Toolittlehuman
resourcesandknowledge
todealwiththeneedsof
businessononehand
andbuildingastrong
architectureontheother
InvestmentinSOAis
seenasoverhead,rather
thanacompetitive
advantage.
CHAPTER 5. ANALYSIS
48

Table5.3:Responsesofeachcompanyforeachproposition(continued)
EnvironmentNeedforagility
frompressures
fromcustomersto
growbiggerand
faster,asectorwith
lowprofitmargins,
fiercecompetition.
Alsoaneedfrom
theoperational
perspective.
Needforagilityto
grabnew
opportunitiesin
themarket,being
abletoreacttothe
crisesandchanges
indifferentsectors,
shifttomobile.
Needforagilityfrom
regulations,theshiftto
mobile,communication
withothergovernmental
bodies.
Quitestable
industry.
Opportunitiesseen
inthetrendtowards
mobileapplications,
servitization,and
APIs,needfordata
integrationforall
theseareas.
Highpressuretokeepup
withcustomers'needsin
thecommercialunit,
goaltowardsbecominga
"digitalairline",partners
willneedtobeintegrated
too.
GovernanceOutsourcedGovernanceofthe
EnterpriseService
Busisatthe
supplier,
functional
governancein-
house.
Quitestrict:department
"DesignAuthority"for
governanceon
architecturalleveland
withineachproject
groupgovernanceon
functionallevel.
Nogoodstructurein
governingthe
services.
Governanceneedstobe
strengthenedtoadoptto
SOAmoresuccessfully.
ResultsofSOAAslightincreasein
efficiencyand
processexecution
throughdata
integration.
Noneyet,asthey
juststarted
implementing
SOA.But
definitelyexpecta
decreaseinTCO
etc.
Reusability,cost
reductionsin
developers'wages.
Metricsfortheresults
availablesuchasthe
extenttowhichthe
architectureisflexible.
Reusability,with
200interfaces
reused,increased
transparent
information,
decreasedTCO,
needforbetter
governancetoobtain
metrics.
Goalshavenotbeen
reachedasenvisioned,
mainlyintegration,
reusability,butlittle
businessinvolvement.
Increaseddevelopment
speed.TheESBand
serviceshavebecomea
commongood.
CHAPTER 5. ANALYSIS
49

CultureInnovativeculture
tostayaheadof
competition.
Agilityisamain
goal.Itisokayto
makemistakesand
learnfromthem.
Keepingitas
standardas
possible,sothat
mostobstaclesand
amountof
complexityiskept
ataminimum.
Theemployeesarequite
opentonew
innovations,suchas
SOA.However,
companyistooproject-
orientedratherthan
architecture-oriented.
Highlyfragmented
culture.ITand
businessprettyfar
awayfromeach
other,becauseof
centralizationand
thewaythatITis
seen:asacostrather
thanacompetitive
advantage.
LowappreciationforIT,
businessisfaraway
fromITbecauseofthe
conceptualgap.
SOArolesOutsourcedSOAismaintained
intheITRegie
department.
Department
architecture,
Information
Managementteams,
agileroleswithproduct
ownersetc.
Thereisan
architecture
department.
Integrationteamwitha
manager.Soon,theywill
startworkingagilewith
productownersetc.
Business-IT
alignment
Stillbusywith
redesigning
businessprocesses
onpaperthrougha
questionnairesent
outtothe
employees.
ITandbusiness
haveagood
dialogue,withthe
focusontheneeds
ofthebusiness.
Practicaland
pragmatic
communication.
Information
Managementteamfor
eachbusinessunitthat
collectsrequirements,
theycommunicatewith
ITandbuildproducts
together,agile
methodology.
Difficultywith
discussingbusiness
valueinITprojects.
TheIMdepartment
doeshelpin
facilitatingthe
business-IT
alignment,butdoes
notsellSOA.
Business-ITalignment
hasneverreallybeen
good.Information
Managersareinbetween
businessandIT,butthey
lackknowledgeofSOA.
SoSOAisnot
communicated.The
businessdoesnot
understandtheadded
valueofSOA.
CHAPTER 5. ANALYSIS
50

Businessprocess
control
Increasedcontrol
overbusiness
processesonpaper,
butnothingis
relatedtoITyet.
Busywith
redesigning
businessprocesses
indifferent
businessunits,
howeversome
differencesin
opinions
sometimeshold
back.
Acertainextentof
automatedbusiness
processesmanagement
andbusinessprocesses
onpaper.BPMdoes
increasetheneedfor
SOA.
Therearebusiness
designs,butnoneof
themareconnected.
Notevenmetricsare
thesamewithinthe
company.
Nocontroloverbusiness
processes.Thebusiness
involvementistoolittle.
Shortvs.long-term
tradeoff
Noconflictofthis
kindexperienced.
Complete
adherencetoSOA
principlesand
standards.No
pressuresfromthe
businesstodo
otherwise.
Becauseofproject-
orientation,many
heterogeneousteams
andproductswithalot
ofredundancy.The
mostimportantthingis
stilltogettheproject
done,evenifthatmeans
connectingapplications
point-to-pointinsteadof
buildingaservice.
Asmuchaspossible
out-of-the-box
solutions.As
AkzoNobelis
marketleaderin
everysector,the
needtostayontop
isn'tthatbig.Focus
onSLAs,ratherthan
technicaldetails.
Completeadherenceto
theSOAstandardswhen
applicationsarebuilt.
Buthighpressurefrom
businessleadstoITnot
beingabletobuild
everythingtheywant.
Projectswillbeputon
holdforthebusiness.
Alsoleadingtolower
qualityofservices.
CHAPTER 5. ANALYSIS
51

ComplexityIT
environment
Thneedfor
integrationof
differententerprise
systems,relatively
simple.
Notperceivedas
complex,though
themigrationofan
18y/opublishing
systemisquite
complex.
Large,with1100+
highlyheterogeneous
applications
1100+interfaces,
enormouslandscape
becauseofthesize
ofthecompany.
Different
backgroundsof
recentlymergedIT
departments.
Businessrequests
areallvery
heterogeneousand
difficulttoalign
themall.
Onebigpoint-to-point
systembefore,whichis
perceivedasadriver,
ratherthanachallenge.
KnowledgeofSOALimitedknowledge
ofSOA,following
industrypeers,
SOAperceivedas
quiteacomplex
concept/technique.
Knowledgeis
quitecomplete
whereneeded,
SOAstill
perceivedasquite
acomplex
concept/technique.
Limitedknowledge
withincompany,but
trainingsfordevelopers
havebeendone.
Followingbigger
players(IBM).
Knowledgeis
enoughforcurrent
applicationofSOA.
Followingout-of-
the-boxasmuchas
possible.
Technicalknowledge
lackswithinthe
informationmanagement
department.But
knowledgeiscomplete
whereneeded.SOAis
stillperceivedasquitea
complextechnology.
CHAPTER 5. ANALYSIS
52

ABNAMRO
Clearing
Bol.comCoolblueNationale
Nederlanden
KLM–AirFrance
SOAvisionSOAasa
philosophy,
Integration,small
components,
scalability,
businessprocess
support.
Philosophy,small
components,
businessprocess
support,reusibility,
purelytechnical,
agility.
Looselycoupling,
reusability,small
components.
Looselycoupling,small
components,philosophy,
reusability,agility,
scalability.
RoadmapNoroadmap
anymore,itis
completed.
Thereisaroadmap
forgrowing
towardsscalability
andcontinuity,to
beachievedwithin
afewyears.
Thereisaclear
roadmapwiththe
nextsystemstobe
servicised.
Theroadmapis
complete.
Thereisanexplicitroadmap
onwhichmoreknowledge
iswishedtobegainedon
thenextstepsofSOA,such
asBusinessActivity
MonitoringandComplex
EventProcessing.
Management
support
PresentPresentPresentPresentPresent
ResourcesITformsthe
biggestcostofthe
company,higher
thanbenchmarksin
thisindustry,this
investmentisso
thatstepstoward
digitizationofthe
organization.
Theorganization
hasenoughSOA
resourcesinterms
ofhumancapital
andknowledge.
Investmentsareall
justifiedthrough
businessvalues.
Coolbluedoesnot
workwithbudgets,
ifitisagoodidea
theyjustgoforit.
Intermsofhuman
resources,therelacks
knowledgeoftrue
SOAprinciplesand
standardsona
detailedlevel.
Thereisalackinhuman
resourceswhenitcomesto
organizationwide
knowledgeofSOA
principlesandstandards.
CHAPTER 5. ANALYSIS
53

ABNAMRO
Clearing
Nederlanden
KLM–AirFrance
EnvironmentHighvolume
business,with15
milliontradesand
30million
messagesaday.
Dynamic
consumermarket,
shifttomobile,
Dynamicconsumer
market,sometimes
demandsfrom
regulations.
Theorganizationis
occupiedwithcost
reductionsandstill
wantstobenumber
oneinthemarket,
thisasksforalotof
agility,operatingina
financialservice
industryalsoimposes
theneedtobe
flexibleandagileto
dobusiness.
Extremelydynamicand
complex.Forcemajeure
incidentsliketheattackson
theWTCorthecrashofthe
MH17areallthingsthat
needtoberespondedto
immediatelywhenthey
occur.Alsoregulationsfrom
countriesallovertheworld
needtobeworkedwithin
anagilemanner.
Competitorsalsofierce.
GovernanceGovernanceis
tricky,thepeople
intheorganization
disliketight
control.Wedotry
tocontrolit,but
actuallyseeing
everythingthat
happensis
impossible.The
architectureloses
itsimportance
downthe
organization.
Thearchitect
guidestheteams
intoadirection,
buttheteamsare
autonomousin
buildingwhatthey
need.They
monitortheirown
services.The
responsibilityof
thearchitecture
departmentisto
maintainthe
landscape.
Noformal
governance,peer-
review.Butthere
arestrictprinciples
tobuildingeneric
entrancepointsin
thearchitecture.
Thereisnoonewho
keepstrackofthe
adherencetotheSOA
principlesand
standardsona
detailedlevel.
Highlevelofgovernance.A
Tibco(middleware)
governanceclub,whois
responsibleforthelifecycle
management,realizationand
useofTibco.Theyalso
ensuretheorchestrationof
theservicesandoperational
andfunctionalgovernance.
Governancealsodesignsthe
principlesandstandardsto
beusedthroughoutthe
organization.Governanceis
doneonCIOlevel.
CHAPTER 5. ANALYSIS
54

ABNAMRO
Clearing
Nederlanden
KLM–AirFrance
ResultsofSOAHighreusability
andlowerTCO
fromtheESB.
Reusability.Every
projectuses
servicesandthese
areallcoupledtoa
certainbusiness
value.Basedon
theamountof
value,priorities
andprojectsare
initiated.
Developers’speed,
costreductionsin
wages,
Thereisahighlevel
ofreusibilityand
everyenterprise
applicationis
connectedthrough
services.NNisquite
matureinitsSOA,
anditisperceivedas
commongood.
Amodernwebsite,high
addedvalueinthe
commercialdomain,besides
fromonelegacysystem,
everythingisconnected
throughservices.Also
externalcouplingsaredone
throughservices,enabling
real-timecommunication.
SOAhasbeenacceptedasa
commongood.Reusability,
lowerTCO,lower
maintenancecostsareall
evident.
CultureA“quick-and-
dirty”culture,in
which
heterogeneous
applicationteams
operatewiththeir
owninterestsand
opinionsputfirst.
Thereisageneral
dislikeformaking
rolesand
responsibility
explicit.
A“stickynote”
culture,thescrum
methodologyis
employedallover
theorganization,
leadingtohigh
alignmentingoals
anddevelopment
throughscrum
teams.
CultureofCoolblue
istotryastheygo.
Mistakesaretobe
madeandlearned
from.Thedialogue
betweenbusiness
andITishighly
encouragedinan
agilemindset.This
culturehasbeen
cultivated.Keyisto
keepeverything
simpleandsmall.
Thereisahighdesire
tocustomizesoftware
asmuchaspossible
withinthecompany
andtoemployagile
working.However,
thecompanyistoo
bigandunwieldyto
employtheseinan
agilemanner.
AsKLM–AFisamerge
betweentwocompanies,
differencesinlanguageand
culturearestillcausingthe
organizationtobevery
heterogeneous.
CHAPTER 5. ANALYSIS
55

ABNAMRO
Clearing
Nederlanden
KLM–AirFrance
SOArolesAnarchitecture
layer.
Anarchitecture
department,lead
architects,
architects.
NoSOAspecific
roles
Architecturecontrols
theSOAlandscape
andtheprinciples.
Business-IT
alignment
ITispresentwithin
thebusinessunits,
whichdecreases
thebusiness-IT
distance.ITisalso
partofthe
managementand
playsaprominent
roleinthe
company’s
strategy.
Thebusiness
contributesfora
bigparttothe
architectureand
understandwhat
servicesare.
Throughtheagile
methodology,
business-and-IT
alignmentishigh.
Thereisan
architectineach
project/scrum
team.Both
businessandIT
haveenough
analytical
capabilitiesto
understandeach
other.
ITisseenas
development,rather
thancosts.The
driveisbusiness,
butthemaingoalis
tofacilitatethe
business.Roleof
businessisto
communicatethe
requirementstoIT.
Todothis,the
dialogueishighly
encouraged.Agile
methodology
facilitatestoo.The
languageused
betweenbusiness
andITis
comprehensive.
Thereisagile
methodology
employedinthe
organization,with
productownerswho
facilitatethe
communication
betweenbusinessand
IT.Businessdoesnot
seethevalueofSOA,
anditishardtoshow
themasnofinancial
valuecanbecoupled
toit.Thedistance
betweenthetwois
twobig.
Thereistightcooperation
betweenthebusinessand
IT.Therequestscomefrom
thebusiness,whothenwork
togetherwiththeproject
teamsofdevelopmentto
achievethosegoals.
CHAPTER 5. ANALYSIS
56

ABNAMRO
Clearing
Nederlanden
KLM–AirFrance
Businessprocess
control
Theorganizationis
tooapplication-
oriented,rather
thanprocess-
oriented.Alotof
valueisbelievedto
begainedfromthe
processes,butthat
isamaturitystep
thattheyneedto
take.
Everyservice
supportsabusiness
processand
belongstoa
specificbusiness
owner.The
organizationis
highlyprocess-
oriented.
Everymicroservice
capturesapartofa
businessprocess
andcanbe
combinedand
recombinedtoform
businessprocesses.
Thereisahighly
process-oriented
logicbehindit.
Thereisahighlevel
ofbusinessprocess
controlanditis
automated.Tools,
however,arenotvery
suitableandupto
standards.
Thebusinessdoesnotsee
theaddedvalueof
becomingmoreprocess-
orientedintheorganization.
Itisamatterofthemnot
wantingtoopenupfor
processredesign,asthat
makesthemvulnerableand
itcostsalotofmoney.
Shortvs.long-term
tradeoff
Veryoftenthe
short-termis
valuedoverthe
long-termbenefits
oftheorganization.
Atthispoint,
however,everyone
hasacceptedSOA
principlesand
standardsasthe
waytointegrate.
Afteratough
battle,building
servicesisfully
accepted,rather
thanbuilding
point-to-point.The
importanceofthe
architectureis
understoodand
thereforeadhered
to.Butwhenever
needed,aquick-fix
isdoneiftimeis
reservedfordoing
itrightlater.
Ifaquick-fixcan
bringalotof
businessvalue,then
itisencouraged.
But,“technical
debt”builds.
Anothermomentin
timeneedstobe
reservedtorebuild.
Manydevelopers,
stilldecideby
themselves,rather
thandiscussingit
withtheteam.
Ingranularityof
servicesiswhere
thingsgowrong.The
adherencetotrue
SOAprinciplesand
standardsis
decreasing,because
ofalackof
developers’SOA
knowledge.The
principlesusedtobe
verywelldefinedon
adetailedlevel.
Thereisafrictionbetween
pressurefromthebusiness
andtheadherencetothe
principlesandstandards.
Thoughthereisstrong
governanceimposedon
thoseconflicts,sometimes
thedecreasedquality
assuranceisanissuethat
arisesasaresultofthese
conflicts.
CHAPTER 5. ANALYSIS
57

ComplexityIT
environment
Currentlythereare
400applications
thatneedtobe
reducedto200,
eachfacilitatingfor
oneofthe38
business
componentsofthe
organization.
10million
productslive
360webshopsthat
needtobekept
running
Thereisalarge
amountof
applicationsthatare
allcoupledtogether
withtheirown
characteristics.
KnowledgeofSOAKnowledgeofSOA
iscompletethere
whereneeded.
Nolackof
knowledgeofSOA
withinthe
organization,
deeplyrooted
already.
Around5to6
peoplewho
understandthe
architecture
thoroughlythat
spreadthe
knowledge
throughoutthe
organization.
LimitedSOA
knowledge,every
juniorandevery
offshoredeveloper
buildsservices,and
veryoftenwithout
adheringtothe
principles.Butwork
isdoneforyourown
team,sothereisno
onewhokeepsall
developersincheck.
However,the
importanceiscoming
backandpeoplestart
torealizetheneedfor
itagain.
TheSOAknowledgehas
notbeenspreadenoughto
allthedevelopers.Thereare
manynewpeoplecoming
in,whoarethennotaware
oftheprinciplesand
standards.Rightnotthere
areplansforarefreshment
trainingforalldevelopers.
CHAPTER 5. ANALYSIS
58

CHAPTER 5. ANALYSIS
5.3 Explaining SOA maturity through challenges experi-
enced
Next the cross-case analysis will be performed. In this part the themes that have emerged
after coding the interviews will be presented. Each theme represents a challenge that
is experienced by at least one or all representatives of the organizations. After that, an
analysis will be drawn over the extent to which each challenge explains the SOA maturity
level of an organization.
5.3.1 SOA vision
The vision on the role of a Service-Oriented Architecture (SOA) differs greatly amongst
cases. Generally each organization sees SOA as a methodology or a philosophy in which
an IT landscape is designed in a way that small components are captured in services that
enable reusability and scalability. Peter Appel Transport is the least mature in terms of
SOA. There currently is no vision of SOA, as the organization is still busy with orienting
and deeping its knowledge on SOA.
The Belastingdienst, has a SOA vision of a concept that is purely technical. Lourens
explains: "That is one of my biggest objections against SOA, that the importance of busi-
ness involvement is coupled to it. If I were in the business, I would not want to know
anything about SOA". The respondents from AkzoNobel, NEN and Coolblue explicitly
agree with Lourens. Bol.com, however, does have the business highly involved in design-
ing services. Transavia and NN feel like the business is not involved enough, forming an
obstacle for them.
Bol.com and Coolblue both have mentioned the importance of business processes to
be supported by services. Both also underline the need for services to be built within
business process boundaries. As Victor of Coolblue explained: "when you have a process
that is responsible for the processing of orders, its service is seperate from another service
that, for instance, is responsible for the process of sending an order confirmation".
Coolblue is very firm in stating that SOA is not an enabler of business-and-IT align-
ment. All other respondents agree with this statement, saying that it is mostly the agile
methodology that some companies have employed that have promoted business-and-IT
alignment.
For ABN AMRO Clearing, Nationale Nederlanden and KLM - Air France, services
have become common good. In these companies there are no discussions about whether
SOA is valuable enough. Benefits are reaped, but sometimes forgotten, as the companies
are so used to having them.
These different views and applications of SOA within these companies do not show
a pattern according to the maturity of the organizations. It can thus be concluded that
the SOA maturity of an organization is not affected by the way that the role of SOA
is perceived. SOA seems to have a widely accepted definition to some extent, namely
the philosophy of cutting up the IT landscape into smaller components to enable agility,
reusability en loosely coupling. However, when it comes to whether or not the business
should be involved, there are different views. Companies that do not associate the impor-
tance of business involvement with the success of SOA seem to have an IT department
that is highly trusted or autonomous in what they do. There is no need for the business to
understand what they are doing exactly, as long as it works. Companies that do lack busi-
ness involvement in their current SOA practices might be more dependent on the business
59

CHAPTER 5. ANALYSIS
to make the architecture thrive. Bol.com is the only exception to this explanation, as they
have consciously chosen to keep the business involved.
5.3.2 Roadmap for SOA
Amongst all cases, only AkzoNobel has no concrete roadmap: "we don’t have that, and
that is also one of the reasons to accept this interview. Because I think it is time to start
thinking about it". Transavia, NEN, Bol.com and Coolblue are still in their transition
and so have specific steps on their roadmaps. Nationale Nederlanden and ABN AMRO
Clearing do not have a SOA specific roadmap, as their roadmaps are already complete on
the topic of SOA. The Belastingdienst has a roadmap on which only the new versions of
software need to be implemented according to the life cycle management metrics. KLM-
Air France has a roadmap on which time will be reserved to deepen knowledge into new
fields and higher layers of SOA, such as Business Activity Monitoring and Complex Event
Processing. These are SOA-enabled applications that add more value to the business by
making use of the real-time data streams that flow through the services.
Maturity can be related to the way that the SOA roadmaps look like in organizations.
The way that the SOA roadmap for an organization looks like may indicate how mature
the organization is. Organizations with a low SOA maturity level seem to be unknowing
which steps to take first and how to continue after the first step. Companies that are a
bit more mature have started thinking about what the concrete steps are to be taken next
during a transition plan. After this phase, companies either choose to settle down and stop
putting things on the SOA roadmap, or they choose to elaborate their knowledge further
to how SOA can create even more business value.
5.3.3 Top management support
Every company interviewed have indicated that top management support was present. In
most of the cases IT was trusted in how they maintain the architecture. Other companies
had to pitch SOA to management. When pitching an accompanied business case was often
said to be essential. Gert-Jan from Peter Appel explained his business case when pitching
the Enterprise Service Bus to the management: "we were sending out salaries to our 1200
employees every four weeks, these would be printed as information needed to be retrieved
from different systems. We were searching for a more efficient and cheaper way, so that is
how the ESB was first introduced". Victor from Coolblue worked with a prototype of the
catalogue service: "that prototype was beautiful and it helped me greatly to convince the
business that this would be the future of Coolblue".
Transavia, on the other hand, experiences some difficulties in convincing manage-
ment: "it is mainly because of the way that the message needs to be conveyed. A transla-
tion from IT to the business needs to be made, and that is quite difficult".
Top management support is thus widely confirmed to be one of the most important
things for a SOA implementation and adoption. Those who experience difficulties with it,
know that that is a difficulty that needs to be overcome before the SOA can thrive.
5.3.4 Nature of business environment
All respondents have indicated to be operating in a dynamic environment, in which the
need for agility is big, except for AkzoNobel and the Belastingdienst. AkzoNobel ex-
60

CHAPTER 5. ANALYSIS
plains its stable industry: "the businesses we deliver to are all quite stable, like the build-
ing and construction business, packaging industry. So there is no quick shift of business
models that impose any volatility in the environment. The focus for us is still on costs
costs costs to AkzoNobel. IT is generally not seen as an investment, rather a cost". The
Belastingdienst indicated that although there is an increasing need for integration with
other governmental bodies, the biggest need for agility must come from regulations and
laws that are often changed. However, these are even indicated long before they become
active. Though changes will need to be made to the systems, there is no real pressure
for increased developer’s speed. Peter Appel Transport does have to do with a lot of cost
cutting in its industry, however developer’s speed and agility is not core to the success of
their operations.
The dynamics of the environment in which an organization operates can thus be cor-
related to the SOA maturity level. The companies that feel least pressure from a dynamic
environment are the ones that are least mature.
5.3.5 Financial resources for SOA
When first planning to introduce SOA an allocation of resources in terms of money and
time is made. Some organizations experience a lack of time, such as NEN: "Finding the
time to implement it is quite difficult. We might have been to ambitious while planning,
leading this to get stuck right now".
In terms of financial resources a bit more challenges have been felt by the interviewed
organizations. While most of them did not mention any problems relating to funding, Ak-
zoNobel, the Belastingdienst and Transavia do experience these problems. The intervie-
wees at AkzoNobel explained: "It is a big challenge to get the project funded and to gain
investment for it. Many people underestimate the difficulty and resources needed to adopt
successfully". The Belastingdienst has to deal with the resource allocation that has been
set from top management: "about 85% of our spend goes to keeping the current architec-
ture running, while only 15% is spent on innovating in things such as SOA". Transavia
adds to the problem: "the Enterprise Service Bus (ESB) is often seen as overhead, so it is
hard to get it funded".
An explanation for why AkzoNobel and the Belastingdienst, who both have a low
level of SOA maturity, experience problems with the financial resources that are allocated
(or better yet not allocated) to the SOA could be that SOA does not play a key role in their
business strategy. Both organizations have a relatively low score on the SOA maturity,
which has been correlated to the need for agility being not as high compared to the other
cases. As the need is not as present, then the funding will also be more troublesome.
Transavia on the other hand has a relatively mature SOA score. However, as analyzed
before, Transavia has had difficulties in convincing top management because they were
experiencing challenges in translating the SOA benefits from a technical language to a
business language.
5.3.6 Governance
When it comes to governance, the cases differ a lot from eachother. AkzoNobel, for one,
does not have a good structure on governing, because there is not enough business interest
in gaining insight in the performance of the SOA yet: "It is a big challenge to get the
project funded and to gain investment for it. Many people underestimate the difficulty and
61

CHAPTER 5. ANALYSIS
resources needed to adopt successfully".
NEN and Peter Appel Transport have outsourced their governance to third parties.
Bol.com and ABN AMRO do not have a formal governance, as the cultures of the com-
panies are not very open to tight control. The culture at Bol.com towards governance was
explained to be like this: "Make sure that the product works and see what needs to be
improved. If there are some loose ends, is thay okay? If it is then leave it. This is what
makes it a bit harder in the future, though". Coolblue also has no formal governance, but
rather rely on peer-review.
Lastly, the companies that do have a strong grip on governance are NN, KLM - Air
France, Belastingdienst and Transavia.
What can be concluded from the way that governance is executed among cases is that
companies whose SOA does not play a key role in the business strategy are likely to have
no governance or have outsourced the governance. Companies that are in transition seem
to have no strong form of governance, but do realize that it will become more complex in
the future. Companies that already have established SOA since a long time ago do seem
to have a strong grip on governance. It may thus be that the companies in transition will
eventually feel an increased need for tighter governance.
5.3.7 Business-and-IT alignment
Business-and-IT alignment is quite different amongst the cases. The organizations that
have indicated to have the least business-and-IT alignment are Transavia, AkzoNobel and
Peter Appel Transport. Though Peter Appel is currently working on gaining insight in
what the business actually wants, Transavia and AkzoNobel have been struggling with
this challenge for quite some time now. The men of AkzoNobel explain: "there is quite
a gap between the IM (information management) organization and the business itself.
Because of the way that we were seen. As we centralized, we created even more distance.
IM used to be part of the business and now they are just one big central department". As
discussed during the within-case analysis, Transavia deals with the problem of the lack
of technological knowledge of the information managers, who are supposed to make the
translation of business needs to IT requirements.
Coolblue and NEN have both fostered a culture in which business and IT are encour-
aged to start the dialogue informally. Whereas at ABN AMRO the IT is integral to the
business teams: "we think it is important for the people that are going to do the job sit
together, so that there is a high level op control on what is happening".
The Belastingdienst, Bol.com, NN and KLM - Air France mostly owe their business-
and-IT alignment to the agile methodology that their organizations employ. Product own-
ers form the messenger between business needs and IT requirements and business works
closely with developers to achieve goals.
Transavia and AkzoNobel seem to have the least business-and-IT alginment, which in
turn explains why it is a difﬁcult challenge for them to get funding for the implementation
of SOA.
As all but two cases seem to have different mechanisms to foster business-and-IT
alignment, no conclusion can be drawn towards the SOA maturity of each company. The
two companies who seem to lack business-and-IT alignment ﬁnd themselves in different
maturity levels.
62

CHAPTER 5. ANALYSIS
5.3.8 Organizational commitment to SOA
Organizational commitment has been unanimously agreed on by all interviewees to be
dependent on how SOA is communicated to the rest of the organization. For the business
to see the added value of the architecture, a business value needs to be coupled to it.
Bol.com said: "by coupling scalability to the non-functionals, that is when the business
sees the benefits too. The translation for the business is indeed very important to increase
the awareness of the architecture".
Bol.com, Coolblue, NEN and ABN AMRO seem to have organizational commitment
on from the business because they are either trusted in the way that they do architecture,
or a lot of time and attention has been given to it. Coolblue: "Communication towards
the business and IT is very important. ’why do we do this?’ and keep repeating it until
everyone is sick and tired of hearing it, and then tell it another time".
KLM and Nationale Nederlanden have put a lot of effort into conveying the message
throughout the organization. Diverse trainings have been given in the beginning, but due
to a high level of employee turnovers due to outsourcing projects and internal dynamics
the level of SOA knowledge is hard to maintain.
Peter Appel Transport is not in stage in which communicating the SOA philosophy
to the rest of the organization is important yet. AkzoNobel and Transavia, however, do
feel the need, but experience trouble communicating it to the business. AkzoNobel also
doubts the need to which it is necessary: "How far do we go in promoting the concept or
philosophy to the need of just delivering? In the end were providing them the agility and
processes, so what does it matter?" Transavia struggles with the lack of knowledge of the
information managers on this matter as well: "How can an information manager tell the
business that there is this tool, if he or she does not know what that piece of technology
does?"
Another important factor for the successful organizational commitment to SOA is the
extent to which the organization outweighs long-term benefits over short-term benefits.
Companies in which the interest of the projects or the business weigh stronger than the
sustainability of the IT landscape are likely to surpass the SOA principles and standards.
Lourens from the Belastingdienst explains their situation: "As long as IT keeps accepting
one on one assignments that come from the projects, then the importance of SOA will never
come through". Building a service takes longer than quick-fixing a connection. Adhering
to building a service as a solution always means that the long-term benefit is chosen, as
Mirjam from KLM-AF says: "projects are per definition finite and the organization isn’t".
In this trade-off, the culture plays an important role. ABN AMRO Clearing, for in-
stance, has a culture in which the quick-and-dirty solutions are often chosen, which makes
it hard to find a balance for SOA. AkzoNobel has a culture in which both business and
IT are internally fragmented, leading to heterogeneous wishes and interest in which the
business, and thus the short term benefits, are leading. The Belastingdienst recognizes the
difficulty to push through a fundamental change within the organization, which challenges
the current SOA implementation and adoption. NEN, Coolblue and Bol.com foster a cul-
ture in which mistakes are to be made and learned from and in which the business-and-IT
alignment is well organized, leading to the importance of services, and thus the long-term
benefit, to be well-understood throughout the companies.
The organizational commitment is lowest at Peter Appel Transport and the Belast-
ingdienst, as they are both not in a stage in which the adoption of SOA affects more
departments aside from the IT department. AkzoNobel and Transavia have not achieved
organization-wide commitment, mainly because communicating the SOA tot the business
63

CHAPTER 5. ANALYSIS
poses a challenge for them. ABN AMRO Clearing and NEN are both trusted by the orga-
nization in what they do, so no real need for business involvement in the way that SOA is
executed is needed in these organizations. Bol.com and Coolblue actively communicate
the SOA/microservices philosophy to both the IT and business. Lastly, NN and KLM-
Air France are also trusted in what they do and they have a lot of experience in it. They
indicate themselves, however, that the commitment is not complete yet.
When analyzing these results, a relationship between organizational commitment and
maturity can be found. Organizations where commitment is lowest seem to be those where
SOA does not play a key role in the company’s strategy (Peter Appel, Belastingdienst,
AkzoNobel). Organizations where there is no need for business awareness of SOA are
those in which the IT is trusted in the way that they execute SOA, as long as they make
sure that it works (NEN, ABN AMRO Clearing). For these companies, working with a
SOA is inherent to the functioning of the organization as a whole. Companies where the
need for agility, and thus the need for a service-oriented architecture, is high, the business
is highly involved in the commitment to the philosophy (Bol.com, Coolblue). For these
companies it is crucial to maintain an agile architecture to survive, therefore more time
and effort is put into making sure that organization-wide commitment is achieved. Lastly,
the organizations that have been working with a SOA for many years now are also trusted
in what they do (KLM, NN). To perform even better, however, these organizations see the
need to increase the level of SOA knowledge within the company even further.
The only exception in this explanation is Transavia. Though their perceived need for
agility is high, there seems to be a big lack of business involvement and interest in SOA.
This can either be explained through the aforementioned lack of SOA knowledge of infor-
mation managers that form a challenge to communicate SOA to the business, or because
the need for business involvement is overestimated by the organization. In this company
the integration has been completed and a high level of reusability is achieved, along with
the lower total costs of ownership and maintenance costs, just like at NEN and ABN
AMRO Clearing. During the interview this explanation is proved as the business has no
interest in the way that the IT department offers solutions: "The business does not invest
in an Enterprise Service Bus (ESB), but rather in a solution to their problems".
5.3.9 Tangible results of SOA
The nature of the results of a Service-Oriented Architecture (SOA) are highly intangible.
When asking the respondents how they explain the beneﬁts of SOA, two themes arose:
The importance of a business value and taking small steps in the implementation of SOA.
Coupling a tangible business value to a SOA project is important to make quantify the
results of SOA. At AkzoNobel, Thomas gave an example: "in my case, I have got around
45 3PL connected to the system. The smaller ones are annually half a million in savings,
the bigger ones are annually a million plus in savings. So just from that 45, I can quantify
that and people can see from my contract value the added value for having that in place."
As explained during the within-case analysis, Bol.com sorts and prioritizes SOA projects
according to business value added. The forecasting module, for instance, was one of the
ﬁrst SOA projects as most business value could be retrieved in terms of lower inventory
costs and higher availability of products.
Implementing SOA step-by-step is another important theme mentioned by the inter-
viewees when it comes to the results of SOA. Victor of Coolblue states: "I would never try
to sell services as an enormous project, rather a step-by-step transition towards services".
64

CHAPTER 5. ANALYSIS
This makes the impact smaller, which in turn enables you to know where exactly things
went wrong and how to learn from it. Victor continues: "We often hear at big companies
that a big-bang project is needed so that most of the organization can be taken along with
it. this is done so that the discussion does not need to take place another time to pitch it on
management level. But that is more of a political matter". Transavia agrees that the step-
by-step approach is the way to implement SOA: "you start by integrating applications to
each other through the Enterprise Service Bus (ESB), so that you work in a structured
manner. The next step would be implementing generic services". Bol.com underlines the
need for a step-by-step approach: "you can’t possibly close the store for three years to
move towards a new architecture, so we do it step-by-step".
Being able to couple business value to SOA projects and implementing the architec-
ture in a step-by-step manner are thus important indicators for a successful SOA imple-
mentation and adoption.
5.3.10 Control over business processes
A Service-Oriented Architecture (SOA) is supposed to enable business process manage-
ment and redesign using smaller components of IT assets, or services. The extent to which
an organization actually has insight over its business processes therefore determines to
what extent SOA enabled business process management and redesign can be achieved.
However, challenges are felt by every company that has been interviewed on this matter.
KLM-Air France, ABN AMRO Clearing, AkzoNobel and Transavia do not have au-
tomated business process management and no real insight and control over the organi-
zations’ businesss processes. AkzoNobel explains that the lack of standardized metrics
already form a large complexity to enable business process management: "For instance
within the Supply Chain Management there are 20 different ways of calculating the OTIF
(on time in full), so you can imagine that the rest of the business process cannot be aligned
if the metrics aren’t even the same". ABN AMRO Clearing and KLM-Air France both lack
the process-orientation within its organization. Patrick of ABN AMRO comments: "In
the organization people are often too application-oriented, rather than process-oriented.
Which is a shame, because the real value can be found in the business processes".KLM-
Air France says that the culture blocks the control over business processes: "There is a
big amount of complexity in our company. When redesigning business processes, people
will need to open up the gates to their territories. People do not like this vulnerability. So
the business does not see the added value".
Within the Belastingdienst and NN there is automated business process management.
NN, however, is in search of a better tool as currently the business process management is
not performed at a quality level as desired. At the Belastingdienst has implemented auto-
mated business process management at the national collection department, with hundreds
of end users: "we see a strong growth in business process management, and the need for
SOA grows along with it".
Peter Appel and NEN are both busy with deﬁning business processes and data mod-
els. Peter Appel has sent out questionnaires to its employees so that processes can be
optimized according to the wishes of the end users. At NEN currently the processes of the
publishing department are being redesigned.
Lastly, Bol.com and Coolblue both see the whole idea of services to be facilitating
business processes. There is thus an inherent control over the business processes when
implementing the services. Victor of Coolblue explains: "for us a microservice is a service
65

CHAPTER 5. ANALYSIS
that has been brought back to the essence of its task. For instance, the handling of an
order". Bol.com adds: "The moment that you are not developing services to facilitate your
businesss processes, you’re doing something wrong. In general we have good business
processes that are supported by services".
The importance of control over business processes perceived differs per organization
and its culture. From these results, no clear relationship can be found between the lack of
business process control and SOA maturity. It can be concluded though that the companies
that are in the biggest need of business processes to be designed easily and quickly, such
as Bol.com and Coolblue, have processes well-facilitated by services.
5.3.11 Definition of SOA principles and standards
Service-Oriented Architecture (SOA) requires standards and principles when it comes
to building services and governing services to be successful. Out of the interviewees,
many have said to experience challenges on these standards and principles. Designing
services can be quite difficult. ABN AMRO says that one of the main challenges that
they experience is making too detailed services: "this increases the complexity". Bol.com
brought forward the same problem: "on one hand we want to keep services as generic as
possible, but on the other hand we want to give the teams the freedom to design their own
services. Very often there is also a lack of how a service is supposed to be built". KLM-
Air France adds to this discussion: "asking yourself ’what is a good SOA service?’, ’how
do we build that’ and ’what does that service look like?’. The capability to answer these
questions often lacks, even in really good architects, because there are so many different
wishes from different stakeholders". Nationale Nederlanden experiences these problems
on a different level. They already have good principles and standards in place, but they
are still not detailed enough.
This challenge has only been mentioned by organizations that find themselves in
higher maturity levels. It can, though in need of more research, be concluded that facing
the challenge of service design happens only to organizations that have reached a maturity
level in which SOA expands to several departments. In this stage the standardization of
data and resources becomes increasingly important.
5.3.12 SOA knowledge
The amount and level of knowledge of Service-Oriented Architecture (SOA), its princi-
ples, premises and its execution, are crucial indicators for a successful SOA implementa-
tion and adoption.
In companies where SOA has not spread further than the IT department yet, SOA
knowledge is limited. Peter Appel has just started investing time to learn about SOA.
Within the Belastingdienst, only 5% of the IT landscape is SOA, which means that no high
level of SOA knowledge is required. AkzoNobel mainly follows out-of-the box solutions,
so no detailed level of SOA knowledge is required either.
In the organizations where architecture teams are trusted in what they do, the level
of SOA knowledge is as high as it needs to be. Patrick from ABN AMRO Clearing said:
"we do innovation in only one manner and we have a team that is highly skilled". NEN
has a team of 8 working that works with SOA, amongst these people SOA knowledge is
complete enough.
66

CHAPTER 5. ANALYSIS
In Bol.com and Coolblue a lot of time is spent on spreading the SOA knowledge. Vic-
tor from Coolblue, for instance, has 5 other colleagues who understand the microservices
philosophy as thoroughly as he does and together they spread the knowledge to the other
developers through presentations and informal conversations.
Within KLM-Air France, NN and Transavia there is enough SOA knowledge to keep
the architecture up, however these companies do experience a lack of SOA knowledge
in some areas. Jeroen from NN recognizes the lack of knowledge amongst management
as well as developers: "The awareness of management, while being in charge of making
important decisions, of what SOA means in detail, the knowledge of the developer in how
to build services within the SOA principles and standards and the constant change in
people coming in who do not understand, all contribute to the lack of SOA knowledge
within NN". As discussed within the within-case analysis, KLM-Air France had invested
in half a year of trainings for developers to get their SOA knowledge up to level. However,
not all developers did this training and the high turnover rates of developers constantly
brings in new employees who are not aware of the organization’s SOA principles and
standards.
The perception of the lack of SOA knowledge within an organization can be concluded
to be correlated to which role SOA plays within an organization an thus its maturity.
Again, organizations whose business strategies do not rely on the architecture are likely
to have little SOA knowledge in-house. The level of SOA knowledge is dependent on the
interests of the people within the IT departments. Companies in which the IT department
is trusted in the way that they design the architecture and in which this architecture plays
a crucial role in the operations of the organization tend to have the SOA knowledge at a
high enough level and is complete among all developers. Organizations where the SOA is
crucial to the existence of the organization by offering agility and developer’s speed that
match up with the speed at which business wishes need to be realized, tend to put a lot
more effort and time in spreading the SOA knowledge until it reaches a high enough level.
Lastly, organizations that have been having SOA for a long time already, usually have a
high level of SOA knowledge to keep the architecture well-run and able to facilitate the
business’ wishes. When these companies talk about the lack of SOA knowledge, it is
mainly on a detailed level of SOA principles and standards, rather than the philosophy
and the beneﬁts to be reaped with SOA.
5.3.13 Additional strengtheners of SOA
Aside from the challenges that were put forward by the literature already, some new in-
sights can be retrieved from this research. Though there is not enough grounded evidence,
these are themes and lessons learned that can be further researched in the future. These
themes are: the role of agile working methodology within an organization, the removal of
obstacles before starting the implementation of SOA and the need for theoretical knowl-
edge of SOA.
Agile methodology
In most of the organizations that have been interviewed, an agile working methodology
is employed throughout the organizations. Methodologies like Scrum, Kanban and SAFe
have been mentioned to be used. These methodologies share the philosophy of that of
Service-Oriented Architecture, namely keeping things small and working in small steps
67

CHAPTER 5. ANALYSIS
so that results can be achieved without waste. Agile methodology encourages business-
and-IT alignment, as the people from both the business and IT are involved in reaching
business goals. Lourens from the Belastingdienst says: "The benefit of agile is that a
goal-oriented way of working is employed, which increases speed. I think that agile is
an accelerator for the success of SOA". As came forward in the within-case analysis,
Bol.com has allocated services to specific scrum-teams in specific domains. Each scrum-
team is responsible for a certain service within the boundaries of their domains, such as
supply chain management. Martin comments: "SOA is an implementation that is done
best in smaller teams in smaller steps, so scrum and SOA fit seamlessly". Though Jeroen
thinks that the agile methodology employed by NN is not done completely right, he says:
"I think agile strengthens SOA, but I think you will need more resources in agile than
NN currently has to do it successfully". Lastly, Coolblue also agreed on the positive re-
lationship between scrum/agile and SOA: "Keeping things as small as possible makes
everything a lot easier. This is why SOA fits well with the Scrum/Agile methodology".
Removing obstacles
Removing obstacles is a theme that has explicitly been mentioned by NEN and Coolblue.
Both organizations have dealt with complexity by taking it away as much as possible.
Sjoerd of NEN has taken away complexity from the beginning of the SOA migration by
agreeing with the main stakeholders that things will be kept as simple and as standard
as possible during the implementation. Coolblue’s Victor says: "take every obstacle for
success away. That sounds very logical, but what I mean with that is that developers
have to be put in an environment in which they can do their thing to build services. It is
human nature to always choose road with least resistance. As soon as there is a road with
less resistance, they are likely to choose this path". Within Coolblue this is achieved by
facilitating workshops, instruction videos and other means so that the gap in knowledge
becomes as small as possible. Not only does this improve the quality of the developing
process, but also in commitment of the developers as they will only be confronted with
problems that they don’t already know. Transavia regrets that this was not done before
they started their implementation: "We did not have the time to prepare everything neatly
before we started the SOA implementation. This has led to problems, chaos and a bad
name".
Academic SOA knowledge
Lastly, the importance of academic SOA knowledge before starting the implementation
of SOA has been highlighted by Mirjam from KLM-Air France. Of the companies inter-
viewed, this organization is most mature and Mirjam mentions a certain level of academic
SOA knowledge as one of the success factors. This was not mentioned by any of the other
organizations. KLM-Air France had initiated a four-year program in which knowledge
and thorough research was done to how the Service-Oriented Architecture was going to
help the organization in improving their IT landscape. Mirjam says: "If there is no aca-
demic value, then solutions will be chosen which may work quickly, but may be hard to
maintain. A dirty fix is a hassle forever".
68

Chapter 6
Main findings, Discussion, Limitations
& Conclusion
6.1 Main findings
6.1.1 Research aim: defining SOA maturity
The first aim of this study was to answer the question of how to measure Service-Oriented
Architecture (SOA) maturity in such a way that the application of SOA throughout the or-
ganization and the way that the architecture is perceived and received by key stakeholders
are key measurements. This answer was found in the maturity model of Mircea and An-
dreescu (2012), with additions of part of the models of OpenGroup (2013), Hirschheim,
Welke, and Schwarz (2010) and Sonic Software Corp. (2005) (Chapter 3). This model en-
tails 6 stages of SOA maturity and each of the cases have been assigned a maturity level
according to this model.
It is important to note that this research did not use the maturity model as a strict divi-
sion of maturity levels, but rather as a means to rank the organizations that were studied.
To explain each individual SOA maturity stage according to the model was not possible,
as not enough data was available to evaluate each organization accordingly. Also doing
this is beyond the scope of this study. As the organizations have been ranked according
to the maturity model, challenges could be explained along the continuum of the maturity
levels of the organizations studied.
Each organization has been evaluated on its SOA maturity level through a within-case
analysis. The analysis found that no evident relationship between maturity and sectors
was present among the cases. The organizations in the online-retail sector, however, do
seem to have a close match, which can be explained through their similar need of high
business agility to compete with each other.
6.1.2 Research aim: identifying SOA challenges
The second research question related to how to identify Service-Oriented Architecture
(SOA) challenges within organizations. This question has been answered by the extensive
literature review (Chapter 3) in which previous studies have been summarized to form
a collection of most experienced challenges by SOA adopters. To find a way to iden-
tify these challenges, three levels of analysis were introduced, namely: enterprise level,
business level and technical level.
69

CHAPTER 6. MAIN FINDINGS, DISCUSSION, LIMITATIONS & CONCLUSION
This structure guided the semi-structured interviews and formed the theoretical frame-
work for the rest of the study. By drawing conclusions over the responses of the intervie-
wees about how these challenges were experienced, the propositions that came forth from
the theoretical framework were tested. An overview of the propositions can be found in
table 4.2.
6.1.3 Research aim: explaining maturity through challenges
The third research aim brought both previous research aims together. The question was
related to how the challenges that have been identified at the ten organizations can explain
their assigned maturity rank compared to each other.
As can be seen all challenges experienced by the organizations could be related to
the maturity position of the organizations with respect to each other, except for four chal-
lenges: the lack of SOA vision (Proposition 1), the underestimation of financial resources
needed (Proposition 4), the lack of business-and-IT alignment (Proposition 9) and the lack
of business process control (Proposition 10). There where no relation was found within
this sample, explanations have been sought for. In table 6.1 the main findings are summa-
rized.
70

Table 6.1: Results: explaining SOA maturity through challenges
Challenge Proposition/Support Explanation
SOA vision P1: Not supported Companies in which the IT/architecture
department is highly empowered and
trusted in what they do there is little
business involvement in the SOA vision.
Companies where the IT/architecture de-
partment is dependent on resource alloca-
tions of the business do see business in-
volvement in their SOA vision.
Roadmap P2: Supported Immature organizations have no clue
what to do next, more mature companies
have concrete steps defined in SOA tran-
sition plan, and mature organizations have
either completed the SOA roadmap or de-
cide to invest in gaining more knowledge
for adding business value.
Top man. support P3: Supported Unanimously defined as an important
success factor by all companies.
Financial resources P4: Not Supported No problems with unexpected costs. But
relationship found in financial resources
allocation across maturity levels. Compa-
nies with low maturity level has problems
with the funding, as SOA is not perceived
as a key component of business strategy
of the companies. Other companies do
value SOA as a crucial part of their ex-
istence and thus experience no problems
with raising funds for SOA.
Business environment P5: Supported Organizations that find themselves in
business environments where the need for
agility is low are less mature.
Governance P6: Supported Governance becomes tighter and better
organized as company becomes more ma-
ture in its SOA.
Tangible results P7: Supported Assigning a business value and taking
a step-by-step approach in implementing
SOA is experienced by organizations to
be important ways to make SOA results
tangible and gaining more organizational
commitment, which leads to an increase
in SOA maturity.
71

Org. commitment P8: Supported Organizational commitment is lowest in
the organizations that are least mature
and whose business strategy does not in-
clude SOA as a crucial component. In or-
ganizations that are more mature, where
SOA is seen as crucial for the organi-
zation and where the IT/architecture de-
partment is trusted in what they do, there
is commitment from all key stakehold-
ers. In organizations that are dependent
on SOA to stay competitively strong and
agile a lot of effort is put in to gain-
ing organizational-wide commitment and
awareness. Organizations that are most
mature in this study see SOA as a com-
mon good and have achieved organiza-
tional commitment a long time ago.
Business-IT alignment P9: Not supported No relationship found between the
business-and-IT alignment of organi-
zations to their SOA maturity. Most
organizations have a good business-and-
IT alignment, achieved through different
methods, except for two companies.
These companies, however, do not ﬁnd
themselves close to each other in their
SOA maturity.
Bus. processes control P10: Not supported This seems to be a challenge that is expe-
rienced across all maturity levels. How-
ever, organizations that are in need of
agility most to survive in their business
environments have the highest levels of
business process control.
SOA principles/standards P11: Supported This challenge was only experienced by
organizations of higher maturity levels
(from stage 3 on). This can be explained
because these organizations have reached
a maturity in which standardization be-
comes more important.
72

SOA knowledge P12: Supported Organizations where SOA does not play a
key role in the organization’s strategy of-
ten have little SOA knowledge in-house.
Organizations that are highly trusted in
what they do, have a high level of SOA
knowledge for only the key stakeholders
as the rest of the organization does not
need to know. Companies where SOA is
crucial to the organization’s agility are
still putting a lot of effort to spread SOA
knowledge. As a larger part of the en-
terprise needs to become aware, it takes
them longer. Lastly, organizations where
SOA already has become a common
good, the lack of SOA knowledge is only
found on highly technical details of the ar-
chitecture.
Agile methodology SOA strengthener Agile methodology and SOA both share
the same philosophy of cutting things up
into smaller components to achieve more
goal-oriented and tangible results. Agile
has been identified as an accelerator of
SOA.
Removing obstacles SOA strengthener Removing obstacles before starting a
SOA implementation is identified as an
important thing to do. This allows people
to only face problems that they do not al-
ready know and it keeps them motivated
and committed.
Academic SOA knowledge SOA strengthener The most mature organization inter-
viewed brought the importance of a cer-
tain amount of academic SOA knowl-
edge for a successful SOA implementa-
tion and adoption. This prevents an orga-
nization from building sub-optimal solu-
tions to problems.
6.2 Discussion
6.2.1 Unsupported propositions
MacLennan and Van Belle (2014) and Birekul and Dogerliogl (2011) put forward the
lack of a SOA vision as one of the main challenges of SOA implementation and adoption.
This, however, was not an evident challenge in this study. The vision on SOA differed
highly across the organizations across different SOA maturity levels. It did become evi-
dent that the role that the IT/architecture department plays within the organization, either
trusted and empowered or dependent on business decisions, influences the way that SOA
73

is viewed in each organization.
Choi, Nazareth, and Jain (2010), Birekul and Dogerliogl (2011), Koumaditis, Themis-
tocleous, and Rupino Da Cunha (2013), Galinium and Shahbaz (2012) and MacLennan
and Van Belle (2014) emphasized the importance of budgeting the financial resources
needed for the implementation of a SOA and the adoption to it. According to these re-
searchers, the underestimation of costs led to an unsuccessful or incomplete SOA imple-
mentation. However, this was not a challenge that came forward in the experiences of the
interviewees. This can be explained by the fact that the companies that were interviewed
were in high need of the architecture to operate as a company, so no underestimation of the
budget that needed to be made available was present. However, companies in the lower
range of the maturity model did experience problems with raising funds for their SOA
projects. But this had more to do with the minor importance of SOA in the organizational
strategies.
Another challenge that was brought forward by previous literature is the lack of
business-and-IT alignment within an organization. Krafzig, Banke, and Slama (2005),
Mircea and Andreescu (2012), Linthicum (2007) and Emadi and Hanza (2013) empha-
size the importance of the involvement of business stakeholders with the IT stakeholders
to align the IT strategy with business goals and strategies. This challenge however was not
experienced by organizations in such a way that a clear relationship could be found be-
tween the business-and-IT alignment of the organization and its maturity level. All organi-
zations have relatively high levels of business-and-IT alignment, which are often achieved
through other methodologies such as agile or an organizational structure in which project
teams have both business and IT people tightly working together. The two organizations
that did not have a high level of business-and-IT alignment found themselves in maturity
levels that were not close to each other. This proposition was thus not supported by the
results.
The last challenge, that was included in the challenges identification model but was
not supported by the results, relates to the level of control over business processes within
an organization. Mircea and Andreescu (2012) and Oliveira et al. (2012) underlined the
importance of business models and business process definitions to build well designed
services. Control over business processes eases the alignment of services with business
requirements and the relationships among the processes. However, the results show no
clear relationship between the control over business processes and the maturity level of
each organization. The control over business processes seems to be a challenge that is
experienced along the entire maturity continuum of the organizations interviewed. The
organizations that have most control over their business processes are those whose com-
pany is unable to survive without the agility that SOA brings, but no line can be traced
back to the maturity levels.
6.2.2 Supported propositions
Aside from these unsupported propositions, all other propositions were supported by
the results from the ten organizations interviewed. On enterprise level, the importance
of a roadmap ((Lee, Shim, and Kim, 2010), (Koumaditis, Themistocleous, and Rupino
Da Cunha, 2013)), top management support ((Feig, 2007), (MacLennan and Van Belle,
2014), (Birekul and Dogerliogl, 2011)), a suitable business environment ((Choi, Nazareth,
and Jain, 2010), (Birekul and Dogerliogl, 2011), (MacLennan and Van Belle, 2014)) and
governance ((Koumaditis, Themistocleous, and Rupino Da Cunha, 2013), (MacLennan
74

and Van Belle, 2014), (Birekul and Dogerliogl, 2011)) were all indeed perceived as chal-
lenges that have been experienced by the organizations interviewed and affected their
SOA maturity differently.
On business level, the lack of tangible results of SOA ((Koumaditis, Themistocleous,
and Rupino Da Cunha, 2013), (McKenzie, 2006), (Beack, 2006), (Ricadela, 2006), (Conz,
2007)) and the level of organizational commitment ((Birekul and Dogerliogl, 2011)) were
perceived as challenges by the interviewed organizations. When analyzing the responses,
these can be correlated to the SOA maturity level of the organizations.
Lastly, on technical level the definition of effective and strict SOA principles and
standards ((Choi, Nazareth, and Jain, 2010)) and the lack of SOA knowledge within the
organization ((Birekul and Dogerliogl, 2011)) were also challenges that came back in
the responses of the interviewees. These challenges explain the level of maturity each
organization is in.
Most of the propositions were thus supported. The range of SOA maturity levels can
be explained through the way that these challenges were experienced by the companies.
Though they are not able to predict which exact maturity level an organization finds itself
in according to the experience of the challenge, they do give an insight in how maturity
levels differ along these challenges. In table 6.1 each proposition topic and whether or not
it was supported by the results of this study has been displayed.
6.3 Limitations & Future research
This research lays a foundation to explaining maturity levels through the challenges that
Service-Oriented Architecture (SOA) adopters experienced.
For this research a sample size of ten organizations was used. Though they are all big
and influential companies in The Netherlands, they do not necessarily represent the wider
population. Inherent to a multiple-case study design, the generalizations made are never
backed up by enough data to draw conclusions over how every SOA adopter’s maturity
level can be explained through the challenges it experiences.
Researcher and respondent bias is a limitation of this study. Interviews were conducted
by one person which limits the extent to which the extent to which objective interpreta-
tion of the responses. The researcher is inexperienced in interviewing and did not always
succeed to refrain from influencing the topics discussed through follow-up questions. The
interpretation and discussion were completely written through the analytic eye of the re-
searcher, leading to an increased chance of researcher bias. Though the determination
of the SOA maturity level per organization was done together with another SOA expert,
most of the coding was done by the researcher and no opportunity arose to get the codes
checked by multiple coders. Per interview, often one, sometimes two, representatives were
interviewed. The extent to which objective and bias-free information is given is another
important limitation of this research methodology.
Overall, the multiple-case study was a suitable fit for this research as the experiences
of respondents were searched for. Answering the ’how’ and ’why’ questions allowed this
research to be set up in the way that it is. This methodology allowed this research to build
further on solid models from previous literature to find new relationships and explana-
tions.
These first findings should be seen as a basis upon which further research can be
conducted. Differences across countries or industries could be studied.
75

This research has reached its goal in explaining SOA maturity levels of organizations
through the challenges experienced by SOA adopters. However, this research is hardly
as detailed as this topic can be. Though the organizations studied could be ranked in
their SOA maturity levels through the maturity model, the actual SOA maturity of an
organization needs a more elaborate model to be determined. This research has merely
identified the correlations between the SOA challenges and SOA maturity on a high-level.
Now that the results have shown that these correlations are indeed present, an opportunity
for further research would thus be to explain a maturity model on all its aspects, both
technical and organization-wide, through the challenges experienced by organizations.
There is a great need for organizations who have adopted a SOA for research towards
the challenges and how they can grow further. As each interview took somewhere be-
tween one hour to two hours, the scope of interest turned out to be a lot bigger than
this research was aiming for. More information has been collected than has actually been
used. This is partly because the researcher is not familiar with the technical kind of in-
formation provided by the respondents or because it was too far off the research aims.
Ample opportunities to research organizations who operate in The Netherlands and how
they experience challenges on different levels of analysis than this research exists.
Lastly, three additional strengtheners of SOA came forward in the results, but were
not taken into account when designing the theoretical framework. These areas are agile
methodology, removing obstacles before SOA implementation and the importance of an
academic level of SOA knowledge. These are areas that can be researched further and
which may form an extension to the current research.
6.4 Conclusion
In this research the Service-Oriented Architecture (SOA) maturity has been explained
through challenges that SOA adopters have experienced in their implementation and adop-
tion to the architecture. For this research, representatives of ten large and influential orga-
nizations that operate in The Netherlands have been interviewed. A maturity model has
been found to use as a means to rank the interviewed organizations in terms of their SOA
maturity (research question 1).
To find a way to identify challenges within organizations related to SOA (Research
question 2), a model has been defined in which the challenges that have been described
by previous literature are divided into three levels of analysis, namely: enterprise level,
business level and technical level.
Once both the maturity level and the identification model for SOA challenges had been
defined, the challenges have been analyzed to find correlations with the SOA maturity
levels of the organizations (Research question 3).
The analysis found that no evident relationship between maturity and sectors was
present among the cases. The organizations in the online-retail sector, however, do seem
to have a close match, which can be explained through their similar need of high business
agility to compete with each other.
Main findings of this research are that out of twelve areas of challenges, the impor-
tance of the presence of a SOA roadmap, top management support, a suitable environ-
ment, SOA governance, tangible results of SOA, enough SOA knowledge, organizational
commitment to SOA, and effective and strict definition of SOA principles and standards
are all found to be able to explain the distribution of the SOA maturity levels across the
organizations interviewed.
76

The importance of a SOA vision, well-budgeting the financial resources for SOA,
business-and-IT alignment and control over business processes, though proposed by pre-
vious literature, do not show any relationship to the SOA maturity levels of the organiza-
tions.
These findings form the final product of this research: an explanation of SOA maturity
levels through the challenges experienced by SOA adopters.
77

Bibliography
Baxter, Pamela and Susan Jack (2008). “Qualitative case study methodology: Study de-
sign and implementation for novice researchers”. In: The qualitative report 13.4,
pp. 544–559.
Beack, Theo (2006). “Service Oriented Architecture: Six steps to a successful SOA”. In:
CIO Canada 14.9, p. 1.
Birekul, Ihsan and Ozgur Dogerliogl (2011). “Impacts of Service-Oriented Architecture
Transformation on Organizational Structures”. In: Journal of Applied Sciences 11,
pp. 2791–2799.
Campbell, Rebecca et al. (1999). “Community services for rape survivors: enhancing psy-
chological well-being or increasing trauma?” In: Journal of consulting and clinical
psychology 67.6, p. 847.
Choi, Jae, Derek L Nazareth, and Hemant K Jain (2010). “Implementing service-oriented
architecture in organizations”. In: Journal of Management Information Systems 26.4,
pp. 253–286.
Conz, Nathan (2007). “SOA: Starting Small, Thinking Big – As more insurers embrace
service-oriented architecture to create the building blocks of business value, best prac-
tices regarding implementation and organization are emerging”. In: Insurance Tech-
nology 32.7, pp. 39–44.
Devi, C Punitha et al. (2014). “A Model for Information Integration Using Service Ori-
ented Architecture”. In: International Journal of Information Engineering and Elec-
tronic Business (IJIEEB) 6.3, p. 34.
Eisenhardt, Kathleen M (1989). “Building theories from case study research”. In: Academy
of management review 14.4, pp. 532–550.
Emadi, Sima and Raziye Hatami Hanza (2013). “Critical Factors in the Effective of
Service-Oriented Architecture”. In: Advances in Computer Science: an International
Journal 2.3, pp. 26–30.
Feig, N (2007). “Foundation for Transformation: Implementing a Successful Service-
Oriented Architecture Starts with Making the Right Decisions Early in the Process”.
In: Wall Street and Technology, May, p. 32.
Galinium, Maulahikmah and Negar Shahbaz (2012). “Success factors model: Case studies
in the migration of legacy systems to Service Oriented Architecture”. In: Computer
Science and Software Engineering (JCSSE), 2012 International Joint Conference on.
IEEE, pp. 236–241.
Haki, Mohammad Kazem and Maia Wentland Forte (2010). “Inter-Organizational Infor-
mation System Architecture: A Service-Oriented Approach”. In: Collaborative Net-
works for a Sustainable World. Springer, pp. 642–652.
Heur, van Rian (2009). Tibco: SOA is een modewoord. URL: http://www.computable.
nl/artikel/achtergrond/architectuur/2863518/2204519/tibco-
soa-is-een-modewoord.html#ixzz3hldssgHe (visited on 08/04/2015).
78

BIBLIOGRAPHY
Hirschheim, Rudy, Richard Welke, and Andrew Schwarz (2010). “Service-oriented ar-
chitecture: Myths, realities, and a maturity model”. In: MIS Quarterly Executive 9.1,
pp. 37–48.
Hulsman, Sander (2010). Beleid opstellen rondom SOA. URL: http://www.computable.
nl/artikel/achtergrond/architectuur/3514570/2204519/beleid-
opstellen-rondom-soa.html#ixzz3hlebCHQn (visited on 08/04/2015).
Kontogiannis, Kostas, Grace A Lewis, and Dennis B Smith (2008). “A research agenda
for service-oriented architecture”. In: Proceedings of the 2nd international workshop
on Systems development in SOA environments. ACM, pp. 1–6.
Koumaditis, Konstantinos, Marinos Themistocleous, and Paulo Rupino Da Cunha (2013).
“SOA implementation critical success factors in healthcare”. In: Journal of Enterprise
Information Management 26.4, pp. 343–362.
Krafzig, Dirk, Karl Banke, and Dirk Slama (2005). Enterprise SOA: service-oriented ar-
chitecture best practices. Prentice Hall Professional.
Lee, Jinyoul, Keng Siau, and Soongoo Hong (2003). “Enterprise Integration with ERP
and EAI”. In: Communications of the ACM 46.2, pp. 54–60.
Lee, Jung Hoon, Hye-Jung Shim, and Kyung Kyu Kim (2010). “Critical success factors
in SOA implementation: an exploratory study”. In: Information Systems Management
27.2, pp. 123–145.
Li, Shing-Han et al. (2007). “Migrating legacy information systems to web services ar-
chitecture”. In: Journal of Database Management 18.4, p. 1.
Linthicum, D (2007). “Five Sureﬁre Ways to Make Your SOA a Success”. In: Infoworld
Information Technology (IT) Strategy Guide, Infoworld, October.
Mack, Natasha et al. (2005). “Qualitative research methods: a data collectors ﬁeld guide.”
In:
MacLennan, Elzavita and Jean-Paul Van Belle (2014). “Factors affecting the organiza-
tional adoption of service-oriented architecture (SOA)”. In: Information Systems and
e-Business Management 12.1, pp. 71–100.
McKenzie, Heather (2006). “Special Supplement: Service-oriented Architecture - Getting
The CEO Onside - Without The Buy-in Of Top Management, SOA Implementation Is
Likely To Fail. And Management Must Understand It Is Not Just A Technology Issue.
Heather McKenzie Reports”. In: The Banker, p. 1.
Meier, F (2006). “Service-Oriented Architecture Maturity Models: A guide to SOA adop-
tion?” PhD thesis. Högskolan Skövde School of Humanities and Informatics.
Miles, Matthew B, A Michael Huberman, and Johnny Saldaña (2013). Qualitative data
analysis: A methods sourcebook. SAGE Publications, Incorporated.
Mircea, Marinela and Anca Ioana Andreescu (2012). “A Roadmap towards Service-Oriented
Enterprise”. In: Journal of Organizational Management Studies 2012, p. 1.
Oliveira, Saulo Barbará de et al. (2012). “Information and service-oriented architecture &
web services: enabling integration and organizational agility”. In: Procedia Technol-
ogy 5, pp. 141–151.
OpenGroup (2013). OSIMM Version 2 Technical Standard : The Model. URL: http:
//www.opengroup.org/soa/sourcebook/osimmv2/model.htm
(visited on 08/13/2015).
Ricadela, Aaron (2006). “The dark side of SOA”. In: Information Week, pp. 54–58.
Saldaña, Johnny (2012). The coding manual for qualitative researchers. 14. Sage.
Schipper M, Verhoeven V (2010). XBRL vanuit technisch perspectief. GLOMIDCO B.V.
79

BIBLIOGRAPHY
Sonic Software Corp. Amberpoint Inc., Bearingpoint Inc. Systinet Corp. (2005). A new
service-oriented architecture (soa) maturity model. URL: http : / / www . omg .
org / soa / Uploaded %20Docs / SOA / SOA _ Maturity . pdf (visited on
08/13/2015).
Touzi, Jihed et al. (2009). “A model-driven approach for collaborative service-oriented
architecture design”. In: International Journal of Production Economics 121.1, pp. 5–
20.
Yin, Robert (1994). Case study research: Design and methods . Beverly Hills.
80

Thesis Nha-Lan Nguyen - SOA

More Related Content

What's hot

Viewers also liked

Similar to Thesis Nha-Lan Nguyen - SOA

Thesis Nha-Lan Nguyen - SOA