Explaining SOA Maturity Through Challenges: A Case Study

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

Explaining SOA Maturity Through Challenges: A Case Study

Explaining SOA Maturity Through Challenges: A Case Study

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Viewers also liked

Viewers also liked (13)

Similar to Explaining SOA Maturity Through Challenges: A Case Study

Similar to Explaining SOA Maturity Through Challenges: A Case Study (20)

Explaining SOA Maturity Through Challenges: A Case Study