Beruflich Dokumente
Kultur Dokumente
November 2016
Canberra Australia
This Page is Left Blank Intentionally
ii
To
My Beloved Mother
Esmiralda
iii
This Page is Left Blank Intentionally
iv
Abstract
xi
Keywords
xii
This Page is Left Blank Intentionally
xiii
Acknowledgements
I would also like to thank the staff of the School of Engineering and
Information Technology at the University of New South Wales, Canberra
campus. I am grateful to Mr. Craig Edwards, Mrs. Elvira Berra and Dr.
Sherene Suchy for continuously supporting me throughout the challenges
of the academic life.
xiv
I am immensely grateful to my wonderful family, for their love,
patience and sacrifices during my PhD journey. I thank them for being able
to put up with the absent son, brother and uncle. I thank my beloved
mother Esmiralda, my dearest sister Nika, and my wonderful nephews
Rika and Medisha. I would also like to thank my late father, Nurik, who
became the idol for the family and for me you are in our hearts forever.
xv
This Page is Left Blank Intentionally
xvi
Any sufficiently advanced technology is
indistinguishable from magic.
Sir Arthur Charles Clarke
xvii
This Page is Left Blank Intentionally
xviii
Preface
xix
As a professional with expertise and experience in business and
technology, I was involved in a wide range of Information Technology
projects. The complexity of the projects varied, but most of them were
associated with the systems and software integration: obsolete systems
had to be integrated; old software had to operate with new software;
adaptors had to be programmed for hardware and software
interoperability; and so forth. Although, in these projects I was always
advocating the use of best practices, industry-wide paradigms and popular
technologies, such as the Enterprise Application Integration (EAI), Service
Oriented Architecture (SOA), Web Services and others, there was a
constant challenge with one of the core elements in most of the integration
projects the Enterprise Service Bus (ESB).
ESB can offer a variety of integration options and even though this
variety can be beneficial for tactical integrations at the bottom of enterprise
IT, it also creates considerable complexity for integration strategies at the
top. As such, this complexity can create unnecessary overburden across
enterprise IT services, by providing functions that are often too much for
an integration initiative, making the design of the system inherently
complex. This is noticeable with the dozens of distinct ESB products, from
different software vendors, available on the market. Some of them are
over-bloated with capabilities that might hardly be needed during
integrations, whilst others are over-promising and advertise functionalities
they are incapable to deliver.
xx
genuinely curious if it is possible to address the ESB from a generic
perspective, to avoid possible vendor or technology lock-in.
With the rise of Cloud Computing, the ESB, paired with Application
Programming Interfaces (API), is getting increasingly used for Cloud
integration. Cloud enables the functions, embedded into the ESB, to be
provided as individual, on demand, services, which can scale and
substantially benefit the integration strategies and subsequently the design
of the end systems. This means that the functions, from different ESB
vendors, can be mixed together to achieve greater diversity in meeting
individual integration requirements. Thus, the identification of functions,
that can be embedded into the ESB, becomes not only possible, but also
necessary and worth investigation.
xxi
Service Bus Model (VESBM). The steps I took in the course of the
development of the VESBM are briefly described in the thesis outline
provided below.
Thesis Outline
xxii
The most complete list of the public appearance of this work is provided
below.
Publications
Conference Papers
Journal Papers
xxiii
N. Jafarov, E. Lewis (2014b). Viable Enterprise Service Bus
Model, Information Systems Symposium, University of New South Wales
at Australian Defence Force Academy. Canberra, Australia.
xxiv
This Page is Left Blank Intentionally
xxv
Table of Contents
Originality Statement.........................................................................................v
Copyright Statement ....................................................................................... vii
Authenticity Statement ..................................................................................... ix
Abstract ............................................................................................................ xi
Keywords ........................................................................................................ xii
Acknowledgements ........................................................................................ xiv
Preface........................................................................................................... xix
Thesis Outline ......................................................................................xxii
Publications ......................................................................................... xxiii
Table of Contents......................................................................................... xxvi
List of Figures .............................................................................................. xxxi
List of Tables.............................................................................................. xxxiv
List of Acronyms ........................................................................................ xxxvi
Chapter 1. Introduction The Need for Action ................................................ 1
1.1 Introduction..................................................................................... 1
1.2 Disruptive Innovation and Cloud Computing .................................. 1
1.3 Service Oriented Architecture ...................................................... 10
1.4 Enterprise Service Bus ................................................................. 11
1.5 Challenges of Implementation ...................................................... 13
1.6 Research Motivation and Research Question .............................. 20
1.7 Conclusion.................................................................................... 22
Chapter 2. Literature Review Service Oriented Architecture and
Enterprise Service Bus .................................................................................. 25
2.1 Introduction................................................................................... 25
2.2 Review of the Existing Literature .................................................. 26
2.2.1 What is SOA? ........................................................................ 29
2.2.2 What is ESB?......................................................................... 32
2.3 SOA Principles of Service Design ................................................ 36
2.3.1 Standardised Service Contract .............................................. 37
2.3.2 Service Loose Coupling ......................................................... 37
2.3.3 Service Abstraction ................................................................ 38
2.3.4 Service Reusability ................................................................ 38
2.3.5 Service Autonomy.................................................................. 39
2.3.6 Service Statelessness ........................................................... 39
2.3.7 Service Discoverability........................................................... 40
2.3.8 Service Composability ........................................................... 40
2.3.9 Service Orientation and Interoperability................................. 40
xxvi
2.4 Characteristics Influencing ESB Design ....................................... 43
2.4.1 Pervasiveness ....................................................................... 44
2.4.2 Standardised Integration........................................................ 45
2.4.3 Distributed Integration and Selective Deployment ................. 46
2.4.4 Distributed Data Transformation ............................................ 46
2.4.5 Extensibility through Layered Services .................................. 47
2.4.6 Event-driven SOA .................................................................. 47
2.4.7 Process Flow ......................................................................... 48
2.4.8 Security and Reliability .......................................................... 49
2.4.9 Autonomous and Federated Environment ............................. 49
2.4.10 Remote Configuration and Management ............................. 50
2.4.11 Native Data Type ................................................................. 52
2.4.12 Real-time Throughput of Business Data .............................. 52
2.4.13 Operational Awareness ....................................................... 52
2.4.14 Incremental Adoption ........................................................... 53
2.5 Research and Applications........................................................... 54
2.6 Research Objective ...................................................................... 62
2.7 Conclusion.................................................................................... 66
Chapter 3. Theoretical Foundation Cybernetics and Viable System
Model ............................................................................................................. 69
3.1 Introduction................................................................................... 69
3.2 Cybernetics .................................................................................. 69
3.2.1 Requisite Variety.................................................................... 70
3.3 Viable System Model.................................................................... 71
3.3.1 Viability .................................................................................. 75
3.3.2 Recursion............................................................................... 76
3.3.3 Black Box ............................................................................... 78
3.4 Systems of the VSM ..................................................................... 79
3.4.1 System ONE Operations .................................................... 79
3.4.2 System TWO Coordination ................................................. 83
3.4.3 System THREE Management............................................. 86
3.4.4 System FOUR Intelligence ................................................. 89
3.4.5 System FIVE Policy ............................................................ 94
3.5 Adaption of the VSM .................................................................... 98
3.6 Critiques of the VSM .................................................................. 102
3.7 Conclusion.................................................................................. 102
Chapter 4. Methodology Design Science Research ................................. 105
4.1 Introduction................................................................................. 105
4.2 Research in Information Systems .............................................. 105
4.3 Design Science Research .......................................................... 108
4.4 DSR Approaches........................................................................ 112
4.4.1 Common Steps .................................................................... 114
4.4.2 Rigour and Relevance ......................................................... 116
4.4.3 Theory in the DSR ............................................................... 119
4.4.4 Knowledge Generation ........................................................ 120
xxvii
4.5 Summary of the DSR ................................................................. 121
4.6 Use of the DSR in this Research................................................ 123
4.7 Conclusion.................................................................................. 125
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus
Model ........................................................................................................... 127
5.1 Introduction................................................................................. 127
5.2 Viable Enterprise Service Bus Model ......................................... 127
5.3 Structure for the Design Principles ............................................. 132
5.4 VESBM Design Principles .......................................................... 135
5.4.1 Management of Complexity, Homeostasis and Requisite
Variety.............................................................................................. 137
5.4.1.1 Principle 1: Variety ........................................................ 140
5.4.2 Viability ................................................................................ 140
5.4.2.1 Principle 2: Viability ....................................................... 141
5.4.3 Value Creation ..................................................................... 141
5.4.3.1 Principle 3: Value Creation............................................ 141
5.4.4 Value Preservation .............................................................. 142
5.4.4.1 Principle 4: Value Preservation ..................................... 142
5.4.5 Black Box ............................................................................. 142
5.4.5.1 Principle 5: Black Box ................................................... 143
5.4.6 Communication Channels, Channel Capacity and
Transduction .................................................................................... 144
5.4.6.1 Principle 6: Channels .................................................... 147
5.4.7 Operations, Recursion, Invariance, Cohesion and Meta-
system ............................................................................................. 147
5.4.7.1 Principle 7: Service Recursion ...................................... 149
5.4.8 Autonomy and Self-reference .............................................. 150
5.4.8.1 Principle 8: Service Autonomy ...................................... 152
5.4.9 Coordination and Anti-oscillation ......................................... 152
5.4.9.1 Principle 9: Service Deviation ....................................... 155
5.4.10 Resource Bargain, Accountability, Regulation Centre,
Comparator, Feedback and Convergence....................................... 155
5.4.10.1 Principle 10: Service Bargain ...................................... 158
5.4.11 Management ...................................................................... 158
5.4.11.1 Principle 11: Service Performance .............................. 160
5.4.12 Audit................................................................................... 161
5.4.12.1 Principle 12: Service Audit .......................................... 162
5.4.13 Intelligence and Self-awareness ........................................ 162
5.4.13.1 Principle 13: Service Intelligence ................................ 165
5.4.14 Policy and Ethos ................................................................ 165
5.4.14.1 Principle 14: Service Policy ......................................... 166
5.4.15 Algedonic Signals .............................................................. 167
5.4.15.1 Principle 15: Service Alert ........................................... 167
5.5 VESBM Summary ...................................................................... 168
5.6 Conclusion.................................................................................. 171
xxviii
Chapter 6. Evaluating the Artefact VESBM Validation.............................. 174
6.1 Introduction................................................................................. 174
6.2 The Use of the VESBM .............................................................. 174
6.3 Practical Cases .......................................................................... 180
6.3.1 TeliaSonera ......................................................................... 180
6.3.2 Global Service Provider ....................................................... 185
6.4 Survey ........................................................................................ 188
6.4.1 Feedback Data .................................................................... 189
6.4.2 Feedback Analysis............................................................... 196
6.5 Conclusion.................................................................................. 202
Chapter 7. Conclusion ................................................................................. 204
7.1 Introduction................................................................................. 204
7.2 Summary .................................................................................... 204
7.3 Answering the Research Question and Achieving the Research
Objective ............................................................................................. 208
7.4 Contributions .............................................................................. 213
7.5 Limitations .................................................................................. 213
7.6 Future Research Prospects and Directions................................ 214
7.7 Conclusion.................................................................................. 216
Bibliography ................................................................................................. 218
Appendix A Survey Approval by the High Research Ethics Advisory
Panel of the UNSW Canberra ...................................................................... 239
Appendix B Survey Form .......................................................................... 241
xxix
This Page is Left Blank Intentionally
xxx
List of Figures
Title Page
xxxi
Disparate Technologies
xxxii
Figure 4-6: Design Science Research Model 120
Figure 6-2: Survey Clause #2: In your organisation, can you regard 189
IT as a Main Output of the organisation or just as a Service Unit?
xxxiii
List of Tables
Title Page
Table 4-1: Comparison between the Design Science and the 111
Routine Design
Table 6-2: Identifying the ESB Features through the VESBM 185
Design Principles
Table 6-4: Survey Clause #3: How many years of work experience 189
in IT do you have?
Table 6-5: Survey Clause #4: Please grade the following VESBM 190
design principles from 1 (bad) to 10 (good), according to your own
xxxiv
vision on the usefulness of these principles for the design of the
ESB.
Table 6-6: Survey Clause #5: Please grade the following VESBM 191
design principles from 1 (bad) to 10 (good), according to your own
vision on the usability of these principles for the design of the ESB.
Table 6-7: Survey Clause #6: Please grade the following VESBM 192
design principles from 1 (bad) to 10 (good), according to your own
vision on the appropriate naming of each design principle.
Table 6-8: Survey Clause #7: Please grade the following VESBM 193
design principles from 1 (bad) to 10 (good), according to your own
vision on the appropriate meaning of each design principle.
Table 6-9: Survey Clause #8: To what extent, grading from 1 (least 194
extent) to 10 (most extent), do you think the VESBM can ensure
that the ESB, designed upon it, will retain its design (that is,
survive)?
Table 6-10: Survey Clause #9: To what extent, grading from 1 194
(least extent) to 10 (most extent), do you think the VESBM
provides the design for the ESB, which will retain its design (that
is, survive) independently from the technologies that may underpin
the ESB?
Table 6-11: Survey Clause #10: How strong, grading from 1 (least 195
strong) to 10 (very strong), do you think the VESBM design
principles can be reused in the development of policies,
procedures and guidelines for the governance, management,
maintenance and implementation of IT, at the whole enterprise
level?
xxxv
List of Acronyms
Abbreviation Title
AJAX Asynchronous JavaScript and XML
aPaaS Application Platform as a Service
API Application Programming Interfaces
BPEL4WS Business Process Execution Language for Web Services
BPM Business Process Management
COTS Commercial-off-the-shelf
CORBA Common Object Request Broker Architecture
CRM Customer Relationship Management
DSR Design Science Research
EAI Enterprise Application Integration
EA Enterprise Architectures
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
EaaS/XaaS Everything as a Service
XML eXtensible Markup Language
GSP Global Service Provider
HREA High Research Ethics Advisory
IS Information Systems
IaaS Infrastructure as a Service
iPaaS Integration Platform as a Service
IoT Internet of Things
JCA/J2CA J2EE Connector Architecture
JBI Java Business Integration
JMX Java Management Extensions
JMS Java Message Service
JSR Java Specification Request
JSON JavaScript Object Notation
LDAP Lightweight Directory Access Protocol
MOM Message Oriented Middleware
NIST National Institute of Standards and Technology
PaaS Platform as a Service
RPC Remote Procedure Calls
REST REpresentational State Transfer
ROI Return on Investment
SCA Service Component Architecture
SOA Service Oriented Architecture
SCORM Sharable Content Object Reference Model
SOAP Simple Object Access Protocol
SaaS Software as a Service
SME Subject Matter Expert
xxxvi
TOGAF The Open Group Architecture Framework
UDDI Universal Description, Discovery and Integration
USB Universal Serial Bus
VESBM Viable Enterprise Service Bus Model
VGM Viable Governance Model
VSM Viable System Model
VEP Virtual Education Platform
VPN Virtual Private Network
WoT Web of Things
WSBPEL Web Services Business Process Execution Language
WSDL Web Services Description Language
WCF Windows Communication Foundation
xxxvii
This Page is Left Blank Intentionally
xxxviii
Chapter 1. Introduction The Need for Action!
1.1 Introduction
This chapter stresses the need for action and provides an
introduction to this research. The chapter emphasises the impact of
disruptive innovation, and the disruptive technology such as the Cloud
Computing, on the paradigms that are based on the Service Oriented
Architecture, its role in the emergence of new paradigms and investigates
the relationship between them. The chapter discusses the challenges
associated with the implementation of service-oriented systems and
provides a brief overview of the Service Oriented Architecture and the
Enterprise Service Bus. This chapter provides the line of argument on the
re-emerging importance of the Enterprise Service Bus, especially in the
era of Cloud and Cybernetics, as well as formulates the motivation for
conducting this research and defines the research question. The next
chapter studies the Service Oriented Architecture and the Enterprise
Service Bus in a detailed literature review.
1
Chapter 1. Introduction The Need for Action!
2
Chapter 1. Introduction The Need for Action!
1. On-demand self-service;
3. Resource pooling;
5. Measured service.
3
Chapter 1. Introduction The Need for Action!
1. Private Cloud;
2. Community Cloud;
4. Hybrid Cloud.
4
Chapter 1. Introduction The Need for Action!
5
Chapter 1. Introduction The Need for Action!
6
Chapter 1. Introduction The Need for Action!
7
Chapter 1. Introduction The Need for Action!
8
Chapter 1. Introduction The Need for Action!
reveals that the impact of API on the global IT market is already visible
(Gat and Succi, 2013) with 77% of the current top 50 freeware and top 50
shareware applications connected to backend services, and 23%
remaining standalone. APIs are also launched as the core delivery
strategy in most organisations and out of 1000 APIs in global directory,
11% are oriented on mobile platforms, 38% are oriented on non-mobile
platforms, and the remaining 51% are shared between them (Gat and
Succi, 2013). By 2016 the number of public APIs will raise from the current
8,826 to 30,000 and 86.5% of organisations will have an API program in
place within 5 years (Layer7, 2013).
9
Chapter 1. Introduction The Need for Action!
paradigms, terms and approaches on the horizon in the coming years and
all these developments represent the impact of disruptive innovation on IT.
10
Chapter 1. Introduction The Need for Action!
One of the traditional driving forces behind the SOA and the
implementation of its design principles is the middleware technology, such
as the Enterprise Service Bus (ESB), through which the SOA can be
realised (Benatallah and Nezhad, 2008; Chappell, 2004; Chung and Chao,
2007; Erl, 2008; Roshen, 2011).
11
Chapter 1. Introduction The Need for Action!
12
Chapter 1. Introduction The Need for Action!
Along with these challenges, the SOA was also seen as a costly
initiative, which despite its promise to provide the economies of scale,
needed a careful calculation of its Return on Investment (ROI) prior to
implementation (Poulin and Himler, 2006).
These factors were the prerequisite for the renown statement, made
in early 2009, by Anne Manes who contended that the SOA, as a term,
met its demise as it was wiped out by the catastrophic impact of the
13
Chapter 1. Introduction The Need for Action!
economic recession (Manes, 2009). Some of the key reasons that led to
such a claim were (Linthicum, 2009b):
During the early 2000s, along with the SOA, the ESB was also
evolving to what was thought to become the middleware manifestation of
SOA design principles as applied to integration (Chappell, 2004, p.77).
However, the ESB also faced a number of challenges and was also
mistakenly positioned as a particular technology (Linthicum, 2008).
14
Chapter 1. Introduction The Need for Action!
15
Chapter 1. Introduction The Need for Action!
The need for the SOA was reaffirmed with the rise and the ever-
increasing use of Cloud Computing. Starting from 2012 and on, it is
stressed that SOA is imperative to make 'everything a service' (Oliver,
2012), that without SOA, there is no Cloud (Rubinstein, 2012), that it is
alive and well, in everything from enterprise integration to Platform as a
Service development platforms (ONeill, 2015), that it is integral to Cloud
development and plays an essential role in the PaaS service model
(Linthicum, 2013). It is important to mention that products of most of PaaS
providers, such as Saleforce, VMaware and others, are really SOA-based
development platforms (Linthicum, 2013). Amongst the well-known SOA-
based PaaS offerings are: Salesforces Force.com, EMC VMware's Cloud
Foundry, Heroku, CloudBees, and Engine Yard.
The ubiquitous use of Cloud Computing, the rise of API and the
ever-growing role of integration also reaffirmed the need for the ESB.
Starting from 2010 and on, many ESB offerings, by such industry vendors
as MuleSoft, WSO2, Fiorano and others, were moved to the Cloud to
enhance the Business-to-Business integration (Barry, 2010). There are
also developments in the in-memory-enabled ESBs (Sayer, 2013) and
16
Chapter 1. Introduction The Need for Action!
ESBs for the IoT (Negash et al., 2015), which indicate the ongoing
evolution of the ESB. Most importantly, the ESB is also positioned as a
tool that can converge SOA and API, whilst being agnostic to the
technology platform that is, support different integration methods
(Moore, 2013). For example, the Fiorano Cloud Platform, which utilises the
Fiorano ESB, lets companies integrate SaaS, PaaS and on-premises
resources to gain centralised control over them all, and supports the Web
Services, XML Services, REST, JSON as well as various other
technologies to meet different integration needs (Fiorano, 2013).
17
Chapter 1. Introduction The Need for Action!
All these factors suggest that, in the era of Cloud, the ESB can be
positioned as a service (Popa and Vaida, 2015) a case of the iPaaS
service model. Such ESB, if provided as a service integration platform in
the Cloud, can facilitate the integration of legacy as well as modern IT
systems via the interfaces, such as the Web Services, APIs, and various
types of adapters, through the Private, Community, Public or Hybrid Cloud
(Moore, 2013).
18
Chapter 1. Introduction The Need for Action!
19
Chapter 1. Introduction The Need for Action!
20
Chapter 1. Introduction The Need for Action!
During the last years the ESB was being steadily accepted more as
a technology concept and there is an increasing awareness that it is not a
product, but an architecture style or a pattern (Chappell, 2004; Erl, 2008;
Kress et al., 2013), which was also supported by the evidence that:
These facts lead to the growing need to address the design of the
ESB from a generic perspective. This perspective needs to investigate
what set of essential functions, in the form of generic design principles,
rather than a particular technology, must be defined in the ESB. These
generic design principles can possibly be combined in a model that would
replicate the ESB, so that it can be useful and usable for designing various
service integration platforms and ensure that the actual ESB designed
upon it will survive despite of the possible disruptive technologies, such as
new integration methods or paradigms, which may arise in the future. In
other words, these generic design principles, that form the model, must be
agnostic to the technology, product and vendor.
21
Chapter 1. Introduction The Need for Action!
Given that the ESB can be an integral part of the SOA, the survival
of the ESB at the bottom can become essential for the survival of the SOA
at the top. Survival at each of these levels, can recursively scale and
partially contribute to the survival of the whole enterprise, ultimately
becoming necessary for organisations whose business purpose is to
provide IT services as well as for organisations whose IT departments are
operating as independent units.
1.7 Conclusion
22
Chapter 1. Introduction The Need for Action!
It was stressed that, both SOA and ESB, despite their emergence
more than a decade ago, remain essential for the implementation of
service-oriented systems. However, they face a range of challenges,
associated with the various misconceptions that can amplify their failure,
especially in the era of Cloud. These misconceptions resulted in the
development of dozens of distinct ESBs that support the notion of SOA
differently. It was also shown that, Cloud Computing led to the evolution of
the ESB, from an on-premises middleware technology, which is essentially
behind the ERP, CRM, Supply Chain, Retail Management and other
similar platforms that integrate services for various purposes, to iPaaS that
can converge SOA, API and possibly other emerging paradigms. All these
facts led to the increasing awareness that the design of the ESB needs to
be addressed from a generic perspective that is, agnostic to the
technology, product and vendor. It was suggested to position the ESB as a
technology concept to investigate what set of essential functions, in the
form of generic design principles, rather than a particular technology, must
be defined in the ESB. It was also proposed to combine these design
principles in a model that would replicate the ESB, so that it can be useful
and usable for designing various service integration platforms and ensure
that the actual ESB designed upon it would survive despite of the possible
disruptive technologies that may arise in the future.
23
This Page is Left Blank Intentionally
24
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
2.1 Introduction
In the previous chapter, it was concluded that both SOA and ESB,
despite their emergence more than a decade ago, remain essential for the
implementation of service-oriented systems. However, it was stressed that
they face a range of challenges, associated with the various
misconceptions that can amplify their failure, especially in the era of
Cloud. As such, some of these misconceptions resulted in the
development of dozens of distinct ESBs that support the notion of SOA
differently. It was also shown, that SOA is at the essence of Cloud
Computing, and that ESB evolved from an on-premises middleware to the
iPaaS service model of Cloud Computing, which can converge SOA, API
and possibly other emerging paradigms. These facts led to the increasing
awareness that the design of the ESB needs to be addressed from a
generic perspective and the suggestion was to position the ESB as a
technology concept, which needs to be investigated. After the formulation
of the motivation for conducting the research and defining the research
question in the previous chapter, this chapter studies the SOA and the
ESB in an in-depth literature review to deepen the understanding of the
problem context, in order to define the research objective.
25
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
The primary scope of the review was determined as the ESB, whilst
the secondary scope was determined as the SOA, including the related
field of Cloud Computing. Along with the Google Scholar search engine,
various other sources, including conferences and journals as well as
databases and magazines at the University of New South Wales Library,
IEEE Explore, ACM Digital Library and CiteSeerX were also searched.
The keywords queried in the course of searching for literature included the
terms, such as the: Enterprise Service Bus, Enterprise Service Bus
Design, Enterprise Service Bus Implementation, Service Integration,
Service Oriented Architecture, Service Oriented Architecture Principles of
Service Design, Cloud Computing and Cloud Service Models.
26
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Author(s) Title
1 (Chappell, 2004) Enterprise Service Bus: Theory in Practice
2 (Keen et al., 2004) Patterns: Implementing an SOA using an Enterprise
Service Bus
3 (Huhns and Singh, 2005) Service Oriented Computing: Key Concepts and
Principles
4 (The Java Community JSR 208: Java Business Integration Specification
Process, 2005)
5 (Keen et al., 2005) Patterns: SOA with an Enterprise Service Bus
6 (Luo et al., 2005) Designing and Implementing Enterprise Service Bus
and SOA Solutions
7 (Schmidt et al., 2005) The Enterprise Service Bus: Making Service Oriented
Architecture Real
8 (Goel, 2006) Enterprise Integration EAI vs. SOA vs. ESB
9 (Ji-chen and Ming, 2006) Enterprise Service Bus and an Open Source
Implementation
10 (Red Hat JBoss, 2006) Why ESB and SOA?
11 (Menge, 2007) Enterprise Service Bus
12 (De Leusse et al., 2007) Enterprise Service Bus: An Overview
13 (Manes, 2007) Enterprise Service Bus: A Definition
14 (Desmet et al., 2007) Throughput Evaluation of Different Enterprise Service
Bus Approaches
15 (Flurry, 2007) Exploring the Enterprise Service Bus, Part 1:
Discover How an ESB Can Help You Meet the
Requirements for Your SOA Solution
16 (Ortiz, 2007) Getting on Board the Enterprise Service Bus
17 (Erl, 2007) SOA: Principles of Service Design
18 (Erl, 2008) SOA Design Patterns
19 (Papazoglou et al., 2008) Service Oriented Computing: A Research Roadmap
20 (Vouk, 2008) Cloud computing Issues, Research and
Implementations
21 (Garces-Erice, 2009) Building an Enterprise Service Bus for Real-time
SOA: A Messaging Middleware Stack
22 (Valipour et al., 2009) A Brief Survey of Software Architecture Concepts and
Service Oriented Architecture
23 (Buyya et al., 2009) Cloud Computing and Emerging IT Platforms: Vision,
Hype, and Reality for Delivering Computing as the 5th
Utility
24 (Linthicum, 2009a) Cloud Computing and SOA Convergence in Your
Enterprise: A Step-by-step Guide
25 (Zhang et al., 2010) Cloud Computing: State-of-the-art and Research
Challenges
26 (Sriram and Khajeh- Research Agenda in Cloud Technologies
Hosseini, 2010)
27 (Blake and Wei, 2010) Service Oriented Computing and Cloud Computing:
Challenges and Opportunities
28 (Dillon et al., 2010) Cloud Computing: Issues and Challenges
29 (Riad et al., 2010) Design of SOA-based Grid Computing with Enterprise
Service Bus
30 (Barry, 2010) ESBs in the Cloud: Tricky in the Early Going
31 (Banerjee et al., 2011) Everything as a Service: Powering the New
27
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Information Economy
32 (Edwards, 2011) Service Component Architecture
33 (Issarny et al., 2011) Service-oriented Middleware for the Future Internet:
State of the Art and Research Directions
34 (Haddad, 2012) Deploy ESB as a Service
35 (Gartner, 2012) Gartner IT Glossary Integration Platform as a
Service
36 (MuleSoft, 2012) What is iPaaS? Gartner Provides a Reference Model
37 (Earls, 2012) Old SOA versus new SOA? Open APIs Change the
Game
38 (Microsoft, 2012) What is Windows Communication Foundation?
39 (Kress et al., 2013) Enterprise Service Bus
40 (Moore, 2013) ESB Persists As Application Integration Tool
41 (Benosman et al., 2013) Design and Implementation of a Massively Parallel
ESB
42 (Nalini and Sanjay, 2013) Study on Web service Implementation in Eclipse
using Apache CXF on JBoss Platform Towards
Service Oriented Architecture Principles
43 (Shezi et al., 2013) Analysis of Open Source Enterprise Service Buses
toward Supporting Integration in Dynamic Service
Oriented Environments
44 (Chandrasekhar, 2013) Software AG Announces Launch of Integration Live
iPaaS Solution
45 (MuleSoft, 2013) Open Source ESB The Best Choice for SOA
46 (Boleng and Sward, 2013) Service Oriented Architecture Concepts and
Implementations
47 (Thompson, 2013) Who is Who among Providers of Enterprise Service
Bus Open-source Software
48 (Pan et al., 2014) Pervasive Service Bus: Smart SOA Infrastructure for
Ambient Intelligence
49 (Utomo and Wellem, 2014) The Implementation of Enterprise Service Bus in
Graduation Business Process Integration
50 (Roche, 2014) Integrating Service Orientated Architecture Design
Principles into Software as a Service Applications
51 (IBM, 2014) SOA Design Principles and the Internet of Things
52 (Orlowski et al., 2014) Enterprise Service Bus Architecture for the Big Data
Systems
53 (Negash et al., 2015) LISA: Lightweight Internet of Things Service Bus
Architecture
54 (Yin et al., 2015) JTangCSB: A Cloud Service Bus for Cloud and
Enterprise Application Integration
55 (Popa and Vaida, 2015) Enterprise Bus as a Service An Ideal Cloud
Connectivity Model
These publications, which are used and cited throughout this thesis,
indicate the importance of the ESB for SOA and Cloud Computing.
However, despite a decade-long research in the domain of ESB, the
number of publications that address its design is low. This suggests that
this area is still in its infancy and needs investigation. However, prior to
28
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
29
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
In SOA, services are divided into two groups: services that provide
a particular function, also known as service providers; and services that
consume that function, also known as service consumers (Abrams and
Schulte, 2008). A service is usually implemented using standardised,
platform-agnostic technologies to overcome the interoperability barriers
with other service-oriented environments (Erl, 2007). In the context of
SOA, services are often positioned as atomic entities that can execute a
particular business function (Erl, 2005). Services can also form service
compositions (Erl, 2008), which can implement complex business
processes (Menge, 2007). Additionally, services can be orchestrated,
aiding the design of business models in organisations (Valipour et al.,
2009).
30
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
31
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
32
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
One of the central ideas behind the ESB was to enable the
integration of heterogeneous applications without writing code (Chappell,
2004). A typical ESB integration scenario (Figure 2-3) traditionally involves
various services that are hosted pervasively across networks, on servers,
inside service containers, along with application adapters, routers,
message brokers and so on (Keen et al., 2004).
33
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
The ESB emerged in the early 2000s as a response to the need for
a new type of infrastructure that could become a backbone for the SOA
and combine messaging, routing, transformation, intelligence and other
types of services, necessary to facilitate the implementation of service-
oriented systems (Chappell, 2004; Garces-Erice, 2009; Keen et al., 2005;
Roshen, 2009). ESB evolved from the Enterprise Application Integration
(EAI) (Goel, 2006; Menge, 2007; Ortiz, 2007) technologies that relied on
APIs, Remote Procedure Calls (RPC) (Microsoft, 2003), Common Object
Request Broker Architecture (CORBA) (Object Management Group, 2012)
as well as various Message Oriented Middleware (MOM) implementations
(De Leusse et al., 2007).
34
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
35
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Although, the MOM was built upon powerful concepts, that became
the basis for modern integration platforms, including the ESB, the quick
rise and fall of MOM is commonly associated with the interoperability
issues between various MOM products that were comprised of proprietary
protocols and platform-specific interfaces incompatible with each other
(Issarny et al., 2007; Menge, 2007; Xu and Xu, 2005). There was a need
for a new of type of paradigm that could solve these interoperability issues
and drive the integration (Goel, 2006). This paradigm became what is now
known as the SOA, of which the ESB is one of the prominent enablers
(Menge, 2007).
3. Service Abstraction;
4. Service Reusability;
5. Service Autonomy;
6. Service Statelessness;
36
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
8. Service Composability.
37
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
38
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
39
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
One item that might appear absent from the above list of principles
is a principle along the lines of Services are Interoperable. The reason
Erl did not list it as a separate principle is because interoperability is
fundamental to all of the eight principles. Thus, in relation to service-
oriented computing, stating that services must be interoperable is just
40
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
about as basic as stating that services must exist (Erl, 2007, p.74).
Examples of how each of the eight principles contributes and supports the
interoperability are given below (Erl, 2007, p.74):
41
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
! Increased federation;
! Increased ROI;
! Reduced IT burden.
42
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
1. Pervasiveness;
2. Standardised Integration;
43
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
6. Event-driven SOA;
7. Process Flow;
2.4.1 Pervasiveness
44
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Figure 2-5: Enterprise Service Bus can form a Pervasive Grid across Global
Enterprise Network (Chappell, 2004)
45
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Service, API and SOAP technologies, and can integrate components that
are created using the C/C++, C#, .NET and so forth.
46
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
ESB, as applications often do not share the same data format. The
purpose of transformation services is to transform messages sent from a
source into a format that could be readable and understood at a
destination. More complex scenarios may often include protocol
transformations and involve various types of translators, content enrichers,
normalisers and similar services that interact with databases and other
resources to enhance messages with additional information required for
the transformation.
47
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
ESB provides process flow capabilities that can be used for the
modelling of business process execution scenarios on both local (for
example, department or business unit) as well as global (for example,
enterprise or cross-enterprise) scales (Figure 2-7). Essentially, the
modeling can range from a simple sequence of steps to more complex
business process orchestration, which may involve intelligent content-
based routing, parallel execution paths and arrays of conditional splits and
joins, and so forth. Distributed business process orchestration in ESB is
traditionally achieved through the use of the BPEL4WS. The process flows
are typically built on top of SOA, which frees the intermediate actors from
the obligation to be continuously aware of the nature of physical networks
they are connected to and the nature of underlying protocols that provide
the connectivity.
Figure 2-7: Process Flow and Process Orchestration can Span Highly-
distributed Deployment Topologies across Physical and Logical Boundaries
(Chappell, 2004)
48
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
49
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
50
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
51
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
52
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
ESB provides the means for the incremental adoption that aids the
process of continuous integration. It drives the implementation of tactical
integration projects, that is one ESB at a time, into more broader
integration initiatives that may form a pervasive grid, that is consisting of
53
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
The potential of SOA (Geric, 2010), its impact at the business level
(Cherbakov et al., 2005), for the business innovation (Bygstad and Gronli,
2011) and for the enterprise (Noran and Bernus, 2008), have been
54
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
55
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
56
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
57
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
58
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Protocol
Java Message
Y Y Y Y(P)
Service
File Transfer Protocol Y Y Y Y
Email Y Y Y Y
Java Database
Y(R) N Y Y(P)
Connectivity
REpresentational
N N Y Y(P)
State Transfer
Transmission Control
N N Y Y
Protocol
User Datagram
N N Y Y
Protocol
Virtual File System N Y Y N
Extensible
Messaging and N Y Y N
Presence Protocol
Rich Site Summary N Y N Y
Enterprise
Y Y Y N
JavaBeans
Java Connector
Y Y N N
Architecture
Simple Object
Y Y Y Y
Access Protocol
Web Services
Y Y Y Y(P)
Security
Service Component
N C N N
Architecture
Java Business
N Y C N
Integration
Windows
Communication N N N Y
Foundation
Business Process
N Y Y Y
Execution Language
Legend: Y Included; N Not Included; C Container Available; (R) Read
Access Only; (S) Separately Available; (P) Partial Support
59
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
60
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
61
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
This research and the range of applications show that the concepts
of ESB and, through it, of SOA are worthwhile contributions to the
integration of systems, including in disruptive times. However, the breadth
of technologies that can be incorporated into ESB creates considerable
ambiguity and over the last decade it was becoming increasingly
confusing whether: the ESB must be defined as a middleware that
supports SOA, Event-driven Architecture, MOM and WSBPEL
(Marchaux, 2006; Schulte, 2003); or ESB must be correlated with the JBI
and a product is ESB if it implements the JBI (The Java Community
Process, 2005); or ESB must implement the WCF (Microsoft, 2012); or
ESB must implement the SCA (Edwards, 2011). It is clear that not all
ESBs implement JBI or WCF, or SCA; not all support WSBPEL; and not
all need to rely on the MOM and can incorporate the JMS, instead (Manes,
2007). That is, there is now evidence that the promise of ESB is not being
realised because of the diversity in approaches to its design and
application. Thus, there is a need to provide a more precise answer to the
research question given in Chapter 1.
62
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
63
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
It was mentioned, that ESB can provide its core functions in the
form of individual services (Chappell, 2004; Garces-Erice, 2009; Keen et
al., 2004). These core functions, that are usually provided through a
service container (Keen et al., 2004), are also at the heart of modern ERP,
CRM, Supply Chain, Retail Management, and other similar platforms that
integrate services for various purposes (OShaughnessey, 2013). ESB is a
service-oriented middleware (Issarny et al., 2011) that can also converge
SOA, API and possibly other emerging paradigms (Moore, 2013).
Moreover, in the era of Cloud, ESB itself can be provided as a service
(Popa and Vaida, 2015) and can be thought of as a case of iPaaS
(Chandrasekhar, 2013; MuleSoft, 2012; Pezzini and Lheureux, 2011).
64
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
65
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Develop the generic design principles for the ESB, in a model that
would ensure the ESB survival, independent from the technologies that
may underpin the ESB.
As seen from the statement of the research objective, there are two
parts that need to be addressed, in order to achieve it:
2.7 Conclusion
This chapter studied the SOA and the ESB in an in-depth literature
review to deepen the understanding of the problem context. The chapter
defined the research objective and examined the existing literature on the
SOA and the ESB to investigate their origin, research and applications.
The chapter also provided a detailed analysis of the SOA principles of
service design and the characteristics that influence the ESB design. It
was concluded that although, there are characteristics that influence the
design of an ESB, there is currently no model that could ensure the
survival of the designed ESB, despite of the changes in technologies that
may underpin it. It was suggested to investigate the domain of
Cybernetics, and the prominent VSM in particular, to identify its suitability
for developing the generic design principles for the ESB, which would
ensure its survival.
To achieve the objective of this research, the next chapter starts the
investigation of the domain of Cybernetics, and the prominent Stafford
66
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
67
This Page is Left Blank Intentionally
68
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
3.1 Introduction
In the previous chapter, after conducting an in-depth literature
review and formulating the research objective, it was suggested to
investigate the concepts in the domain of Cybernetics, especially those
embedded into the VSM, to identify whether they can be applied to the
design of the ESB. The VSM is a cybernetic model for communication and
control that can be used as a blueprint for designing viable systems,
whereas the ESB is a compound design pattern of SOA that can provide
communication and control for integrated and embedded services. Given
that communication and control is at the basis of both the VSM and the
ESB, there could be a possible overlap between them. To understand this
overlap, this chapter thoroughly analyses the VSM and builds a theoretical
foundation required to proceed with the research.
3.2 Cybernetics
Cybernetics is the science of communication and control in animals
and machines (Weiner, 1948). Although, in a managerial context the
emphasis shifts more towards the term governance (Beer, 2002), in its
contemporary usage it still refers to the study of communication and
control, but in systems (Lewis, 2013). The systems include broad socio-
technical settings, such as those found in organisations in which the
cybernetics is referred as the science of effective organisations (Hilder,
1995). Cybernetics is widely used in various applications and most of them
69
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
70
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
71
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
1. Viability;
2. Value Creation;
3. Value Preservation;
4. Black Box;
5. Management of Complexity;
6. Homeostasis;
7. Requisite Variety;
8. Communication Channels;
9. Channel Capacity;
10. Transduction;
11. Autonomy;
12. Self-reference;
13. Recursion;
14. Meta-system;
15. Invariance;
16. Cohesion;
17. Anti-oscillation;
72
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
20. Accountability;
21. Comparator;
22. Feedback;
23. Convergence;
24. Self-awareness;
All these concepts are built around five key management functions
and one extended function, which are the: Operations, Coordination,
Management and Audit (the extension of Management), Intelligence, and
Policy. They are symbolised in the VSM, as the: System ONE, TWO,
THREE and THREE*, FOUR, and FIVE, respectively. Together, these
functions (or systems) are connected through a series of information
channels and communication flows to form the VSM (Figure 3-1).
73
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
The five systems of the VSM are five invariant functions of a viable
organisation that do not necessarily represent distinct organisational units,
as the VSM is a structure of functions, rather than titles (Christopher,
2007). This means, that two or more functions may be carried out by the
same organisational unit or individual for the whole organisation to remain
viable (Hilder, 1995): The VSM gives us an excellent guide for clarifying
what needs to be done, and where. Titles and job assignments follow from
that (Christopher, 2007, p.76).
74
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
3.3.1 Viability
The purpose (that is, what we do) defines the identity (that is, who
we are), as emphasised by Hoverstadt (Hoverstadt, 2011, p.251): For all
practical purposes, managers could take identity for granted as long as
they understood the purpose of their organisation. This approach goes
back to Aristotle I am what I do. Hilder (Hilder, 1995, p.41) also states,
that: The ability to maintain identity is related to the fact that self-
75
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
3.3.2 Recursion
76
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
77
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
78
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
information and so on), what goes out of it and what are the relations
between the inputs and the outputs (Christopher, 2007).
79
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
80
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
81
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
1. They exist not for profit, but for the support of the business
units; and
82
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
83
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
84
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
85
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
The part of the VSM that is responsible for the internal and
immediate functions of the system is known as System THREE (Beer,
1985). System THREE is different to System ONE in that it reviews the
system as a totality and to System TWO in that it exercises authority as it
is placed on the command axis (Hilder, 1995). Although, it is not
undertaking any anti-oscillatory functions, it is still responsible for how the
86
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
87
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
88
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
The part of the VSM that is responsible for providing the self-
awareness for the System-in-focus is known as System FOUR (Beer,
1985). In comparison, with Systems ONE, TWO and THREE, which are
89
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
90
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
that connects two systems, as it lacks the capacity to handle huge variety
(Beer, 1979).
System FOUR is built upon two essential loops (Figure 3-1): the
first loop (Alpha ) that is focused on the internal aspects of the
organisation, assists in projecting organisations unique identity onto the
external environment; and the second loop (Beta ) that gathers
information from the external environment regarding the possible changes
on the market, including changes in technology and other factors that are
of the future concern (Beer, 1985). This external environment, that is of
the loop concern, is a subset of the total environment, which determines
the future viability of the organisation (Millar, 2009). In this environment,
the organisation must be alerted to novelty and act innovatively, in order to
91
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
92
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
with the ability to visualise alternative futures and invent them (Beer,
1979, p.243). To project the identity of the organisation onto its
environment, the intelligence function may use such activities, as public
relations and market research (Espejo and Gill, 1997).
93
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
Using these three functions, System FOUR can do the job that is
crucial for the continued organisations success on the market, in the
future. System FOUR scans the environment, does the research and
development, including planning and innovation, to assure that the
changes, required for the creation of the desired future state of the
organisation, can be achieved. These functions of the System FOUR
remain the same, regardless of the level of recursion inside the
organisation (Christopher, 2007).
94
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
(Beer, 1985). System FIVE defines the rules that determine the criteria of
relevance for the patterns that need to be recognised by System FOUR
and filtered from less relevant ones in the unknown space of continuously
changing future. It also attenuates the variety of System THREE, as it is
aware of what the existing business the organisation is in. In other words,
the corporate ethos, in some sense, has the awareness of what kind of
business the organisation might fall in as well as what kind of patterns
need more attention, thus putting constraints on both System THREE and
System FOUR (Beer, 1979). However, flexibility, rather than rigidity, shall
always prevail in all these undertakings, as steering corporate course in
the unknown, future and always changing environment is virtually
impossible. Hence, System FIVE is a mechanism that intervenes the
balancing activity of the System THREE and System FOUR homeostasis.
Thus, the organisational effectiveness is dependent on how System
THREE and System FOUR functions are interconnected and organised,
so that the issues that arise are initially checked in between them before
reaching the System FIVE (Beer, 1979).
It must be noted that System FIVE does not have sufficient variety
to absorb the combined variety of System THREE and System FOUR,
and, by design, the policy-making must be a low variety process (Espejo
and Harnden, 1989, p.84). Thus, to handle variety System THREE and
System FOUR functions must provide a complementary perspective on
the definition, implementation and adjustment of the organisational identity
and therefore must be given enough weight in the policy-making process
(Beer, 1985). In other words, both System THREE and System FOUR can
act as effective attenuators of complexity that can bring it to the range of
response capacity of System FIVE (Espejo and Reyes, 2011). This
attenuation can help in creating effective interaction between the groups,
in each as well as between the functions, which can reach decisions
through cross-functional debates and sharing perspectives on relevant
95
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
issues (Beer, 1985). For this, System THREE and System FOUR must
also provide information about their current states in a language that is
understandable by System FIVE (Beer, 1979). Although, this might
simplify the role of System FIVE to the mere monitoring of System THREE
and System FOUR interaction, System FIVE is still expected to possess
sufficient requisite variety to regulate the System THREE and System
FOUR loop (Millar, 2009). A failure to do so would lead policy makers in
the invidious position of deciding issues that are beyond their competence
(Espejo and Reyes, 2011, p.106) and result in very costly and sometimes
irreversible decisions that could undermine the accountability for
organisational policies (Christopher, 2007). A system design that
considers these interactions, interconnections and organisation of
functions, will lead to more effective policy-making (Beer, 1979).
96
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
97
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
Amongst these studies is also the work of Millar (Millar, 2009), who
adapted the VSM to create the Viable Governance Model (VGM). By
positioning the corporation as a System-in-focus, Millar created the
theoretical model for the governance of corporate IT. VGM emphasises
that IT function should be modelled as a service unit, rather than an
operational unit, unless the IT is a part of organisations value chain. In
other words, if the organisation is in the business of providing IT services,
98
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
then the elements of the organisation that provide these services should
be modelled as embedded operational units.
The VSM was also adapted by Graves who investigated how the
SOA can extend the concepts of EA beyond IT, using the VSM (Graves,
2009). He analyses the relationship between the concepts of SOA and
VSM in the context of service-oriented enterprise. Focusing on the
coordination of services inside the enterprise, Graves identifies three types
of coordination services, such as the (Graves, 2014):
99
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
strategy team; the Change the Business is the kind of work typically
done by a Project Management Office or individual project-managers; and
the Run the Business is literally, run-time coordination (Graves, 2014).
100
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
As was noted, the ESB can be an integral part of the SOA and the
survival of the ESB at the bottom can become essential for the survival of
the SOA at the top. It was mentioned that, the survival at each of these
levels can recursively scale and partially contribute to the survival of the
whole enterprise. Because of the recursive nature of the VSM, policies,
procedures and guidelines for the governance, management, maintenance
and implementation of IT at the bottom can be scaled up, to various levels
of the enterprise. A framework, such as the Information Technology
Infrastructure Library, can be used as a best practice for designing
policies, procedures and guidelines that are set to scale. The Information
Technology Infrastructure Library is a set of practices for IT service
management, which focuses on the alignment of IT services with the
needs of business. Although, the aim of such study would be beyond the
scope of this research, it can provide an insight into how VSM can be
adapted to align services that comprise enterprise IT systems.
101
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
ensure that the actual ESB designed upon them will survive despite of the
possible disruptive technologies, such as new integration methods or
paradigms, which may arise in the future.
3.7 Conclusion
This chapter built a theoretical foundation by reviewing the VSM
and the cybernetic concepts that underpin it. This review has shown that
the VSM structure could be adapted in various applications, justifying its
capability to define the way systems work.
102
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
103
This Page is Left Blank Intentionally
104
Chapter 4. Methodology Design Science Research
4.1 Introduction
Chapter 1 started the journey in this research by stressing the need
for action in the domains of SOA and ESB, formulating the motivation for
conducting the research and defining the research question. Chapter 2
provided an in-depth literature review of both domains and defined the
research objective by highlighting the need for developing the generic
design principles for the ESB, in a model that would ensure the ESB
survival, independent from the technologies that may underpin the ESB.
Chapter 3 built a theoretical foundation by reviewing the VSM and the
cybernetic concepts embedded into it and emphasised the need for a
suitable methodology that could help in answering the research question
and assist in achieving the research objective. This chapter tries to find
such a methodology, by investigating various approaches in Information
Systems discipline, and particularly in the Design Science Research.
Taking into account the qualitative nature of this research, a relevant
qualitative methodology could be a potential candidate.
105
Chapter 4. Methodology Design Science Research
(Fischer and Gregor, 2011; Gregor, 2007; Hevner et al., 2004; Peffers et
al., 2007). As a result, the problems it aims to solve are at the intersection
of technology, people and organisations (Davis and Olson, 1984; Hevner
et al., 2004; Lee, 1999).
106
Chapter 4. Methodology Design Science Research
107
Chapter 4. Methodology Design Science Research
108
Chapter 4. Methodology Design Science Research
109
Chapter 4. Methodology Design Science Research
Although, there are explicit differences between the DSR and the
Behavioural Science, they can (Aken, 2004; Gregor, 2007; Hevner et al.,
2004) and often must (Goldkuhl and Lind, 2010; Jones and Gregor, 2007;
March and Smith, 1995; Walls et al., 1992) be used together in the IS
research. Hevner et al. (Hevner et al., 2004) describe how both theories
can compliment each other: The goal of Behavioural Science research is
truth. The goal of DSR is utility. As argued above, our position is that truth
and utility are inseparable. Truth informs design and utility informs theory.
An artefact may have utility because of some as yet undiscovered truth. A
theory may yet be developed to the point where its truth can be
incorporated into design. In both cases, research assessment via the
justify/evaluate activities can result in the identification of weaknesses in
the theory or artefact and the need to refine and reassess. The refinement
and reassessment process is typically described in future research
directions (Hevner et al., 2004, p.80).
110
Chapter 4. Methodology Design Science Research
Thus, the nature of problems and solutions, the DSR is focused on,
is different from that of systems building or routine design (Peffers et al.,
2007). In comparison, the routine design involves the use of best practices
in the form of existing artefacts that are comprised of existing knowledge
to solve organisational or other related problems, whereas the DSR
addresses important unsolved problems in unique or innovative ways or
solved problems in more effective or efficient ways (Hevner et al., 2004,
p.81). DSR does rely on the existing knowledge, but often the knowledge
required to solve problems does not exist and needs to be produced. This
state positions the DSR as a direct contributor to knowledge, making it
distinct from the routine design. Moreover, the DSR is commonly used for
a class of problems, rather than particular problems for specific
stakeholders or organisations (Aken, 2004). The comparison between the
111
Chapter 4. Methodology Design Science Research
Design Science and the routine design is summarised in the table (Table
4-1) below (Alturki et al., 2012).
Table 4-1: Comparison between the Design Science and the Routine Design
(Alturki et al., 2012)
112
Chapter 4. Methodology Design Science Research
113
Chapter 4. Methodology Design Science Research
114
Chapter 4. Methodology Design Science Research
115
Chapter 4. Methodology Design Science Research
Peffers et al. (Peffers et al., 2007) state that the DSR, although
being structured sequentially, can still be started at almost any desirable
step, as required by the nature and venue of the research. The sequence
given above describes a problem-centred approach, but similar objective-
centred, development-centred and client-centred approaches can be
chosen to create novel solutions for problems in both industrial and
academic settings.
This framework serves as the basis for the three inherent research
cycles, depicted in the figure (Figure 4-5), which must be present and
clearly identified in any DSR initiative: The Relevance Cycle bridges the
116
Chapter 4. Methodology Design Science Research
117
Chapter 4. Methodology Design Science Research
Table 4-2: Guidelines of the Design Science Research (Hevner et al., 2004)
118
Chapter 4. Methodology Design Science Research
2. Artefact purposefulness;
119
Chapter 4. Methodology Design Science Research
120
Chapter 4. Methodology Design Science Research
Figure 4-6: Design Science Research Model (Vaishnavi and Kuechler, 2007)
121
Chapter 4. Methodology Design Science Research
122
Chapter 4. Methodology Design Science Research
123
Chapter 4. Methodology Design Science Research
The DSR has been used in various fields of IS (Peffers et al., 2007),
but its use in the development of the generic design principles for the ESB
is a novel idea, which may lead to various significant contributions in the
fields of service integration, SOA and hence through to Cloud Computing
and other related domains.
124
Chapter 4. Methodology Design Science Research
4.7 Conclusion
This chapter outlined various research methods in IS discipline. It
was concluded that the DSR is a suitable methodology for conducting this
research, because of its profound characteristics. Amongst the various
comprehensive DSR approaches, the approach by Hevner et al. was
chosen to define the set of steps for conducting this research. According
to the defined steps, the next chapter proceeds with the development of
the actual artefact.
125
This Page is Left Blank Intentionally
126
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
5.1 Introduction
In Chapter 4, after investigating various approaches in IS discipline,
and particularly in the DSR, the approach by Hevner et al. was chosen to
define the set of steps for conducting this research. According to the
defined steps, this chapter proceeds with the development of the actual
artefact. As was mentioned, the DSR output can be in the form of four
types of artefacts that address the heretofore-unsolved problems, which
are the: constructs, models, methods and instantiations. Adhering to the
design process step, of the DSR, this chapter proposes a novel artefact,
which is a model, created in the course of this research to answer the
research question and achieve the research objective. This novel artefact
is the Viable Enterprise Service Bus Model.
127
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
amalgamates the SOA, the ESB and the VSM, it is necessary to clarify the
definition of a model.
A model is not a real world, but a human construct that can help in
better understanding of real world systems. According to the Merriam-
Webster Dictionary and Thesaurus, a model is (Merriam-Webster, 2015):
128
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
129
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
130
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
131
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Throughout this chapter, the support level services of the ESB and
the embedded ESB services refer to the same category of services, and
are used interchangeably. To further proceed with the VESBM design
principles, it is necessary to adhere to the common standards and
practices for defining principles, so that they could be developed in a
consistent manner.
1. Name;
2. Statement;
3. Rationale; and
4. Implications.
The Name and the Statement are at the essence of each principle.
They must be clear, unambiguous and understandable. Each principle
must also have associated Rationale and Implications to promote
understanding and acceptance of the principles themselves, and to
support the use of the principles in explaining and justifying why specific
decisions are made (The Open Group, 2012, p.236).
132
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Table 5-1: Recommended Format for Defining Principles (The Open Group,
2012)
133
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
To comply with the TOGAF format, all of the four elements for
defining principles are retained in the VESBM design principles, but except
the Name the other three elements are labeled differently:
1. Name;
4. ESB Implications.
Given that the VESBM is developed for the support level services of
the ESB, the format was adapted in the following way:
134
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
The fifteen design principles proposed in this section are the result
of the detailed analysis of the cybernetic concepts embedded into the
VSM (Beer, 1985, 1981, 1979, 1972), from which the principles are
derived. However, given that the scope of the VSM extends to an entire
135
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
organisation, there are two types of the design principles that are
developed in the course of this research:
1. The VSM design principles that are directly derived from the
cybernetic concepts embedded into the VSM. Each principle
is presented in the form of a proposition and they are all
generic for any system, including organisations. Therefore, if
the system aims to remain viable, and thus survive, it must
comply with these principles.
As VESBM amalgamates the SOA, the ESB and the VSM, there
are many-to-many correlations between the eight SOA principles of
service design, the fourteen characteristics that influence the ESB design
and the fifteen design principles derived from the cybernetic concepts
embedded into the VSM. Although, Erl (Erl, 2007) did not list the Service
Orientation and Interoperability as a principle, it is still included into the
VESBM design principles, because interoperability is fundamental to all of
the eight principles. It is similar to the concept of Viability for which all of
the sub-systems of the VSM exist, because in relation to service-oriented
computing, stating that services must be interoperable is just about as
basic as stating that services must exist (Erl, 2007, p.74). The summary
of the correlations is provided at the end of this chapter.
136
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
137
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Reduction below the threshold will not allow the system respond
appropriately and exhibit as expected. On the other hand, low variety is
associated with amplification it needs to be increased to a number of
possible states, so that the system can handle it. Similarly to attenuation,
amplification shall not imply to the generation of variety above the required
level, although as in case of attenuation, a system has a capability to do
so. However, generation of redundant variety usually leads to the creation
of states a system might not ever need to enter to preserve its viability. As
a result, generation of variety above the threshold will require additional
regulation and control, which in turn might jeopardise overall effectiveness
and efficiency of the system. It is therefore necessary to keep a balance
between what needs to be reduced and what needs to be increased, so
that the system could operate responsively and handle the variety it can
accommodate (Figure 5-1). This is the main reasoning behind the
Requisite Variety.
138
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
only variety can absorb (that is, destroy) variety (Ashby, 1956). The Law of
Requisite Variety influences:
139
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
5.4.2 Viability
140
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
141
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
142
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
143
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
144
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
noted that not the variety is getting transmitted, but data with little
redundancy itself, which holds instructions for either attenuation or
amplification of variety, assuming that the instructions formulated by data
are appropriate to the relevant variety selection. To interpret whether data
transmitted is appropriate, it needs to be transduced.
145
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
146
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
147
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
148
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
149
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
150
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
151
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
152
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
153
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Figure 5-2: Vertical and Horizontal Scalability of System TWO (Beer, 1985)
154
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
155
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
156
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
shall initially transduce it. Therefore, systems take actions based on the
interpretation of the given purpose that eventually leads to the change of
their own initial states to the resultant ones, as the purpose of a system is
what it does (Beer, 1985, p.99). However, given that the purpose can
morph there is an obvious possibility for the disequilibrium. This issue can
be resolved by engaging a mechanism, in the form of a comparator, which
analyses the states of the system.
157
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
5.4.11 Management
158
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
159
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Figure 5-3: System ONE, TWO, THREE and THREE* (Beer, 1985)
160
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
5.4.12 Audit
161
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
162
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Beta loop as well, with only one remark that the external environment it is
concerned of is of unknown future (Beer, 1985).
163
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
164
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
165
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
166
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
167
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Table 5-2: Correlations between the ESB Design Characteristics and the
VESBM Design Principles
Service Audit
Performance
Service Alert
ESB Design
Preservation
Intelligence
Recursion
Autonomy
Black Box
Channels
Deviation
Creation
Viability
Bargain
Characteristics
Service
Service
Service
Service
Service
Service
Service
Variety
Policy
Value
Value
/ VESBM
Design
Principles
1 Pervasiveness X
Standardised
2 X X
Integration
Distributed
Integration and
3 X X X X
Selective
Deployment
Distributed Data
4 X
Transformation
Extensibility
through
5 X
Layered
Services
Event-driven
6 X
SOA
7 Process Flow X X X
Security and
8 X
Reliability
Autonomous
9 and Federated X X
Environment
Remote
Configuration
10 X X X
and
Management
Native Data
11 X X
Type
Real-time
12 Throughput of X
Business Data
13 Operational X X
168
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Awareness
Incremental
14 X X X X
Adoption
Table 5-3: Correlations between the SOA Principles of Service Design and
the VESBM Design Principles
SOA
Value Creation
Service Policy
Service Audit
Performance
Principles of
Service Alert
Preservation
Intelligence
Recursion
Autonomy
Black Box
Channels
Deviation
Viability
Bargain
Service
Service
Service
Service
Service
Service
Service
Variety
Value
Design /
VESBM
Design
Principles
Standardised
1 Service X X X X X
Contract
Service Loose
2 X X X X
Coupling
Service
3 X X X
Abstraction
Service
4 X X X
Reusability
Service
5 X X X X
Autonomy
Service
6 X X X
Statelessness
Service
7 X X X
Discoverability
Service
8 X X X X
Composability
Service
9 Orientation and X X X X X X X X
Interoperability
Given that the scope of the VSM is wider than that of the VESBM,
there are acknowledged limitations in the VESBM design principles, which
underplay the purposeful role of individuals in the system. The reason for
this is based on the assumption that, ESBs can ultimately be designed as
autonomous units, which can make decisions without human intervention.
This limitation is discussed in the last chapter.
169
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
170
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
5.6 Conclusion
Following the DSR steps, outlined in Chapter 4, this chapter
proposed the novel VESBM artefact, which was created in the course of
this research to answer the research question and achieve the research
objective. The VESBM is an amalgamation of the SOA principles of
service design, the characteristics that influence the ESB design and the
design principles derived from the cybernetic concepts embedded into the
VSM. The chapter proposed two types of the design principles: the VSM
design principles, which were directly derived from the cybernetic
concepts embedded into the VSM; and the VESBM design principles,
which were directly derived from the VSM design principles. To form the
VESBM, the VSM design principles were adapted to the application of this
research, which is the ESB. However, it was acknowledged that, because
the scope of the VSM is wider than that of the VESBM there are limitations
in the VESBM design principles, which underplay the purposeful role of
171
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
It was noted that, the developed design principles are generic for
any system that aims to survive and remain viable. As ESB is an
architectural style or pattern (Chappell, 2004; Erl, 2008; Kress et al.,
2013), which is at the heart of modern ERP, CRM, Supply Chain, Retail
Management (OShaughnessey, 2013), and other similar platforms that
integrate services for various purposes, the VESBM design principles
could possibly be suitable to define the design of these platforms as well.
According to the design-evaluate process, defined in the DSR, the next
chapter proceeds with the evaluation of the VESBM in the real world
settings, to validate its usefulness and usability.
172
This Page is Left Blank Intentionally
173
Chapter 6. Evaluating the Artefact VESBM Validation
6.1 Introduction
In Chapter 4, after outlining the steps for conducting this research, it
was mentioned that the validation of the usefulness and usability of the
proposed model needed to be done through multiple design-evaluate
iterations, in the real world settings. According to the defined steps, this
chapter proceeds with the validation of the VESBM. This validation
involved six companies that examined and used the VESBM in practice,
and provided feedback, through a survey, on the usefulness and usability
of the VESBM design principles. These studies were conducted in multiple
iterations and the outcome of this work contributed to defining the final
version of the VESBM design principles.
174
Chapter 6. Evaluating the Artefact VESBM Validation
focus of the projects was on the service integration platforms, such as the
ESB, for both the on-premises and Cloud use.
175
Chapter 6. Evaluating the Artefact VESBM Validation
176
Chapter 6. Evaluating the Artefact VESBM Validation
systems together and examined the VESBM for its applicability to identify
the design of this platform.
177
Chapter 6. Evaluating the Artefact VESBM Validation
These facts led to the growing need to address the design of the
ESB from a generic perspective. This perspective had to investigate what
set of essential functions, in the form of generic design principles, rather
than a particular technology, must be defined in the ESB. It was noted
that, these generic design principles could possibly be combined in a
model that would replicate the ESB, so that it could be useful and usable
for designing various service integration platforms and ensure that the
actual ESB designed upon it would survive despite of the possible
disruptive technologies, such as new integration methods or paradigms,
which may arise in the future. It was highlighted that, these generic design
principles, that form the model, must be agnostic to the technology,
product and vendor.
As was noted, given that the ESB can be an integral part of the
SOA, the survival of the ESB at the bottom can become essential for the
survival of the SOA at the top. Survival at each of these levels, can
recursively scale and partially contribute to the survival of the whole
enterprise, ultimately becoming necessary for organisations whose
business purpose is to provide IT services as well as for organisations
whose IT departments are operating as independent units.
This formulated the motivation for conducting this research and led
to the research question being asked:
178
Chapter 6. Evaluating the Artefact VESBM Validation
Develop the generic design principles for the ESB, in a model that
would ensure the ESB survival, independent from the technologies that
may underpin the ESB.
179
Chapter 6. Evaluating the Artefact VESBM Validation
180
Chapter 6. Evaluating the Artefact VESBM Validation
181
Chapter 6. Evaluating the Artefact VESBM Validation
182
Chapter 6. Evaluating the Artefact VESBM Validation
183
Chapter 6. Evaluating the Artefact VESBM Validation
The VESBM design principles defined the design of the VEP and
helped in deriving, structuring and aligning its business requirements and
technical rationale. As the design principles were reflecting the design of
the ESB, their acceptance suggests that the VESBM is useful and usable
184
Chapter 6. Evaluating the Artefact VESBM Validation
for designing not only the VEP, but also possibly other similar service
integration platforms. The most convincing demonstration of the regard for
the use of the VESBM design principles was the invitation to continue the
collaboration with the company to assist them in future projects.
Table 6-2: Identifying the ESB Features through the VESBM Design
Principles
185
Chapter 6. Evaluating the Artefact VESBM Validation
186
Chapter 6. Evaluating the Artefact VESBM Validation
This mapping and the diagram are the result of the collaboration
and teamwork of 12 SMEs from the GSP, including myself, supervised by
Dr. Edward Lewis. As with any practical case that follows the DSR, during
this work, the evaluation of the VESBM design principles was done in
multiple iterations. The feedback that was collected from the SMEs during
these iterations helped in clarifying the application of each principle in the
practical settings and improved them, accordingly. Examples of the
feedback provided by the SMEs include:
187
Chapter 6. Evaluating the Artefact VESBM Validation
6.4 Survey
As was noted, the collaboration with TeliaSonera and Global
Service Provider resulted into two practical cases, described earlier,
whereas the collaboration with Defence3D, Talented Technologies, Credo
Group Ltd. and Discover Ltd. was in the form of consultancy work, in
which the companies were assisted in their projects. Because of the
limited time of a PhD program, it is very difficult to conduct several
experiments simultaneously and collect results from multiple sources. To
get the feedback from all of the six companies involved, the decision was
made to conduct a survey.
188
Chapter 6. Evaluating the Artefact VESBM Validation
189
Chapter 6. Evaluating the Artefact VESBM Validation
and the summary of this feedback is provided in the tables (Table 6-3-
Table 6-11) and the figure (Figure 6-2) below.
Figure 6-2: Survey Clause #2: In your organisation, can you regard IT as a
Main Output of the organisation or just as a Service Unit?
Table 6-4: Survey Clause #3: How many years of work experience in IT do
you have?
190
Chapter 6. Evaluating the Artefact VESBM Validation
12 3
14 2
15 2
17 1
18 1
Table 6-5: Survey Clause #4: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the
usefulness of these principles for the design of the ESB.
191
Chapter 6. Evaluating the Artefact VESBM Validation
Table 6-6: Survey Clause #5: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the usability
of these principles for the design of the ESB.
192
Chapter 6. Evaluating the Artefact VESBM Validation
Table 6-7: Survey Clause #6: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the
appropriate naming of each design principle.
193
Chapter 6. Evaluating the Artefact VESBM Validation
Table 6-8: Survey Clause #7: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the
appropriate meaning of each design principle.
194
Chapter 6. Evaluating the Artefact VESBM Validation
Table 6-9: Survey Clause #8: To what extent, grading from 1 (least extent) to
10 (most extent), do you think the VESBM can ensure that the ESB, designed upon
it, will retain its design (that is, survive)?
Table 6-10: Survey Clause #9: To what extent, grading from 1 (least extent)
to 10 (most extent), do you think the VESBM provides the design for the ESB,
which will retain its design (that is, survive) independently from the technologies
that may underpin the ESB?
195
Chapter 6. Evaluating the Artefact VESBM Validation
Table 6-11: Survey Clause #10: How strong, grading from 1 (least strong) to
10 (very strong), do you think the VESBM design principles can be reused in the
development of policies, procedures and guidelines for the governance,
management, maintenance and implementation of IT, at the whole enterprise level?
196
Chapter 6. Evaluating the Artefact VESBM Validation
197
Chapter 6. Evaluating the Artefact VESBM Validation
198
Chapter 6. Evaluating the Artefact VESBM Validation
199
Chapter 6. Evaluating the Artefact VESBM Validation
200
Chapter 6. Evaluating the Artefact VESBM Validation
201
Chapter 6. Evaluating the Artefact VESBM Validation
6.5 Conclusion
Adhering to the design-evaluate process, defined in the DSR, this
chapter provided the details about how the novel VESBM artefact, created
in this research, was validated by the SMEs of TeliaSonera, Global
Service Provider, Defence3D, Talented Technologies, Credo Group Ltd.
and Discover Ltd., through two practical cases and a survey. Because the
VESBM was adapted for each specific case, it was natural for the design
principles to adapt in accordance with the requirements of each
application. The feedback provided by the SMEs, during the collaboration
and through the survey, contributed to defining the final version of the
VESBM design principles and to answering the research question and
achieving the research objective. The diversity of the applications, in which
the VESBM was used, also indicated its suitability for designing platforms
that integrate services for various purposes.
202
This Page is Left Blank Intentionally
203
Chapter 7. Conclusion
Chapter 7. Conclusion
As we know, there are known knowns; there are things we know we
know. We also know there are known unknowns; that is to say, we
know there are some things we do not know. But there are also
unknown unknowns the ones we do not know we do not know.
Donald Henry Rumsfelds adaptation of the Domains of
Ignorance by Ann Kerwin
7.1 Introduction
This chapter concludes our journey in this research by summarising
the work that has been done in this thesis. The chapter investigates
whether the research question was answered and whether the research
objective was achieved. This chapter also outlines the outcomes of this
research, the contributions made, the limitations discovered, as well as
provides an insight on the future research prospects and directions in the
field, and concludes the thesis.
7.2 Summary
This research started with stressing the need for action in the
domains of SOA and ESB, in Chapter 1, which formulated the motivation
for conducting this research and defined the research question. It was
highlighted that both SOA and ESB, despite their emergence more than a
decade ago, remain essential for the implementation of service-oriented
systems, but face a range of challenges, associated with the various
misconceptions, that can amplify their failure, especially in the era of
Cloud. These misconceptions resulted in the development of dozens of
distinct ESBs that support the notion of SOA differently. It was also shown
that, Cloud Computing led to the evolution of the ESB, from an on-
premises middleware technology, which is essentially behind the ERP,
CRM, Supply Chain, Retail Management and other similar platforms that
204
Chapter 7. Conclusion
integrate services for various purposes, to iPaaS that can converge SOA,
API and possibly other emerging paradigms. All these facts led to the
increasing awareness that the design of the ESB needed to be addressed
from a generic perspective that is, agnostic to the technology, product
and vendor. It was suggested to position the ESB as a technology concept
to investigate what set of essential functions, in the form of generic design
principles, rather than a particular technology, must be defined in the ESB.
It was also proposed to combine these design principles in a model that
would replicate the ESB, so that it can be useful and usable for designing
various service integration platforms and ensure that the actual ESB
designed upon it would survive despite of the possible disruptive
technologies that may arise in the future. After formulating the motivation
for conducting the research and defining the research question, the
research proceeded with an in-depth literature review of the SOA and the
ESB.
205
Chapter 7. Conclusion
206
Chapter 7. Conclusion
207
Chapter 7. Conclusion
Develop the generic design principles for the ESB, in a model that
would ensure the ESB survival, independent from the technologies that
may underpin the ESB.
208
Chapter 7. Conclusion
209
Chapter 7. Conclusion
210
Chapter 7. Conclusion
! Conference Papers
211
Chapter 7. Conclusion
! Journal Papers
212
Chapter 7. Conclusion
model that can ensure the ESB survival, independent from the
technologies that may underpin it, which indicates that the research
question being asked is answered and the research objective being
pursued is achieved.
7.4 Contributions
During this research, multiple contributions were made to the
knowledge base.
These contributions can possibly provide the basis for the future
research in the field.
7.5 Limitations
213
Chapter 7. Conclusion
214
Chapter 7. Conclusion
As was noted, the ESB can be an integral part of the SOA and the
survival of the ESB at the bottom can become essential for the survival of
the SOA at the top. It was mentioned that, the survival at each of these
levels can recursively scale and partially contribute to the survival of the
whole enterprise. Recalling the survey clause #10, which was asking
about the reusability of the VESBM design principles for the development
of policies, procedures and guidelines for the governance, management,
maintenance and implementation of IT, at the whole enterprise level, I
started working on the adaptation of the VESBM design principles in the
Information Technology Infrastructure Library. The Information Technology
Infrastructure Library is a set of practices for IT service management,
which focuses on the alignment of IT services with the needs of business.
Using the VESBM, I was able to align 26 processes of the Information
Technology Infrastructure Library with the 15 design principles of the
VESBM. The aim of that study, which is also beyond this research, was to
provide a viable alignment for all services that comprise the enterprise IT.
215
Chapter 7. Conclusion
7.7 Conclusion
This chapter summarised the work that has been done in this
thesis. The chapter outlined the contributions made, the limitations
discovered, as well as provided an insight on the future research
prospects and directions in the field. Within the constraints of a PhD
program, this research has made unique contributions to the knowledge
base, with the VESBM as the core contribution. After outlining the
outcomes of this research, the conclusion was made that the research
question was answered and the research objective was achieved.
216
This Page is Left Blank Intentionally
217
Bibliography
Abolfazli, S., Sanaei, Z., Sanaei, M.H., Shojafar, M., Gani, A., 2015.
Mobile Cloud Computing: The-state-of-the-art, Challenges, and
Future Research.
Abrams, C., Schulte, R.W., 2008. Service Oriented Architecture Overview
and Guide to SOA Research. Gart. Res.
Adner, R., 2002. When are Technologies Disruptive? A Demand-based
View of the Emergence of Competition. Strateg. Manag. J. 23, 667
688.
Agarwal, S., 2013. API vs. SOA? Are they Different?,
https://blog.akana.com/api-vs-soa-different/, Accessed: July 15,
2015. AKANA.
Alturki, A., Bandara, W., Gable, G.G., 2012. Design Science Research
and the Core of Information Systems, in: Design Science Research
in Information Systems. Advances in Theory and Practice. Springer,
pp. 309327.
Alturki, A., Gable, G.G., Bandara, W., 2011. A Design Science Research
Roadmap, in: Service Oriented Perspectives in Design Science
Research. Springer, pp. 107123.
Alwadain, A., Fielt, E., Korthaus, A., Rosemann, M., 2013. Service-
oriented Architecture Integration within Enterprise Architecture: A-
priori Model, in: 24th Australasian Conference on Information
Systems (ACIS). RMIT University, pp. 111.
Amazon, 2006. Amazon EC2, http://aws.amazon.com/ec2/, Accessed:
July 15, 2015. Amazon.
Andrikopoulos, V., Strauch, S., Leymann, F., 2013. Decision Support for
Application Migration to the Cloud. Proc. CLOSER13 149155.
Andriole, S.J., 2012. Seven Indisputable Technology Trends that Will
Define 2015. Commun. Assoc. Inf. Syst. 30, 4.
APIGEE, 2012. Extending Your SOA in the API Economy,
https://pages.apigee.com/extend-soa-ebook.html, Accessed: July
15, 2015. APIGEE.
Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R., Konwinski, A.,
Lee, G., Patterson, D., Rabkin, A., Stoica, I., others, 2010. A View
of Cloud Computing. Commun. ACM 53, 5058.
Arsanjani, A., 2004. Service Oriented Modeling and Architecture. IBM Dev.
Works 115.
Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S., Holley,
K., 2008. SOMA: A Method for Developing Service Oriented
Solutions. IBM Syst. J. 47, 377396.
Ashby, W.R., 1956. An Introduction to Cybernetics. Chapman and Hall
London.
Atzori, L., Iera, A., Morabito, G., 2010. The Internet of Things: A Survey.
Comput. Netw. 54, 27872805.
218
Bai, X., Xie, J., Chen, B., Xiao, S., 2007. DRESR: Dynamic Routing in
Enterprise Service Bus, in: E-Business Engineering, 2007. ICEBE
2007. IEEE International Conference on. IEEE, pp. 528531.
Banerjee, P., Bash, C., Friedrich, R., Goldsack, P., Huberman, B.A.,
Manley, J., Patel, C., Ranganathan, P., Veitch, A., 2011. Everything
as a Service: Powering the New Information Economy. Computer
44, 3643.
Bannerman, P., 2010. Cloud Computing Adoption Risks: State of Play.
Governance 3, 20.
Barcia, R., Brown, K.G., Peterson, R.R., Reinitz, R.M., 2014. Aspect-
oriented Application of a Mediator in an Enterprise Service Bus of a
Service-oriented Architected Data Processing System. Google
Patents.
Baroudi, C., Halper, F., 2006. Executive Survey: SOA Implementation
Satisfaction. Hurwitz Assoc.
Barrios, J., Nurcan, S., 2004. Model Driven Architectures for Enterprise
Information Systems. Sprigner, Lecture Notes in Computer Science
3084, 319.
Barry, R., 2010. ESBs in the Cloud: Tricky in the Early Going,
http://searchsoa.techtarget.com/news/1514427/ESBs-in-the-cloud-
Tricky-in-the-early-going, Accessed: July 15, 2015. TechTarget.
Beckford, J., 2002. Quality. Psychology Press.
Beer, S., 2002. What is Cybernetics? Presented at the Kybernetes,
Emerald, pp. 209219.
Beer, S., 1985. Diagnosing the System for Organizations. Chichester:
John Wiley & Sons.
Beer, S., 1981. Brain of the Firm (2nd ed.). Chichester: John Wiley &
Sons.
Beer, S., 1979. The Heart of Enterprise: Companion volume to Brain of the
Firm. Chichester: John Wiley & Sons.
Beer, S., 1972. Brain of the Firm: The Managerial Cybernetics of
Organizations. London: Allen Lane and Penguin Press.
Benatallah, B., Nezhad, H.R.M., 2008. Service Oriented Architecture:
Overview and Directions, in: Advances in Software Engineering.
Springer, pp. 116130.
Benbasat, I., Zmud, R.W., 2003. The Identity Crisis within the IS
Discipline: Defining and Communicating the Disciplines Core
Properties. MIS Q. 183194.
Benbasat, I., Zmud, R.W., 1999. Empirical Research in Information
Systems: The Practice of Relevance. MIS Q. 316.
Benosman, R., Barkaoui, K., Albrieux, Y., 2013. Design and
Implementation of a Massively Parallel ESB, in: Programming and
Systems (ISPS), 2013 11th International Symposium on. IEEE, pp.
8995.
Berkem, B., 2008. From the Business Motivation Model to Service
Oriented Architecture. J. Object Technol. 7, 5770.
219
Bertolino, A., De Angelis, G., Polini, A., Sabetta, A., 2011. Trends and
Research Issues in SOA Validation. IGI Glob. Perform.
Dependability Serv. Comput. Concepts Tech. Res. Dir.
Bharadwaj, S.S., Chauhan, S., Raman, A., 2015. Achieving Business
Agility through Service Oriented Architecture in Recovering
Markets, in: Managing in Recovering Markets. Springer, pp. 1526.
Biffl, S., Schatten, A., Zoitl, A., 2009. Integration of Heterogeneous
Engineering Environments for the Automation Systems Lifecycle,
in: Industrial Informatics, 2009. INDIN 2009. 7th IEEE International
Conference on. IEEE, pp. 576581.
Birman, K., Chockler, G., van Renesse, R., 2009. Toward a Cloud
Computing Research Agenda. ACM SIGACT News 40, 6880.
Biswas, A.R., Giaffreda, R., 2014. IoT and cloud Convergence:
Opportunities and Challenges, in: Internet of Things (WF-IoT), 2014
IEEE World Forum on. IEEE, pp. 375376.
Blake, M.B., Wei, Y., 2010. Service Oriented Computing and Cloud
Computing: Challenges and Opportunities. IEEE Internet Comput.
14.
Boleng, J., Sward, R., 2013. Service Oriented Architecture Concepts and
Implementations. ACM, Proceedings of the 2013 ACM SIGAda
Annual Conference on High Integrity Language Technology, pp.
1112.
Borenstein, N., Blake, J., 2011. Cloud Computing Standards: Wheres the
Beef? Internet Comput. IEEE 15, 7478.
Bower, J.L., Christensen, C.M., 1995. Disruptive Technologies: Catching
the Wave. Harvard Business Review.
Brebner, P., 2009. Service Oriented Performance Modeling the Mule
Enterprise Service Bus Loan Broker Application, in: Software
Engineering and Advanced Applications, 2009. SEAA09. 35th
Euromicro Conference on. IEEE, pp. 404411.
Brocke, J. vom, Simons, A., Niehaves, B., Riemer, K., Plattfaut, R.,
Cleven, A., others, 2009. Reconstructing the Giant: On the
Importance of Rigour in Documenting the Literature Search
Process, in: ECIS. pp. 22062217.
Brocklesby, J., Cummings, S., Davies, J., 1995. Demystifying the Viable
Systems - Model as a Tool for Organizational Analysis. Asia-Pac. J.
Oper. Res. 12, 6586.
Brown, P., 2006. Reference Model for Service Oriented Architecture,
http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.doc, Accessed: July
15, 2015.
Buckl, S., Matthes, F., Schweda, C.M., 2009. A Viable System Perspective
on Enterprise Architecture Management, in: Systems, Man and
Cybernetics, 2009. SMC 2009. IEEE International Conference on.
IEEE, pp. 14831488.
220
Buschle, M., Ekstedt, M., Grunow, S., Hauder, M., Matthes, F., Roth, S.,
2012. Automating Enterprise Architecture Documentation using an
Enterprise Service Bus. AMCIS.
Buyya, R., Yeo, C.S., Venugopal, S., 2008. Market-oriented Cloud
Computing: Vision, Hype, and Reality for Delivering IT Services as
Computing Utilities, in: High Performance Computing and
Communications, 2008. HPCC08. 10th IEEE International
Conference on. IEEE, pp. 513.
Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I., 2009. Cloud
Computing and Emerging IT Platforms: Vision, Hype, and Reality
for Delivering Computing as the 5th Utility. Future Gener. Comput.
Syst. 25, 599616.
Bygstad, B., Gronli, T.-M., 2011. Service Oriented Architecture and
Business Innovation, in: System Sciences (HICSS), 2011 44th
Hawaii International Conference on. IEEE, pp. 110.
Cambridge University Press, 2015. Cambridge University Press,
http://dictionary.cambridge.org/dictionary/british/model, Accessed:
July 15, 2015. Cambridge University Press.
Catteddu, D., 2010. Cloud Computing: Benefits, Risks and
Recommendations for Information Security, in: Web Application
Security. Springer, pp. 1717.
Chandrasekhar, D., 2013. Software AG Announces Launch of Integration
Live (iPaaS) Solution,
http://www.softwareag.com/blog/reality_check/index.php/integration
-insights/software-ag-announces-launch-of-integration-live-ipaas-
solution/, Accessed: July 15, 2015. Software AG.
Channabasavaiah, K., Holley, K., Tuggle, E., 2003. Migrating to a Service
Oriented Architecture. IBM Dev. 16.
Chappell, D., 2009. Introducing Windows Communication Foundation in
.NET Framework 4, http://msdn.microsoft.com/en-
us/library/ee958158.aspx, Accessed: July 15, 2015. Microsoft.
Chappell, D., 2004. Enterprise Service Bus: Theory in Practice. OReilly
Media, Inc.
Checkland, P.B., 1980. Are Organisations Machines? Futures 12, 421
424.
Cherbakov, L., Galambos, G., Harishankar, R., Kalyana, S., Rackham, G.,
2005. Impact of Service Orientation at the Business Level. IBM
Syst. J. 44, 653668.
Christensen, C., 2015. Disruptive Innovation: Key Concepts,
http://www.claytonchristensen.com/key-concepts/, Accessed: July
15, 2015.
Christensen, C., 1997. The Innovators Dilemma: When New Technologies
Cause Great Firms to Fail. Harvard Business Review Press.
Christensen, C.M., Overdorf, M., 2000. Meeting the Challenge of
Disruptive Change. Harv. Bus. Rev. 78, 6677.
221
Christopher, W.F., 2007. Holistic Management: Managing what Matters for
Company Success. John Wiley & Sons.
Chun, B.-G., Maniatis, P., 2009. Augmented Smartphone Applications
Through Clone Cloud Execution, in: HotOS. pp. 811.
Chung, J.-Y., Chao, K.-M., 2007. A View on Service Oriented Architecture.
Serv. Oriented Comput. Appl. 1, 9395.
Creeger, M., 2009. CTO Roundtable: Cloud Computing. Commun. ACM
52, 5056.
Crockford, D., 2001. JavaScript Object Notation, http://www.json.org/,
Accessed: July 15, 2015. JSON.
Cucinotta, T., Mancina, A., Anastasi, G.F., Lipari, G., Mangeruca, L.,
Checcozzo, R., Rusin, F., 2009. A Real-time Service Oriented
Architecture for Industrial Automation. Ind. Inform. IEEE Trans. On
5, 267277.
Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N., Weerawarana,
S., 2002. Unraveling the Web Services Web: An Introduction to
SOAP, WSDL, and UDDI. IEEE Internet Comput. 6, 8693.
Curry, E., 2004. Message Oriented Middleware. Middlew. Commun. 128.
Das, D., Kundu, P., 2012. Application of Service Oriented Architecture in
Implementing a CRM Process: A Conceptual Approach. Res. High.
Educ. Comput. Sci. Inf. Technol. 148152.
Davis, G.B., Olson, M.H., 1984. Management Information Systems:
Conceptual Foundations, Structure, and Development. McGraw-
Hill, Inc.
Dawson, B., 2007. The Impact of Technology Insertion on Organisations,
http://www.hfidtc.com/research/process/reports/phase-2/HFIDTC-2-
12-2-1-1-tech-organisation.pdf, Accessed: July 15, 2015.
de Deugd, S., Carroll, R., Kelly, K.E., Millett, B., Ricker, J., 2006. SODA:
Service Oriented Device Architecture. IEEE Pervasive Comput. 5,
9496.
De Leusse, P., Periorellis, P., Watson, P., 2007. Enterprise Service Bus:
An Overview. University of Newcastle upon Tyne, Computing
Science.
Demirkan, H., Harmon, R.R., Goul, M., 2011. A Service-oriented Web
Application Framework. IT Prof. 1521.
Desmet, S., Volckaert, B., Van Assche, S., Van Der Weken, D., Dhoedt,
B., De Turck, F., 2007. Throughput Evaluation of Different
Enterprise Service Bus Approaches, in: Proceedings of SERP2007,
the 2007 International Conference on Software Engineering
Research & Practice (part of the 2007 World Congress in Computer
Science, Computer Engineering, and Applied Computing). pp. 378
384.
Dillon, T., Wu, C., Chang, E., 2010. Cloud Computing: Issues and
Challenges, in: Advanced Information Networking and Applications
(AINA), 2010 24th IEEE International Conference on. Ieee, pp. 27
33.
222
Dodge, G.E., Webb, H.W., Christ, R.E., 1999. Impact of Information
Technology on Battle Command: Lessons From Management
Science and Business. DTIC Document.
Earls, A., 2012. Old SOA versus new SOA? Open APIs Change the
Game, http://searchsoa.techtarget.com/feature/Old-SOA-versus-
new-SOA-Open-APIs-change-the-game, Accessed: July 15, 2015.
TechTarget.
Edwards, M., 2011. Service Component Architecture (SCA), http://oasis-
opencsa.org/sca, Accessed: July 15, 2015. OASIS.
Encyclopaedia Britannica, 2015. Encyclopaedia Britannica,
http://www.britannica.com/EBchecked/topic/682073/operations-
research/68178/Model-construction, Accessed: July 15, 2015.
Encyclopaedia Britannica.
Erl, T., 2008. SOA Design Patterns. Prentice Hall.
Erl, T., 2007. SOA: Principles of Service Design. Prentice Hall.
Erl, T., 2005. Service Oriented Architecture (SOA): Concepts, Technology,
and Design.
Ermagan, V., Krger, I.H., Menarini, M., 2008. Aspect Oriented Modeling
Approach to Define Routing in Enterprise Service Bus
Architectures, in: Proceedings of the 2008 International Workshop
on Models in Software Engineering. ACM, pp. 1520.
Espejo, R., 2011. Epistemological Considerations of VSM Case Studies,
in: Grey Systems and Intelligent Services (GSIS), 2011 IEEE
International Conference on. IEEE, pp. 899901.
Espejo, R., Gill, A., 1997. The Viable System Model as a Framework for
Understanding Organizations. Phrontis Ltd. SYNCHO Ltd.
Espejo, R., Harnden, R., 1989. The Viable System Model: Interpretations
and Applications of Stafford Beers VSM. Wiley Chichester.
Espejo, R., Reyes, A., 2011. Organizational Systems: Managing
Complexity with the Viable System Model. Springer.
Fiondella, L., Gokhale, S.S., Mendiratta, V.B., 2013. Cloud Incident Data:
An Empirical Analysis, in: Cloud Engineering (IC2E), 2013 IEEE
International Conference on. IEEE, pp. 241249.
Fiorano, 2013. Fiorano ESB, http://www.fiorano.com/products/ESB-
enterprise-service-bus/Fiorano-ESB-enterprise-service-bus.php,
Accessed: July 15, 2015.
Fischer, C., Gregor, S., 2011. Forms of Reasoning in the Design Science
Research Process, in: Service Oriented Perspectives in Design
Science Research. Springer, pp. 1731.
Flood, R.L., Carson, E.R., 1993. Dealing with Complexity. Springer.
Flurry, G., 2007. Exploring the Enterprise Service Bus, Part 1: Discover
How an ESB Can Help You Meet the Requirements for Your SOA
Solution. IBM.
Fowler, M., Lewis, J., 2014. Microservices,
http://martinfowler.com/articles/microservices.html, Accessed: July
15, 2015.
223
Fox, A., Griffith, R., Joseph, A., Katz, R., Konwinski, A., Lee, G.,
Patterson, D., Rabkin, A., Stoica, I., 2009. Above the Clouds: A
Berkeley View of Cloud Computing. Dept Electr. Eng Comput Sci.
Univ. Calif. Berkeley Rep UCBEECS 28, 13.
Frigg, R., Hartmann, S., 2009. Models in Science. Stanf. Encycl. Philos.
Galliers, R.D., Land, F.F., 1987. Viewpoint: Choosing Appropriate
Information Systems Research Methodologies. Commun. ACM 30,
901902.
Garces-Erice, L., 2009. Building an Enterprise Service Bus for Real-time
SOA: A Messaging Middleware Stack, in: Computer Software and
Applications Conference, 2009. COMPSAC09. 33rd Annual IEEE
International. IEEE, pp. 7984.
Garrison, G., Kim, S., Wakefield, R.L., 2012. Success Factors for
Deploying Cloud Computing. Commun. ACM 55, 6268.
Gartner, 2012. Gartner IT Glossary - Integration Platform as a Service
(iPaaS), http://www.gartner.com/it-glossary/information-platform-as-
a-service-ipaas/, Accessed: July 15, 2015. Gartner Research.
Gartner, 2011. Gartner Reference Model for Integration PaaS,
https://www.gartner.com/doc/1729256/gartner-reference-model-
integration-paas, Accessed: July 15, 2015. Gartner Research.
Gat, I., Succi, G., 2013. A Survey of the API Economy. Cut. Consort.
Geric, S., 2010. The Potential of Service Oriented Architectures, in:
Information Technology Interfaces (ITI), 2010 32nd International
Conference on. IEEE, pp. 471476.
Girbea, A., Suciu, C., Nechifor, S., Sisak, F., 2014. Design and
Implementation of a Service Oriented Architecture for the
Optimization of Industrial Applications. Ind. Inform. IEEE Trans. On
10, 185196.
Goel, A., 2006. Enterprise Integration EAI vs. SOA vs. ESB. Infosys
Technol. White Pap. 87.
Goldkuhl, G., Lind, M., 2010. A Multi-grounded Design Research Process,
in: Global Perspectives on Design Science Research. Springer, pp.
4560.
Golnam, A., Regev, G., Wegmann, A., 2011. On Viable Service Systems:
Developing a Modeling Framework for Analysis of Viability in
Service Systems, in: Exploring Services Science. Springer, pp. 30
41.
Google, 2006. Google Apps,
http://www.google.com/intx/en_au/enterprise/apps/business/,
Accessed: July 15, 2015. Google.
Gottschalk, K., Graham, S., Kreger, H., Snell, J., 2002. Introduction to
Web Services Architecture. IBM Syst. J. 41, 170177.
Graves, T., 2014. Services and Enterprise Canvas Review 3B:
Coordination, http://weblog.tetradian.com/2014/10/18/services-and-
ecanvas-review-3b-coordination/, Accessed: July 15, 2015.
224
Graves, T., 2009. The Service Oriented Enterprise: Enterprise Architecture
and Viable Services. Tetradian Books.
Gray, P., 2014. SOA vs. APIs to Deliver IT Services: Is There a Difference,
and Does it Matter?, http://www.techrepublic.com/article/soa-vs-
apis-to-deliver-it-services-is-there-a-difference-and-does-it-matter/,
Accessed: July 15, 2015. TechRepublic.
Gregor, S., 2009. Building Theory in the Sciences of the Artificial, in:
Proceedings of the 4th International Conference on Design Science
Research in Information Systems and Technology. ACM, p. 4.
Gregor, S., 2007. Design Theory in Information Systems. Australas. J. Inf.
Syst. 10.
Gregor, S., 2006. The Nature of Theory in Information Systems. Mis Q.
611642.
Gregor, S., 2002. A Theory of Theories in Information Systems. Inf. Syst.
Found. Build. Theor. Base 120.
Gregor, S., Hevner, A.R., 2013. Positioning and Presenting Design
Science Research for Maximum Impact. MIS Q. 37, 337356.
Gronbaek, I., 2008. Architecture for the Internet of Things (IoT): API and
Interconnect, in: Sensor Technologies and Applications, 2008.
SENSORCOMM08. Second International Conference on. IEEE,
pp. 802807.
Guangyao, P., Xinju, L., Keda, L., 2014. An Applied Research in MULE on
Public Service Platform of Regional Modern Logistics Information.
J. Wuzhou Univ. 3, 003.
Guinard, D., Trifa, V., Karnouskos, S., Spiess, P., Savio, D., 2010.
Interacting with the SOA-based Internet of Things: Discovery,
Query, Selection, and On-demand Provisioning of Web Services.
Serv. Comput. IEEE Trans. On 3, 223235.
Guinard, D., Trifa, V., Mattern, F., Wilde, E., 2011. From the Internet of
Things to the Web of Things: Resource-oriented Architecture and
Best Practices, in: Architecting the Internet of Things. Springer, pp.
97129.
Hacking, I., 1983. Representing and Intervening: Introductory Topics in the
Philosophy of Natural Science. Cambridge Univ Press.
Haddad, C., 2012. Deploy ESB as a Service,
http://blog.cobia.net/cobiacomm/2012/07/05/deploy-esb-as-a-
service/, Accessed: July 15, 2015.
Harcuba, O., Vrba, P., 2015. Unified REST API for Supporting the
Semantic Integration in the ESB-based Architecture, in: Industrial
Technology (ICIT), 2015 IEEE International Conference on. IEEE,
pp. 30003005.
Haslett, T., Sarah, R., 2006. Using the Viable Systems Model to Structure
a System Dynamics Mapping and Modeling Project for the
Australian Taxation Office. Syst. Pract. Action Res. 19, 273290.
Hrault, C., Thomas, G., Lalanda, P., 2005. Mediation and Enterprise
Service Bus: A Position Paper, in: Proceedings of the First
225
International Workshop on Mediation in Semantic Web Services
(MEDIATE 2005). pp. 6780.
Herring, C., Kaplan, S., 2001. The Viable System Architecture, in: System
Sciences, 2001. Proceedings of the 34th Annual Hawaii
International Conference on. IEEE, p. 10pp.
Hevner, A., Chatterjee, S., 2010. Design Science Research in Information
Systems. Springer.
Hevner, A., March, S.T., Park, J., Ram, S., 2004. Design Science in
Information Systems Research. MIS Q. 28, 75105.
Hevner, A.R., 2007. A Three Cycle View of Design Science Research.
Scand. J. Inf. Syst. 19, 4.
He, W., Da Xu, L., 2014. Integration of Distributed Enterprise Applications:
A Survey. Ind. Inform. IEEE Trans. On 10, 3542.
Higgins, J.P., Green, S., others, 2008. Cochrane Handbook for Systematic
Reviews of Interventions. Wiley Online Library.
Hilder, T., 1995. The Viable System Model. Retrieved June 28, 2005.
Hou, H., 2010. Application and Research of Service Oriented Architecture
in Constructing the Urban Geographic Information Public Service
Platform. Shanghai Geol. 2, 2629.
Hoverstadt, P., 2011. The Fractal Organization: Creating Sustainable
Organizations with the Viable System Model. John Wiley & Sons.
Huhns, M.N., Singh, M.P., 2005. Service Oriented Computing: Key
Concepts and Principles. Internet Comput. IEEE 9, 7581.
IBM, 2014. SOA Design Principles and the Internet of Things, in: IBM.
Presented at the IBM SOA Architect Summit.
IBM, 2007. Service Component Architecture Overview,
https://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp
?topic=/com.ibm.iea.wpi_v6/wpswid/6.0.2/SCA.html, Accessed:
July 15, 2015. IBM Press.
Iivari, J., Hirschheim, R., Klein, H.K., 1998. A Paradigmatic Analysis
Contrasting Information Systems Development Approaches and
Methodologies. Inf. Syst. Res. 9, 164193.
Inaganti, S., Aravamudan, S., 2007. SOA Maturity Model. BP Trends April
2007, 123.
Irani, Z., Themistocleous, M., Love, P.E., 2003. The Impact of Enterprise
Application Integration on Information System Lifecycles. Inf.
Manage. 41, 177187.
Issarny, V., Caporuscio, M., Georgantas, N., 2007. A Perspective on the
Future of Middleware-based Software Engineering, in: 2007 Future
of Software Engineering. IEEE Computer Society, pp. 244258.
Issarny, V., Georgantas, N., Hachem, S., Zarras, A., Vassiliadist, P., Autili,
M., Gerosa, M.A., Hamida, A.B., 2011. Service-oriented Middleware
for the Future Internet: State of the Art and Research Directions. J.
Internet Serv. Appl. 2, 2345.
Jackson, M.C., 2003. Systems Thinking: Creative Holism for Managers.
226
Jadeja, Y., Modi, K., 2012. Cloud Computing - Concepts, Architecture and
Challenges, in: Computing, Electronics and Electrical Technologies
(ICCEET), 2012 International Conference on. IEEE, pp. 877880.
James, A., Chung, J.-Y., 2015. Business and Industry Specific Cloud:
Challenges and Opportunities. Future Gener. Comput. Syst. 48,
3945.
Ji-chen, J., Ming, G., 2006. Enterprise Service Bus and an Open Source
Implementation, in: Management Science and Engineering, 2006.
ICMSE06. 2006 International Conference on. IEEE, pp. 926930.
Jones, D., Gregor, S., 2007. The Anatomy of a Design Theory. J. Assoc.
Inf. Syst. 8, 1.
Jung, M., Weidinger, J., Kastner, W., Olivieri, A., 2013. Building
Automation and Smart Cities: An Integration Approach based on a
Service Oriented Architecture, in: Advanced Information Networking
and Applications Workshops (WAINA), 2013 27th International
Conference on. IEEE, pp. 13611367.
Kaplan, R.S., Norton, D.P., 2006. Alignment: Using the Balanced
Scorecard to Create Corporate Synergies. Harvard Business Press.
Keen, M., Acharya, A., Bishop, S., Hopkins, A., Milinski, S., Nott, C.,
Robinson, R., Adams, J., Verschueren, P., 2004. Patterns:
Implementing an SOA using an Enterprise Service Bus. IBM,
International Technical Support Organization.
Keen, M., Adinolfi, O., Hemmings, S., Humphreys, A., Kanthi, H.,
Nottingham, A., 2005. Patterns: SOA with an Enterprise Service
Bus. IBM Redb.
Khajeh-Hosseini, A., Sommerville, I., Sriram, I., 2010. Research
Challenges for Enterprise Cloud Computing. ArXiv Prepr.
ArXiv10013257.
Klein, H.K., 2003. Crisis in the IS Field? A Critical Reflection on the State
of the Discipline. J. Assoc. Inf. Syst. 4, 10.
Knippel, R., 2005. Service Oriented Enterprise Architecture. IT Univ. Cph.
Komoda, N., 2006. Service Oriented Architecture in Industrial Systems, in:
Industrial Informatics, 2006 IEEE International Conference on.
IEEE, pp. 15.
Kress, J., Maier, B., Normann, H., Schmeidel, D., Schmutz, G., Trops, B.,
Utschig, T.W., 2013. Enterprise Service Bus. Oracle.
Krueger, I.H., Meisinger, M., Menarini, M., Pasco, S., 2006. Rapid
Systems of Systems Integration - Combining an Architecture-centric
Approach with Enterprise Service Bus Infrastructure, in: Information
Reuse and Integration, 2006 IEEE International Conference on.
IEEE, pp. 5156.
Kuechler, B., Vaishnavi, V., 2008. On Theory Development in Design
Science Research: Anatomy of a Research Project. Eur. J. Inf.
Syst. 17, 489504.
227
Kuechler, W., Vaishnavi, V., 2012. A Framework for Theory Development
in Design Science Research: Multiple Perspectives. J. Assoc. Inf.
Syst. 13, 395423.
Kyusakov, R., Eliasson, J., Delsing, J., Van Deventer, J., Gustafsson, J.,
2013. Integration of Wireless Sensor and Actuator Nodes with IT
Infrastructure using Service Oriented Architecture. Ind. Inform.
IEEE Trans. On 9, 4351.
Lankhorst, M.M., 2004. Enterprise Architecture Modelling - The Issue of
Integration. Adv. Eng. Inform. 18, 205216.
Layer7, 2013. API Security and Management Today,
www.layer7tech.com/infographic, Accessed: July 15, 2015. Layer7.
Lee, A., 1999. Inaugural Editors Comments. Mis Q. 23, 1.
Leonard, A., Beer, S., 1994. The Systems Perspective: Methods and
Models for the Future. ACUNU Proj.
Lewis, E., 2013. Layrib: Planning Viable Systems, http://www.layrib.com/,
Accessed: July 15, 2015.
Lewis, E., Millar, G., 2010. The Viable Governance Model: A Theoretical
Model for the Corporate Governance of IT. Int. J. ITBusiness
Alignment Gov. IJITBAG 1, 1935.
Lewis, G.A., Morris, E., Simanta, S., Wrage, L., 2007. Common
Misconceptions about Service Oriented Architecture, in:
Commercial-off-the-Shelf (COTS)-Based Software Systems, 2007.
ICCBSS07. Sixth International IEEE Conference on. IEEE, pp.
123130.
Lewis, G.A., Smith, D.B., Kontogiannis, K., 2010. A Research Agenda for
Service Oriented Architecture: Maintenance and Evolution of
Service Oriented Systems.
Linthicum, D.S., 2013. SOA dead? Not if youre using PaaS for App Dev.
InfoWorld.
Linthicum, D.S., 2009a. Cloud Computing and SOA Convergence in Your
Enterprise: A Step-by-step Guide. Pearson Education.
Linthicum, D.S., 2009b. Burton Group: SOA is Dead; Long Live Services.
CIO.
Linthicum, D.S., 2008. Are ESBs Evil?,
http://www.ebizq.net/topics/soa_management/features/10093.html,
Accessed: July 15, 2015.
Linthicum, D.S., 2006. Why ESB will be Dead in a Year,
http://www.ebizq.net/blogs/linthicum/2006/03/why_esb_will_be.php,
Accessed: July 15, 2015.
Linthicum, D.S., 2000. Enterprise Application Integration. Addison-Wesley
Professional.
Liu, X.-M., Liu, Q., Xu, F., 2009. Research of Enterprise Application
Integration Model based on SOA. Comput. Eng. Des. 30, 3790
3793.
Liu, Y., Gorton, I., Zhu, L., 2007. Performance Prediction of Service
Oriented Applications based on an Enterprise Service Bus, in:
228
Computer Software and Applications Conference, 2007.
COMPSAC 2007. 31st Annual International. IEEE, pp. 327334.
Li, Z., Yang, B., 2013. Application of Enterprise Service Bus (ESB)
Technology in Large Enterprises. Inf. Technol. 2, 044.
Lojka, T., Miskuf, M., Zolotova, I., 2014. Service Oriented Architecture for
Remote Machine Control in ICS, in: Applied Machine Intelligence
and Informatics (SAMI), 2014 IEEE 12th International Symposium
on. IEEE, pp. 327330.
Lundblad, M., 2015. Information Logistics Service Router - an ESB for
Integrating Enterprise Services.
Luo, M., Goldshlager, B., Zhang, L.-J., 2005. Designing and Implementing
Enterprise Service Bus (ESB) and SOA Solutions, in: Services
Computing, 2005 IEEE International Conference on. IEEE, p. xiv
vol.
Manes, A.T., 2009. SOA is Dead; Long Live Services. Burton Group.
Manes, A.T., 2007. Enterprise Service Bus: A Definition. Burton Group 1
35.
March, S.T., Smith, G.F., 1995. Design and Natural Science Research on
Information Technology. Decis. Support Syst. 15, 251266.
Marchaux, J.-L., 2006. Combining Service Oriented Architecture and
Event-driven Architecture using an Enterprise Service Bus. IBM
Dev. Works 12691275.
Markus, M.L., Majchrzak, A., Gasser, L., 2002. A Design Theory for
Systems that Support Emergent Knowledge Processes. Mis Q.
179212.
Mateescu, G., Gentzsch, W., Ribbens, C.J., 2011. Hybrid Computing -
Where HPC Meets Grid and Cloud Computing. Future Gener.
Comput. Syst. 27, 440453.
McKay, J., Marshall, P.H., 2005. A Review of Design Science in
Information Systems, in: ACIS. p. EJ.
Mei, L., Chan, W.K., Tse, T.H., 2008. A Tale of Clouds: Paradigm
Comparisons and Some Thoughts on Research Issues, in: Asia-
Pacific Services Computing Conference, 2008. APSCC08. IEEE.
Ieee, pp. 464469.
Menge, F., 2007. Enterprise Service Bus, in: Free and Open Source
Software Conference. pp. 16.
Merriam-Webster, 2015. Merriam-Webster, http://www.merriam-
webster.com/dictionary/model, Accessed: July 15, 2015. Merriam-
Webster.
Microsoft, 2012. What is Windows Communication Foundation (WCF)?,
http://msdn.microsoft.com/en-
us/library/ms731082%28v=vs.110%29.aspx, Accessed: July 15,
2015. Microsoft.
Microsoft, 2010. Windows Azure, https://www.windowsazure.com/en-us/,
Accessed: July 15, 2015. Microsoft.
229
Microsoft, 2003. What is RPC?, http://technet.microsoft.com/en-
us/library/cc787851%28v=ws.10%29.aspx, Accessed: July 15,
2015. Microsoft.
Millar, G., 2009. The Viable Governance Model: A Theoretical Model of IT
Governance within a Corporate Setting. DIT Published Doctoral
Dissertation, University of New South Wales, Canberra.
Miller, K.W., Voas, J., 2010. Ethics and the Cloud. IT Prof. 12, 45.
Mingers, J., Rosenhead, J., 2001. An Overview of Related Methods: VSM,
System Dynamics and Decision Analysis.
Moore, J., 2013. ESB Persists As Application Integration Tool. CIO.
Moreno-Vozmediano, R., Montero, R.S., Llorente, I.M., 2013. Key
Challenges in Cloud Computing: Enabling the Future Internet of
Services. Internet Comput. IEEE 17, 1825.
Mueller, B., Viering, G., Legner, C., Riempp, G., 2010. Understanding the
Economic Potential of Service Oriented Architecture. J. Manag. Inf.
Syst. 26, 145180.
MuleSoft, 2014. MuleSoft Named a Leader in the Gartner Magic
Quadrant for Enterprise Integration Platform as a Service (iPaaS),
http://www.mulesoft.com/gartner-leaders-ipaas, Accessed: July 15,
2015. MuleSoft.
MuleSoft, 2013a. Open Source ESB - The Best Choice for SOA,
https://www.mulesoft.com/resources/esb/open-source-esb-best-
choice-soa, Accessed: July 15, 2015.
MuleSoft, 2013b. CloudHub iPaaS Cloud-based Integration,
https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-
based-integration, Accessed: July 15, 2015. MuleSoft.
MuleSoft, 2012. What is iPaaS? Gartner Provides a Reference Model,
https://www.mulesoft.com/resources/cloudhub/what-is-ipaas-
gartner- provides-reference-model, Accessed: July 15, 2015.
MuleSoft.
Nalini, T., Sanjay, M., 2013. Study on Web service Implementation in
Eclipse using Apache CXF on JBoss Platform Towards Service
Oriented Architecture Principles. Int. J. Comput. Technol. Appl. 4,
115.
Namjoshi, J., Gupte, A., 2009. Service Oriented Architecture for Cloud-
based Travel Reservation Software as a Service, in: Cloud
Computing, 2009. CLOUD09. IEEE International Conference on.
IEEE, pp. 147150.
Natis, Y., Schulte, W., 2003. Introduction to Service Oriented Architecture,
https://www.gartner.com/doc/391377, Accessed: July 15, 2015.
Gartner Research.
Negash, B., Rahmani, A.-M., Westerlund, T., Liljeberg, P., Tenhunen, H.,
2015. LISA: Lightweight Internet of Things Service Bus
Architecture. Presented at the The 6th International Conference on
Ambient Systems, Networks and Technologies (ANT-2015), the 5th
230
International Conference on Sustainable Energy Information
Technology (SEIT-2015), Elsevier, pp. 436443.
Niglas, K., 2001. Paradigms and Methodology in Educational Research,
in: European Conference on Educational Research on.
NIST, 2011. The NIST Definition of Cloud Computing,
http://www.nist.gov/itl/csd/cloud-102511.cfm, Accessed: July 15,
2015. Natl. Inst. Stand. Technol.
Noran, O., Bernus, P., 2008. Service Oriented Architecture vs. Enterprise
Architecture: Competition or Synergy?, in: On the Move to
Meaningful Internet Systems: OTM 2008 Workshops. Springer, pp.
304312.
OASIS Committee, 2007. Web Services Business Process Execution
Language, https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wsbpel, Accessed:
July 15, 2015.
Object Management Group, 2012. Common Object Request Broker
Architecture (CORBA), http://www.omg.org/spec/CORBA/3.3/,
Accessed: July 15, 2015. Object Management Group.
Oduntan, O.O., Park, N., 2012. Enterprise Viability Model: Extending
Enterprise Architecture Frameworks for Modeling and Analyzing
Viability under Turbulence. J. Enterp. Transform. 2, 125.
Okoli, C., Schabram, K., 2010. A Guide to Conducting a Systematic
Literature Review of Information Systems Research. Available
SSRN 1954824.
Oliver, A., 2012. Long Live SOA in the Cloud Era. CIO.
Olliffe, G., 2014. Time to Get Off the Enterprise Service Bus?,
http://www.gartner.com/webinar/2855231, Accessed: July 15, 2015.
Gartner Research.
ONeill, M., 2015. SOA Is (Still) Not Dead (and Shouldnt Be),
https://www.axway.com/en/blog/2015/03/soa-still-not-dead-and-
shouldn%E2%80%99t-be, Accessed: July 15, 2015. Axway.
Oracle, 2009. Oracle SCA The Power of the Composite,
http://www.oracle.com/technetwork/topics/entarch/whatsnew/oracle
-sca-the-power-of-the-composi-134500.pdf, Accessed: July 15,
2015. Oracle.
Oracle, 1995. About the Java Technology,
http://docs.oracle.com/javase/tutorial/getStarted/intro/definition.html
, Accessed: July 15, 2015. Oracle.
Orlikowski, W.J., Iacono, C.S., 2001. Research Commentary: Desperately
Seeking the IT in IT Research - A Call to Theorizing the IT Artifact.
Inf. Syst. Res. 12, 121134.
Orlowski, C., Szczerbicki, E., Grabowski, J., 2014. Enterprise Service Bus
Architecture for the Big Data Systems. Manag. Prod. Eng. Rev. 5,
2831.
Ortiz, S., 2007. Getting on Board the Enterprise Service Bus. Computer
40, 1517.
231
OShaughnessey, S., 2013. ESB Does Not Equal SOA; Learn the Real
Equation, http://www.tibco.com/blog/2013/08/22/esb-does-not-
equal-soa-learn-the-real-equation/, Accessed: July 15, 2015.
TIBCO Software.
Pan, G., Zhang, L., Wu, Z., Li, S., Yang, L., Lin, M., Shi, Y., 2014.
Pervasive Service Bus: Smart SOA Infrastructure for Ambient
Intelligence. Intell. Syst. IEEE 29, 5260.
Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F., 2008. Service
Oriented Computing: A Research Roadmap. Int. J. Coop. Inf. Syst.
17, 223255.
Papazoglou, M.P., Van Den Heuvel, W.-J., 2007. Service Oriented
Architectures: Approaches, Technologies and Research Issues.
VLDB J. 16, 389415.
Patel, P., Ranabahu, A.H., Sheth, A.P., 2009. Service Level Agreement in
Cloud Computing.
Peffers, K., 2008. IS Research using Theory from Elsewhere. J. Inf.
Technol. Theory Appl. JITTA 9, 2.
Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee, S., 2007. A
Design Science Research Methodology for Information Systems
Research. J. Manag. Inf. Syst. 24, 4577.
Peirce, C.S., 1931. The Collected Papers. Cambridge, MA: Harvard
University Press.
Pezzini, M., Lheureux, B.J., 2011. Integration Platform as a Service:
Moving Integration to the Cloud, http://www-
304.ibm.com/industries/publicsector/fileserve?contentid=250736,
Accessed: July 15, 2015. IBM.
Popa, S., Vaida, M.-F., 2015. Enterprise Bus as a Service An Ideal
Cloud Connectivity Model. Acta Tech. Napoc. 56, 29.
Poulin, J., Himler, A., 2006. The ROI of SOA based on Traditional
Component Reuse. LogicLibrary Inc.
Purao, S., 2002. Design Research in the Technology of Information
Systems: Truth or Dare. Online Pa. State Univ. Httppurao Ist Psu
Eduworking-Pap.-Purao Pdf.
Rainbow, P., Sullivan, W., 1979. Interpretive Social Science: A Reader.
Berkeley, CA: University of California Press.
Rane, D., Lomow, G., 2008. SOA Governance: More than Just Registries
and Repositories. BearingPoint.
Rao, B., Angelov, B., Nov, O., 2006. Fusion of Disruptive Technologies::
Lessons from the Skype Case. Eur. Manag. J. 24, 174188.
Red Hat JBoss, 2006. Why ESB and SOA? Red Hat JBoss.
Ren, K., Wang, C., Wang, Q., 2012. Security Challenges for the Public
Cloud. IEEE Internet Comput. 6973.
Riad, A.M., Hassan, A.E., Hassan, Q.F., 2010. Design of SOA-based Grid
Computing with Enterprise Service Bus. AISS 2, 7182.
Richardson, L., Ruby, S., 2007. RESTful Web Services. OReilly Media.
232
Roche, J., 2014. Integrating Service Orientated Architecture Design
Principles into Software as a Service Applications.
Rodriguez, A., 2008. RESTful Web Services: The Basics,
https://www.ibm.com/developerworks/webservices/library/ws-
restful/, Accessed: July 15, 2015.
Roshen, W., 2011. Enterprise Service Bus with USB-like Universal Ports,
in: Web Services (ECOWS), 2011 Ninth IEEE European
Conference on. IEEE, pp. 177183.
Roshen, W., 2009. SOA-based Enterprise Integration: A Step-by-step
Guide to Services-based Application. McGraw-Hill, Inc.
Rubinstein, D., 2012. SOA (the Term) is Dead, but SOA (the Architecture)
Lives On. Software Development Times.
Rubinyi, P., 1998. Unchaining the Chain of Command. Thomson Crisp
Learning.
Ruh, W.A., Maginnis, F.X., Brown, W.J., 2002. Enterprise Application
Integration: A Wiley Tech Brief. John Wiley & Sons.
Sachs, K., Kounev, S., Bacon, J., Buchmann, A., 2009. Performance
Evaluation of Message Oriented Middleware using the
SPECjms2007 Benchmark. Perform. Eval. 66, 410434.
Sanaei, Z., Abolfazli, S., Gani, A., Buyya, R., 2014. Heterogeneity in
Mobile Cloud Computing: Taxonomy and Open Challenges.
Commun. Surv. Tutor. IEEE 16, 369392.
Sanders, D.T., Hamilton Jr, J.A., MacDonald, R.A., 2008. Supporting a
Service Oriented Architecture, in: Proceedings of the 2008 Spring
Simulation Multiconference. Society for Computer Simulation
International, pp. 325334.
Sayer, P., 2013. Software AG Goes All-out for In-memory Data
Processing. CIO.
Schmidt, M.-T., Hutchison, B., Lambros, P., Phippen, R., 2005. The
Enterprise Service Bus: Making Service Oriented Architecture Real.
IBM Syst. J. 44, 781797.
Schulte, W., 2003. The Growing Role of Events in Enterprise Applications,
https://www.gartner.com/doc/399662/growing-role-events-
enterprise-applications, Accessed: July 15, 2015. Gartner
Research.
Schulte, W., Natis, Y., 1996. Service Oriented Architectures, Part 1,
https://www.gartner.com/doc/302868, Accessed: July 15, 2015.
Gartner Research.
Shanks, G., Arnott, D., Rouse, A., 1993. A Review of Approaches to
Research and Scholarship in Information Systems. Department of
Information Systems, Faculty of Computing and Information
Technology, Monash University.
Shezi, T., Jembere, E., Adigun, M.O., Nene, M.T., 2013. Analysis of Open
Source Enterprise Service Buses toward Supporting Integration in
Dynamic Service Oriented Environments, in: E-Infrastructure and E-
Services for Developing Countries. Springer, pp. 115125.
233
Sholler, D., Smith, D., 2005. New SOA Specification will Fill Niche among
Java Users,
http://www.gartner.com/resources/136600/136687/new_soa_specifi
cation_will_f_136687.pdf, Accessed: July 15, 2015. Gartner
Research.
Siegeln, H., 2015. The ESB is dead, long live the ESB,
https://www.integrationmatters.com/integration/blog/detail/the-esb-
is-dead-long-live-the-esb.html, Accessed: July 15, 2015.
Simon, H.A., 1969. The Sciences of the Artificial. MIT press.
Skyttner, L., 2005. General Systems Theory: Problems, Perspectives,
Practice. World scientific.
Sonnenberg, C., Brocke, J. vom, 2012. Evaluations in the Science of the
Artificial Reconsidering the Build-Evaluate Pattern in Design
Science Research, in: Design Science Research in Information
Systems. Advances in Theory and Practice. Springer, pp. 381397.
Sriram, I., Khajeh-Hosseini, A., 2010. Research Agenda in Cloud
Technologies. ArXiv Prepr. ArXiv10013259.
Steen, M.W., Strating, P., Lankhorst, M.M., Doest, H. ter, Iacob, M.-E.,
2005. Service Oriented Enterprise Architecture. Serv. Oriented
Syst. Eng. Hershey 132154.
Succi, G., Remencius, T., 2013. Profiting in the API Economy,
http://www.cutter.com/itjournal/fulltext/advisor/2013/itj131002.html,
Accessed: July 15, 2015. Cut. Consort.
Sward, R.E., Whitacre, K.J., 2008. A Multi-language Service Oriented
Architecture using an Enterprise Service Bus, in: ACM SIGAda Ada
Letters. ACM, pp. 8590.
Swoyer, C., 1991. Structural Representation and Surrogative Reasoning.
Synthese 87, 449508.
Takeda, H., Veerkamp, P., Yoshikawa, H., 1990. Modeling Design
Process. AI Mag. 11, 37.
Tang, L., Dong, J., Peng, T., 2008. A Generic Model of Enterprise Service
Oriented Architecture, in: Service Oriented System Engineering,
2008. SOSE08. IEEE International Symposium on. IEEE, pp. 17.
Trneberg, W., Mehta, A., Tordsson, J., Kihl, M., Elmroth, E., 2015.
Resource Management Challenges for the Infinite Cloud, in: 10th
International Workshop on Feedback Computing at CPSWeek
2015.
Tesch, R., 1990. Qualitative Research: Analysis Types and Software
Tools. Psychology Press.
The Economist, 2012. Agent of change - The Future of Technology
Disruption in Business. The Economist.
The Java Community Process, 2013. JSR 343: Java Message Service
(JMS) Specification,
https://jcp.org/aboutJava/communityprocess/final/jsr343/index.html,
Accessed: July 15, 2015. JCP.
234
The Java Community Process, 2005. JSR 208: Java Business Integration
(JBI) Specification, https://jcp.org/en/jsr/detail?id=208, Accessed:
July 15, 2015. JCP.
The Open Group, 2012. The Open Group Architecture Framework
(TOGAF) Version 9, http://www.opengroup.org/togaf/, Accessed:
July 15, 2015. Open Group 1.
The Open Group, 2009. Service Oriented Architecture: What Is SOA?,
http://www.opengroup.org/soa/source-book/soa/soa.htm, Accessed:
July 15, 2015. The Open Group.
Thompson, J., 2013. Whos Who among Providers of Enterprise Service
Bus Open-source Software,
https://www.gartner.com/doc/2599517/whos- providers-enterprise-
service-bus, Accessed: July 15, 2015. Gartner Research.
Thramboulidis, K., 2015. Service Oriented Architecture in Industrial
Automation Systems - The case of IEC 61499: A Review. ArXiv
Prepr. ArXiv150604615.
TIBCO, 2012. Service Component Architecture,
https://docs.tibco.com/pub/activematrix_businessworks_service_en
gine/5.9.3_march_2012/html/tib_amx_concepts/wwhelp/wwhimpl/c
ommon/html/wwhelp.htm#href=c_BWSE.htm&single=true,
Accessed: July 15, 2015. TIBCO Software.
Tigli, J.-Y., Lavirotte, S., Rey, G., Hourdin, V., Riveill, M., 2011.
Lightweight Service Oriented Architecture for Pervasive Computing.
ArXiv Prepr. ArXiv11025193.
Toosi, A.N., Calheiros, R.N., Buyya, R., 2014. Interconnected Cloud
Computing Environments: Challenges, Taxonomy, and Survey.
ACM Comput. Surv. CSUR 47, 7.
Tranfield, D.R., Denyer, D., Smart, P., 2003. Towards a Methodology for
Developing Evidence-informed Management Knowledge by Means
of Systematic Review. Br. J. Manag. 14, 207222.
Tripathi, A., Mishra, A., 2011. Cloud Computing Security Considerations,
in: Signal Processing, Communications and Computing (ICSPCC),
2011 IEEE International Conference on. IEEE, pp. 15.
Tsai, W.-T., Sun, X., Balasooriya, J., 2010. Service-oriented Cloud
Computing Architecture, in: Information Technology: New
Generations (ITNG), 2010 Seventh International Conference on.
IEEE, pp. 684689.
UDDI Technical Committee, 2004. Universal Description, Discovery and
Integration, http://uddi.org/pubs/uddi-v3.0.2-20041019.htm,
Accessed: July 15, 2015.
Ulrich, W., 1989. Critical Heuristics of Social Systems Design, in:
Operational Research and the Social Sciences. Springer, pp. 79
87.
Ulrich, W., 1981. A Critique of Pure Cybernetic Reason: The Chilean
Experience with Cybernetics. J. Appl. Syst. Anal. 8, 3359.
235
Utomo, W.H., Wellem, T., 2014. The Implementation of Enterprise Service
Bus in Graduation Business Process Integration. J. Theor. Appl. Inf.
Technol. 62.
Vaishnavi, V.K., Kuechler, W., 2007. Design Science Research Methods
and Patterns: Innovating Information and Communication
Technology. CRC Press.
Vaishnavi, V., Kuechler, W., 2004. Design Research in Information
Systems.
Valipour, M.H., AmirZafari, B., Maleki, K.N., Daneshpour, N., 2009. A Brief
Survey of Software Architecture Concepts and Service Oriented
Architecture, in: Computer Science and Information Technology,
2009. ICCSIT 2009. 2nd IEEE International Conference on. IEEE,
pp. 3438.
van Aken, J.E., 2004. Management Research based on the Paradigm of
the Design Sciences: The Quest for Field-tested and Grounded
Technological Rules. J. Manag. Stud. 41, 219246.
Vescoukis, V., Doulamis, N., Karagiorgou, S., 2012. A Service Oriented
Architecture for Decision Support Systems in Environmental Crisis
Management. Future Gener. Comput. Syst. 28, 593604.
Vidgen, R., 1998. Cybernetics and Business Processes: Using the Viable
System Model to Develop an Enterprise Process Architecture.
Knowl. Process Manag. 5, 118131.
Vollmer, K., Gilpin, M., Rose, S., 2006. The Forrester Wave: Enterprise
Service Bus. Forrester Res.
Vouk, M.A., 2008. Cloud computing - Issues, Research and
Implementations. CIT J. Comput. Inf. Technol. 16, 235246.
W3C, 2008. Extensible Markup Language, http://www.w3.org/TR/REC-
xml/, Accessed: July 15, 2015.
W3C, 2007. SOAP Version 1.2 Part 1: Messaging Framework (Second
Edition), http://www.w3.org/TR/soap12-part1/, Accessed: July 15,
2015. W3C.
W3C, 2004. Web Services Architecture, http://www.w3.org/TR/ws-arch/,
Accessed: July 15, 2015.
W3C, 2001. Web Services Description Language,
http://www.w3.org/TR/wsdl, Accessed: July 15, 2015.
Whner, K., 2015. Do Good Microservices Architectures Spell the Death
of the Enterprise Service Bus?,
https://www.voxxed.com/blog/2015/01/good-microservices-
architectures-death-enterprise-service-bus-part-one/, Accessed:
July 15, 2015.
Walls, J.G., Widermeyer, G.R., Sawy, O.A. El, 2004. Assessing
Information System Design Theory in Perspective: How Useful was
Our 1992 Initial Rendition? J. Inf. Technol. Theory Appl. JITTA 6, 6.
Walls, J.G., Widmeyer, G.R., Sawy, O.A. El, 1992. Building an Information
System Design Theory for Vigilant EIS. Inf. Syst. Res. 3, 3659.
236
Walsh, S.T., Kirchhoff, B.A., Newbert, S., 2002. Differentiating Market
Strategies for Disruptive Technologies. Eng. Manag. IEEE Trans.
On 49, 341351.
Weber, R., 1987. Toward a Theory of Artifacts: A Paradigmatic Base for
Information Systems Research. J. Inf. Syst. 1, 319.
Webster, J., Watson, R.T., 2002. Analyzing the Past to Prepare for the
Future: Writing a Literature Review. Manag. Inf. Syst. Q. 26, 3.
Weiner, N., 1948. Cybernetics. New York: Wiley.
Werth, D., Leyking, K., Dreifus, F., Ziemann, J., Martin, A., 2007.
Managing SOA through Business Services A Business Oriented
Approach to Service Oriented Architectures, in: Service Oriented
Computing ICSOC 2006. Springer, pp. 313.
Winter, R., 2008. Design Science Research in Europe. Eur. J. Inf. Syst.
17, 470475.
Wu, B., Liu, S., Wu, L., 2008. Dynamic Reliable Service Routing in
Enterprise Service Bus, in: Asia-Pacific Services Computing
Conference, 2008. APSCC08. IEEE. IEEE, pp. 349354.
Xiao, J., Wu, J., Yang, J.G., 2013. A New Integrated Front Platform of
Financial Self-service Equipment Based on ESB, in: Advanced
Materials Research. Trans Tech Publ, pp. 11801184.
Xing, H., Zhai, W., 2015. Design and Implementation of Service Bus in the
Multi-mission System, in: Proceedings of the 27th Conference of
Spacecraft TT&C Technology in China. Springer, pp. 513522.
Xu, J., Xu, W., 2005. Summarization of Message Oriented Middleware.
Comput. Eng. 16, 029.
Yin, J., Lu, X., Pu, C., Wu, Z., Chen, H., 2015. JTangCSB: A Cloud
Service Bus for Cloud and Enterprise Application Integration. IEEE
Internet Comput. 3543.
Zadeh, M.E., Millar, G., Lewis, E., 2012. Mapping the Enterprise
Architecture Principles in TOGAF to the Cybernetic Concepts An
Exploratory Study, in: System Science (HICSS), 2012 45th Hawaii
International Conference on. IEEE, pp. 42704276.
Zarvi, N., Wieringa, R., 2014. An Integrated Enterprise Architecture
Framework for Business-IT Alignment. Des. Enterp. Archit.
Framew. Integrating Bus. Process. IT Infrastruct.
Zhang, L.-J., Zhang, J., Fiaidhi, J., Chang, J.M., 2010. Hot Topics in Cloud
Computing. IT Prof. 12, 1719.
Zhang, Q., Cheng, L., Boutaba, R., 2010. Cloud Computing: State-of-the-
art and Research Challenges. J. Internet Serv. Appl. 1, 718.
Ziyaeva, G., Choi, E., Min, D., 2008. Content-based Intelligent Routing
and Message Processing in Enterprise Service Bus, in:
Convergence and Hybrid Information Technology, 2008. ICHIT08.
International Conference on. IEEE, pp. 245249.
237
This Page is Left Blank Intentionally
238
Appendix A Survey Approval by the High
Research Ethics Advisory Panel of the UNSW
Canberra
239
240
Appendix B Survey Form
241
242
243
244
245
246
This Page is Left Blank Intentionally
247