Jafarov 2016 PDF

VIABLE ENTERPRISE
SERVICE BUS MODEL

A Model for Designing a Viable Service
Integration Platform
Nizami Jafarov
Master of Business Administration

(Computer Information Systems)
Bachelor of Applied Mathematics and Economic Cybernetics

(Applied Mathematics)
A thesis submitted in partial fulfilment of the requirements for

the degree of Doctor of Philosophy at
the School of Engineering and Information Technology,
the University of New South Wales
November 2016
Canberra Australia
This Page is Left Blank Intentionally
ii
To
My Beloved Mother
Esmiralda
iii
iv
Abstract
Enterprise Service Bus (ESB) is a compound pattern of Service

Oriented Architecture (SOA) that can provide sophisticated
interconnectivity between services. The ESB concepts can be found at the
heart of modern Enterprise Resource Planning, Customer Relationship
Management and other conceptually similar platforms that integrate
services for various purposes. It has evolved from an on-premises
middleware to one of the essential elements of the Cloud Computing
service models, such as the emerging Integration Platform as a Service.
However, there is a problem in the use of ESB for the integration of
services that arises from the breadth of technologies that can be
incorporated into ESB, resulting in it becoming over-bloated with functions,
noticeable in the distinct ESB products, offered by different software
vendors, that support the notion of SOA differently.
This research uses the Design Science Research (DSR)

methodology to address the generic design of ESB. This approach
amalgamates Thomas Erls SOA principles of service design and David
Chappells characteristics that influence the ESB design with the design
principles that are derived from the cybernetic concepts embedded into
Stafford Beers Viable System Model (VSM). The result of this approach is
the development of a novel artefact, in the form of a Viable Enterprise
Service Bus Model (VESBM), which can be used for designing an ESB,
independent from the technologies that might underpin it. The VESBM
was found to be useful and usable in its application by several
organisations that were designing Cloud-based and other integrated
systems.
xi
Keywords
Cybernetics, Enterprise Service Bus, Service Oriented Architecture,

Viable System Model.
xii
xiii
Acknowledgements
During this research I was blessed to work with amazing people,

who were supporting, assisting and guiding me throughout this journey.
I would like to express my sincere gratitude to Dr. Edward Lewis, for

his constant help, unlimited patience as well as individual and professional
wisdom, which benefited me so much during these years. I am also deeply
grateful to my late co-supervisor, Dr. Gary Millar, for challenging,
understanding and extending the ideas we were exchanging during our
long and joyful conversations.
I am thankful to the staff of all companies involved in this research

for their interest and support. Special thanks go to the Department of
Defence, THALES Australia and the staff of Airservices Australia, for the
fruitful cooperation at various stages of the research.
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.
Special gratitude also goes to my colleagues and friends, whom I

enjoyed working with and shared all the ups and downs during these
years. I thank Dr. Evgeny Mironov, Mrs. Natalia Derevyanko, Ms. Anna
Skobeleva, Mr. Alexey Balakirev, Dr. George Leu, Dr. Saber Elsayed, Dr.
Mohamed Mabrok, Ms. Nastaran Nemati and Dr. Mohammad Esmaeil
Zadeh. I also want to thank Prof. Hussein Abbass, Dr. Samir Alam, Prof.
Hemanshu Pota, Dr. William Murray Mount, Dr. Deborah Tuek and
others, for their collaboration throughout this research.
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
xvi
Any sufficiently advanced technology is
indistinguishable from magic.
Sir Arthur Charles Clarke
xvii
xviii
Preface
Technology is an essential part of my life that defined me as an

individual and a professional. From the early ages, I was genuinely
interested in how computers work. My journey to the world of computers
started in 1991 with the IBM 386SLC, old 5.25-inch floppy diskettes and a
couple of programs running on DOS.
As I grew, it was clear for me to keep pursuing my further education

and future profession in the field close to Information Technology.
However, along with technology, my love towards precise science was
growing naturally too. I was trying to find a golden mean that could unite
the two fields and came to the conclusion to do my Bachelors in Applied
Mathematics and Economic Cybernetics. By the time of finishing my
Bachelors, I had a couple of years of work experience as a programmer
and software developer, in several domestic and international companies.
Yet, I was still hungry for more knowledge and thankfully for my early work
experience, I had an awareness of which degree to do the next. For me
that was the Master of Business Administration (MBA).
Taking a business degree benefited me tremendously. MBA

provided me with the big picture thinking that I was initially, mistakenly,
neglecting. A clear strategic vision on how technology can fit business was
steadily getting revealed. This degree, and the experience in the technical
and business fields, was also a substantial trigger for C-level executives,
in the companies I worked for, to promote me into higher managerial
positions. During those years, I grew from a programmer and software
developer to a system architect and project manager.
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.
Along with the possible effects on the integration strategies, the

variety of functions in ESB also affects the cost of the end product and
thus the investment strategies as well. Integration projects tend to be
expensive initiatives and therefore, despite of the possible changes in
integration requirements, companies diligently avoid the reinvestment of
resources in new products or functions. As a result, for a long time, I was
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.
I started my PhD with complex integration projects of Air Traffic

Management Systems, working with Airservices Australia and Boeing and
for, the main defence contractor of the Royal Australian Air Force,
THALES. Those projects were deeply technical, exceptionally interesting
and important for the government, but for me it was still a walking around
and about. Because of the non-disclosure agreement, information on
those projects cannot be revealed, but I was clearly far from the actual
research area that I wanted to investigate. I decided to update and
reinforce my research direction and started looking into the fields of
Systems Thinking, Design Science and most importantly the Cybernetics.
Whilst investigating the field of Cybernetics, thankfully to my

supervisors, I came across of the Viable System Model (VSM), created by
Stafford Beer, which could define the communication and control of a
viable system. As at the basis of the ESB is the communication and
control as well, I saw a potential, in the VSM, in addressing the design of
the ESB from a generic perspective. This led to the development of what
ultimately became the topic of this research the Viable Enterprise
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
This thesis uses the Design Science Research (DSR) methodology

to outline the steps for conducting the research and according to these
steps:
! Chapter 1 stresses the need for action and provides an

introduction to this research;
! Chapter 2 studies the SOA and the ESB in an in-depth

literature review;
! Chapter 3 thoroughly analyses the VSM and builds a

theoretical foundation;
! Chapter 4 outlines various research methods in Information

Systems (IS) discipline, and particularly in the DSR, to find a
methodology suitable for conducting this research;
! Chapter 5 proceeds with the design process step, defined in

the DSR, to create the novel VESBM artefact;
! Chapter 6 proceeds with the evaluation process step,

defined in the DSR, to validate the VESBM; and
! Chapter 7 concludes this research by summarising the work

that has been done in this thesis.
In the course of this research, some parts of this work were

published in peer-reviewed journals and conferences, whilst other parts
were reprinted as well as presented in various seminars and symposiums.
xxii
The most complete list of the public appearance of this work is provided
below.
Publications
Conference Papers
N. Jafarov, E. Lewis (2015a). Reinterpreting the Principles of SOA

through the Cybernetic Concepts of VSM to Design the ESB as iPaaS in
the Cloud, IEEE-Springer Science and Information Conference. London,
United Kingdom.
N. Jafarov, E. Lewis (2014a). Mapping the Cybernetic Principles of

Viable System Model to Enterprise Service Bus, (ISBN: 978-0-9803267-
5-8), IEEE 9th International Conference on Information Technology and
Applications, Academic Alliance International. Sydney, Australia.
N. Jafarov, E. Lewis, G. Millar (2012b). Bringing Viability to

Service-Oriented Enterprises in Cloud Ecosystems, (ISBN: 978-1-61208-
237-0), The 6th International Conference on Advanced Engineering
Computing and Applications in Sciences (ADVCOMP 2012), International
Academy, Research and Industry Association. Barcelona, Spain.
Journal Papers
N. Jafarov, E. Lewis (2014c). Mapping the Cybernetic Principles of

Viable System Model to Enterprise Service Bus (Extended), (ISSN (Print):
2204-0595, ISSN (Online): 2203-1731), IT in Industry, vol. 2, no. 3.
Melbourne, Australia.
Symposiums, Seminars and Reprints
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.
N. Jafarov, E. Lewis, G. Millar (2012c). Bringing Viability to

Service-Oriented Enterprises in Cloud Ecosystems, (ISBN: 978-1-61208-
237-0), University of New Orleans, ThinkMind and TechRepublic (CBS
Interactive). University of New Orleans Fund. New Orleans, United States.
N. Jafarov (2012a). Service Oriented Architecture for the Civil-

Military Air Traffic Management Systems Integration, DiscoverIT
Symposium, Australian Computer Society. Canberra, Australia.
xxiv
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
xxx
List of Figures
Title Page
Figure 1-1: The Effect of Disruptive Innovation 2
Figure 1-2: Cloud Service Models Association with Service Layers 5

of Enterprise Systems
Figure 1-3: Service-oriented Approach to the Use of Shared 8

Resources in the Cloud
Figure 1-4: Service Interaction Scenario in Service Oriented 11

Architecture
Figure 1-5: ESB as a Layer between Integrated Applications 12
Figure 1-6: Use of Capabilities of Individual ESBs as Shared 19

Resources in the Cloud
Figure 2-1: Decomposition of Business Problem and Software 30

Logic
Figure 2-2: Typical Service Oriented Architecture Implementation 31

Scenario
Figure 2-3: Typical Enterprise Service Bus Integration Scenario 33
Figure 2-4: Typical Message Oriented Middleware Architecture 35
Figure 2-5: Enterprise Service Bus can form a Pervasive Grid 45

across Global Enterprise Network
Figure 2-6: Enterprise Service Bus can Integrate a Variety of 46
xxxi
Disparate Technologies
Figure 2-7: Process Flow and Process Orchestration can Span 48

Highly-distributed Deployment Topologies across Physical and
Logical Boundaries
Figure 2-8: Enterprise Service Bus is an Autonomous and 50

Federated Unit that can enable Cooperative Federation of
Operations across Organisational Boundaries
Figure 2-9: Enterprise Service Bus Configuration Blueprint can be 51

Deployed at a Remote Location and be Remotely Configured and
Managed
Figure 2-10: Value-added Services can enable Operational 53

Awareness and Provide Real-time Insight into Live Business Data
Figure 2-11: Enterprise Service Bus can enable Continuous 54

Integration through Incremental Adoption
Figure 2-12: Enterprise Representation Layers 64
Figure 3-1: Viable System Model 74
Figure 4-1: Research Methods in Information Systems 105
Figure 4-2: Available Forms of Science 106
Figure 4-3: Process Model of Design Science Research 114

Methodology
Figure 4-4: Information Systems Research Framework 115
Figure 4-5: Cycles of the Design Science Research 116
xxxii
Figure 4-6: Design Science Research Model 120
Figure 4-7: Design Science Research Roadmap 121
Figure 5-1: Attenuators and Amplifiers of Management and 137

Operations
Figure 5-2: Vertical and Horizontal Scalability of System TWO 153
Figure 5-3: System ONE, TWO, THREE and THREE* 159
Figure 5-4: Homeostatic Relationship of System THREE and 163

System FOUR
Figure 5-5: Viable Enterprise Service Bus Model 169
Figure 6-1: VESBM-based ESB Design 186
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 2-1: List of the Seminal Works 27
Table 2-2: Comparative Analysis of Commercial and Open-source 58

Enterprise Service Bus Products
Table 4-1: Comparison between the Design Science and the 111
Routine Design
Table 4-2: Guidelines of the Design Science Research 117
Table 5-1: Recommended Format for Defining Principles 132
Table 5-2: Correlations between the ESB Design Characteristics 167

and the VESBM Design Principles
Table 5-3: Correlations between the SOA Principles of Service 168

Design and the VESBM Design Principles
Table 6-1: Business Design Requirements and Technical Design 180

Rationale of the Virtual Education Platform
Table 6-2: Identifying the ESB Features through the VESBM 185
Design Principles
Table 6-3: Survey Clause #1: What is your occupation? 189
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.
vision on the usability of these principles for the design of the ESB.
vision on the appropriate naming of each design principle.
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
xxxviii
Chapter 1. Introduction The Need for Action!
Chapter 1. Introduction The Need for Action

Everything new is actually well-forgotten old.
A Russian Saying
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.2 Disruptive Innovation and Cloud Computing

The theory of disruptive innovation, first coined by Clayton M.
Christensen in his research on the disk-drive industry and later
popularised by his book The Innovators Dilemma (Christensen, 1997),
describes the process by which a product or service takes root initially in
simple applications at the bottom of a market and then relentlessly moves
up market, eventually displacing established competitors (Christensen,
2015) (Figure 1-1).
1
Figure 1-1: The Effect of Disruptive Innovation (Christensen, 2015)
Over the last decade, the impact of disruptive innovation was

extensively studied in both industry and academia for civil and military
purposes. This includes the research by the U.K. Ministry of Defence
Scientific Research Programme and the U.S. Army Research Institute that
examined the impact of technology insertion on organisations (Dawson,
2007) and on battle command (Dodge et al., 1999), respectively.
Research on the fusion of disruptive technologies (Rao et al., 2006),
identification of demand conditions that enable disruptive dynamics
(Adner, 2002), investigation of organisational capabilities in handling the
disruptive change (Christensen and Overdorf, 2000) are just a few
examples of the topics studied in this wide research area.
Disruptive technology, attention to which was initially brought by

Bower and Christensen (Bower and Christensen, 1995), is one of the most
debated topics of the XXI century. According to the Economist Intelligence
Unit (The Economist, 2012), by 2020 the advancement of technologies will
lead to the emergence of new business models and it will be increasingly
complex to cope with the pace of technology developments on the market
for already established firms. Disruptive technologies involve the high risk
of failure, often because of customer resistance (Walsh et al., 2002), but it
is forecasted that there will be a few industries remain intact (The
Economist, 2012).
2
An example of a most recent disruptive technology that is of current

concern is Cloud Computing. It is one of the most sensitive topics for
contemporary businesses because of the disruption it causes to the
market (Linthicum, 2009a). Along with providing apparently cheap and
virtually limitless processing power and storage (Fox et al., 2009; The
Economist, 2012), Cloud Computing also impacts the alignment of
technology with business, reshapes the models that federate technology
and influences the decision-making in investment strategies into
Commercial-off-the-shelf (COTS) products (Andriole, 2012).
Cloud Computing is a paradigm that is gaining increasing popularity

amongst small, mid-size, and large enterprises as an approach to build
scalable systems that can utilise multiple resources over the network in
the form of services (Armbrust et al., 2010). The National Institute of
Standards and Technology (NIST) describes Cloud Computing as a
model for enabling convenient, on-demand network access to a shared
pool of configurable computing resources (for example, networks, servers,
storage, applications, and services) that can be rapidly provisioned and
released with minimal management effort or service provider interaction.
This cloud model promotes availability and is composed of five essential
characteristics, three service models, and four deployment models (NIST,
2011).
Namely, the five characteristics are:
1. On-demand self-service;
2. Broad network access;
3. Resource pooling;
4. Rapid elasticity; and
5. Measured service.
3
The three service models are:
1. Software as a Service (SaaS);
2. Platform as a Service (PaaS); and
3. Infrastructure as a Service (IaaS).
The four deployment models are:
1. Private Cloud;
2. Community Cloud;
3. Public Cloud; and
4. Hybrid Cloud.
Amazon with its Elastic Compute Cloud (Amazon, 2006), Microsoft

with its Windows Azure Cloud Platform (Microsoft, 2010) and Google with
its Google Apps (Google, 2006) are amongst the most renowned vendors
of dominant Cloud products and platforms on the market (Buyya et al.,
2008; Q. Zhang et al., 2010).
In the scope of enterprise systems, Cloud service models can be

associated with the relevant enterprise service layers, but along with the
specified three service models the other possible service models are
defined in the so called Everything as a Service (EaaS/XaaS) model that
can be associated with each of IaaS, PaaS and SaaS models separately,
and may also include business models, processes, activities and so on
(Banerjee et al., 2011) (Figure 1-2).
4
Figure 1-2: Cloud Service Models Association with Service Layers of

Enterprise Systems
In enterprises, this hierarchy of four service layers is defined

according to Enterprise Architectures (EA) that commonly describe them
as (Lankhorst, 2004):
1. Business is the layer that includes services, which form a

model, a process, an activity and so on. It is the most
abstract representation of services that are present within
enterprise systems in one form or another.
2. Data is the layer that includes services, which collect,

organise, transform, transfer, encrypt, secure and conduct
other operations on data. It is common for enterprise
systems to have various data manipulation services, both
open-source and proprietary.
3. Applications is the layer that includes services, which are

the means for implementing a particular functionality of an IT
5
system. The functionality can be implemented and later

exposed to internal or external networks using Web
Services, APIs and similar technologies.
4. Technology is the layer that includes services, which are

the means for interconnecting IT assets to form an
infrastructure, so they can be utilised cooperatively.
Enterprise IT infrastructures usually consist of networks that
connect computers through various types of hardware and
software hubs.
In enterprise context, these services are in continuous interaction

with one another at various levels of service abstraction (Lankhorst, 2004).
Cloud Computing is an on-going research topic that raises a range

of challenges for enterprises of any size, as it is not just another
improvement paradigm, but a fundamentally new approach to the
provisioning as well as use of IT (Creeger, 2009). Some of the key
challenges caused by Cloud Computing, which are studied throughout the
professional literature, include, but not limited to, the:
! Pervasive and mobile Cloud Computing (Abolfazli et al.,

2015; Mei et al., 2008; Sanaei et al., 2014; Toosi et al.,
2014);
! Power management, new models and protocols for

convergent consistency, stability of large-scale event
notification platforms, management of technologies, impact
of virtualisation on scalability and economies of scale
(Birman et al., 2009; Biswas and Giaffreda, 2014; Moreno-
Vozmediano et al., 2013);
6
! Service Level Agreement in Cloud Computing (Patel et al.,

2009);
! Ethics (Miller and Voas, 2010);
! Standardisation (Borenstein and Blake, 2011);
! Viability of Cloud Computing services in the context of

availability of data and business functionality, protection of
data from unauthorised access and ability to handle security
incidents (Fiondella et al., 2013; Tripathi and Mishra, 2011);
! Trust (Garrison et al., 2012);
! Organisational change, economical implications, security,

legal and privacy issues (James and Chung, 2015; Khajeh-
Hosseini et al., 2010; Ren et al., 2012);
! Migration to Cloud Computing services, service resilience

and e-Government (Andrikopoulos et al., 2013; Catteddu,
2010); and
! Vendor and technology lock-in, service provision, service

integration, cost, performance, competencies, industry
structure, control, monitoring, management, governance,
business risk, policy and so forth (Bannerman, 2010; Jadeja
and Modi, 2012; Trneberg et al., 2015; Vouk, 2008; Q.
Zhang et al., 2010).
Nevertheless, despite of the disruption that Cloud Computing

causes and the innovation it leads to, it is based on a relatively established
paradigm. As such, Cloud Computing is closely correlated with Service-
oriented Computing (Dillon et al., 2010) and Service Oriented Architecture
7
(SOA) is one of its essential technical foundations (L.-J. Zhang et al.,

2010) (Figure 1-3).
Figure 1-3: Service-oriented Approach to the Use of Shared Resources in

the Cloud
Essentially, Cloud Computing in conjunction with Service-oriented

Computing and SOA led to the improvement of old and the development
of new technology paradigms, amongst which are the Hybrid Computing of
Grid and Cloud (Mateescu et al., 2011), High Performance Computing and
Virtualisation in the Cloud (Buyya et al., 2009) and others (Sriram and
Khajeh-Hosseini, 2010). During the recent years, Cloud Computing also
popularised the use of Application Programming Interfaces (API) in
connecting disparate mobile platforms through the Cloud by utilising the
external resources that empower applications on smartphones and
overcome hardware limitations by partially off-loading their execution into
the Cloud (Chun and Maniatis, 2009).
The newest case of using APIs was mainly driven by technological

advancements in smartphones, tablets as well as social networks and
social commerce (Gat and Succi, 2013). It became a basis for
fundamentally new business models and a new type of economy, known
as the API Economy (Succi and Remencius, 2013). Industrial research
8
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).
API, in the API Economy, is used in a broad context and

encompasses: Classical APIs, Web Services as well as any other software
interfaces to the business assets (Gat and Succi, 2013). Yet, the use of
APIs in the application development is based on the similar principles of
service orientation as defined in SOA, but the endpoints are relying on the
JavaScript Object Notation (JSON) (Crockford, 2001), rather than XML
(W3C, 2008), for data definition and instead of Simple Object Access
Protocol (SOAP) (W3C, 2007) traditionally used in SOA, various other
connectivity options (Richardson and Ruby, 2007), are available for use
(APIGEE, 2012).
API can be seen as one of the latest examples of the disruptive

innovation caused by Cloud Computing. However, API itself is a disruptor
that led to the emergence of the Internet of Things (IoT) (Gronbaek, 2008),
which is also on the rise (Atzori et al., 2010). IoT, on the other hand,
influenced the Web of Things (WoT) (Guinard et al., 2011). Cloud
Computing also led to the emergence of Microservice Architecture, which
is a term with no precise definition of the architectural style, that
describes a particular way of designing software applications as suites of
independently deployable services (Fowler and Lewis, 2014). Given the
pace of innovation in IT, there could be even more new technology
9
paradigms, terms and approaches on the horizon in the coming years and
all these developments represent the impact of disruptive innovation on IT.
However, despite of the variety of these newly developed

technology paradigms and the differences in their implementation, they
are still based on the conceptually similar principles of service orientation
that outline their design and architectural considerations. Traditionally, in
IT systems, service orientation is realised through the SOA (Erl, 2005).
The similarities between the SOA and the API, IoT and other paradigms
were extensively studied in the industry and throughout the professional
literature (Agarwal, 2013; Earls, 2012; Gray, 2014; Guinard et al., 2010;
IBM, 2014) and as for the IoT, Guinard et al., stated that the SOA
approaches traditionally used to couple functionality of heavyweight
corporate IT systems are becoming applicable to embedded real-world
devices, that is, objects of the physical world that feature embedded
processing and communication (Guinard et al., 2010, p.223). It was also
concluded that the SOA design principles are at the essence of the API
and IoT (Agarwal, 2013; IBM, 2014; ONeill, 2015).
1.3 Service Oriented Architecture

SOA is a paradigm that outlines a set of principles for the design of
an IT system, the implementation of which is not tied to a particular
vendor, product or technology (Arsanjani, 2004; Baroudi and Halper, 2006;
Chappell, 2004). In SOA environment two actors are playing the main
roles: service providers and service consumers. The interaction might also
involve an intermediate registry or directory that is used by both parties:
the service providers register to the directory, so that the service
consumers could discover them (Boleng and Sward, 2013). Service
providers are also endowed with service contracts that outline their
functionality and connectivity options for the potential service consumers
(Figure 1-4).
10
Figure 1-4: Service Interaction Scenario in Service Oriented Architecture
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).
1.4 Enterprise Service Bus

ESB, often coined as a backbone of SOA (Papazoglou and Van
Den Heuvel, 2007), is the critical component of SOA infrastructure
(Roshen, 2011) that provides essential communication and integration
facilities required to implement a service-oriented system (Keen et al.,
2004). ESB can provide a variety of adaptors and integration brokers that
can be used to integrate legacy and modern applications and further
expose them in the form of services (Figure 1-5). These services can then
interact with each other in an asynchronous manner, through service end-
points, by utilising the reliable message delivery and many other
functionalities of ESB (Chappell, 2004). In these interaction scenarios ESB
acts as a service container, positioned as a layer between the participants,
which can provide the required core functionality in the form of services
(Keen et al., 2004).
11
Figure 1-5: ESB as a Layer between Integrated Applications
ESB arose as one of the important SOA compound design patterns

(Erl, 2008) and can be described as a highly distributed, message-oriented
middleware integration engine that is built upon open standards to provide
routing, invocation and mediation mechanisms to maximise the quality of
service interaction and transaction management between pervasive
services in a secure and reliable manner (Menge, 2007).
Although, the implementation of SOA does not depend on any

technology, the ESB still is the most comprehensive technology that can:
help in enabling SOA; prevent the implementation of accidental
architectures, to which SOA is prone; handle the dynamics of rapidly
changing business needs, by providing all the essential integration means
for the connected services, which constitute the service-oriented system,
and so forth (Boleng and Sward, 2013; Chappell, 2004; Flurry, 2007;
MuleSoft, 2013a; Red Hat JBoss, 2006).
However, despite their emergence more than a decade ago, both

SOA and ESB are associated with a range of challenges that complicate
the implementation of service-oriented systems. Given the role of SOA
design principles in the implementation of service-oriented systems in the
era of Cloud (Nalini and Sanjay, 2013; Roche, 2014), these challenges
worth an in-depth analysis.
12
1.5 Challenges of Implementation

In the early 2000s, one of the foremost challenges for SOA was the
misconception that it is a product yet, SOA was never a product, despite
being widely correlated with the Web Service technology (Arsanjani, 2004;
Oliver, 2012). Other common misconceptions about SOA were associated
with the belief that (Lewis et al., 2007; Rane and Lomow, 2008): SOA can
provide a complete architecture for a system; legacy systems can be
easily integrated into an SOA environment; standards is all what is needed
to implement SOA and guarantee interoperability amongst services; it is
easy to develop applications based on services; SOA can be implemented
quickly; SOA is all about technology; and that SOA governance spans only
to registries and repositories, to mention a few. However, SOA is agnostic
to the technology and needs to be positioned more as a bridge that can
connect IT and Business domains through business-aligned IT services
using design principles, patterns and techniques (Erl, 2008, 2005).
In addition to the above mentioned misconceptions, vendor

approach towards labeling disparately different products as SOA,
complicated the overall adoption of the paradigm: its an architectural
approach that promises to solve knotty problems, but vendors put lipstick
on their product pigs and confuse the market (Rubinstein, 2012).
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
economic recession (Manes, 2009). Some of the key reasons that led to
such a claim were (Linthicum, 2009b):
1. Most of SOA projects were focused on tactics, rather than on

short- and long-term values;
2. Many projects were initially concentrated on technology and

then on architecture, when it is completely backwards;
3. Vendors were selling what they claimed to be an SOA

product, rather the actual solution that could deliver it; and
4. The absence of qualified SOA architects.
Nevertheless, it was concluded that although the SOA might be in

its downfall, the need for service-oriented architectures was stronger than
ever (Linthicum, 2009b; Manes, 2009).
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).
On the contrary, ESB can comprise a collection of technologies,

which may significantly vary from one ESB product to another, in
architecture, features, standards support, interaction with other ESBs,
integration of existing middleware technologies as well as licensing
(Manes, 2007). However, with the explosion of interest in SOA, almost all
of those who had anything that resembled an integration server, message-
oriented middleware, or a message broker, re-labeled their product as an
ESB. Thus, you had dozens of ESBs out there, all different, thus all
supporting the notion of SOA differently (Linthicum, 2008). Nowadays,
this is still apparent from the variety of open-source and commercial ESB
14
implementations offered by leading software vendors, such as the: IBM,

Microsoft, Oracle, SAP, Software AG, Progress Software, Fiorano
Software, TIBCO, Apache, Red Hat JBoss, MuleSoft and WSO2. It is
worth to mention, that if in 2006, according to the Wave Research of
Forrester (Vollmer et al., 2006), leaders amongst the ESB products were
Cape Clear (acquired by Workday Inc., in 2008), Fiorano Software, BEA
Systems (acquired by Oracle, in 2008), Sonic Software (acquired by Rovi
Corporation, in 2010) and IONA Technologies (acquired by Progress
Software, in 2008), then by 2013 the situation on the ESB market had
changed and according to the Magic Quadrant of Gartner (Thompson,
2013) the current leaders are MuleSoft (MuleSoft, 2014), Red Hat JBoss,
Talend and WSO2. Although, such a variety of ESB products may indicate
the importance of the service integration for contemporary enterprises, it
also represents the differences in the interpretation of the ESB, because of
the quite distinct features each ESB product has and because no two
ESBs are alike (Linthicum, 2006). These factors led to the famous
statement, made by David Linthicum, in 2006, who contended that: ESB,
the term not the technology, will no longer be interesting, but the solutions
will (Linthicum, 2006). One of the possible reasons for such an ubiquitous
confusion with the ESB could be the fact that the ESB still does not have a
standard definition (Desmet et al., 2007; Kress et al., 2013).
In addition, many vendors branded their ESB products as SOA in a

Box, which led to the major misconception that ESB can guarantee the
successful implementation of SOA (Linthicum, 2008). On the contrary,
ESB does not equal SOA and even though at the heart of modern
Enterprise Resource Planning (ERP), Customer Relationship
Management (CRM), Supply Chain, Retail Management, and other similar
platforms that integrate services for various purposes, is essentially the
ESB, the resulting system is not necessarily SOA (OShaughnessey,
2013).
15
Because of these challenges, ESBs have a tendency to be found

within components of the architecture where they do not belong, they can
create costly messes and they are dragged into the enterprise for the
wrong reasons, and without the proper amount of planning. Typically,
there is no holistic architecture defined and the enterprise is a huge
collection of one-off tactical solutions that do not work well together. Thus,
the architecture is fragile and static, the opposite goal of SOA (Linthicum,
2008). One of the reasons for these complications is the enterprise focus
on the tactical solutions in the problem domains, rather than on SOA or
EA, and the actual strategic architecture, which takes years to develop
and is an ongoing operation that needs to constantly consider the
dynamics of changes in business needs (Linthicum, 2008).
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
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).
These factors led to the reemergence of the ESB to one of the

essential elements of the Cloud Computing service models, especially the
emerging Integration Platform as a Service (iPaaS) model (Gartner, 2012),
and position it as an ideal Cloud connectivity model (Popa and Vaida,
2015). As was mentioned earlier, beside the three Cloud Computing
service models i.e, SaaS, PaaS and IaaS, defined by NIST, there is also
the EaaS/XaaS service model that can be associated with each of the
three models. The iPaaS can possibly be seen as one of the examples of
the EaaS/XaaS model, because of the crosscutting features it may
encompass.
According to Gartner, the iPaaS is an emerging model that can be

described as: a suite of Cloud services enabling development, execution
and governance of integration flows connecting any combination of on-
premises and Cloud-based processes, services, applications and data
within individual or across multiple organisations (Gartner, 2012). The
iPaaS is also described as: a platform for building and deploying
integrations within the Cloud and between the Cloud and enterprise. With
iPaaS, users can develop integration flows that connect applications
residing in the Cloud or on-premises and then deploy them without
installing or managing any hardware or middleware (MuleSoft, 2012).
Gartner also positions the iPaaS as a potential platform for the buying,
17
selling, and exchange of integration flows (both out-of-the-box and

custom-built) between integration providers, service providers and users
(Gartner, 2011).
In defining the technology context for the iPaaS, Pezzini and

Lheureux of IBM state that: Schematically, we can say that cloud
applications will run on one or multiple application platform as a service
(aPaaS) offerings and will integrate with each other (and with on-premises
applications) through one or multiple iPaaS offerings, which will also be
used to manage the associated governance processes. This is very similar
to the relationship between application servers, ESB suites and SOA
governance tools in a traditional application infrastructure middleware
setting: Applications run on application servers, are integrated through an
ESB suite and the relevant governance processes are managed through
SOA governance tools. The analogy doesnt stop there, however (Pezzini
and Lheureux, 2011, p.6). It was also stressed that the: iPaaS is not a
replacement for an ESB. As a matter of fact, Gartner predicts that more
and more companies are going to adopt a hybrid integration infrastructure
comprising of both an on-premise ESB and an on-cloud iPaaS
(Chandrasekhar, 2013).
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).
Additionally, Cloud Computing can also scale the ESB by

interconnecting multiple ESBs as the iPaaS, which will eventually lead to
the emergence of a new IT model of Cloud of ESBs (Figure 1-6). In such
18
a model capabilities of individual ESBs can possibly be used as shared

resources (for example, services of a service container) across multiple
ESBs, in the Cloud.
Although, the conceptual model of the Cloud of ESBs is beyond the

scope of this research, it must be noted that providing ESB-to-ESB
facilities through the Cloud can greatly benefit the design of service-
oriented systems and enable decentralisation (Haddad, 2012; MuleSoft,
2013b). It may also have a positive effect on the economies of scale,
saving up to 66% on IT costs and half of server instance count, if shared
across eight or more tenants, and increase agility as teams will be able to
rapidly provision an ESB tenant space, automatically enforce standard
security and management features, quickly upload ESB endpoints and
mediation flows, and share a reliable, high availability infrastructure
configuration (Haddad, 2012).
Figure 1-6: Use of Capabilities of Individual ESBs as Shared Resources in

the Cloud
There is an evidence of an increasing use of ESB through the

Cloud, even in the healthcare industry (Barry, 2010). It is clear that the
ESB will remain critical for integrations (Moore, 2013), but depending on
the type of Cloud deployment model, it may raise a range of issues
19
associated with the management, connectivity, security, flexibility, agility,

scalability, distribution, decentralisaiton and so forth (Barry, 2010; Siegeln,
2015; Whner, 2015).
1.6 Research Motivation and Research Question

In the era of Cloud, the economics of integration dictate that there is
a need for a strategy to implement SOA, but with the variety of
technologies that might be involved in the implementation the discovery of
services and on-demand provisioning of missing functionality is a
significant challenge (Guinard et al., 2010, p.223). Although, SOA
implementation does not depend on the ESB, and there could be different
disruptive technologies in development, the use of ESB still is the most
comprehensive approach towards implementing SOA, as it can provide
the decoupling of service interfaces from the actual implementation,
allowing the interfaces to be organised in a consumer-oriented way, as
well as facilitate the realisation of other fundamental principles of SOA
(Chappell, 2004; Erl, 2008, 2007; Fiorano, 2013; Kress et al., 2013;
Lundblad, 2015; Moore, 2013; Orlowski et al., 2014; Riad et al., 2010).
As it was stressed earlier, ESB does not guarantee the success of

SOA, because there is a foremost need for a master plan around
architecture which includes a core understanding of the business
(Linthicum, 2008). However, a sole top-down strategy towards the
implementation of an SOA initiative may still lead to failures, as there are
two sides of the coin, and there is also a need for the bottom-up strategy,
in enabling SOA, of which the ESB is the fundamental element (Chappell,
2004; MuleSoft, 2013a). In other words, without a service integration
platform at the bottom, which can facilitate the master plan at the top, the
initiative might still get compromised.
20
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:
! All ESBs are not the same (Linthicum, 2008);
! ESBs are at the heart of modern ERP, CRM, Supply Chain,

Retail Management, and other similar platforms that
integrate services for various purposes (OShaughnessey,
2013);
! ESBs can converge SOA, API and possibly other emerging

paradigms, whilst being agnostic to the technology platform
(Moore, 2013); and
! Many ESBs are over-bloated and tend to become too much

for an SOA initiative (Olliffe, 2014).
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.
The possible approach for achieving this could be through

Cybernetics, and the prominent Stafford Beers Viable System Model
21
(VSM) (Beer, 1985) in particular. 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. This
overlap can help in developing those generic design principles for the ESB
that would ensure its survival.
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 reasoning formulates the motivation for conducting this

research and leads to the research question being asked:
Can the design of an ESB be improved so that it enables systems

to be integrated without depending upon particular technology or vendor
approaches?
Such a generic perspective may possibly help reuse the same

design approach in the development of policies, procedures and
guidelines for the governance, management, maintenance and
implementation of IT, at the whole enterprise level.
1.7 Conclusion
22
This chapter started our journey in this research by stressing the

need for action in the domains of SOA and ESB, formulated the motivation
for conducting this research and defined the research question.
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.
After formulating the motivation for conducting this research and

defining the research question in this chapter, the next chapter studies the
SOA and the ESB in an in-depth literature review to understand the roots
of both domains and so to establish an approach for improving the design
of ESBs.
23
24
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!
Chapter 2. Literature Review Service

Oriented Architecture and Enterprise Service
Bus
Someone is sitting in the shade today because someone planted a
tree a long time ago.
Warren Edward Buffett
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
2.2 Review of the Existing Literature

An in-depth literature review on the SOA and the ESB was
conducted following the common Systematic Literature Review
methodologies, such as those defined by (Brocke et al., 2009; Higgins et
al., 2008; Okoli and Schabram, 2010; Tranfield et al., 2003; Webster and
Watson, 2002).
The review started with identifying the scope of the literature to be

explored, the search engines to be used and the keywords to be queried.
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.
The search was not restricted to academic publications only and

included the latest trends in industrial journals and various web sources, to
prepare a comprehensive list of literature that would include professional
viewpoints from both industry and academia.
The publications were crosschecked for their relevance and those

irrelevant, to the search topic, were excluded. As such, publications that
were addressing the design in other disciplines, or the articles that used
the term design, in other meanings, were removed. The final list of the
seminal works, relevant to the search topic, is provided below (Table 2-1).
26
Table 2-1: List of the Seminal Works
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
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
deepening the understanding of the design characteristics of ESB, it is

necessary to examine the domain of SOA, of which the ESB can be an
integral part.
2.2.1 What is SOA?
SOA is an architectural paradigm that emerged during the last

decade as a response to the ever-accelerating changes in business
processes, products and services (Abrams and Schulte, 2008). SOA
outlines a set of principles for the design of an IT system, the
implementation of which is not tied to a particular vendor, product or
technology (Arsanjani, 2004; Baroudi and Halper, 2006; Chappell, 2004).
The need for service-oriented architectures was coined by Gartner

(Schulte and Natis, 1996) back in 1996. SOA is the result of the evolution
of Distributed Computing, Component-based Software Engineering,
Interface-based Programming (Papazoglou and Van Den Heuvel, 2007)
as well as CORBA (Channabasavaiah et al., 2003). SOA can be described
as a: ...client/server software design approach in which an application
consists of software services and software service consumers (also known
as clients or service requesters) (Natis and Schulte, 2003); ...paradigm
for organising and utilising distributed capabilities that may be under the
control of different ownership domains (Brown, 2006); and ...architectural
style that supports service-orientation (The Open Group, 2009).
Identified by some organisations as the most important architectural

paradigm in IT (Baroudi and Halper, 2006), SOA outlines design
principles, patterns and techniques (Arsanjani, 2004) that address
requirements for such system characteristics as: service quality,
standardisation, service abstraction, discoverability, federation,
extensibility, composability, loose coupling, location transparency, agility,
scalability, modularity, reusability, flexibility and interoperability, amongst
the many others (Erl, 2005; Huhns and Singh, 2005; Valipour et al., 2009).
29
Essentially, SOA provides a roadmap for the decomposition of

complex monolithic software logic into reusable fine-grained services
(Menge, 2007) that can become the solution seeds for large business
problems (Bygstad and Gronli, 2011; Cherbakov et al., 2005) (Figure 2-1).
Figure 2-1: Decompositions of Business Problem and Software Logic
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).
Systems built upon SOA can be designed as autonomous units

within the enterprise and integrate a diverse range of vendor products as
30
building blocks (Erl, 2005). A typical SOA implementation scenario (Figure

2-2) traditionally built around a central naming service that plays a role of a
hub through which services can be discovered (Boleng and Sward, 2013;
The Open Group, 2009). The naming service also has a service registry
connected to it. Service providers use the service registry to provide the
information about their functionality, which is summarised in a service
contract. Service consumers then use the service registry to discover the
service providers, retrieve the information about the connectivity options,
functionality and other parameters. Interaction between services occurs
through service end-points and ideally does not require service providers
and service consumers to be aware of each other, which in turn
contributes to the overall scalability of the system (Lewis et al., 2010). In
other words, services can interact in a location-independent manner, since
the central naming service would be the only end-point for both the service
providers and the service consumers (Erl, 2005).
Figure 2-2: Typical Service Oriented Architecture Implementation Scenario
SOA is different to the traditional client-server model, because of its

focus on the loose coupling between software components and the
extensive use of standardised integration interfaces (Natis and Schulte,
2003). SOA promotes the reuse of business functionality by encapsulating
its logic into platform-independent services (Lewis et al., 2010). SOA does
31
not prescribe any specific implementation technology, but the most

common technology is the Web Services (Gottschalk et al., 2002; W3C,
2004) that provides the means for interactions between service providers
and service consumers, which are supplied with the relevant service
contracts, standardised interfaces, various binding protocols and data
format specifications (Arsanjani et al., 2008). Other technologies
traditionally used in the course of SOA implementation include, but not
limited to, the: SOAP (W3C, 2007) for data transmission; Web Services
Description Language (WSDL) (W3C, 2001) for service definitions;
Universal Description, Discovery and Integration (UDDI) (UDDI Technical
Committee, 2004) for service registration and discovery (Curbera et al.,
2002); Web Services Business Process Execution Language (WSBPEL)
(OASIS Committee, 2007) for service orchestration (Papazoglou et al.,
2008); eXtensible Markup Language (XML) (W3C, 2008) for diverse data
manipulations; REpresentational State Transfer (REST)ful for building
scalable services (Rodriguez, 2008) and so forth (Benatallah and Nezhad,
2008).
2.2.2 What is ESB?
ESB is one of the important SOA compound design patterns made

of such core patterns, as the Service Broker, Asynchronous Queuing and
Intermediate Routing to provide the interoperability-enablement features
(Erl, 2008). It is often coined as a backbone of SOA (Keen et al., 2005;
Menge, 2007; Papazoglou and Van Den Heuvel, 2007) and as a critical
component of SOA infrastructure (Roshen, 2011) that provides essential
communication and integration facilities required to implement a service-
oriented system (Keen et al., 2004; Schmidt et al., 2005).
ESB can be described as a highly distributed integration engine that

is built upon open standards to provide routing, invocation and mediation
mechanisms to maximise quality of service interaction and transaction
32
management between pervasive services, in a secure and reliable manner

(Menge, 2007; Roshen, 2009). Its features may include, but not limited to,
the: message routing, message-processing, message enrichment,
message split and merge, message format validation, message exchange
patterns, process choreography, complex event processing, process
orchestration, service abstraction, protocol transformation, application
integration adapters, interoperability, integration tooling, commodity
services, queuing, load balancing and governance, amongst many others
(Chappell, 2004; Menge, 2007; Roshen, 2009).
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).
Figure 2-3: Typical Enterprise Service Bus Integration Scenario
33
Such containers provide a wide range of integration and

communication services (Chappell, 2004; Menge, 2007). Communication
services are often implemented using the Java Message Service (JMS)
(The Java Community Process, 2013) technology, whilst the integration
services are built upon open standards, so that the provided facilities could
be used by various heterogeneous applications (Ortiz, 2007). Through
such service containers, the integrated applications can interact with each
other as service end-points, in an asynchronous manner (Garces-Erice,
2009).
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).
At the end of the 90s, complex IT environments, that could often

consist of countless of old as well as new software applications,
databases, web sites, portals and other third party products, were
constantly integrated to work together to deliver value to customers (Ruh
et al., 2002). As there is never one-size-fits-all solution, a wide variety of
technologies was used to integrate these diverse enterprise applications
and services (Liu et al., 2009). However, one of the central challenges of
such integration initiatives was associated with the absence of messaging
engines capable of providing reliable communication and information
exchange between the integrated applications in an asynchronous manner
34
(Linthicum, 2000). As the number of integrated applications was constantly

growing, the problem of integration was scaling and was becoming
increasingly complex to handle (Irani et al., 2003). There was a need for a
type of infrastructure that could complement the EAI in the areas it lacks,
such as the messaging, queuing, routing and so forth (He and Da Xu,
2014).
This complementary infrastructure was realised in the MOM, which

was the asynchronous messaging system providing the backbone of the
EAI (Curry, 2004). A typical MOM architecture (Figure 2-4) traditionally
consists of a message broker, a persistent storage and two or more
applications connected to it through interfaces (Xu and Xu, 2005). The
message broker plays the role of a central queuing system that is
receiving, storing, transforming and sending messages. Persistent storage
is usually a grid of databases that are continuously connected to the
message broker to store messages for further processing. This
architecture provides the means for both the asynchronous
communication and routing. Most importantly, this architecture does not
obligate the integrated applications to be connected, all at the same time,
to exchange messages, as it is capable of reliably delivering messages to
multiple recipients once they are connected to the message broker (Biffl et
al., 2009; Sachs et al., 2009).
35
Figure 2-4: Typical Message Oriented Middleware Architecture
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).
2.3 SOA Principles of Service Design

As was mentioned earlier, SOA is the paradigm that outlines a set
of principles for the design of an IT system, independent from the
underlying technology (Arsanjani, 2004; Baroudi and Halper, 2006;
Chappell, 2004). There are currently eight widely-accepted principles,
advocated by Thomas Erl (Erl, 2007) and popularised through his seminal
work the SOA: Principles of Service Design. These principles are:
1. Standardised Service Contract;
2. Service Loose Coupling;
3. Service Abstraction;
4. Service Reusability;
5. Service Autonomy;
6. Service Statelessness;
7. Service Discoverability; and
36
8. Service Composability.
The application of these fundamental principles can serve as a

guideline towards identifying the design of technology-independent
services (Erl, 2007).
2.3.1 Standardised Service Contract
"Services within the same service inventory are in compliance with

the same contract design standards." (Erl, 2007, p.130)
Through service contracts, services can express their purpose and

capabilities. The Standardised Service Contract is one of the most
fundamental principles in service orientation. Essentially, it outlines
specific considerations that need to be taken into account when designing
the public technical interface of a service to be provided and assessing the
quantity as well as nature of the content that will be published as a part of
the official service contract. In designing the contract an emphasis is made
on how services express their functionality, how data models and data
types are defined, and how the relevant policies are asserted and
attached. It is necessary to constantly ensure that service contracts are
well optimised, granular as well as standardised, so that the services
endpoints are reliable, consistent and governable.
2.3.2 Service Loose Coupling
"Service contracts impose low consumer coupling requirements and

are themselves decoupled from their surrounding environment." (Erl,
2007, p.168)
Coupling refers to a relationship or connection between two entities.

Services tend to have dependencies and the relationship between them is
expressed in terms of coupling. A measure of coupling can be compared
to the level of dependency: for example, tightly coupled or loosely coupled.
37
There are various types of coupling involved in the design of a service,

each of which can impact the granularity as well as the content of a
service contract. The Service Loose Coupling principle promotes the
independent design and evolution of the service logic and its
implementation, whilst ensuring the baseline interoperability with the
consumers that rely on the capabilities of the service. To achieve the
appropriate level of coupling practical considerations need to be taken into
account and be balanced against the actual service design preferences.
2.3.3 Service Abstraction
"Service contracts only contain essential information and

information about services is limited to what is published in service
contracts." (Erl, 2007, p.215)
Abstraction plays an important role in encapsulating the underlying

logic of a service and hiding it from the outside world, providing only the
abstraction of the details that underpin it. The Service Abstraction is one of
the essential principles of service orientation that directly contributes to
how the loosely coupled relationships amongst services are formed. The
Service Abstraction is also essential in designing the service
compositions. Thus, the extent of abstraction applied to a service can
affect the granularity of the service contract and subsequently affect the
ultimate cost and effort of governing the service.
2.3.4 Service Reusability
"Services contain and express agnostic logic and can be positioned

as reusable enterprise resources." (Erl, 2007, p.259)
Service orientation is focused on reusing existing assets.

Reusability is an essential part of the service design process that forms
the basis for future service models. The Service Reusability principle
38
positions services as enterprise assets with agnostic functional contexts.

Clear design considerations need to be taken into account to ensure that
individual service capabilities are defined in accordance with the agnostic
service context and that they can facilitate the necessary reuse
requirements.
2.3.5 Service Autonomy
"Services exercise a high level of control over their underlying

runtime execution environment." (Erl, 2007, p.296)
To constantly and reliably provide their capabilities the logic of

services requires a significant degree of control over their resources and
environment. The Service Autonomy principle supports the design
characteristics that increase service reliability and behavioural
predictability, but also raises issues associated with the design of service
logic and its implementation environment. In defining the suitable measure
of service autonomy, considerations need to be made in the levels of
isolation and service normalisation, especially for reusable services that
are extensively shared.
2.3.6 Service Statelessness
"Services minimise resource consumption by deferring the

management of state information when necessary." (Erl, 2007, p.333)
The excessive management of state information can limit the

availability of services and as a result undermine their scalability potential.
The Service Statelessness principle requires that measures of realistically
attainable statelessness be assessed based on the surrounding
technology architecture to provide deferral options and state management
delegation. Ideally, services are designed to remain stateful only when
required.
39
2.3.7 Service Discoverability
"Services are supplemented with communicative meta-data by

which they can be effectively discovered and interpreted." (Erl, 2007,
p.369)
To be positioned as the reusable assets of the enterprise, services

need to be easily identified and understood when an opportunity to reuse
them arises. The Service Discoverability principle requires service design
to take into consideration both the communications quality and the
individual capabilities of the service, regardless of whether a discovery
mechanism, in a form of a service registry, is part of the environment or
not.
2.3.8 Service Composability
Services are effective composition participants, regardless of the

size and complexity of the composition. (Erl, 2007, p.393)
Creation of effective service compositions is one of the goals of

service-oriented computing. Complex compositions require clear service
designs to avoid possible deviations and refitting overburden of potential
service participants. Complexity of the composition configurations also
grows with the sophistication of the underlying technology. The Service
Composabiltiy principle ensures that these issues are taken into account
when creating a service composition.
2.3.9 Service Orientation and Interoperability
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
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):
1. Service contracts are standardised to guarantee a baseline

measure of interoperability associated with the
harmonisation of data models.
2. Reducing the degree of service coupling fosters

interoperability by making individual services less dependent
on others and therefore more open for invocation by different
service consumers.
3. Abstracting details about the service limits all interoperation

to the service contract, increasing the long-term consistency
of interoperability by allowing underlying service logic to
evolve more independently.
4. Designing services for reuse implies a high-level of required

interoperability between the service and numerous potential
service consumers.
5. By raising a services individual autonomy, its behaviour

becomes more consistently predictable, increasing its reuse
potential and thereby its attainable level of interoperability.
6. Through an emphasis on stateless design, the availability

and scalability of services increase, allowing them to
interoperate more frequently and reliably.
7. Service Discoverability simply allows services to be more

easily located by those who want to potentially interoperate
with them.
41
8. For services to be effectively composable they must be

interoperable. The success of fulfilling composability
requirements is often tied directly to the extent to which
services are standardised and cross-service data exchange
is optimised.
The goal of applying service orientation is for interoperability to

become a natural and expected service design characteristic, as intrinsic
interoperability represents a fundamental goal of service-orientation that
establishes a foundation for the realisation of other strategic goals and
benefits (Erl, 2007, p.57). These strategic goals and benefits are (Erl,
2007):
! Increased intrinsic interoperability;
! Increased federation;
! Increased vendor diversification options;
! Increased business and technology domain alignment;
! Increased ROI;
! Increased organisational agility; and
! Reduced IT burden.
The SOA principles of service design provide a paradigm with roots

in previous computing generations. Compared to them, the principles are
not that new. Yet, in case of service orientation, what is distinct is which
of these existing principles have been included and excluded that and
the high-minded goals promised by its successful application (Erl, 2007,
p.104).
42
To ensure that the application of the design principles is directly

influencing the design characteristics, Erl advises to adhere to the best
practices, such as the (Erl, 2007):
! Incorporate principles within service-oriented analysis;
! Incorporate principles within formal design processes;
! Establish supporting design standards; and
! Apply principles to a feasible extent.
2.4 Characteristics Influencing ESB Design

As was noted earlier, the ESB is a technology concept (Kress et al.,
2013) that can be positioned as the middleware manifestation of SOA
design principles as applied to integration (Chappell, 2004, p.77). It was
also stressed that there is a lot of confusion about the ESB, because of
the absence of the standard definition (Desmet et al., 2007; Kress et al.,
2013). Given the misunderstandings amongst vendors on the ESB
(Linthicum, 2008), combined with the number of industry analysts and
journalists reporting with their opinions on it, understandably there is much
confusion as to what an ESB actually is (Chappell, 2004, p.42). In his
seminal work the Enterprise Service Bus: Theory in Practice (Chappell,
2004), David Chappell outlines fourteen main characteristics that influence
the design of an ESB. These characteristics are:
1. Pervasiveness;
2. Standardised Integration;
3. Distributed Integration and Selective Deployment;
4. Distributed Data Transformation;
43
5. Extensibility through Layered Services;
6. Event-driven SOA;
7. Process Flow;
8. Security and Reliability;
9. Autonomous and Federated Environment;
10. Remote Configuration and Management;
11. Native Data Type;
12. Real-time Throughput of Business Data;
13. Operational Awareness; and
14. Incremental Adoption.
2.4.1 Pervasiveness
ESB can form a pervasive grid that can spawn across an

enterprise, acting as a bridge that interconnects disparate organisational
departments, business units and corporate divisions in a standardised
manner (Figure 2-5). In such an ecosystem, applications can be
connected to the ESB incrementally, which is often the case for large-
scale integration projects. Once connected, applications can start sharing
data as well as discover other applications or services that are connected
to the ESB.
44
Figure 2-5: Enterprise Service Bus can form a Pervasive Grid across Global
Enterprise Network (Chappell, 2004)
Although, ESB promotes the use of standardised technologies,

such as the Web Service, any technology, even proprietary, can be used
instead. Thus, connectivity in the ESB can often be provided through third-
party APIs, protocols, adapters, messaging systems and so forth.
2.4.2 Standardised Integration
ESB provides an infrastructure for integration of both industry-

standard as well as proprietary components through standardised
interfaces that can be mixed together to form an open-ended pluggable
architecture capable of combining various integration options (Figure 2-6).
These options may include J2EE Connector Architecture (JCA/J2CA) for
application adapters connectivity; J2EE components such as the JMS for
MOM connectivity; XML standards such as XPath, XSLT and XQuery for
intelligent routing, data transformation and real-time querying; WSDL, WS-
Choreography and Business Process Execution Language for Web
Services (BPEL4WS) for dealing with business process routing and SOA.
In addition to that, ESB can connect with anything that supports Web
45
Service, API and SOAP technologies, and can integrate components that
are created using the C/C++, C#, .NET and so forth.
Figure 2-6: Enterprise Service Bus can Integrate a Variety of Disparate

Technologies (Chappell, 2004)
2.4.3 Distributed Integration and Selective Deployment
ESB provides functionality that is traditional to most EAI solutions

and includes data transformation, business process orchestration, routing
of data and adapters for applications. However, in comparison with
centralised and monolithic architecture common to EAI, in ESB all these
functions are provided in the form of individual services. This in turn allows
the ESB and services to scale independently and be deployed selectively
at distributed locations within or outside the IT environment that is, on-
premises or outsourced to the Cloud.
2.4.4 Distributed Data Transformation
ESB provides data transformation services at the core of its

integration strategy. Data transformation is vital for realising the value of
46
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.
2.4.5 Extensibility through Layered Services
ESB provides extensive capabilities for complex integration projects

that can be augmented through the use of layered technologies, such as
the Business Process Management (BPM), to manage workflows or
business processes, along with services that provide data conversions into
XML and services that manage business partners through collaboration
servers. Such integration tooling is also capable of providing visualisation,
deployment and other additional services that can extend the base
functionality of the ESB.
2.4.6 Event-driven SOA
ESB can enable the event-driven SOA. In such a setting,

applications are exposed as services that are abstracted away from
underlying implementation protocols, including routing mechanisms and
are acting as generic application endpoints that treat messages they
receive as events, which they then process. In complex event processing
scenarios, the event-driven architecture is usually implemented with
pattern matching, interpretation, and other mechanisms, to process events
during the asynchronous message exchange. ESB is responsible for the
asynchronous message delivery and automation of business processes in
real-time enterprise. These capabilities can be used for the integration,
customisation and composition of new services, which may combine the
47
functionality of several application endpoints and possibly extend the

capabilities of ESB, promoting the even greater reuse of the existing
assets.
2.4.7 Process Flow
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
2.4.8 Security and Reliability
ESB supports firewall-enabled connectivity options for all interacting

endpoints that may include both the services in its own ecosystem as well
as the services provided through external ESBs. The security measures
are established using rigid authentication, access control, credential
management, message encryption/decryption and other security
mechanisms that can be implemented as required. Reliability in the ESB is
supported by the modern MOM solutions that provide asynchronous
communications, transactional integrity and reliable delivery of data.
2.4.9 Autonomous and Federated Environment
ESB can help organisations in building federated environments with

autonomous units, capable of scaling globally, as organisation grows
(Figure 2-8). This feature is critical for any contemporary enterprise that
consists of multiple business units operating independently from one
another. One of the biggest issues in the old integration approaches,
especially those build around the traditional hub-and-spoke EAI solutions,
was the limitation to span across corporate networks, along with granting
local units enough autonomy to operate independently. Thus, they could
not support decentralised infrastructures and in contrary were
consolidating entire data flow in a centralised location. Apparently, for
enterprises whose units are operating independently, or semi-
independently, an option for an infrastructure that can provide the
necessary level of autonomy, yet federate shared resources, business and
other type of data flow, is more preferable. In such environments, business
units can localise their IT functions down to their own boundaries and
therefore manage more efficiently internal message routing, security rules
and business processing, while still effectively operate externally as a part
of a more generic infrastructure that may consist of other, similarly
autonomous, business units. ESB provides the model capable of installing,
49
configuring, managing and securing local message traffic, business

processing and other types of components. In the ESB, autonomy is
achieved through the abstraction of endpoint definitions from the details of
physical deployment, including wire protocols, orchestration as well as
routing data, whilst federation is achieved through the segregation and
selective traversing of application domains and security boundaries.
Figure 2-8: Enterprise Service Bus is an Autonomous and Federated Unit

that can enable Cooperative Federation of Operations across Organisational
Boundaries (Chappell, 2004)
2.4.10 Remote Configuration and Management
ESB provides the means for the monitoring, logging, audit,

administration, remote configuration and management of services, which
are subject to distribution at both local and global scales (Figure 2-9).
Amongst these mechanisms is also the integration blueprint that enables
smooth integration of pervasive ESBs. This is achieved through the
detailed interfacing of connectivity protocols, access permissions, security
management, application adapters and message channels to a remote
location. The purpose of the integration blueprint is to act as a
customisable template that can be deployed at any location, operate
independently and provide the functionality needed for each specific IT
50
setting. This can especially be beneficial, in times when applications of

pervasive infrastructures are similar in nature. Thus, rather than deploying
the same tools at each location, a single infrastructure can be shared
amongst the sites. Apparently, it must also provide enough capacity and
capability to handle a substantial amount of requests. The use of
integration blueprints, as a unified integration mechanism, can boost the
overall adoption of ESBs in highly distributed ecosystems and help in
balancing the degree of coupling, autonomy and federation. However, the
overuse of this integration approach may lead to creation of highly
centralised, rigid and inflexible infrastructures, prone to costly interruptions
that may occur during message exchanges. It is therefore necessary to
undertake a careful analysis of the overall IT infrastructure prior to making
any integration decisions and a viable balance between the centralised
and decentralised designs must be established.
Figure 2-9: Enterprise Service Bus Configuration Blueprint can be Deployed

at a Remote Location and be Remotely Configured and Managed (Chappell, 2004)
51
2.4.11 Native Data Type
ESB provides a range of capabilities for carrying out data

interpretation, transformation and representation, as it flows through the
services. However, beside these capabilities, ESB natively supports the
XML data format that can enable the use of specialised services, which
can combine data from various sources, retarget it for advanced data
sharing as well as enrich it when needed.
2.4.12 Real-time Throughput of Business Data
ESB supports real-time data flow, which can eliminate or

dramatically reduce the latency problems across interacting services.
Compared to the popular integration methods, such as the nightly or
bulk/batch processing, that often result in costly delays in information
retrieval, ESB provides an infrastructure with the capability and capacity
for real-time throughput of business data.
2.4.13 Operational Awareness
ESB provides operational awareness through an infrastructure that

gains information about the state of business operations, along with the
timely data tracking and reporting, as it flows in real-time through the
enterprise (Figure 2-10). The standardised data formats, such as the XML,
can advance the operational awareness of the ESB through various
layering services that can be shipped with an ESB product or installed as
an extension. As such, the XML data format is at the basis of value-added
services that generate real-time, notifications, alerts and reports regarding
the state of basic and complex services, which include, but not limited to,
the: auditing, tracking, monitoring, routing, process flow, data collection,
data aggregation, data caching, visual rendition and so forth. In case of
basic services, the real-time generation of notifications is typically
achieved through the use of specialised auditing and tracking points within
52
process flows that enable data monitoring, reporting as well as collection

of contents of business messages, which travel through the business
processes. In case of complex services, the real-time generation of alerts
is usually achieved through the special caching and aggregation points
that are set to collect, transform and queue data, and forwarded it to other
applications for reports generation. All these built-in and add-on
capabilities of ESB can significantly improve the overall operational
awareness in the enterprise as well as position the ESB as a more
preferable solution for business intelligence, compared to other traditional
Business Activity Monitoring solution stacks.
Figure 2-10: Value-added Services can enable Operational Awareness and

Provide Real-time Insight into Live Business Data (Chappell, 2004)
2.4.14 Incremental Adoption
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
a vast number of ESBs (Figure 2-11). Such incremental approach in

integration is possible because of the federated and autonomous
capabilities of ESB, which can help in realising immediate values from the
integration initiative and quickly detect possible errors and adjustments
that need to be made in the course of integration. Given that ESBs are
often incorporated into legacy infrastructures, which usually consist of
legacy message brokers and integration hubs, this capability can also
promote the greater reuse of existing infrastructure assets and play a
central role in the overall transformation and evolution of enterprise IT.
Figure 2-11: Enterprise Service Bus can enable Continuous Integration

through Incremental Adoption (Chappell, 2004)
2.5 Research and Applications

Despite their emergence more than a decade ago, both SOA and
ESB remain active research topics in industry and academia.
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
extensively examined throughout professional literature. Research

applications in this domain include, but are not limited to, the use of SOA
in:
! Service-oriented EA (Knippel, 2005; Steen et al., 2005);
! Design of device architectures (de Deugd et al., 2006);
! Industrial automation and management (Cucinotta et al.,

2009; Komoda, 2006; Thramboulidis, 2015);
! Development of SOA maturity models (Inaganti and

Aravamudan, 2007);
! Development of methods for business service management

(Werth et al., 2007);
! Service-oriented solutions (Arsanjani et al., 2008);
! Development of a generic enterprise SOA model (Tang et

al., 2008);
! Alignment of Business and IT domains (Berkem, 2008);
! Service-oriented enterprise (Graves, 2009);
! Cloud-based travel reservation SaaS (Namjoshi and Gupte,

2009);
! Service-oriented Computing and Cloud Computing (Blake

and Wei, 2010);
! Service-oriented Cloud Computing Architecture (Tsai et al.,

2010);
55
! Understanding the economic potential of service-oriented

systems (Mueller et al., 2010);
! Constructing the urban geographic information public service

platform (Hou, 2010);
! Pervasive computing (Tigli et al., 2011);
! Testing, validation and support (Bertolino et al., 2011;

Sanders et al., 2008);
! Service-oriented web application framework (Demirkan et al.,

2011);
! Decision Support Systems (Vescoukis et al., 2012);
! Implementing a CRM process (Das and Kundu, 2012);
! Integration of wireless sensor and actuator nodes with IT

infrastructure (Kyusakov et al., 2013);
! Building automation and smart cities (Jung et al., 2013);
! Integration within EA (Alwadain et al., 2013);
! Optimisation of industrial applications (Girbea et al., 2014);
! Remote machine control (Lojka et al., 2014);
! Integrated EA Framework for the alignment of Business and

IT domains (Zarvi and Wieringa, 2014); and
! Achieving business agility in recovering markets (Bharadwaj

et al., 2015).
The research in the domain of ESB is closely correlated with that of

SOA and spans across such common areas as the service orientation,
56
integration, interoperability and so forth (Garces-Erice, 2009; Luo et al.,

2005). The role of ESB in large-scale enterprises (Li and Yang, 2013) is
studied throughout professional literature and its applications include, but
are not limited to, the:
! Intelligent mediation (Hrault et al., 2005);
! Rapid system of systems integration (Krueger et al., 2006);
! Dynamic reconfigurable service routing (Bai et al., 2007);
! Performance prediction of service-oriented applications (Liu

et al., 2007);
! Reliable service routing (Ermagan et al., 2008; Lundblad,

2015; Wu et al., 2008);
! Content-based intelligent routing and message processing

(Ziyaeva et al., 2008);
! Development of multi-language SOA (Sward and Whitacre,

2008);
! Building of message middleware stack for real-time SOA

(Garces-Erice, 2009);
! Modelling of service-oriented performance (Brebner, 2009);
! SOA-based grid computing (Riad et al., 2010);
! Universal Serial Bus (USB)-like ports (Roshen, 2011);
! Automation of EA documentation (Buschle et al., 2012);
! Platform for financial self-service equipment (Xiao et al.,

2013);
57
! Public service platform of regional logistics (Guangyao et al.,

2014);
! Data processing systems (Barcia et al., 2014);
! Semantic integration (Harcuba and Vrba, 2015); and
! Multi-mission systems (Xing and Zhai, 2015).
It was noted that ESBs vary in their implementations and because

of the vast number of vendors, which interpret ESB differently, no two ESB
products are alike (Chappell, 2004; Kress et al., 2013; Linthicum, 2008,
2006). To contemplate the differences between the various ESBs, the
table below (Table 2-2) provides a comparative analysis of some of the
most popular commercial and open-source ESB products on the market.
The table compares the core features of Microsoft BizTalk, MuleSoft ESB,
Apache ServiceMix and BEA AquaLogic (Oracle product, from 2008).
Table 2-2: Comparative Analysis of Commercial and Open-source

Enterprise Service Bus Products
Characteristics/ESB BEA Apache MuleSoft Microsoft

Products AquaLogic ServiceMix ESB BizTalk
Extensible Stylesheet
Language Y Y Y Y
Transformations
Pluggable Extensible
Stylesheet Language
Y Y Y Y(P)
Transformations
Engine
Custom
Y Y Y Y(P)
Transformations
Scripting N Y Y Y(P)
Rules Engine N(S) Y Y Y
Business Process
N(S) Y Y Y
Management
Scheduling N(S) Y Y Y
Built-in Data Storage Y Y N Y
Java Calls Y Y Y Y(P)
Monitoring Y N N Y
Call Tracing Y N N Y
Built-in Test Client Y N N Y
Hypertext Transfer Y Y Y Y
58
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
As it is seen from the table, depending on the vendor, some ESB

products have features the other products do not. One of the reasons
behind this is the difference in the implementation technology used in
each product, at the basis of which could be either Java Business
Integration (JBI) or Windows Communication Foundation (WCF), or
Service Component Architecture (SCA).
JBI is the Java Specification Request (JSR) 208 for the

implementation of SOA using Java Technology (Oracle, 1995): JBI
59
employs concepts similar to J2EE to extend application packaging and

deployment functionality to include JBI Components. JBI Components are
an open-ended class of components that are based on JBI abstract
business process metadata. The JBI JSR itself does not define how
developers code Components. Both standard and proprietary ways of
coding Components may exist. A specific class of Component may
provide rich business process functionality while another class of
Component may provide a specialised integration function like a data
transformation table or support a domain specific business rule encoding
(The Java Community Process, 2005). JBI is a pluggable architecture that
allows integration of additional components through a communication
bone, decoupling them from a direct interaction. JBI consists of the JBI
Environment, the JBI Machine and the JBI Binding. The JBI Environments
define a standard internal representation for business protocol messages
based on standard business protocol metadata and are linked to the JBI
Machines and JBI Bindings, through this representation; the JBI Machines
are responsible for supporting the lifecycle of a particular class of JBI
Components; and the JBI Bindings are used by the JBI Environments to
communicate with external services via specific business protocol
bindings (The Java Community Process, 2005).
WCF is a framework for building service-oriented systems: Using

WCF, you can send data as asynchronous messages from one service
endpoint to another. A service endpoint can be part of a continuously
available service hosted by Internet Information Services, or it can be a
service hosted in an application. An endpoint can be a client of a service
that requests data from a service endpoint. The messages can be as
simple as a single character or word sent as XML, or as complex as a
stream of binary data (Microsoft, 2012). WCF is implemented as a set of
classes built upon Microsofts proprietary .NET Frameworks Common
Language Runtime. WCF-based services can run in any Windows process
60
and interact with services internal or external to the environment, through

SOAP and other communication protocols (Chappell, 2009). WCF
features: Service Orientation, Interoperability, Multiple Message Patterns,
Service Metadata, Data Contracts, Security, Multiple Transports and
Encodings, Reliable and Queued Messages, Durable Messages,
Transactions, Asynchronous JavaScript and XML (AJAX), REST and so
on (Microsoft, 2012).
SCA is a set of specifications that describe an implementation

model for building systems based on SOA paradigm: SCA is based on
the idea that business function is provided as a series of services, which
are assembled together to create solutions that serve a particular business
need. These composite applications can contain both new services
created specifically for the application and also business function from
existing systems and applications, reused as part of the composition. SCA
provides a model both for the composition of services and for the creation
of service components, including the reuse of existing application function
within SCA compositions (Edwards, 2011). SCA is an initiative that was
created and supported by such leading software vendors, as IBM (IBM,
2007), Oracle (Oracle, 2009) and TIBCO (TIBCO, 2012). SCA aims to
encompass a wide range of technologies, service components and access
methods that include distinct programming languages, various frameworks
and environments used with the languages, along with communication and
service access technologies that include various messaging systems as
well as Web Services and RPCs (Edwards, 2011). SCA attempts to deliver
a programming model for SOA, which would be a non-Java-specific,
metadata-driven model that can describe the composition of services
without the JBI (Sholler and Smith, 2005).
Amongst the other prominent ESB vendors, also known to rely on

the JBI, WCF or SCA in their products, are: Blackbird, Cape Clear
Software, Cast Iron Systems, ChainBuilder, Fiorano Software, IONA
61
Technologies, iWay Software, Neudesic, ObjectWeb, OpenEAI, OpenLink

Software, Oracle, OrderWare Solutions, Paremus, PolarLake, Progress
Software, Red Hat, SAP, Skyway Software, SOA Software, Software AG,
TIBCO Software, Vitria Technology and WSO2.
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.
2.6 Research Objective

As it was shown, despite the main characteristics that influence the
design of an ESB (Chappell, 2004), there are no two identical ESBs, same
as there is no one-size-fits-all ESB (Linthicum, 2008) and nor should the
ESB be regarded as a particular product that can guarantee the success
of an SOA initiative (Keen et al., 2005, 2004; Manes, 2007). Some of the
key reasons for that, which can be derived from the earlier discussions,
are:
62
! SOA is more about strategy, not the technology (Linthicum,

2009b; Manes, 2009); and
! ESB is not a specific technology, but an architectural style or

pattern that can combine various technologies to facilitate
the SOA (Chappell, 2004; Erl, 2008; Kress et al., 2013).
If the ESB is chosen to facilitate the SOA, it is necessary to

contemplate the impact of the ESB on the implementation of the SOA
(Chappell, 2004; MuleSoft, 2013). As such, the characteristics that
influence the ESB design, reviewed earlier in this chapter, seem to
suggest that besides services at the application level that are integrated
through the ESB as a part of an SOA initiative, there are also services at
the support level that are facilitating the actual integration. These
services include, but not limited to, the: process orchestration, data
transformation, protocol transformation, message encryption, message
routing, message enrichment and so forth (Chappell, 2004; Menge, 2007;
Roshen, 2009). In other words, there are several crosscutting layers of
services that need to be considered in the course of SOA implementation.
This viewpoint can be visualised using the model developed by Barrios
and Nurcan (Barrios and Nurcan, 2004) that outlines three interrelated
enterprise layers, such as the: Business Goals, Business Processes and
Information Systems (Figure 2-12).
63
Figure 2-12: Enterprise Representation Layers (Barrios and Nurcan, 2004)
Using these layers, for the abstract representation of services within

an SOA initiative, the following correlations can be derived: the Business
Goals layer would represent the service goals defined in the SOA strategy,
at the top; the Business Processes layer would represent the services
integrated through the ESB at the application level; and the Information
Systems layer would represent the services at the support level, those
inside the ESB, that facilitate the actual integration from the bottom.
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
However, as there is no standard definition for the ESB (Desmet et

al., 2007; Kress et al., 2013), the ESBs get over-bloated with functions that
tend to become too much for an SOA initiative (Olliffe, 2014), whether it is
implemented on-premises or in the Cloud. Taking into account the effects
of disruptive innovation (Christensen, 2015), it is also unclear what other
types of technologies may emerge and get incorporated into ESB, or other
service integration platforms, in the future. Such obscurity can make the
SOA inherently complex and compromise it (Linthicum, 2008; Roche,
2014).
Although, there are characteristics that influence the design of an

ESB (Chappell, 2004), there is currently no model that could ensure the
survival of the designed ESB, despite of the changes in technologies that
may underpin it that is, the services at the support level, embedded into
the ESB, such as the data transformation, protocol transformation,
message encryption and so on. Thus, as was highlighted in the previous
chapter, there is a need to address the design of the ESB from a generic
perspective that would be agnostic to the technology, product and
vendor. The current research in academia has a gap in this area and
therefore worth attention.
This generic perspective needs to focus on the set of essential

functions, in the form of generic design principles, which must be defined
in the ESB, rather than on every possible technology that could be
embedded into it. These generic design principles can possibly be
combined in a model that would replicate the ESB and ensure that the
ESB designed upon it will survive despite of the possible disruptive
technologies, which may arise in the future. Given that ESB can be an
integral part of SOA, the survival of the ESB at the bottom can become
essential for the survival of the SOA at the top. Additionally, depending on
the type of organisation, survival at each of these levels can recursively
65
scale and partially contribute to the survival of the whole enterprise.

Hence, the objective of this research is to:
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:
1. Develop the generic design principles for the ESB, in a

model that would ensure the ESB survival; and
2. Ensure the survival of the ESB, independent from the

technologies that may underpin the ESB.
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
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
Beers VSM (Beer, 1985) in particular, to identify its suitability for

developing those generic design principles for the ESB that would ensure
its survival.
67
68
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model
Chapter 3. Theoretical Foundation

Cybernetics and Viable System Model
"It is not the strongest of the species that survive, but the one most
responsive to change."
Charles Robert Darwin
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
are bonded by a common set of principles (Skyttner, 2005). Amongst

these principles is the Ashbys Law of Requisite Variety (Ashby, 1956) that
is at the essence of organisation theory.
3.2.1 Requisite Variety
In Systems Science, 'variety is a measure of complexity

(Christopher, 2007). To handle complexity, it is necessary to understand
the system, the relationships amongst its parts, including the number of
behavioral distinctions within it (Espejo and Reyes, 2011). Variety
measures the complexity of the system by counting the number of
possible states it can be in (Beer, 1985). Given that in complex
environments it might practically not always be feasible to count all the
possible states, a comparative statement about the degree of variety (for
example, one system has a higher variety, than the other) can still be
made and when necessary asserted by using probabilistic methods
(Christopher, 2007).
The variety of the system depends on the context it is embedded in

and the ones who are observing the system (Hilder, 1995). Contemporary
organisations tend to be embedded in complex and dynamic environments
and in order to cope with substantial variety, they employ various filters in
the form of attenuators and amplifiers to reduce the variety that arises
from the environment and to increase their own variety to influence the
environment (Beer, 1985; Hilder, 1995).
Ashbys Law of Requisite Variety interprets the role of amplifiers

and attenuators in handling variety in the following statement: Control can
be obtained only if the variety of the controller is at least as great as the
variety of the situation to be controlled (Ashby, 1956). In other words, only
variety can absorb variety. For organisations, this means that an
organisation must exhibit capacity that is, variety sufficient enough to
match the potential environmental states, that can impact organisations
70
purpose (Millar, 2009). Thus, an organisation without requisite variety

would be unable to respond and adapt to unexpected changes in the
environment. As a result, this lack of adaptation can jeopardise the
organisations long-term viability (Beer, 1985).
Ashbys Law of Requisite Variety is one of the fundamental

principles in Cybernetics and especially in the VSM. This law is usually
considered to be obvious, once understood (Hilder, 1995). Yet, it is
important to contemplate the role of the law in the design of units and the
relationships amongst them, in viable organisations, rather than regarding
it only as a statement of a law of nature.
If applied to the ESB, the Ashbys Law of Requisite Variety may

enforce the design to consider the extensibility of the platform. That is, the
variety of services at the support level must be at least as great as the
variety of integration requirements of services at the application level.
3.3 Viable System Model

In 1972, Stafford Beer applied the laws and principles of
cybernetics, including the Ashbys Law of Requisite Variety, to formulate
the VSM a blueprint for designing organisations that are able to survive
and thrive in changing environments (Beer, 1972). VSM is the cybernetic
model for designing the communication and control aspects of a viable
system. The VSM was fully described in his trilogy: Brain of the Firm
(Beer, 1981, 1972), Heart of Enterprise (Beer, 1979) and Diagnosing the
System for Organisations (Beer, 1985). The VSM is described as a
neurocybernetic model that draws upon research on the human nervous
system, especially on the brain (Leonard and Beer, 1994). At the core of
the VSM is the concept of viability; that is, a system able to maintain a
separate existence (Beer, 1985).
71
VSM is a holistic model that encompasses a wide range of

cybernetic concepts, amongst which are (Beer, 1985):
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;
18. Regulation Centre;
72
19. Resource Bargain;
20. Accountability;
21. Comparator;
22. Feedback;
23. Convergence;
24. Self-awareness;
25. Ethos; and
26. Algedonic Signals.
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
Figure 3-1: Viable System Model (Beer, 1985)
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
Prior to describing each of the systems of the VSM, it is necessary

to understand the fundamental concepts upon which the viable systems
are built. These concepts include Viability, Recursion and Black Box.
3.3.1 Viability
The foremost purpose of any system is to maintain viability

(Christopher, 2007). A viable system thrives to survive on its own in the
environment, while maintaining a separate existence (Beer, 1979).
Separate existence shall be interpreted in the context of autonomy.
However, autonomy shall not imply the existence in vacuum, but within the
environment that may consist of other systems, each having a separate
identity. Thus, existence is never independent of other existences and can
only survive within a supportive environment (Beer, 1985). Survival is a
precondition for reaching other organisational purposes, but systems are
created not only for mere surviving (Millar, 2009), but to achieve some
purpose or outcome that is meaningful to its original founders or current
stakeholders (Christopher, 2007, p.39). This means that the purpose of a
viable system, such as of a business system, is in the continuous creation
of value for its customers, by providing products that would match or
exceed the customers expectations (Christopher, 2007, p.59): Purpose
might be stated in terms of market position, some level of organisation
development, some level of quality/productivity, some level of innovation,
some basic level of profitability. However stated, purpose needs an
emphasis on creating value for customers.
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
organising systems have purposes. These purposes provide the

framework for their maintenance of identity. Lack of purpose is usually
indicative of the impending collapse of a self-organising system.
Viability implies the organisations ability to sustain its existence in a

dynamically changing environment through its capacity to learn and adapt
(Beckford, 2002). This means that organisation must be capable of
maintaining a stable operation over time, able to respond to familiar
disruptions, as well as have the capacity to respond to unexpected ones
(Espejo and Reyes, 2011). Thus, viable organisations tend to be capable
of adapting appropriately to their chosen environment or adapting the
environment to suit their needs (Hoverstadt, 2011). According to Beer
(Beer, 1981, p.239) a VSM-based organisation have all the mechanisms
and opportunities to grow and to learn, to evolve and to adapt to become
more and more potent in its environment. This statement is also
supported by Lewis and Millar (Lewis and Millar, 2010) who assert that in
the complex world, surviving must not only be interpreted in the context of
existing, but also in growing, adapting and learning.
If applied to the ESB, the concept of Viability can be correlated with

the purpose of providing standardised integration. Although, it is superior
to the existing characteristics that influence the ESB design, this
correlation imply that an ESB will not survive in the environment, if it does
not provide integration in a standardised manner.
3.3.2 Recursion
VSM is recursive. Stafford Beer describes the recursive nature of

VSM in the Recursive System Theorem, which states, that: in a recursive
organisational structure, any viable system contains, and is contained
within, a viable system (Beer, 1981, p.228). This implies the fractal
structure of the VSM, in which subsystems have the same generic
organisational characteristics, as the systems there are contained in
76
(Hoverstadt, 2011). For example, organisations, such as firms, are often

subsidiaries of larger corporations. At the same time, these firms may also
consist of subsidiaries. In the context of VSM, these subsidiaries, firms
and corporations are all viable entities that contain these organisations
and are contained within them. In other words, they are all recursions of
the viable system. The same can be applied to other similar chains of
embedded recursive systems. Together they form the recursive
dimensions. However, in the VSM recursion does not imply to just a loose
insertion of one system inside another, but to an absolutely precise
definition of viability (Beer, 1985).
As embedded replications of the containing viable system, viable

systems have the capacity to deal with complexity inherent in their local
environments that are themselves sub-sets of the environment of the
containing system (Millar, 2009). This means that an embedded system
can attenuate variety that needs to be managed at the higher level of
recursion, whilst local management can amplify the variety of the
organisation with the respect to its environment (Jackson, 2003). Thus,
recursive structures provide the means for managing most of the
complexity locally, leaving only some residual variety to be handled by the
senior management (Espejo and Reyes, 2011).
The fractal structure of the VSM can help organisations in dealing

with the complexity of their activities as well as their environment
(Hoverstadt, 2011), because the recursive nature of the VSM provides a
vast attenuator of the huge variety in the structure and operations of any
large company (Christopher, 2007, p.20). Thus, the fractal structure can
be used to model and understand organisations regardless of their size or
the degree of complexity (Hoverstadt, 2011). Being a fractal model, VSM
replicates the same organisational mechanisms at each level of recursion
in each and every sub-system contained within the viable system
(Hoverstadt, 2011). This means that the recursive nature of the VSM
77
provides the means for distributing accountability and responsibility

throughout the organisation, for facilitating the decision-making at multiple
levels of organisation through series of conversational processes between
the levels (Hoverstadt, 2011) and for ensuring that each autonomous unit
at each structural level is fully aware of the short, medium and long terms
(Espejo and Reyes, 2011, p.85).
If applied to the ESB, the concept of Recursion can be correlated

with pervasiveness. Given that ESB can be selectively deployed at
different locations, provide distributed integration and be incrementally
adopted, this correlation implies that in complex environments multiple
ESBs can handle various integrations needs, at different levels of an
integration initiative, ultimately leading to the formation of system of ESBs,
as in the case of Cloud of ESBs.
3.3.3 Black Box
Black Box is a cybernetic concept that provides a robust approach

towards managing organisational complexity, when used in conjunction
with recursion. This concept is especially essential for large organisations,
in which senior managers are practically unable to obtain information
about all possible states of subsidiaries, for which they are responsible.
They cannot intervene within lower level operations (Christopher, 2007),
as command of total information is seldom possible or even desirable
(Skyttner, 2005, p.79). Therefore, operational units must be treated as
black boxes and according to Stafford Beers First Regulatory Aphorism:
It is not necessary to enter the black box to understand the nature of the
function it performs (Beer, 1979, p.40). As those outside an operational
unit, including the senior management, do not have the requisite variety to
handle the variety of the unit, all what needs to be known is what goes into
the unit (for example, resources such as people, financial assets,
78
information and so on), what goes out of it and what are the relations
between the inputs and the outputs (Christopher, 2007).
If applied to the ESB, the concept of Black Box can also be

correlated with the standardised integration. Although, it is superior to the
existing characteristics that influence the ESB design, this correlation
implies that an ESB must be treated as a Black Box, which can be
understood through its inputs and outputs, with relations between them
being regulated by the supported standards.
3.4 Systems of the VSM

Stafford Beer developed the VSM based on the Ashbys Law of
Requisite Variety that was used to derive the VSM and organisational
principles (Millar, 2009) when creating the science of organisation (Beer,
1985), which are: the principles that underpin all organisations, and
create viability, which is the capacity to exist and thrive in sometimes
unpredictable and turbulent environments (Hoverstadt, 2011, p.27).
As was demonstrated in the previous section, there are possible

correlations between the VSM and the ESB, and these correlations imply
the many-to-many relationship. However, prior to determining the further
correlations, it is necessary to analyse the structure of the VSM to
understand how it was derived. The following sections provide a thorough
review of the five systems of the VSM, whilst Chapter 5 investigates the
influence of the organisational principles on viability.
3.4.1 System ONE Operations
The part of the VSM that produces it is known as System ONE

(Beer, 1985). System ONE of the System-in-focus forms a set of
embedded viable systems (Millar, 2009). Because System ONE
implements the System-in-focus, it is also known as the Implementation
79
function (Millar, 2009). System ONE produces products and services at

different levels of aggregation and therefore the instances of System ONE
contribute directly to the value chain of the organisation that implements
its purpose (Espejo and Gill, 1997). The primary activities, the instances
of System ONE undertake, influenced by the organisations identity,
deliver the actual products and services of the organisation (Hoverstadt,
2011). Thus, without System ONE there would be no sense for the
organisation to exist (Hilder, 1995).
Depending on the nature of the organisation, it may consist of a

number of System ONE instances (Millar, 2009). These instances are
determined by unfolding the primary activities of the organisation
(Hoverstadt, 2011) during the modelling process (Christopher, 2007). One
of the approaches in determining the instances is to identify what the
System-in-focus does that is, its purpose, and consecutively detect the
instances that undertake the activities towards the purpose (Brocklesby et
al., 1995). It must be noted that the instances of System ONE are not
necessarily the departments in the organisational chart and such
identification might be misleading and mistaken: Defining these viable
businesses involves much more than selecting boxes from the traditional
organisation chart. A viable business system: (1) offers products and
services to customers in the marketplace; (2) has an operations structure
for providing and marketing those products and services; (3) has the
management needed for the above (Christopher, 2007, p.46).
System ONE instances also include the management of the

operations (Christopher, 2007), but not the senior management, which is
positioned more as a service for the System ONE (Hilder, 1995). In the
VSM, the senior management is defined in between System TWO and
System FIVE, which form the meta-system (Figure 3-1). Meta-system is a
system that is over and beyond a system of lower logical order to which
the higher-level authority might not be applied (Beer, 1985). Thus, the
80
meta-system is the actual control system of the System-in-focus (Flood

and Carson, 1993).
Identifying System ONE instances within organisation is not a trivial

task and requires the senior management to carefully analyse the
organisational scope, within the context of the VSM (Christopher, 2007). It
starts with determining the primary activities of the organisation that are
divided into sub-activities (Hoverstadt, 2011), which are responsible for
carrying out the value-adding tasks for the given System-in-focus, and
unfolds to the end point where a complete work is conducted by a team
that can resemble a manufacturing cell (Espejo and Gill, 1997). Theory
suggests that a System ONE instance shall be able to survive in its given
environment, if extracted from the containing System-in-focus (Brocklesby
et al., 1995). The theory also states that, a human being can be positioned
as a viable system, although in complex organisational contexts the
System-in-focus is a model of cooperation between individuals (Espejo
and Gill, 1997).
The recursive nature of the VSM implies the autonomy of the

System ONE instances within the System-in-focus (Beer, 1985). These
instances exhibit all the features of the VSM and thus have the capacity to
self-regulate and self-organise (Millar, 2009), in accordance with the
dynamics of the environment they interact with: the viable System ONE
has the capability to exist on its own. But it doesnt exist on its own. It is a
part of the total company, with many interrelationships that make the
company much more than the sum of its parts (Christopher, 2007, p.46).
It is therefore expected that viable systems, regardless of the structural
levels they occur in, will contain as many further sub-systems as needed
to handle the complexity of their environments (Christopher, 2007). In
other words, the degree of freedom granted to System ONE instances
directly contributes to the capacity of these instances to absorb the variety
of their local environments and to the capability to respond to
81
environmental changes in line with their own priorities (Jackson, 2003).

However, to preserve cohesion within the system it is expected from
System ONE instances to operate strictly within the purpose of the whole
system and the relevant control must be imposed on the autonomy to
achieve this (Beer, 1985). Yet, it is important to note that in the VSM
control and autonomy are not the opposites. Rather, the capacity and
capability of the System ONE instances to absorb the environmental
variety, make the actual control of organisational outcomes possible
(Espejo and Harnden, 1989).
It is also necessary to note that in an organisation, along with

operational departments, there are other departments that are not part of
the value chain and exist only to carry out support of the main activities of
the organisation. Such departments (for example, financial, human
resources and so on) are called support functions (Espejo and Reyes,
2011) as well as service units (Beer, 1979). Service units are distinct from
business units in that (Kaplan and Norton, 2006):
1. They exist not for profit, but for the support of the business
units; and
2. Their customers are usually internal to the organisation.
Differentiation of operational departments from service departments

is often a cumbersome task: it turns out in practice to offer the worst
problems, and the most traps to intending users (Beer, 1979, p.120). One
of the approaches to achieve this differentiation is to identify System ONE
instances through the concept of viability. As was mentioned, viability
implies the separate existence of embedded operational units that is, of
System ONE instances. On the other hand, service units support the
activities of operational units and must not be positioned as a contained
viable system. For example, for a manufacturing firm an IT department
might provide essential services to facilitate the production process, but it
82
does not implement the purpose of the organisation. Therefore, in this

setting an IT department is a service unit: it supports operations, but does
not do them (Millar, 2009). This definition of IT as a service unit means
that for the given System-in-focus, the manufacturing firm, an IT
department cannot be a viable system on its own right (Beer, 1985) and
might be more relevant to the System THREE instead, as it contributes to
the overall synergy of operational units (Beer, 1979).
3.4.2 System TWO Coordination
The part of the VSM that undertakes anti-oscillatory activities in the

System ONE, of the System-in-focus, is known as System TWO (Beer,
1985). System TWO is an important regulatory mechanism that provides
the following four functions (Christopher, 2007):
1. Coordination of actions in the operational units;
2. Transducing information from System ONE to higher-level

management;
3. Communicating corporate parameters and monitoring

compliance; and
4. Budgeting and budgetary control.
Amongst these functions, the most important function is the

coordination, which ensures that the balance between the autonomy of the
sub-subsystems and the cohesion of the whole system is achieved.
As was mentioned earlier, operational units must be granted the

considerable degree of autonomy, provided that organisational cohesion is
maintained: Given their freedom, operational units possess considerable
flexibility in how they respond to the demands of their environments.
However, this flexibility comes at a cost. When an operational unit uses its
83
independence to maximise its performance, it may adversely impact other

units (Millar, 2009, p.46). For example, this may occur in times when two
or more operational units are competing for the same customer on the
market or the same resource within the organisational scope.
Such conflict of interests might lead the system to a less stable

state and ignite the oscillation. Oscillation is a specific sickness of
homeostasis (Beer, 1985). It is a condition in which every subsidiary of the
System-in-focus tries to adjust to the every other one. Because this
process is continuous, the adjustments never end, thus leading to
oscillation. Oscillation must be damped or otherwise it might lead to a
collapse of the system, on both local and global scales. In the VSM,
System TWO (Figure 3-1) is the function that dumps the oscillation, as it:
ensures that the activities of the operational units do not conflict with one
another (Hoverstadt, 2011); and anticipates, eliminates and resolves such
conflicts when they occur (Christopher, 2007).
In situations where conflicts require higher authority for resolution,

System THREE might get involved (Christopher, 2007). Thus, senior
management (that is, the meta-system, the next level of recursion) can
also provide coordination, but this coordination does not imply
commanding requisite variety for the resolution of a conflict (Beer, 1985),
as any attempt to do so would put constrains on the freedom of the
operational units and limit their ability to handle the dynamics of their
respective environments, and provide effective and efficient response
(Beckford, 2002).
Moreover, coordination by self-adjustment is a high variety function

that reduces the residual variety, which needs to be managed by other
parts of the meta-system (Espejo and Harnden, 1989) and by supporting
self-regulation it also preserves the local autonomy: The more teams can
share common standards, approaches and values, the greater the
84
chances that spontaneous lateral communication will occur, resulting in

less re-invention of the wheel and more chance of synergy. The stronger
these lateral links, which are of both a technological and human nature,
the less the requirement for management to attempt to impose control
from above and the greater the sense of autonomy and empowerment
experienced by the subsumed primary activities (Espejo and Gill, 1997,
p.3).
System TWO coordination mechanisms can be simple, but

extremely powerful and take the form of: common standards, protocols,
operations/production scheduling, and as well as these formal
mechanisms, common language and shared cultures that ease
communication between operational units can be important as can mutual
agreement between units (Hoverstadt, 2011, p.29). All these means can
smoothen the problems between operational units and prevent activities of
one unit to disrupt the activities of another (Hoverstadt, 2011). In addition,
System TWO works closely with System THREE and can be considered
as embedded into it (Christopher, 2007). It is unlikely for the senior
management to have requisite variety to dictate the operation of System
TWO and this mostly needs to be organised by the management of
System ONE, instead. Ignoring this fact might lead to significant errors on
the side of senior management, which might consequently disrupt the
entire organisation: Where co-ordination mechanisms fail, we find
problems such as: process bottlenecks, failed production planning, turf
wars between departments, conflicting messages to customers (internal or
external), and appeals to higher management to sort the mess out
(Hoverstadt, 2011, p.29).
Another important role of System TWO is to assure that System

ONE complies with corporate parameters. Corporate parameters outline
what needs to be done in each System ONE instance (Christopher, 2007),
in order to keep the operations smooth and prevent unnecessary
85
disruptions. Corporate parameters usually include ethical behaviour,

corporate act, corporate policy as well as the use of trademarks and
names, and so on (Christopher, 2007). Such coordination of System ONE
instances, by System TWO, greatly limits the amount of variety generated
and prevents its further proliferation to the higher-tier levels of
management, contributing to the overall balance within organisation.
If necessary, each System ONE instance can be coordinated by

more than one System TWO of the higher level of recursion. In other
words, for the given System-in-focus System TWO can scale horizontally.
These additional instances of System TWO follow the same rules: they are
not positioned at the command axis and thus do not exercise executive
authority; they are dependent on the Senior Management of the System-
in-focus; they treat System ONE as a whole, regardless of a number of
instances it encompasses (Beer, 1985). Presence of several System TWO
instances is beneficial in situations when more than one oscillatory source
is identified and requires regulation. However, in any case, System TWO
must not be positioned as the mechanism of a hierarchical structure with
the authority higher than that of System ONE. Apparently, its sole anti-
oscillatory purpose, which implies gathering of additional knowledge on
possible regulatory options, might create a sense of power that is often
misinterpreted in organisations (Beer, 1985). A clear definition of System
TWO role must be declared to avoid any such misunderstandings.
3.4.3 System THREE Management
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
System TWO operates (Christopher, 2007). Therefore, it can be best

associated with the inside-and-now daily management of the enterprise
(Beer, 1985). System THREE functions might include: budgeting,
accounting, human resources, engineering, quality control, marketing,
sales and so on.
System THREE plays an important role in providing the overall

cohesion inside the System-in-focus. It must integrate the operational
elements into a cohesive whole (Espejo and Harnden, 1989), so that the
total system would perform much better than the sum of its parts acting
independently (Skyttner, 2005). Espejo and Reyes (Espejo and Reyes,
2011, p.98) state that cohesion is one of the main mechanisms for the
viability of the system that must be balanced against the autonomy of
operational units: For a collective to become an organisation they need to
achieve cohesion Cohesion requires aligning individual and collective
interests. This alignment does not imply that individuals and their collective
have the same interests and purposes, but that however different these
might be, the implementation of individuals purposes produces the
purposes collectively ascribed to the organisation. Thus, cohesion is an
important mechanism for reaching structural alignment, whilst keeping the
autonomy of operational units intact as well as for solving the
centralisation and decentralisation dilemma in organisations.
System THREE is in charge of directing and controlling the

operation of System ONE management (Beer, 1985). However, as it does
not have enough variety to intervene the decision-making process of lower
level operational units, it perceives them as black boxes, leaving the
decision-making to each respective operational unit (Christopher, 2007).
This means that only minimal meta-systemic intervention of System
THREE into elemental autonomy is usually needed (Beer, 1979).
87
System THREE exercises control using the vertical command

channels as well as by negotiating resources through a two-way
communication channel (Figure 3-1), which ensures the flow of
accountability reports upwards to the meta-level management to keep it in
touch with the operations of sub-units of the System-in-focus, as a
prerequisite for viability (Beer, 1985). Resource negotiation is done
through a resource bargain that is at the heart of the balance between the
control and autonomy (Mingers and Rosenhead, 2001). Resource bargain
outlines what System ONE does, its boundaries, resources, performance
measures, goals, purpose (Christopher, 2007) and determines which
activities are done, and which are not (Mingers and Rosenhead, 2001).
Resource bargain is another mechanism that allows the senior
management to control the actions of operational management by
imposing restrictions on bargain, so that the operational management
would agree to reach particular objectives in exchange for resources, such
as the financial, corporate assets, human capital and so on, available in
the System-in-focus (Beer, 1985).
System THREE also monitors the coordination activities of System

TWO (Hilder, 1995) and is responsible for how the anti-oscillatory
functions of this system are performed (Beer, 1985). It collaborates with
System TWO to prevent as well as resolve any conflicts that might occur
in the System ONE operational units (Christopher, 2007). Thus, whilst
System THREE is a collaborator and a negotiator, System TWO is a
regulator, a facilitator and a tiebreaker, which is in need of System THREE
authority to provide decisions in times of conflicts in the operational units
System THREE may also need to ensure that System ONE

management is not accidentally pulling the wool over their eyes (Hilder,
1995) and for this reason it is authorised to initiate infrequent checks,
audits in the operational units (Beer, 1985). This is done through a special
88
extension function of System THREE, known as System THREE*, which is

by consensus not positioned on the command axis (Figure 3-1). System
THREE* undertakes audit activities that are sporadic, high variety and
intra-operational, defined in terms of System THREE to restore its
requisite variety and System THREE is responsible for the design and
operation of System THREE*. System THREE* is designed to connect the
meta-level management with sub-units, bypassing the management of
sub-units, to ensure that the reports regarding the true state of operations
are accurate and reflect the reality, rather than personal bias about the
situation. As its role is to top up the requisite variety of System THREE,
any corrective actions identified during an audit must be transmitted to the
operational units through the corporate intervention channel, rather the
audit channel (Beer, 1979). However, over-usage of audit activities can
have implications on the overall organisational viability and therefore it is
necessary for the System THREE* to comply with a set of rules that shall
lead to its more effective use. That is, System THREE* shall: be sporadic,
rather than regular to avoid any anticipations and pre-planned
preparations (Beer, 1979); be infrequent so it will not undermine the
authority and trust in the sub-units management (Beer, 1985); be openly-
declared mechanism of which everyone is aware to reduce reactive and
defensive behaviours during audits and cross-checks (Beer, 1979); and
link only two contiguous levels of recursion as inclusion of more levels is
often practically unworkable because of the complexity involved, but most
importantly it may also lead to the corruption of the overall integrity of the
System-in-focus and a complete breakdown of trust through sections of
the entire organisation (Espejo and Gill, 1997).
3.4.4 System FOUR Intelligence
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
concerned with the management of the inside-and-now of the System-in-

focus, System FOUR is concerned with the management of the outside-
and-then of the system (Hilder, 1995). System FOUR is a necessary
mechanism that supports the coevolution of the System-in-focus with
agents in its environment and provides the capacity to adapt to
disturbances in the external environment, which could threaten the internal
stability of the system: But it is not enough for the collective to become a
cohesive whole to maintain viability; in addition this cohesive whole must
be adaptive to changes in its environment. This is the hallmark of viability
and a necessary condition to transform the collective into an organisation.
An effective enterprise is one that not only does things right but is also
able to find the right things to do. Moreover, a responsible enterprise is
one that finds ethical means to do the right things. Capacities for
adaptation and sensitivity to the ecosystem are normally associated with
the enterprises normative and strategic levels of management (Espejo
and Reyes, 2011, p.105).
In the VSM, System FOUR is in a continuous homeostatic loop with

System THREE (Christopher, 2007). This homeostatic linkage is there
because intelligent adaption cannot be achieved without understanding of
the current state of the organisation (Hilder, 1995). For System FOUR
the outside-and-then and System THREE the inside-and-now, the
linkage is as strong as it is for the future with the past (Christopher, 2007).
Therefore, any proposal for adaption must be coordinated with System
THREE, to balance the creative drive of the intelligence function with the
realties of the organisation and to prevent System FOUR from dictating
strategies that are unproductive or unworkable (Millar, 2009). This rich
interaction between System FOUR and System THREE is depicted in the
figure (Figure 3-1) with two thick curved arrows. This homeostatic
relationship obeys the four principles of organisation (Beer, 1985) and the
loop that it forms is different to the low variety central command channel
90
that connects two systems, as it lacks the capacity to handle huge variety
(Beer, 1979).
Furthermore, System FOUR consists of the model of itself

embedded into the model of the System-in-focus (Millar, 2009). This
recursive embodiment that includes all the relationships is indefinite. The
System FOUR responsibility is to monitor the external environment,
undertake the intelligence function, in which the organisation is operating
and to provide an insight on the internal organisational capabilities, so that
the organisation can adapt appropriately and plan ahead its course of
evolution. Because the recursive embodiment is indefinite, the ability to
adapt is distributed throughout the layers of organisational recursion
(Millar, 2009). At the lower levels of recursion, the operational units are
viable units themselves, whose management units must be endowed with
the intelligence function that would allow them to adapt to the disturbance
in their local environment. However, as the total environment of the
System-in-focus is greater than the sum of the local environments of the
System ONE instances (Beer, 1979), they do not have the capability to
handle the total environment. Therefore, there is a need for System FOUR
that can provide understanding of the total environment, by undertaking
intelligence activities for the whole System-in-focus.
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
shape the future (Beer, 1985). In Systems Science, innovation is a

characteristic of viable systems and is also a necessity for the business
success. The VSM and Systems Thinking can help innovation happen
It must be mentioned that a rational balance between the loops

needs to be preserved, as: too much focus on the external environment
may overwhelm organisation with data that can reach its capacity and
corrupt proper interpretation, and actions that might need to be taken; and
too much focus on the internal organisational aspects, its unique identity
and the message that needs to be sent to the environment, may lead to
the development of poor communication mechanisms that would be
incapable of listening for a feedback from the external environment (Beer,
1985). To ensure that a viable balance between the loops is preserved
and the course of evolution is following a well-developed plan, the
intelligence shall be supplied with an up-to-date model of the organisation
(Beer, 1979).
The System FOUR intelligence function in a corporate setting

includes: strategic planning, innovation, environmental relations, finance,
market research, research and development (Christopher, 2007). This list
of functions is the same for all System FOUR units, regardless of the level
of recursion. However, at lower levels there might not be units for so many
functions and instead these functions may take the form of individual
assignments. Nevertheless, their presence at all levels of recursion is
necessary (Christopher, 2007).
In addition to the functions outlined above, people that execute

System THREE functions, such as the: human resources, engineering,
marketing, finance, accounting, quality and productivity, will be working in
conjunction with System FOUR, when dealing with the outside and then
(Christopher, 2007). Together, all these functions endow the organisation
92
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).
It must be noted that System FOUR cannot do the job of intelligent

adaption without containing a model of the whole organisation, including
its environment. The quality of such internal model is essential for the
capability of the organisation to adapt to changes (Hilder, 1995) and as the
Conant-Ashby Theorem, derived from the Law of Requisite Variety, states
every regulator must contain a model of the system being regulated
(Beer, 1979). The model that is to regulate the system must exhibit the
requisite variety to deal with all possible states of the system or otherwise
the system could fall into a state that is beyond its capacity to comprehend
and control. In this case, the VSM can aid the design of the model of the
system and its environment (Hilder, 1995).
The apparatus of adaption (Beer, 1979, p.101) for the organisation

is provided through the three functions of System FOUR (Lewis and Millar,
2010):
1. Sensing the current environment and contemplating possible

futures (using the and loops respectively);
2. Making sense of the organisations purpose and value

proposition in a turbulent world (using models of the
organisation and its environment); and
3. Thinking strategically about what direction the organisation

should steer, to adapt to an unknown and unknowable future
(using the System THREE System FOUR loop).
93
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).
3.4.5 System FIVE Policy
The part of the VSM that is responsible for creating a corporate

ethos for the System-in-focus is known as System FIVE (Beer, 1985).
System FIVE is the logical closure of the VSM (Figure 3-1) that connects
the next levels of recursion: it is the point of self-reference where the
identity of the system is asserted and no more systems are placed above
it at a given level of recursion (Beer, 1979). The ethos System FIVE
creates, forms the flexible atmosphere, rather than a rigorous set of
objectives, for the entire system. Therefore, the ethos serves as a variety
sponge of gigantic capacity (Beer, 1985). Without System FIVE the
embodied elements of the collective may fail to achieve the status of an
organisation (Espejo, 2011, p.899).
For an organisation, strategic decision-making is the process of

matching its reality that is, the AS-IS of System THREE, to the future
needs and objectives that is, the TO-BE of System FOUR (Hoverstadt,
2011). However, as these functions are concerned with different time
spans and environments, an additional function is needed to balance the
two. This additional function is the System FIVE, which is the overall
policy-making entity of the VSM (Beer, 1979).
In contemporary organisations, System FIVE can be compared to a

board of directors that is usually responsible for the corporate course
94
(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
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).
However, the achievement of the desired balance in the System

THREE and System FOUR loop, might also impact the System FIVE,
leaving it nothing to do and subsequently putting it into a somnolent state
(Beer, 1985). In this state sleep turns into coma and coma becomes
death (Beer, 1979, p.406). To avoid it, a special signal, called algedonic,
which is depicted as a hatched line flowing directly to System FIVE (Figure
3-1), is deployed to wake up System FIVE in the events that require
immediate attention, so that the development of potentially distort
situations can be averted (Beer, 1985).
In organisations, System FIVE is responsible for the companys

most important executive decisions determining company structure and
management principles. Structure defines the company, its purpose, and
its boundaries; establishes company goals and performance measures;
and provides the needed resources. Management principles determine
how the structure will be managed (Christopher, 2007, p.75). It is different
to System THREE, that performs many executive functions in relation to
operations, in providing the executive direction to the organisation
96
(Christopher, 2007). Paul Rubinyi describes more than twenty functions in

relation to the executive leadership of System FIVE in his book
Unchaining the Chain of Command (Rubinyi, 1998). Organisations that
do not comprehend the difference between System THREE and System
FIVE are prone to become inherently unstable (Hilder, 1995).
System FIVE is also responsible for overseeing the structure and

functionality of all the functions of System FIVE, System FOUR, System
THREE, System THREE*, System TWO and System ONE instances
(Christopher, 2007). This governing role of System FIVE ensures that
organisation has all the mechanisms it needs to achieve the desired
efficiency and internal cohesion (Hoverstadt, 2011).
With System FIVE, the viable system is a self-contained and self-

sufficient whole with its personality and purpose (Hilder, 1995). Thus, the
role of System FIVE is not about mere management of organisations
values, but its identity (Hoverstadt, 2011), including the understanding of
its existence, relevance to its stakeholders and the business areas and
their meaning in a particular context (Espejo and Harnden, 1989, p.84).
Another role of System FIVE is to understand how the organisation

fits into the larger system of which it is a part. For a department, this is a
matter of understanding the larger organisation and its politics. At the
corporate level, it is the reason we have non-exec directors and join
industry bodies (Hoverstadt, 2011, p.36). As a policy-making entity within
organisation, System FIVE, through the ethos formation, outlines the
values and beliefs that underpin the philosophy of organisations existence
(Beckford, 2002), provides the overall personality and character of the
organisation (Christopher, 2007) and also ensures that the organisation
has an identity and that this is known and acted upon (Mingers and
Rosenhead, 2001, p.274). This puts System FIVE in a position of
97
providing leadership for realising the structure of the organisation,

including the principles by which it is managed (Christopher, 2007).
3.5 Adaption of the VSM

The interdisciplinary nature of the VSM led to its wide adaption in
various applications, in a number of industrial and academic studies.
Some of these applications include, but not limited to, the:
! Enterprise Process Architecture (Vidgen, 1998);
! Viable System Architecture (Herring and Kaplan, 2001);
! System dynamics mapping and modelling project for the

Australian Taxation Office (Haslett and Sarah, 2006);
! EA management (Buckl et al., 2009);
! Creating sustainable organisations with the VSM

(Hoverstadt, 2011);
! Enterprise Viability Model that extends the EA frameworks

for modelling and analysing viability under turbulence
(Oduntan and Park, 2012); and
! Mapping the EA principles in The Open Group Architecture

Framework to the cybernetic concepts (Zadeh et al., 2012).
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
then the elements of the organisation that provide these services should
be modelled as embedded operational units.
Another application of the VSM is the framework for analysis of

viability in service systems, developed by Golnam et al. (Golnam et al.,
2011). Authors use the Systemic EA Method to gain an understanding of
how service systems, in energy sector, maintain their identity and remain
viable in their environment. By applying the theoretical basis of Systems
Science and Organisational Cybernetics, Golnam et al. investigate an
utility company, as a service system, that is the System-in-focus, and the
energy segment, as its total environment. The environment comprises the
Government, as the regulator, and Gas and Electricity consumers (both
individual and company) as the service adopters.
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):
1. Coordinate Develop the Business (bridge between System

FIVE and System FOUR);
2. Coordinate Change the Business (bridge between System

FOUR and System THREE); and
3. Coordinate Run the Business (bridge between System

THREE and System ONE, and also between System ONE
instances).
In the enterprise context, the Develop the Business is the kind of

work typically done by a Portfolio Management Group, attached to the
99
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).
Graves stresses that although, the coordination-services are of

different types, they still also need to coordinate with each other and
hence the VSM can provide a checklist of services that are needed for
coordination of interactions between services, because (Graves, 2014):
! Every service needs some means to manage coordination of

change of itself as a whole Coordinate Develop the
Business;
! Every service needs some means to manage and coordinate

the myriad of structural and design-level changes to itself, in
response to internal and external needs Coordinate
Change the Business;
! Every service needs some means to manage and coordinate

run-time links between its sibling-services in the same
service-cluster, and with services in other service-clusters
Coordinate Run the Business; and
! Every service is likely to need an Any-to-Any connection

with other services, such as for emergency response, or
notification of non-manageable exceptions.
These assertions signify the importance of services embedded into

a System-in-focus, for the fulfillment of its purpose, as almost by
definition, a service will be unable to provide any of those coordination-
functions directly within itself, because the whole point is that such
coordination-services operate in the spaces between other services
(Graves, 2014).
100
VSM can also be adapted to address the purposeful role of

individuals in organisational systems. One of the examples of such
systems is the Scrum Agile Software Development Framework. The
Scrum is one of the most prominent frameworks for the management of
people in the continuous delivery of software products. VSM can be used
for aligning the team roles in the Scrum according to the cybernetic
concepts embedded into the VSM. Although, this research is focused
solely on the ESB, such study can help in identifying the balance between
agility and viability in the rapid development, delivery and deployment of
software products.
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.
The provided examples indicate that more work is necessary to

investigate these areas of the research. However, because of the limited
time of a PhD program, the focus of the current research is narrowed to
address only the generic design principles of the ESB, which could be
useful and usable for designing various service integration platforms and
101
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.6 Critiques of the VSM

It must be mentioned that despite of the increasing popularity of the
VSM, in professional studies, it also receives a considerable amount of
criticism. For example, the VSM was criticised by Ulrich for underplaying
the purposeful role of individuals in organisations (Ulrich, 1989, 1981) and
by Checkland for consequent failing in considerations of social and
political dimensions of organisations (Checkland, 1980). Flood and Carson
note that the component parts of organisations are human beings, who
can attribute meaning to their situations and can therefore see in
organisations whatever purposes they wish and make of organisations
whatever they will (Flood and Carson, 1993, p.89).
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.
The relationship between the concepts of SOA and VSM, analysed

by Graves (Graves, 2014), indicate that the VSM can provide the structure
for embedded services, which are needed for the coordination of services
in the service-oriented enterprise. Recalling the potential overlap between
the ESB and the VSM, including the early correlations derived in this
chapter, this application of the VSM demonstrates that it can be suitable
for providing the structure for the services embedded into the ESB that
is, those at the support level. Given that the existing characteristics that
influence the design of an ESB do not ensure its survival, the VSM can be
102
a reasonable model for developing the generic design principles, which

would guide the necessary design considerations.
Positioning the ESB as the actual System-in-focus, in this research,

the theoretical foundation is now established to develop the generic design
principles for the ESB. However, prior to proceeding with the development,
a suitable methodology must be chosen to help in answering the research
question and assist in achieving the research objective. The next chapter
tries to find such a methodology, by investigating various approaches in
Information Systems discipline, and particularly in the Design Science
Research.
103
104
Chapter 4. Methodology Design Science Research
Chapter 4. Methodology Design Science

Research
"A designer knows he has achieved perfection not when there is
nothing left to add, but when there is nothing left to take away."
Antoine de Saint-Exupry
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.
4.2 Research in Information Systems

Information Systems (IS) is a multi-disciplinary field that is
empowered by a diverse range of philosophies and research approaches
(Galliers and Land, 1987; Shanks et al., 1993). It is commonly agreed that
the IS, being a new field of study, mostly uses the achievements of other
disciplines, such as the computer science, social science and economics
105
(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).
The multi-disciplinary nature of IS is investigated in a wide range of

IS research methods, most of which are summarised by Niglas (Niglas,
2001) in the diagram (Figure 4-1), which is an extension to the types of
qualitative research methods defined by Tesch (Tesch, 1990). She
represented the diagram in three-dimensions, which are: the philosophy-
methodology continuum, unfolding from top to bottom; the quantitative-
qualitative continuum, unfolding from left to right; and the relationships and
influences of various research paradigms combined in a two-dimensional
scheme, with the second dimension being stretched to both sides from the
centre.
Figure 4-1: Research Methods in Information Systems (Niglas, 2001)
Although, the IS is rich in the research methods, because of its

reliance on multiple fields, one property that makes the IS unique is the
106
use of artefacts in human-machine systems (Jones and Gregor, 2007).

Thus, the IS can be positioned as a discipline that is at the intersection of
knowledge of human behaviour and knowledge of properties of machines:
Research in the information systems field examines more than just the
technological system, or just the social system, or even the two side by
side; in addition, it investigates the phenomena that emerge when the two
interact (Jones and Gregor, 2007, p.313).
In addition, the IS is an applied science (Galliers and Land, 1987),

which means that its research findings should be applicable in the real
world. This thought is supported by Peffers et al. (Peffers et al., 2007) who
articulate the application of IS in the creation of artefacts that aim to solve
problems and guide professionals in doing their work in the real world
settings. This in turn is consistent with the idea of the available forms of
science for the socio-technological systems, as depicted in the diagram
(Figure 4-2). The diagram represents the socio-technological systems in
the intersection of social science, which is usually interpretivist (Rainbow
and Sullivan, 1979); natural science, which is mostly positivist (Galliers
and Land, 1987); and practical science.
Figure 4-2: Available Forms of Science (Lewis, 2013)
107
Knowledge that can be acquired at the intersection of technology,

people and organisations is a direct contributor to the effective and
efficient implementation of IS in organisations (Hevner et al., 2004).
It is also emphasised that the research in IS is characterised by two

complimentary, but different paradigms: Design Science and Behavioural
Science (March and Smith, 1995). The latter has its roots in natural
science and aims to develop and justify theories that explain or predict
human and organisational behaviour (Simon, 1969). The former aims to
go beyond the human and organisational boundaries by creating new and
innovative artefacts (Hevner and Chatterjee, 2010). The Design Science
Research gets an increasing recognition, attention, encouragement and
authority (Gregor, 2006; Hevner et al., 2004; March and Smith, 1995).
4.3 Design Science Research

As was mentioned earlier, the IS being an applied discipline aims to
create artefacts that can solve problems and guide professionals in doing
their work in the real world settings (Peffers et al., 2007). This context of
the IS was taken as the basis for the proposition by Hevner et al. (Hevner
and Chatterjee, 2010) who stressed that the Design Science Research
(DSR) paradigm is: highly relevant to IS research because it directly
addresses two of the key issues of the discipline: the central, albeit
controversial, role of the IT artefact in IS research (Benbasat and Zmud,
2003; Orlikowski and Iacono, 2001; Weber, 1987) and the perceived lack
of professional relevance of IS research (Benbasat and Zmud, 1999;
Klein, 2003). Simon (Simon, 1969) and Alturki et al. (Alturki et al., 2012)
contended that the DSR is suitable for the IS research as ...the design
aims to change the current status into the desired status. IS aims to build
systems that help people to achieve the desired status. Thus, DSR and IS
have the same intention, making DSR suitable for IS research (Alturki et
al., 2012, p.311).
108
The DSR distinction from the Behavioural Science is in the design

of the actual artefact (Hevner et al., 2004; Jones and Gregor, 2007;
Peffers et al., 2007), as it seeks to create innovations that define the
ideas, practices, technical capabilities, and products through which the
analysis, design, implementation, management, and use of information
systems can be effectively and efficiently accomplished (Hevner et al.,
2004, p.76). Aken (Aken, 2004) positions the Behavioural Science as
being descriptive, explaining what is and the DSR as a research
methodology that focuses on the actual outcome of what can be (Simon,
1969). Thus, the DSR emphasises the development and performance of
designed artefacts, with the explicit intent to improve their functional
performance (Aken, 2004) or as Walls et al. state (Walls et al., 1992):
design theory is a prescriptive theory based on theoretical underpinning
which says how a design process can be carried out in a way which is
both effective and feasible. This statement is supported by Gregor
(Gregor, 2006), who describes the design theory as the one that gives
prescriptions in the form of principles and guidelines for constructing an
artefact. This contrast with the Behavioural Science positions the DSR as
a prescription-driven, rather than description-driven methodology (Aken,
2004).
A summary by Alturki et al. (Alturki et al., 2012, p.314) outlines

other important differences between the Behavioural Science and the
DSR, and whilst the former concentrates mainly on the analysis, to
discover the components of an existing system, the latter focuses mainly
on the synthesis, to shape those components (Walls et al., 1992). The
DSR looks ahead to create possibilities by producing artefacts, whereas
the Behavioural Science looks back to explain the past through constructs,
theories, and laws (Purao, 2002). The DSR is characterised by knowing-
through-making and the Behavioural Science by knowing-through-
observing (Purao, 2002). The Behavioural Science is focused at the
109
exploration and validation of generic cause-effect relations; and the DSR

is focused at the construction and evaluation of generic means-ends
relations (Winter, 2008).
The prescriptive, or normative, nature of the DSR is one of its

fundamental distinguishing features (Gregor, 2006), as it allows to focus
on solving problems, in which prescriptions are of heuristic origin (Aken,
2004). The DSR is sometimes correlated with the improvement research,
that actualises the context of the DSR, which is defined in the
performance-improving or problem-solving activities (Kuechler and
Vaishnavi, 2008). The DSR is also concentrated on the pragmatic
validation, to justify the belief that problems are always related to the given
context: The prescription is to be used as a design exemplar. A design
exemplar is a general prescription which has to be translated to the
specific problem at hand; in solving that problem, one has to design a
specific variant of that design exemplar (Aken, 2004, p.227).
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
In the IS, various design activities have been studied, formalised,

normalised and became routine. In contrast, within the IS, the DSR is
driven to solve the problems that are of wicked nature, characterised as
(Hevner et al., 2004, p.81):
! Unstable requirements and constraints based upon ill-

defined environmental contexts;
! Complex interactions among subcomponents of the problem

and its solution;
! Inherent flexibility to change design processes as well as

design artefacts (that is, malleable processes and artefacts);
! A critical dependence upon human cognitive abilities (for

example, creativity) to produce effective solutions; and
! A critical dependence upon human social abilities (for

example, teamwork) to produce effective solutions.
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
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)
Design Science Routine Design

How to resolve a type of problems Solve one case only
Addresses abstract or a class of problems Addresses a particular problem for a
for a class of organisations and specific organisation and stakeholders
stakeholders
Solves unaddressed important problems in Solves problems using existing knowledge
a new and effective way
Technology Invention Technology Application
Contributes to the knowledge base (a Does not contribute to the knowledge base
development of scientific knowledge) (an application of scientific knowledge)
Produces new knowledge (novelty) Uses current/existing knowledge
Unknowns (not known) things in the Design is known
planned design
General solution Specific solution
4.4 DSR Approaches

The DSR is an engineering research methodology, with a scope in
a variety of applied domains, as the design activities are central to most
applied disciplines (Hevner and Chatterjee, 2010). As was stated earlier,
the DSR involves the design of novel or innovative artefacts and the
analysis of the use and/or performance of such artefacts to improve and
understand the behaviour of aspects of IS (Vaishnavi and Kuechler, 2004,
p.1), so that new knowledge can be contributed to the body of scientific
evidence (Hevner and Chatterjee, 2010, p.5).
There are various perspectives on the processes and outputs of

DSR in the IS domain (Kuechler and Vaishnavi, 2012; McKay and
Marshall, 2005; Peffers et al., 2007; Vaishnavi and Kuechler, 2007; Walls
et al., 1992) that can commonly be described in the context of: develop
and justify or build and evaluate processes (Hevner et al., 2004, p.78).
This research method relies on the trial-and-error search and creativity,
112
leading to the extensive use of theory to solve a problem, by building (that

is, designing) something (that is, an artefact). Subsequently, this
something is tried out in real cases to justify its usefulness and usability.
Thus, the DSR can be positioned as not only an approach to design
products or processes, but also to generate knowledge about what works
in socio-technical systems (Lewis, 2013).
In the DSR, the develop and justify activity is dependent on the

type of the IS artefact being selected for study (Millar, 2009). Hevner et al.
(Hevner et al., 2004, p.83) describe artefacts as: innovations that define
the ideas, practices, technical capabilities, and products through which the
analysis, design, implementation, and use of IS can be effectively and
efficiently accomplished and highlights that this definition is consistent
with the concept of IS theory as used by Walls et al. (Walls et al., 1992)
and Markus et al. (Markus et al., 2002), in which the theory focuses on the
design process and on the designed product.
In the process of designing an artefact, the DSR can contribute to

the theory in a similar way the experimental methods do, as its output is
better theories, as defined by Takeda et al. (Takeda et al., 1990).
Hevener et al. (Hevner et al., 2004) identify the DSR output in the form of
four types of artefacts that address the heretofore-unsolved problems,
which are the: constructs, models, methods and instantiations (March and
Smith, 1995).
Constructs aim to provide the language in which problems and

solutions are communicated and defined.
Models utilise constructs to represent real world settings that

include both the design problem and the solution space, so that the
models could aid problem and solution, represent the relevant connections
between the problem and solution components, and enable the
exploration of possible effects of design decisions and changes.
113
Methods focus on defining the processes that can provide guidance

on solving problems by searching the solution space, which can range
from informal textual descriptions to complex formal mathematical
algorithms.
Instantiations emphasise demonstrating how the constructs, models

and methods can be implemented in a working system, by conducting the
feasibility studies that assess an artefacts suitability to the purpose as well
as by motivating researchers to understand what are the effects of artefact
on the real world.
The resulting design artefact can be either purely conceptual or

extensively technical (Iivari et al., 1998).
4.4.1 Common Steps
A typical process for the DSR can be summarised in 6 steps, as

defined by Peffers et al. (Peffers et al., 2007) in the diagram below (Figure
4-3):
1. In the first step, the research problem, of a theoretical or

applied nature, is identified. This step heavily relies on the
knowledge about the problem and the importance of its
solution.
2. In the second step, the objective for a solution is defined and

its feasibility as well as possibly is analysed. This step can
be either qualitative or quantitative in nature.
3. In the third step, an actual artefact is designed and

developed. This step leads to the creation of an artefact of
any of the outputs listed previously, such as the constructs,
models, methods or instantiations.
114
4. In the fourth step, the usability of an artefact is demonstrated

in one or more problem instances. This step includes the use
of the artefact in experimentation, case study, simulation and
so on.
5. In the fifth step, the functionality of an artefact is evaluated

and measured. This step involves the use of relevant metrics
and analysis techniques. Depending on the nature of the
problem and the artefact, evaluation can take various forms,
but is still within the scope of the objectives defined in the
second step. Thus, based on the second step, the evaluation
can be either qualitative or quantitative. This step also allows
the researchers to iterate back to refine the artefact if there is
an opportunity for improvement or proceed to the next step if
iteration is unnecessary.
6. In the sixth step, the knowledge about the artefact is

communicated. This step involves the articulation of the
importance of the artefact, its design, novelty, utility as well
as effectiveness, to the research community and other
potential audiences.
Figure 4-3: Process Model of Design Science Research Methodology

(Peffers et al., 2007)
115
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.
4.4.2 Rigour and Relevance
Hevner et al. (Hevner et al., 2004) propose a conceptual framework

that combines Behavioural Science and Design Science paradigms to
drive the understanding, evaluation and execution of the IS research, as
depicted in the figure below (Figure 4-4).
Figure 4-4: Information Systems Research Framework (Hevner et al., 2004)
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
contextual environment of the research project with the Design Science

activities. The Rigor Cycle connects the Design Science activities with the
knowledge base of scientific foundations, experience, and expertise that
informs the research project. The central Design Cycle iterates between
the core activities of building and evaluating the design artefacts and
processes of the research (Hevner, 2007, p.88).
Figure 4-5: Cycles of the Design Science Research (Hevner, 2007)
The Relevance Cycle is focused on the identification of business

needs (Hevner et al., 2004, p.79) and the problem space (Simon, 1969). It
defines the criteria of acceptance for the research outcomes to ensure that
the designed artefact can deliver measurable improvements in the
environment. The application of the research activities, in the problem
space, addresses the business needs and ensures the relevance of the
research.
The Design Cycle is focused on building and evaluating the

artefact, which is designed to meet the identified business needs. The
justification of the suitability of the artefact can lead to the identification of
gaps in the theory as well as the refinement and reassessment of the
artefact.
117
The Rigour Cycle is focused on applying the existing knowledge

and methodologies: The knowledge base provides the raw materials from
and through which IS research is accomplished (Hevner et al., 2004,
p.80).
Hevner et al. (Hevner et al., 2004) identify seven guidelines,

provided in the table below (Table 4-2), for understanding, executing and
evaluating the IS research and stress the importance of the balance
between the cycles: Pragmatism is a school of thought that considers
practical consequences or real effects to be vital components of both
meaning and truth. Along these lines I contend that DSR is essentially
pragmatic in nature due to its emphasis on relevance; making a clear
contribution into the application environment. However, practical utility
alone does not define good DSR. It is the synergy between relevance and
rigor and the contributions along both the relevance cycle and the rigor
cycle that define good DSR (Hevner, 2007, p.91).
Table 4-2: Guidelines of the Design Science Research (Hevner et al., 2004)
118
The contributions made through the Design Science and the

Behavioural Science in IS are assessed as they are applied to the
business needs in the relevant problem space, so that the contributions to
the knowledge base can also be justified: A justified theory that is not
useful for the environment contributes as little to the IS literature as an
artefact that solves a non-existent problem (Hevner et al., 2004, p.81).
4.4.3 Theory in the DSR
The nature of theory in the IS research was extensively investigated

by Gregor, who proposed a taxonomy for classifying the IS theories
(Gregor, 2009, 2007, 2006, 2002). In this taxonomy, she identifies the
theory for design and action, referred as Type V (Gregor, 2006), to be
highly influential in IS, because it provides guidance for professionals who
work within the IS field (Jones and Gregor, 2007). Gregor also contends
(Gregor, 2009) that the creation of artefacts is fundamental to theorising
and outlines seven essential principles for creating knowledge in IT
disciplines, such as the:
1. Artefact system centrality;
2. Artefact purposefulness;
3. Need for design theory;
4. Induction and abduction in theory building;
5. Artefact construction as theory building;
6. Interior and exterior modes for theorising; and
7. Issues with generality.
119
Gregor also suggests that consideration of these principles can

improve theorising and knowledge creation in design disciplines (Gregor,
2009).
4.4.4 Knowledge Generation
Vaishnavi and Kuechler (Vaishnavi and Kuechler, 2007) suggest

that knowledge contribution needs to be the key focus of the DSR. They
propose this articulation based on the model that is an adaption of the
computable design process model by Takeda et al. (Takeda et al., 1990).
In their model (Figure 4-6), the design activities are commenced with the
awareness of a problem (Peirce, 1931) that results into a proposal for a
new research initiative: Suggestions for a problem solution are
abductively drawn from the existing knowledge or theory base for the
problem area. An attempt at implementing an artefact according to the
suggested solution is performed next. Partially or fully successful
implementations are then evaluated (according to the functional
specification implicit or explicit in the suggestion). Development,
Evaluation, and further Suggestions are often iteratively performed in the
course of the research (design) effort. The basis of the iteration, the flow
from partial completion of the cycle back to awareness of problem, is
indicated by the circumscription arrow. Conclusion indicates termination of
a specific design project (Vaishnavi and Kuechler, 2004, p.10).
120
Figure 4-6: Design Science Research Model (Vaishnavi and Kuechler, 2007)
Vaishnavi and Kuechler explicitly stress that the model is quite

similar to most of the DSR process models, despite of the differences in
some phases, as the emphasis of the model is on the detailed process for
generating Design Science knowledge (Vaishnavi and Kuechler, 2007).
4.5 Summary of the DSR

DSR is an important paradigm in the IS research that is yet to
become mature until it is accepted by the wider community of the IS
researchers, as the holistic approach to conduct the DSR in IS still needs
to be confirmed (Alturki et al., 2011). Gregor and Hevner contend that the:
DSR has yet to attain its full potential impact on the development and use
of IS due to gaps in the understanding and application of DSR concepts
and methods (Gregor and Hevner, 2013, p.337). Although, there are
various methodological guidelines to conduct the DSR, their validity and
completeness is yet to proved (Alturki et al., 2012). The summary of these
121
various approaches, in the DSR process, are provided by Alturki et al.

(Alturki et al., 2011) in the figure below (Figure 4-7).
Figure 4-7: Design Science Research Roadmap (Alturki et al., 2011)
122
4.6 Use of the DSR in this Research

As was stated earlier, the objective of this research is to 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. This objective falls within the broader socio-technological setting
of the IS discipline that requires a research method capable of handling
technological aspects, social aspects, design implications and dynamic
interactions amongst the various elements, including the feedback
between them. These are the specifications of the DSR, as it is at the
intersection of technology, people and organisations. The DSR promotes
the use of literature to define the parameters for the design of a potential
artefact, which can be tested for usefulness and usability. The aim of this
research is to design such an artefact, in this case a model, to solve the
existing class of problems, as suggested by the proponents of the DSR
(Hevner et al., 2004; Jones and Gregor, 2007; Kuechler and Vaishnavi,
2008; March and Smith, 1995; Peffers, 2008; Walls et al., 2004, 1992). As
this research is of applied nature, the resulting artefact aims to be used by
professional organisations, which can evaluate the proposed artefact in
the real world settings.
To conduct this research almost all of the explained DSR

approaches can be used. However, the DSR approach by Hevner et al.
(Hevner et al., 2004) is chosen, because it considers the dynamics in the
change of the design process and the design artefacts, requirements and
constraints in the research, interaction with the solution, including human
cognitive and social abilities. As such, the steps that are defined by
Hevner et al. (Hevner et al., 2004) are adapted to outline the steps for
conducting this research:
! Problem relevance to business needs, which includes:

stressing the need for action in the fields of SOA and ESB,
123
conducting an in-depth literature review, formulating the

research motivation, defining the research question and the
research objective. This step is covered in Chapter 1 and
Chapter 2.
! Research rigour, which includes: establishing the theoretical

foundation in the field of Cybernetics, and the VSM in
particular, in the course of fulfilling the research objective.
This step is covered in Chapter 3.
! Design process, which includes: 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. This step is covered in Chapter 5.
! Artefact evaluation, which includes: validating the usefulness

and usability of the proposed model in the real world
settings, through multiple design-evaluate iterations, as
defined in the DSR and suggested by Sonnenberg and vom
Brocke (Sonnenberg and vom Brocke, 2012). This step is
covered in Chapter 6.
! Research contribution and communication, which includes:

publishing the research findings and contributing to the
knowledge base. This concluding step is covered in Chapter
7.
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
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
126
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model
Chapter 5. Designing the Artefact The Viable

Enterprise Service Bus Model
Innovation is taking two things that already exist and putting them
together in a new way.
Thomas Freston
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.
5.2 Viable Enterprise Service Bus Model

The Viable Enterprise Service Bus Model (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. These latter design
principles are the unique contribution in this research. These principles are
developed to be generic for any system that aims to survive and remain
viable, and are adapted to the application of this research, which is the
ESB, to form the novel VESBM artefact. To understand how the VESBM
127
amalgamates the SOA, the ESB and the VSM, it is necessary to clarify the
definition of a model.
A model is a mean for understanding the world that allows

surrogative reasoning (Swoyer, 1991). Scientific investigation heavily
relies on models (Hacking, 1983), rather than on reality, because by
studying a model various features and facts about the system, it
represents, can be discovered (Frigg and Hartmann, 2009).
A model can come in many sizes, shapes and styles. The

Cambridge University Press Dictionary defines model as something that
represents another thing, either as a physical object that is usually smaller
than the real object, or as a simple description that can be used in
calculations (Cambridge University Press, 2015).
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):
! A usually small copy of something;
! A particular type or version of a product (such as a car or a

computer); and
! A set of ideas and numbers that describe the past, present,

or future state of something (such as an economy or a
business).
Encyclopaedia Britannica defines model as a simplified

representation of the real world and, as such, includes only those
variables relevant to the problem at hand (Encyclopaedia Britannica,
2015). Furthermore, a model may not include all relevant variables
because a small percentage of these may account for most of the
phenomenon to be explained (Encyclopaedia Britannica, 2015).
128
The objective of this research is to 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. The
VESBM pursues the aim to become such a model and the reasoning
behind its development is formulated based on the following assertions:
! VSM can provide the structure for embedded services

(Graves, 2014);
! ESB is a service-oriented middleware (Issarny et al., 2011);
! ESB functions can be provided through a service container

(Keen et al., 2004);
! ESB functions can be provided in the form of individual

services (Chappell, 2004); and
! The application of the SOA principles of service design can

serve as a guideline towards identifying the design of
technology-independent services (Erl, 2007).
Earlier it was shown that, the characteristics that influence the

design of the ESB (Chappell, 2004) can define the types of services that
may be incorporated into it. However, as was mentioned, there is currently
no model that could ensure the survival of the designed ESB, despite of
the changes in technologies that may underpin it that is, the services at
the support level, embedded into the ESB, such as the data
transformation, protocol transformation, message encryption and so on.
Although, the ESB is a middleware manifestation of SOA design
principles as applied to integration (Chappell, 2004, p.77), it is also a
service-oriented middleware (Issarny et al., 2011), which can provide its
functions in the form of individual services (Chappell, 2004), through a
service container (Keen et al., 2004), and there are no impediments in
129
applying the SOA principles of service design towards identifying the

design of technology-independent support level services of the ESB. This
assertion is also supported by the evidence that the SOA design principles
can be integrated into SaaS (Roche, 2014) and that the ESB can be
provided as a service in the Cloud (Popa and Vaida, 2015).
The SOA principles of service design shape both service contracts

and service logic. Service logic can exist in a variety of forms: it can be
implemented as the core logic component within a service; as a
standalone component with a public interface; or as a component within
an event-driven service agent (Erl, 2007). As for the contract-related
principles, their application to the logic encapsulated within an event-
driven service agent might be limited, because of the nature of the service
agent. Nevertheless, this does not make the logic any less service-
oriented; it only limits the principles that need to be taken into account
during its development (Erl, 2007, p.114). In addition, the choice of
implementation medium or format can be influenced by environmental
constraints, architectural considerations, as well as the application of
various design patterns (Erl, 2007, p.114).
Recalling the enterprise representation layers, by Barrios and

Nurcan (Barrios and Nurcan, 2004), which were used for the abstract
representation of services within an SOA initiative, the IS layer was
representing the services at the support level, those inside the ESB, that
facilitate the actual integration from the bottom. Given the applicability of
the VSM for the SOA and its suitability for providing structure for the
coordination services inside a service-oriented enterprise (Graves, 2014),
it was asserted that the VSM can provide a structure for the service
embedded into the ESB. As VSM is endowed with a set of cybernetic
concepts that ensure the survival of a system (Beer, 1985), it was
concluded that the VSM can be a reasonable model for developing the
generic design principles for the ESB, which would ensure its survival.
130
Therefore, to achieve the research objective, the VESBM is developed for

the support level services of the ESB, those embedded into it, rather than
the services that reside at the application level.
As was mentioned earlier, the statement of the research objective

has two parts that need to be addressed, in order to achieve it. The first
part emphases development of the generic design principles for the ESB,
in a model that would ensure the ESB survival. The second part
emphases necessity to ensure the survival of the ESB, independent from
the technologies that may underpin the ESB. Based on the discussions
above, these two parts are addressed, in the VESBM, in the following way:
1. The communication and control is at the basis of both the

VSM and the ESB, and the early correlations identified
between them, indicate that the cybernetic concepts
embedded into the VSM could possibly be formed into the
generic design principles for the ESB, subsequently aligning
the characteristics that influence the ESB design. The VSM
can provide the structure for embedded services and in order
to build a model that would ensure the ESB survival, the
VSM structure needs to be used as the basis for combining
the generic design principles into a cohesive whole.
2. ESB is a service-oriented middleware, which can provide its

functions, through service containers, in the form of
individual services. The application of the SOA principles of
service design can serve as a guideline towards identifying
the design of technology-independent services and in order
to ensure the survival of the ESB, independent from the
technologies that may underpin the ESB, these principles
could possibly be used to define the design characteristics in
the support level services of the ESB.
131
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.
5.3 Structure for the Design Principles

Amongst the most prominent practices, that can be used to define
the structure for the design principles, is the format outlined in the The
Open Group Architecture Framework (TOGAF) (The Open Group, 2012).
TOGAF is one of the most widely used EA frameworks (Zadeh et al.,
2012) and its format for defining principles is comprised of the (The Open
Group, 2012):
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).
The Rationale highlights the business benefits of the principle,

which can be expressed in both quantitative and qualitative terms. It
132
outlines the relation of one principle to other principles, including the

priorities that can be set between them.
The Implications is concerned with the issues related to the use of

principles. It outlines resources, key tasks and potential costs of following
the principle, including the inputs to planning activities and future transition
initiatives.
The table below (Table 5-1) is the exact replica of the

recommended format for defining principles, as outlined in the TOGAF
(The Open Group, 2012).
Table 5-1: Recommended Format for Defining Principles (The Open Group,
2012)
Should both represent the essence of the rule as well as be easy to

remember. Specific technology platforms should not be mentioned in
the name or statement of a principle. Avoid ambiguous words in the
Name Name and in the Statement such as: "support", "open", "consider", and
for lack of good measure the word "avoid", itself, be careful with
"manage(ment)", and look for unnecessary adjectives and adverbs
(fluff).
Should succinctly and unambiguously communicate the fundamental
rule. For the most part, the principles statements for managing
Statement
information are similar from one organisation to the next. It is vital that
the principles statement be unambiguous.
Should highlight the business benefits of adhering to the principle, using
business terminology. Point to the similarity of information and
technology principles to the principles governing business operations.
Rationale Also describe the relationship to other principles, and the intentions
regarding a balanced interpretation. Describe situations where one
principle would be given precedence or carry more weight than another
for making a decision.
Should highlight the requirements, both for the business and IT, for
carrying out the principle in terms of resources, costs, and
activities/tasks. It will often be apparent that current systems, standards,
or practices would be incongruent with the principle upon adoption. The
impact to the business and consequences of adopting a principle should
Implications
be clearly stated. The reader should readily discern the answer to: "How
does this affect me?" It is important not to oversimplify, trivialise, or
judge the merit of the impact. Some of the implications will be identified
as potential impacts only, and may be speculative, rather than fully
analysed.
133
As an EA framework, TOGAF can define the principles structure for

enterprise IT services at Business, Data, Applications and Technology
layers. For this reason, the TOGAF format for defining principles can be a
suitable template for the VESBM design principles, to follow. However,
because the scope of services in TOGAF is wider than that of the VESBM,
the format needs to be adapted to suit the specific needs of the 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;
2. VESBM Design Principle Statement;
3. SOA Rationale; and
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:
1. The Name represents the essence of the rule, is easy to

remember and does not mention any specific technology
platform.
2. The VESBM Design Principle Statement communicates the

fundamental rule, but mentions the ESB. Although, the
TOGAF format recommends not to mention specific
technology platforms, the ESB must be regarded as an
architectural style or pattern (Chappell, 2004; Erl, 2008;
Kress et al., 2013), rather than a specific technology.
Therefore, as it is unavoidable to mention architecture in the
TOGAF principles (The Open Group, 2012), it is unavoidable
134
to mention ESB in the VESBM design principles. However,

no specific underpinning technology, that can be embedded
into the ESB, such as the Web Service, SOAP, RESTful and
so on, is mentioned.
3. The SOA Rationale highlights the benefits of the SOA

principles of service design in designing the technology-
independent support level services of the ESB and describes
the relationship to other principles, where necessary.
4. The ESB Implications highlights the requirements for

carrying out the principle, in accordance with the
characteristics that influence the ESB design, and states the
consequences of adopting a principle.
The next section outlines the VESBM design principles, which

follow the adapted TOGAF format for defining principles (The Open
Group, 2012).
5.4 VESBM Design Principles

Principles play an essential role in shaping every aspect of our
world. In history, the IT world was encouraged to use design principles, so
that systems being developed would be developed properly on a
consistent basis (Erl, 2007). The principles were typically positioned as a
recommendation, as they were viewed more as guidelines than
standards, providing advice that we could choose to follow (Erl, 2007,
p.104).
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
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.
2. The VESBM design principles that are directly derived from

the VSM design principles. Each principle is presented in a
separate profile that is based on the adapted TOGAF format
for defining principles. To form the novel VESBM artefact,
the VSM design principles are adapted to the application of
this research, which is the ESB.
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
5.4.1 Management of Complexity, Homeostasis and

Requisite Variety
One of the core activities of any living organism, whether it is a

biological cell or a huge enterprise, is the management of complexity.
Similar to living organisms, in viable systems, all the subsystems of the
given level of recursion are responsible for stabilising the internal
environment of this recursion. In Biology, stabilisation has a special term
known as homeostasis.
The complexity of a system is measured by the special measure

known as variety. Variety is a measure of complexity that counts the
number of possible states a system can be in. Apparently, in highly
complex environments counting the number of states is not always
possible, not mentioning that it might be ineffective and inefficient as well.
However, what is possible is to make comparative statements about the
degree of variety for a given system. For example, in organisations, it is
common for management not to be completely aware of all the states of
operations and therefore to have a lower variety than that of operations;
similarly, operations cannot be aware of all the possible states of the
environment and thus will have the variety lower than that of the
environment. In other words, the variety of the environment greatly
exceeds the variety of operations that serves or exploits it, which in turn
exceeds that of management that regulates and controls it (Beer, 1985).
It is important to distinguish between high and low variety and what

they are associated with. High variety is associated with attenuation it
needs to be reduced to a number of possible states, so that the system
can handle it. However, attenuation shall not imply to the complete
reduction of variety below the threshold, although it empowers a system
with a capability to do so. Ruthless reductions usually lead to a complete
ignorance of the states that need to be examined by the system.
137
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.
Figure 5-1: Attenuators and Amplifiers of Management and Operations

(Beer, 1985)
Requisite Variety is one of the most potent and fundamental

concepts in Cybernetics. Ashbys Law of Requisite Variety states, that:
138
only variety can absorb (that is, destroy) variety (Ashby, 1956). The Law of
Requisite Variety influences:
! Management strategies, which consist of mixes of

attenuators and amplifiers;
! Problem of measurement, which shall be minimal, as not the

counting of possible states is important, but the assurance
that the counter-balancing varieties are roughly equal; and
! Problem of management, which becomes less hectic once

the homeostatic regulation is achieved and proliferation of
variety is balanced through the establishment of attenuation
and amplification mechanisms designed to absorb the variety
of each others entities.
To create acceptable conditions for homeostatic regulation the

requisite variety needs to be restored. This is achieved through the
combination of attenuators and amplifiers that form continuous loops of
variety involvement. Restoration of requisite variety is the essence of
viability.
According to the First Principle of Organisation:
Managerial, operational and environmental varieties, diffusing

through an institutional system, tend to equate; they should be designed to
do so with minimum damage to people and to cost. (Beer, 1979, p.97)
In other words, this statement implies that organisations of any

sizes, which are built upon and embed in this principle, by definition are
self-organising entities. Given that variety absorbs variety and systems run
into homeostasis, because of the linkages between the subsystems, all
the complexities as a result cancel each other out.
139
The First Axiom of Management states, that:
The sum of horizontal variety disposed by n operational elements

equals the sum of the vertical variety disposed by the six vertical
components of corporate cohesion. (Beer, 1985, p.89)
The principles proposed in this chapter are derived from this

fundamental law and therefore the Ashbys Law of Requisite Variety is
positioned as fundamental for the design principles.
Proposed VSM Design Principle Variety: To obtain control the

controller must have the variety that is as great as the variety of the
situation to be controlled.
5.4.1.1 Principle 1: Variety

Name Variety
VESBM ESB must have the variety of support level services that would be at
Design least as great as the variety of integration requirements of application
Principle level services.
Statement
Service Orientation and Interoperability influence support level
SOA Rationale services to achieve greater integration capabilities, by imposing
interoperability between the existing and newly incorporated services.
ESB supports extensibility through layered services and its features
can be extended through the addition of the necessary functionality, in
the form support level services. These services may perform process
ESB
orchestration, data transformation, protocol transformation, message
Implications
encryption, message routing, message enrichment and so forth. The
extendable nature of the ESB positions it as a tool capable of handling
a variety of integration needs.
5.4.2 Viability
An organisation is called viable if it can maintain a separate

existence (Beer, 1985). Separate existence shall be interpreted in the
context of autonomy that an organisation is endowed with in a given
environment. However, autonomy shall not imply to an existence in
vacuum, as survival there is not possible, but in the environment that may
consist of other organisations, each having a separate identity. Thus,
140
existence is never independent of other existences and can only survive

within a supportive environment.
Proposed VSM Design Principle Viability: Remaining viable is the

ultimate goal of the system.
5.4.2.1 Principle 2: Viability

Name Viability
VESBM ESB must provide service orientation and interoperability between all
Design support level services, to remain viable.
Principle
Statement
Service Orientation and Interoperability outline the fundamental means
SOA Rationale for the interoperability between the support level services, which are
integrated in a standarised manner.
ESB supports standardised integration and can integrate components
ESB through standardised interfaces that can be mixed together to form an
Implications open-ended pluggable architecture capable of combining various
integration options, including data types native to the components.
5.4.3 Value Creation
Value creation must be interpreted in the context of the concept of

Viability. To remain viable and to survive it is essential to comply with the
laws and principles of the VSM. However, surviving must not be
interpreted in the sense of mere existence. Rather, it must involve
learning, adaptation and growth (Beer, 1981). Thus, to remain viable a
system must add value in one form or another.
Proposed VSM Design Principle Value Creation: Resources of

the system are directed and controlled to achieve viability through the
effective and efficient creation of value.
5.4.3.1 Principle 3: Value Creation

Name Value Creation
VESBM ESB resources must be directed and controlled to extend their
Design reusability and incremental adoption, with interoperability, service
Principle orientation and necessary integration requirements being preserved
Statement through the use of the standardised service contracts.
Service Reusability outlines design considerations for the support level
SOA Rationale
services, to increase their reusability. Service Orientation and
141
Interoperability influence the interoperability and orientation between

the support level services. Standardised Service Contract outlines the
integration requirements in service contracts to standardise the
incorporation of support level services.
ESB supports selective deployment and can provide distributed
ESB
integration through the incremental adoption of support level services
Implications
from disparate locations.
5.4.4 Value Preservation
Value preservation is essential for ensuring that organisations

current survival is not in danger. In other words, the concept of Viability is
closely correlated with the concepts of Value Creation and Value
Preservation, and both are the ultimate sources of organisations viability
(Lewis and Millar, 2010).
Proposed VSM Design Principle Value Preservation: The

ongoing survival of the system is dependent on the management of risks
that is dedicated to preserving the proposed value.
5.4.4.1 Principle 4: Value Preservation

Name Value Preservation
ESB support level services must undergo through as many
VESBM
incremental updates as needed, or substituted with alternatives, to
Design
reduce the risks of deviations caused by possible service
Principle
deteriorations, in accordance with the reusability and interoperability
Statement
requirements, so that the value of the ESB is preserved.
Service Reusability outlines design considerations for the support level
services to provide the means for reusing the services after updates or
for using alternative services instead. Service Orientation and
SOA Rationale
Interoperability influence support level services to achieve greater
integration capabilities, through providing interoperability between the
existing, newly updated or alternative services.
ESB supports selective deployment and can provide distributed
ESB
integration through the incremental adoption of updated or alternative
Implications
support level services from disparate locations.
5.4.5 Black Box
Black Box is a cybernetic concept the nature of which can be

understood without a need to entering it. This concept is essential in the
142
management of complexity in systems, as senior managers usually unable

to obtain the information about all the possible states of embedded
systems, for which they are ultimately responsible, and thus they cannot
intervene within lower level operations (Christopher, 2007). To effectively
manage the embedded systems, the concept of Black Box can be used
and for all those outside the operational unit, including higher-tier
management, the only information that needs to be obtained is: what goes
into the Black Box, what goes out of it and what the relations between the
inputs and the outputs are (Christopher, 2007). Combined with the
concept of Recursion, the Black Box enables effective management of
complexity in systems (Millar, 2009). Stafford Beers First Regulatory
Aphorism states, that: It is not necessary to enter the Black Box to
understand the nature of the function it performs (Beer, 1979, p.40).
Proposed VSM Design Principle Black Box: The system must be

supplied with interfaces that would describe what goes into it, what goes
out of it and what the relations between the inputs and the outputs are,
encapsulating the logic of any functions behind them.
5.4.5.1 Principle 5: Black Box

Name Black Box
ESB must be designed as a black box that abstracts the underlying
VESBM
implementation details of all support level services and exposes only
Design
the interfaces through service contracts for providers (output) and
Principle
consumers (input) to support greater service orientation and
Statement
interoperability.
Service Abstraction imposes service contracts to contain only the
essential information about the support level services. With such
SOA Rationale abstraction, Service Orientation and Interoperability can improve the
interoperability between the support level services and streamline the
relations between the inputs and the outputs.
ESB supports standardised integration capabilities and can provide
ESB components integration through standardised interfaces. This allows
Implications treating the ESB as a black box, which can be understood through its
inputs and outputs.
143
5.4.6 Communication Channels, Channel Capacity and

Transduction
All the subsystems of the VSM are mutually interdependent.

Because each subsystem is vital to the overall viability of the system,
there is no choice dilemma in which one is more or less important (Beer,
1972). The subsystems are also interconnected. A number of
communication channels provide the means for information exchange,
along with the central channel, also known as the command axis, which
allows direct and independent interaction with the management of each
subsidiary. These communication channels may form sets of separate
threads.
However, when dealing with information flow, it is also

fundamentally important to have channels in place that would provide
variety for the data that is to be transmitted (Beer, 1985). Thus, it is
necessary to find the balance of requisite variety in the channels that
transmit variety, which is already acknowledged and is to be provided in
terms of policy. This balance can be achieved through the provision of little
redundancy in the transmission channels that are designed to transmit
more information than generated at a given time.
According to the Second Principle of Organisation:
The four directional channels carrying information between the

management unit, the operation, and the environment must each have a
higher capacity to transmit a given amount of information relevant to
variety selection in a given time than the originating subsystem has to
generate it in that time. (Beer, 1979, p.99)
In comparison with the First Principle, the Second Principle invokes

a time base, because of the capacity of transmission channels that are
absolutely dependent on the rate of data transmission involved. It must be
144
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.
Transduction is responsible for encoding and decoding messages

that flow in information channels whenever they cross system boundary,
so that senders and receivers of messages could interpret them
accordingly.
According to the Third Principle of Organisation:
Wherever the information carried on a channel capable of

distinguishing a given variety crosses a boundary, it undergoes
transduction; the variety of the transducer must be at least equivalent to
the variety of the channel. (Beer, 1979, p.101)
In other words, transduction capacity is distinct from channel

capacity. As the aim of transducers is to preserve variety and the aim of
channels is to transmit information, the capacity of the former shall be
associated with the message interpretation, whereas capacity of the latter
shall be associated with the message transmission.
Given that System ONE is concerned with the attenuation of

horizontal variety so that its operations would be effective in its
environment and thus discharge its resource bargain with the senior
management; and given that in an ideally designed system, accountability
in bargain, which is concerned with the homeostasis of resourcefulness,
would be comprised of a monotonous signal conforming that everything is
proceeding as agreed (Beer, 1985); then it becomes apparent that senior
management will unlikely to accept that variety is requisite in their terms,
and possibly reveal only two states, that are OK or not-OK. Although, the
145
maximum variety senior management can handle, for each subsidiary, is

equal to their own total capacity divided by the number of subsidiaries in
System ONE (Beer, 1979).
Therefore, the design of accountability transducers and channels

must conform to the variety attenuation already built into the managerial
strategy (Beer, 1985, p.51). This means that the Second and the Third
Principles of Organisation can be interpreted only in terms of the First
Principle. It must be noted that senior management, which is agreed to the
designed accountability, must not practice frequent investigations as its
prerogative, so that the confidence and autonomy are not undermined.
Essentially, it shall not have access to the subsidiarys regulatory centre,
which is the local managements service domain (Beer, 1979).
According to the Fourth Principle of Organisation:
The operation of the first three principles must be cyclically

maintained through time without hiatus and lags. (Beer, 1979, p.258)
As was mentioned earlier, in the VSM, representation of

subsidiaries of the System-in-focus do not have a particular significance in
ranking, thus there is no imposed order for the listing. Moreover, vertical
command axes, which consist of accountability, resource bargain and
intervention channels, connect the management boxes of all System One
instances and have an independent access to each of them. All the
channels form loops, with accountability and resource bargain forming a
homeostatic loop. These conventions are also considered for the
representation of operational axes, which connect the subsidiaries of the
System-in-focus: the connection does not imply operational flow from one
subsidiary to another, but it does not exclude this option from the design
either. Thus, where necessary this needs to be acknowledged and
accomplished accordingly. Additionally, given that all subsidiaries are
designed to operate as viable systems, in their own environments, this
146
does not entail the self-exclusion of environments from one another. In

contrary, environments might intersect and the extent of this intersection
may vary: the environments might be either identical (for example, a set of
gas stations of the same company in the same county) or separate (for
example, a set of distinct companies of a conglomerate, in the same
country) (Beer, 1985). These cases need to be considered when
analysing, designing and representing a viable system.
Proposed VSM Design Principle Channels: The system must

provide transparency in the capacity management and capability in data
transduction, in a secure and reliable manner, to achieve the viable
balance in information channels.
5.4.6.1 Principle 6: Channels

Name Channels
ESB must be designed with the appropriate level of channel capacity
VESBM
and capability for data manipulation, supported with relevant security
Design
standards, to guarantee the acceptable network balance, data
Principle
exchange and secure transactions between the existing and newly
Statement
integrated support level services that constitute it.
Service Orientation and Interoperability outline the fundamental means
SOA Rationale for the interoperability between the support level services that interact
through messaging systems.
ESB supports real-time throughput of business data and execution of
process flows through secured and reliable channels. ESB can
balance the network load as well as provide integration, interoperation,
ESB
interpretation and communication between support level services. This
Implications
may include the use of load balancers, data and protocol
transformation, including various open standards for secure and
reliable message exchange, and so forth.
5.4.7 Operations, Recursion, Invariance, Cohesion and

Meta-system
System ONE, referred as Operations or sometimes as

Implementation, is responsible for producing services that are driven by
organisations identity (Espejo and Gill, 1997).
147
Organisations, such as firms, are often subsidiaries of larger

corporations. At the same time, these firms may also consist of
subsidiaries. In the context of VSM, these subsidiaries, firms and
corporations are all viable entities that contain these organisations and are
contained within them (Beer, 1972). In other words, they are all recursions
of the viable system (Beer, 1985). The same can be applied to other
similar chains of embedded recursive systems. Together they form the
recursive dimensions (Beer, 1979). In the VSM, recursion does not imply
to just a loose insertion of one system inside another, but to an absolutely
precise definition of viability (Beer, 1981). This definition is invariant.
Invariant is a factor in complicated situations that is not getting

affected by any changes that surround it (Beer, 1985). In the VSM,
invariance facilitates the inheritance of all the features of the VSM for any
given level of recursion. This in turn contributes to the overall cohesion
and the actual modelling process of complex systems, as it is not affected
by any surrounding changes.
Cohesion implies the alignment of individual and collective interests

(Espejo and Reyes, 2011). A system can be a collective of autonomous
units. This autonomy, if unchecked, may lead to organisational chaos.
Cohesion is necessary for the collective to become organisation. To
achieve this, cohesion imposes restriction on the autonomy of the
operational units by ensuring that they operate in consistentcy with the
purpose of the whole organisation. Without such restriction, the
organisation would lose coherence and fracture. In the VSM, System
THREE is responsible for the integration and alignment of operational
units into a cohesive whole (Espejo and Harnden, 1989).
For multiple recursions of the viable system the Law of Cohesion

states, that:
148
The System ONE variety accessible to System THREE of

recursion x equals the variety disposed by the sum of the meta-systems of
recursion y for every recursive pair. (Beer, 1985, p.134)
In recursive dimensions, systems of the higher level of recursion

are meta-systemic to the systems of the lower level. Meta-system is a
system that is over and beyond a system of the lower logical order to
which the higher level authority might not be applied (Beer, 1981). In the
VSM, the combination of Systems THREE-FOUR-FIVE that is dealing with
the outside-and-then is meta-systemic to the combination of Systems
THREE-TWO-ONE that is dealing with the inside-and-now. System
THREE, being in between these combinations, plays a role of vital
fulcrum for the entire System-in-focus (Beer, 1985).
Given the recursive nature of the VSM, services could be produced

at different levels of aggregation and therefore form the value chain within
organisation to fulfill its purpose. The structure of organisation is usually
getting unfolded until the point where a service produced reaches the level
of a manufacturing cell. Thus, it is expected from organisations, that thrive
for viability, to contain sub-systems at the further levels of recursion, which
are dedicated to handle the complexity of the environments they operate
in as well as to undertake the value-adding activities in the System-in-
focus (Espejo and Gill, 1997).
Proposed VSM Design Principle Recursion: The design of the

system, that is derived from the design principles, is invariant to provide
cohesion in the system, so that the synergies across the operational units
are exploited at all levels of recursion to ensure that the system as a whole
delivers more than the sum of its parts.
5.4.7.1 Principle 7: Service Recursion

Name Service Recursion
VESBM ESB design must be derived from the same design principles for any
Design ESB, to facilitate the common approach to service contracts,
149
Principle abstraction of the underlying implementation technology, level of

Statement coupling between the support level services, so that the greater
service composability, autonomy, reusability, statelessness and
discoverability, including service orientation and interoperability, can
be provided across support level services of ESBs and the synergies
of all ESBs combined could deliver more value, as a whole, than the
sum of separate ESBs.
Standardised Service Contract, Service Loose Coupling, Service
Abstraction, Service Reusability, Service Autonomy, Service
Statelessness, Service Discoverability, Service Composability,
SOA Rationale
including Service Orientation and Interoperability define design
considerations for support level services of the ESB, which can be
replicated across multiple ESBs.
ESB can form a pervasive grid that can spawn across an enterprise,
acting as a bridge that interconnects disparate organisational
departments, business units and corporate divisions, with their own
ESB
respective ESBs. As ESB supports selective deployment and can
Implications
provide distributed and standardised integration, multiple ESBs, in an
incremental manner, can form a system of ESBs, as in the case of
Cloud of ESBs.
5.4.8 Autonomy and Self-reference
Autonomy implies the freedom of embedded viable systems in

taking actions based on their own initiative, but within the framework of
actions determined by the purpose of the entire system (Beer, 1981).
It can be derived from a logical assumption that if the purpose of the

system is what it does and the convergence between the System ONE
and System THREE is achieved, as well as given that the variety is
measurable and thus can define how much of it needs to be handled
according to the First Axiom, then the minimum variety on the vertical
command axis that transmits regulation, to preserve cohesion in the viable
system, can be determined. The remaining freedom to manage, for the
management on the horizontal axis, is what defines the autonomy for the
embedded viable systems (Beer, 1985).
It is important to note that, lower recursions of the given System-in-

focus are not less important than the system itself or its higher recursions.
Of course, as higher recursions deal with environments much wider than
150
that of lower recursions, the responsibilities, technologies and most

importantly the language used at different recursive levels might be
different. Thus, this might create an imagination that because the
environment of lower recursions is embedded into the environment of
higher recursions, the latter will be completely aware of everything in the
environment of the former. However, none of them is completely aware of
the environment of another and this is true for any hierarchical
embodiment of viable systems (Beer, 1979). Nonetheless, the complexity
of environments is higher at higher recursions, because at each level the
given environments do not only represent solely the sum of embedded
environments of lower recursions, but the complexity of relationships
between them as well. Thus, by granting the degree of freedom, autonomy
can help the embedded operational units to adapt to their local
environments and attenuate the variety that would otherwise be handled
by the higher-tier management (Espejo and Reyes, 2011).
In the VSM, the logic of viable systems is closed-in on itself that

is, each part makes sense precisely in terms of the other parts. In other
words, the systems are self-referential. This does not mean that viable
systems are closed. Rather, they are in continuous interaction with
external environment. However, as with external, there is also an internal
environment that is continuously balanced. In addition, the self-referential
characteristic of the VSM also encompasses self-awareness, the
maintenance of identity, the facility of self-repair and recursivity.
Proposed VSM Design Principle Autonomy: The system and its

embedded systems must be designed as self-organising entities with a
maximum degree of autonomy for actions that would only be constrained
by the maintenance of cohesion towards the goal of implementing the
system.
151
5.4.8.1 Principle 8: Service Autonomy

Name Service Autonomy
ESB must be designed as a self-organising entity with a high degree of
VESBM Design
autonomy and loose coupling between the support level services,
Principle
which are only constrained by the maintenance of cohesion towards
Statement
the goal of implementing the ESB.
Service Autonomy defines the high level of control for support level
services over their environment. Service Loose Coupling imposes
SOA Rationale
lowering the coupling or completely decoupling the support level
services from their environment.
ESB autonomous units, capable of scaling globally. These units can provide
Implications their capabilities, in the form of individual services ultimately
autonomous and loosely coupled.
5.4.9 Coordination and Anti-oscillation
System TWO, referred as Coordination, is responsible for

coordinating the interfaces of the value-adding functions of the VSM as
well as the operations of its primary sub-units (Espejo and Gill, 1997).
In the VSM, coordination implies mutual adjustments between the

autonomous units and between the support functions, and needs to be
distinguished from that of traditional direct-and-control mechanisms. To
protect units and functions from the direct intervention, an additional layer
is usually implemented to shield the operations and reduce possible
intrusions into the workflows. Essentially, a system that is designed with
an effective two-way communication mechanism for mutual adjustments
will feed the design of business processes as well as support overall
coordination between the value-adding and supporting functions. Given
that primary sub-units are sharing the same parent unit, the modelling
process they are derived from provides the logical connection for their
operations and establishes a common ground for synergetic cooperation.
It is therefore important not to put the units into direct competition or keep
them blind to each other.
152
System TWO undertakes anti-oscillatory activities in the System

ONE. Oscillation is a specific sickness of homeostasis. It is a condition in
which every subsidiary of the System-in-focus tries to adjust to the every
other one. Because this process is continuous, the adjustments may never
end and thus lead to possible oscillation. Oscillation must be damped or
otherwise it might lead to a collapse of the entire system (Beer, 1985).
System TWO is therefore positioned as a device that aims to manage
possible disintegrations in the whole system (Beer, 1979). It is important to
realise that its purpose is not to command, but rather damp possible
oscillations and thus it does not lie on the command axis, but is a part of
each instance of a viable system.
System TWO is a regulatory center that is in touch with System

ONE as a complete entity. In other words, regardless of a number of
System ONE instances, regulatory center of the given level of recursion
will treat them as a whole. At the same time, each instance of the System
ONE has its own regulatory center at the level of recursion it resides at,
which in turn interacts with the lower level of System ONE recursions in
the same way as it is done by the System TWO of the System-in-focus.
If necessary, each System ONE instance can be regulated by more

than one System TWO of the higher level of recursion. Thus, in a given
System-in-focus, System TWO can also scale horizontally (Figure 5-2).
These additional instances of System TWO follow the same rules that
were stated earlier: they are not positioned on the command axis and
therefore do not exercise executive authority; they are dependent on the
senior management of the System-in-focus; they treat System ONE as a
whole, regardless of a number of System ONE instances.
153
Figure 5-2: Vertical and Horizontal Scalability of System TWO (Beer, 1985)
Presence of several System TWO instances is beneficial in

situations when more than one oscillatory source is identified and requires
regulation (Beer, 1972). However, in any sense, System TWO shall not be
positioned as the mechanism of a hierarchical structure with the authority
higher than that of System ONE. Apparently, its sole anti-oscillatory
purpose, that implies gathering additional knowledge on regulatory
options, may create a sense of power that is often misinterpreted in many
organisations (Beer, 1979). A clear definition of its role, within the scope of
the enterprise or a system, shall be declared to avoid any such
misunderstandings. Along with the corporate intervention, resource
bargain, operational linkages and environmental intersects, System TWO
154
is another vertical constraint that limits the freedom of variety generation

by System ONE and its subsequent proliferation in the System-in-focus.
Proposed VSM Design Principle Deviation: The system must

coordinate the operations to avoid possible deviations in its sub-systems
by adjusting them to the accepted levels of service provision and by
reporting any possible deviations to assist future improvement and
evaluation.
5.4.9.1 Principle 9: Service Deviation

Name Service Deviation
ESB must coordinate the support level services to avoid possible
VESBM
deviations in the compositions they may form in the runtime, so that
Design
the level of coupling and autonomy is preserved in accordance with
Principle
the defined service contracts, and reported to assist future
Statement
improvement and evaluation.
Service Composability outlines how the support level services are
combined in an effective composition, regardless of its size and
complexity. Service Autonomy defines the high level of control for
support level services over their environment. Service Loose Coupling
SOA Rationale
imposes lowering the coupling or completely decoupling the support
level services from their environment. Standardised Service Contract
outlines the design standards for the compliance by the support level
services.
ESB provides process flow capabilities that can be used for the
ESB
modelling of complex process execution scenarios, which may include
Implications
multiple support level services.
5.4.10 Resource Bargain, Accountability, Regulation

Centre, Comparator, Feedback and Convergence
Resource bargain is the deal by which some degree of autonomy is

agreed between the senior management and its junior counterparts (Beer,
1985). It is a dynamic process, which is responsible for negotiating the
resource allocation as well as attenuation of possible alternatives, as a
part of established homeostatic loop between the management of System
ONE and the senior management of the System-in-focus. However, to
monitor accountability for the allocated resources and strike resource
bargain as necessary, additional mechanisms need to be deployed.
155
In the context of resource bargain, it is necessary to think of

accountability for the resources being provided. The accountability must
be interpreted not in terms of funding, but in terms of variety engineering
(Beer, 1979). As it is obviously impossible for the senior management to
monitor all the activities undertaken by all the subsidiaries of the System-
in-focus, it is essential to position accountability as the high variety
attenuator of possible outcomes. Thus, accountability implies the
responsibility for the use of resources, which is problematic for the senior
management to handle. To mitigate these complexities and associated
risks a mechanism in the form of regulatory centre needs to be engaged.
Regulatory centre is a mechanism that is responsible for the

amplification of the managerial variety and the attenuation of the
operational variety of System ONE. It is a focus of homeostasis between
the management and the operations (Beer, 1985). Given that the
management of System ONE conducts its operations according to the
resource bargain, which is itself restrained by the senior management, an
act of regulation in the form of plans, programmes and procedures
transmission can help in the amplification of the managerial variety,
through the elaboration of details of the resource bargain; and in the
attenuation of the operational variety, through harnessing of operational
potentiality to the agreed objectives (Beer, 1981).
However, given that the system can be in a number of states, there

could be states that are relevant, but also irrelevant to the purpose of the
system (Beer, 1985). These irrelevant states can cause to use of scarce
resource that are essential for the viability of the system. In other words, if
the purpose of the system is to survive, then the process of selection of
states, that serve this purpose, is fundamental to the viability of the
system. It is common for the purpose of the system to be defined at a
higher level of recursion (Beer, 1979). However, the purpose might
change and the systems that need to understand the changed purpose
156
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.
The role of the comparator is to continuously compare the declared

purpose against the purpose that is imputed from the results delivered by
the system (Beer, 1979). If the results are irrelevant to the declared
purpose then the feedback, in a form of an error signal (), is sent to adjust
this initially declared purpose statement. Thus, possible disequilibrium can
be avoided with the corrective actions that converge on a compromise of
purpose for both the system at the higher level of recursion and the viable
system itself (Beer, 1985).
Of course this will result in implications for the planning of resources

the viable system is accounted for. Given that the resource planning is the
responsibility of System THREE, the agreed objectives with System ONE
are often prioritised over the purpose convergence, rather than vice-versa.
Since the purposes of viable systems, of System ONE, are formulated at a
different level of recursion and thus imply to a separate existence, it is
completely natural for them to deviate from the purpose of the higher-tier
system. Surprisingly, the degree of purpose difference between the levels
of recursions represents the authoritarian mechanisms in the system.
However, as long as the System-in-focus remains cohesive, the
compromise convergence must continuously act (Beer, 1979).
Proposed VSM Design Principle Bargain: The system must

regulate its resource consumption, collect the feedback on the services it
157
provides as well as compare the services and converge them as

necessary.
5.4.10.1 Principle 10: Service Bargain

Name Service Bargain
VESBM ESB must regulate and minimise the resource consumption by the
Design support level services to increase their reusability and scalability, whilst
Principle preserving autonomy, and collect the feedback on the service usage to
Statement compare service compositions and converge them if necessary.
Service Reusability outlines design considerations in the support level
services that can provide the means for reusing them. Service
Autonomy defines the high level of control for the support level
services over their environment. Service Statelessness imposes
SOA Rationale
minimisation of resource consumption by deferring the management of
state information in the support level services. Service Composability
outlines how the support level services are combined in an effective
composition, which can be restructured if necessary.
autonomous units, capable of scaling globally. These units can provide
their capabilities, in the form of individual services. For these services
to scale in the environment, it is necessary for the ESB to regulate and
minimise the service resource consumption, so that the necessary
ESB balance can be achieved between them. This balance can be retained
Implications through the relevant feedback loops that provide information about the
service usage and also assist with the further comparison of the
alignment of service compositions with their declared purposes in the
process flows. When necessary these service compositions can be
adjusted, by converging support level services, so that the expected
functionality could be continuously delivered.
5.4.11 Management
System THREE, referred as Management or sometimes as Control,

is responsible for issuing direct line management instructions as well as
for negotiating resources through a two-way communication channel to
ensure the flow of accountability reports upwards to the meta-level
management and to keep it in touch with the operations of sub-units of the
System-in-focus, as a prerequisite for viability (Espejo and Gill, 1997).
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. Although, it is not undertaking any anti-
oscillatory functions, it is still responsible for how the System TWO
158
operates. Therefore, it can be best associated with the here-and-now

daily management of the enterprise (Beer, 1985). Generally, both System
ONE and System TWO, including System THREE, are concerned with the
here-and-now (Beer, 1979) (Figure 5-3).
Often, rigid control of sub-units by meta-level has its implications on

the overall flexibility in operations. To avoid the over-usage of direct
commands, mechanisms in the form of exception-reporting systems or
management-by-objectives can be designed to grant sub-units enough
space for maneuvering (Espejo and Harnden, 1989). However, as with
any routine mechanism the variety attenuation activities, undertaken by all
the five channels of the VSM, might unintentionally lead to information
loss, either because of over generalisation or oversimplification of
information that needs to be passed. This could especially be sensitive for
the senior management of the System-in-focus, since the absence of
complete information might attenuate the decision-making, often leading to
costly outcomes (Beer, 1972). To avoid these implications a special
sporadic mechanism needs to be employed at the level of the senior
management that would bypass all of the existing five channels and
undertake audit activities directly upon the operations of System ONE.
This mechanism is realised in the sixth channel known as Audit.
159
Figure 5-3: System ONE, TWO, THREE and THREE* (Beer, 1985)
Proposed VSM Design Principle Performance: The system must

manage the services it provides and monitor their performance against
agreed objectives.
5.4.11.1 Principle 11: Service Performance

Name Service Performance
VESBM ESB must manage the support level services, balance the degree of
Design coupling between them and monitor their performance to provide
Principle cohesion within the compositions they constitute, according to the
Statement agreed objectives.
Service Loose Coupling influences the level of coupling between the
SOA Rationale support level services. Service Composability outlines how the support
level services are combined in an effective composition.
gains information about the state of operations, along with the timely
ESB data tracking and reporting, as it flows in real-time through the system.
Implications ESB management platform can provide the means for the monitoring,
logging, audit, administration, remote configuration and management
of the support level services.
160
5.4.12 Audit
System THREE*, referred as Audit or sometimes as Monitoring, is

an extension of System THREE, which is by consensus not positioned on
the command axis. The audit activities it undertakes are sporadic, high
variety and intra-operational defined in terms of System THREE to restore
its own requisite variety (Beer, 1985).
System THREE* channel is designed to connect the meta-level

management with sub-units, bypassing the management of sub-units, to
ensure that reports regarding the state of operations are accurate and
reflect the reality, rather than personal bias about the situation (Espejo and
Gill, 1997). However, over-usage of audit activities can have implications
on the overall organisational viability and therefore it is necessary for the
System THREE* to comply with a set of rules that will lead to its more
effective use. That is, System THREE* must be: sporadic, rather than
regular to avoid any anticipations and pre-planned preparations (Beer,
1979); infrequent so it will not undermine the authority and trust in the
sub-units management (Beer, 1985); openly-declared mechanism of which
everyone is aware to reduce reactive and defensive behaviours, during
audits and cross-checks (Beer, 1979); and must link only two contiguous
levels of recursion, as inclusion of more levels is often practically
unworkable because of the complexity involved, but most importantly
because it may also lead to the corruption of the overall integrity of the
System-in-focus and a complete breakdown of trust throughout the
sections of the entire organisation (Espejo and Gill, 1997).
Proposed VSM Design Principle Audit: The system must

undertake sporadic, high variety and intra-operational checks on the
services it provides to prevent and remove any impediments, which may
arise from incidents and problems during operation.
161
5.4.12.1 Principle 12: Service Audit

Name Service Audit
ESB must have tools that can enable sporadic, high variety and intra-
VESBM
operational checks on the support level services to prevent or remove
Design
any impediments, which may arise from incidents or problems during
Principle
the runtime, especially when deferring the management of state
Statement
information.
Service Statelessness imposes minimisation of resource consumption
SOA Rationale
by deferring the management of state information.
administration, remote configuration and management of the support
level services. These tools can be used for the non-regulatory audits
ESB
on the support level services and perform intra-operational checks on
Implications
their operation as well as the resource consumption, to minimse
possible negative effects of deferring the management of state
information on the operation.
5.4.13 Intelligence and Self-awareness
System FOUR, referred as Intelligence, is responsible for

monitoring the external environment an organisation is operating in as well
as for providing an insight on the internal organisational capabilities, so
that it can adapt appropriately and plan ahead its course of evolution
(Espejo and Gill, 1997).
System FOUR interacts with the external environment through a

number of channels that aim to satisfy the common areas of interest that
of concern of System FOUR. Each of these areas has Alpha () and Beta
() loops that both consist of amplification and attenuation channels. Alpha
amplifier continuously projects the image of each area on the environment
to identify the space of relevance that must be marked with subsequent
state of presence, commanding knowledge and plans. Alpha attenuator of
each area continuously observes the information relevance in the
environment, in a proactive manner avoiding the waiting attitude for any
accidental information appearance. Alpha loop must then consider not
only the interests of one particular area, but the intersection of interests
with other areas of System FOUR, as well. All of this is applicable to the
162
Beta loop as well, with only one remark that the external environment it is
concerned of is of unknown future (Beer, 1985).
In organisations, these loops of intelligence undertake similar

activities: one loop gathers information from external environment
regarding the possible changes on the market, including changes in
technology and other factors that are of future concern and the other loop
is focused on the internal aspects of the organisation to assist it in
projecting its unique identity onto the external environment. It is important
to keep a rational balance between both loops, as too much focus on the
external environment may overwhelm organisation with data that can
reach its capacity and corrupt proper interpretation of actions that might
need to be taken, same as too much focus on the internal organisational
aspects, its unique identity and the message that needs to be sent to the
environment, may lead to the development of poor communication
mechanisms that would be incapable of listening for the feedback from the
external environment. To ensure that a viable balance between the loops
is preserved and the course of evolution is following a well-developed
plan, the intelligence shall be supplied with an up-to-date model of the
organisation (Espejo and Harnden, 1989).
This way, System FOUR provides the self-awareness for the

System-in-focus. In comparison with Systems ONE, TWO and THREE,
which are concerned with the management of the inside-and-now,
System FOUR is concerned with the management of the outside-and-
then, of the system.
System FOUR is also in a continuous homeostatic loop with System

THREE (Figure 5-4). This homeostatic relationship obeys the four
principles of organisation. Furthermore, System FOUR consists of the
model of itself embedded into the model of the System-in-focus (Millar,
163
2009). This recursive embodiment, that includes all the relationships, is

indefinite (Beer, 1979).
Figure 5-4: Homeostatic Relationship of System THREE and System FOUR

(Beer, 1985)
Given that the First Axiom of Management provides the measure of

variety in System THREE, the homeostatic relationship of System FOUR
and System THREE is then described in terms of the Second Axiom of
Management.
The Second Axiom of Management states, that:
The variety disposed by System THREE resulting from the

operation of the First Axiom equals the variety disposed by System
FOUR. (Beer, 1985, p.121)
In other words, homeostatic relationship of System THREE and

System FOUR is the organ of adaptation for the system (Beer, 1985).
164
Proposed VSM Design Principle Intelligence: The system must

have the awareness of the environment that surrounds it, by monitoring it
for possible opportunities, which could contribute to the overall viability of
the system.
5.4.13.1 Principle 13: Service Intelligence

Name Service Intelligence
ESB must have the awareness of the support level services available
VESBM
in the environment, by discovering and monitoring service directories
Design
as well as by interacting with other ESBs and use service meta-data
Principle
information to further integrate new support level services as
Statement
necessary.
Service Discoverability imposes the support level services to be
SOA Rationale supplemented with communicative meta-data by which they can be
effectively discovered and interpreted.
ESB gains information about the state of operations and can monitor the
Implications support level services available in the external environment, whether in
service directories or in other ESBs, it interacts with.
5.4.14 Policy and Ethos
System FIVE, referred as Policy, is responsible for providing clarity

to the direction, values and purpose of the organistional unit, as well as to
the design, at the highest level, of conditions for organisational
effectiveness (Espejo and Gill, 1997).
System FIVE is ultimately responsible for creating the corporate

ethos for the System-in-focus. System FIVE is the logical closure of the
VSM: it is the point of self-reference, where the identity is asserted and no
more systems are placed above it, at a given level of recursion. The ethos
it creates forms a flexible atmosphere, rather than a rigorous set of
objectives, for the entire system. Therefore, the ethos serves as a variety
sponge of gigantic capacity (Beer, 1985, p.125).
The Third Axiom of Management states, that:
165
The variety disposed by System FIVE equals the residual variety

generated by the operation of the Second Axiom. (Beer, 1985, p.134)
Residual does not imply to small, but to anything leftover, which in

some cases can be considerably large (Beer, 1981).
In comparison with other functions of the VSM, the policy is a low-

variety function that makes decisions upon information that it selectively
receives, through interactions of intelligence and management functions,
which are checked after extensive analysis that takes place within and
between those functions. Thus, the organisational effectiveness is
dependent on how intelligence and management functions are
interconnected and organised, so that issues that arise are initially
checked in between them, before reaching the policy function (Beer,
1979). Intelligence and management functions provide a complimentary
perspective on the definition, implementation and adjustment of
organisational units identity and therefore need to be given enough weight
in the policy-making process. A system design that considers these
interactions, interconnections and organisation of functions will lead to a
more effective policy-making and to the creation of an effective
organisation overall (Espejo and Gill, 1997).
Proposed VSM Design Principle Policy: The system, as a whole,

must comply with legislative and regulatory obligations, and have a clear
policy that would define a consistent identity of the system, its goal and its
purpose.
5.4.14.1 Principle 14: Service Policy

Name Service Policy
VESBM ESB support level services must comply with the service contract
Design design standards that are abstracted and regulated by the policy,
Principle which influences the identity, goal and purpose of the ESB.
Statement
Standardised Service Contract enforces the support level services, in
SOA Rationale the same service inventory, to comply with the same contract design
standards. Service Abstraction imposes service contracts to contain
166
only the essential information about the support level services.

administration, remote configuration and management of the support
level services. These tools can be used to impose the same
ESB
contractual requirements to all support level services that are deployed
Implications
at disparate locations and therefore facilitate standardised distributed
integration and incremental adoption of the ESB, as a whole, in
accordance with its identity, goal and purpose.
5.4.15 Algedonic Signals
System FIVE is prone to occupational hazards that can put it in a

somnolent state. Because of all the filters on the main axis the organism
can get droned and System FIVE may eventually fall asleep (Beer,
1985, p.133). To wake up the system a special type of alarm signal,
known as algedonic (etymology of which is ancient Greek and it stands
for both pain and pleasure), is employed in the system. It performs non-
analytical regulation, divides signals ascending from System ONE, which
enter meta-systemic filtrations, and uses its own algedonic filter to decide
whether System FIVE shall be alerted or not (Beer, 1985).
Proposed VSM Design Principle Alert: The system must be

endowed with a mechanism that would alert it in situations that require
immediate actions.
5.4.15.1 Principle 15: Service Alert

Name Service Alert
VESBM ESB must be endowed with a mechanism that would alert in situations
Design when the viability of the system is compromised.
Principle
Statement
Service Orientation and Interoperability influence support level
SOA Rationale services to achieve greater integration capabilities, by imposing
interoperability between the services.
ESB can enable the event-driven architecture and expose support
level services as generic endpoints, which can interact and treat
messages they receive as events. In complex event processing
ESB scenarios, the event-driven architecture is usually implemented with
Implications pattern matching, interpretation, and other mechanisms, to process
events during the asynchronous message exchange. Along with these
mechanisms, the ESB can be endowed with a special alerting service
that can provide notifications in times of deviation from the policy,
167
whether it is because of the changing integration requirements,

interoperability issues or other reasons that may compromise the
viability of the ESB.
5.5 VESBM Summary

As was mentioned earlier, 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.
The summary of these correlations is provided in the tables (Table 5-2)
and (Table 5-3) below.
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
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.
Nevertheless, as ESB can be an integral part of SOA, the survival

of the ESB at the bottom can become essential for the survival of the SOA
at the top. As was noted, this survival 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
169
services as well as for organisations whose IT departments are operating

as independent units. The figure below (Figure 5-5) presents the VESBM
and must be regarded as complementary to the VESBM design principles.
Figure 5-5: Viable Enterprise Service Bus Model
As seen from the figure, the VESBM is a simplified representation

of the VSM (Figure 3-1) that retains the VSM structure, its sub-systems
and all of the essential elements.
The design principles proposed in this chapter underwent multiple

design-evaluate iterations, as defined in the DSR and suggested by
170
Sonnenberg and vom Brocke (Sonnenberg and vom Brocke, 2012).

During these iterations, the feedback from the reviewers of the peer-
reviewed academic conference and journal papers, published during this
research (please, see Publications section for more information), was
collected and analysed to update the design principles. As this research is
of applied nature, the VESBM was also used by professional organisations
(please, see the next chapter), which evaluated it in the real world
settings. This evaluation and the feedback collected from the
organisations contributed to defining the final version of the VESBM
design principles. As such, the final version of the design principles is a
modification of the initial set of the design principles. The initial set of the
design principles is not listed in this chapter, to avoid possible
duplications, but in the next chapter some of the key modifications are
highlighted.
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
individuals in the system. This limitation will be discussed in the last

chapter.
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
173
Chapter 6. Evaluating the Artefact VESBM Validation
Chapter 6. Evaluating the Artefact VESBM

Validation
Design is not just what it looks like and feels like. Design is how it
works.
Steven Paul Jobs
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.
6.2 The Use of the VESBM

Six companies, from Europe and Australia, contributed to defining
the final version of the VESBM design principles. In these studies, the
collaboration with two companies namely, TeliaSonera and Global Service
Provider resulted into two practical cases. The collaboration with the other
four companies, namely, 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. All of the six
companies provided feedback through a survey, for which they were
selected because of their background in IT and Telecommunications, and
because of the nature of their latest projects. As described below, the
174
focus of the projects was on the service integration platforms, such as the
ESB, for both the on-premises and Cloud use.
TeliaSonera is a dominant telephone company and mobile network

operator in Sweden and Finland, with operations in Northern and Eastern
Europe, Central and Southern Asia as well as Spain, and more than 180
million active mobile customers. In January 2015, one of its divisions in
Eastern Europe initiated the development of a multi-functional Virtual
Education Platform (VEP). The VEP supposed to integrate the existing
educational software of companys regional offices and provide them as
services, through the internal Virtual Private Network (VPN) and further
through the Cloud, to its staff members, so that they could take online
training whilst visiting, residing or working in different regions of the
country. In this initiative, the VESBM was chosen to identify and align the
business design requirements and the technical design rationale for the
VEP.
Global Service Provider (GSP) is a leading satellite communications

operator in the Commonwealth of Independent States. GSP is involved in
various projects with companies and organisations in both the public and
private sectors, amongst which are the Ministry of Emergency Situations,
Ministry of Defence, British Petroleum, Halliburton, Schlumberger,
McDermott International and others. From the early 2015, GSP is
implementing a large project for the shipping company, the objective of
which is to upgrade the obsolete on-board navigation hardware equipment
on 61 vessels operating in the Caspian and North Seas. As a part of this
project, GSP is also responsible for integrating the obsolete software
systems used on-board of these vessels into a modern service-oriented
system that would be accessible through the Cloud. Because of the vastly
heterogeneous nature of these systems, one of the challenges for the
GSP, prior to initiating the integration, was to decide whether there is a
need to develop a custom integration platform, such as the ESB, or
175
acquire, and extend if necessary, an ESB product already available on the

market, as a COTS, instead. In this project, the VESBM was chosen to
define the features of the potential ESB.
Defence3D is a virtual simulation software development company,

headquartered in Canberra, Australia, and specialised in designing,
integrating and developing advanced interactive simulation and training
systems for the Australian and European military markets. The company is
constantly involved in complex integration projects of a variety of
proprietary military software, using custom built integration adapters,
message brokers and so on. Defence3D was searching for an ESB, but
because of the diverse integration requirements, of the latest projects, it
was unclear, for the company, what type of features needed to be
incorporated into the ESB. The company examined the VESBM for its
suitability to derive the design of the ESB.
Talented Technologies is a software development company, from

Eastern Europe, specialised in providing CRM and ERP products, through
the Cloud to client companies. Several times in a year, the company
conducts diagnosis of its products, for possible issues, to maintain the
quality of the services being provided. Talented Technologies examined
the VESBM, as a benchmarking tool, for the identification of potential
design gaps in their products.
Credo Group Ltd. is an IT services company, from Central Europe,

that provides hosting, web development, API integration and a variety of
other services to its clients, through the Cloud. The company was building
a service integration platform in the Cloud and expressed its interest in
examining the VESBM as a model for defining the design of the platform.
Discover Ltd. is a web and software development company, from

Eastern Europe, that builds travel, hotel and flight reservation systems.
Discover Ltd. was building a platform that could integrate the three
176
systems together and examined the VESBM for its applicability to identify
the design of this platform.
Having spent more than 10 years, working for 17 different

companies, I was fortunate to build a profound relationship with a large
network of professionals. Over the years, I constantly collaborated with
most of the companies, helping them in various projects. As a result, the
management of the companies was aware of my professional
engagement, whether it was in industry or academia. This close
cooperation helped in involving some of the companies into my research
work. The background of the involved companies is in IT and
Telecommunications, and as a result, there was a genuine interest, from
their side, in applying my research to their current challenges in IT. This
genuine interest helped in avoiding any possible biased approach to the
research and contributed to the quality of the work being conducted.
As was mentioned, in Chapter 1, the ESB is an architectural style or

pattern (Chappell, 2004; Erl, 2008; Kress et al., 2013) and:
! All ESBs are not the same (Linthicum, 2008);
! ESBs are at the heart of modern ERP, CRM, Supply Chain,

Retail Management, and other similar platforms that
integrate services for various purposes (OShaughnessey,
2013);
! ESBs can converge SOA, API and possibly other emerging

paradigms, whilst being agnostic to the technology platform
(Moore, 2013); and
! Many ESBs are over-bloated and tend to become too much

for an SOA initiative (Olliffe, 2014).
177
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:

approaches?
Earlier, in Chapter 2, it was shown that although, there are

characteristics that influence the design of an ESB (Chappell, 2004), there
was no model that could ensure the survival of the designed ESB, despite
of the changes in technologies that may underpin it that is, the services
at the support level, embedded into the ESB, such as the data
178
transformation, protocol transformation, message encryption and so on.

Based on the assertions in Chapter 1, the objective of this research was
defined as:
It was stressed that, the statement of the research objective has

two parts that needed to be addressed, in order to achieve it. The first part
emphasised development of the generic design principles for the ESB, in a
model that would ensure the ESB survival. The second part emphasised
necessity to ensure the survival of the ESB, independent from the
As was noted, in Chapter 4, the steps that were defined by Hevner

et al. (Hevner et al., 2004) were adapted to outline the steps for
conducting this research. According to these steps, 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.
Adhering to the outlined steps, after the development of the VESBM
design principles, in Chapter 5, the validation of the usefulness and
usability of the VESBM, in practice, is determined in the following way:
! If the VESBM design principles could help in defining the

design of an ESB, or a similar service integration platform,
then the model is useful; and
! If the VESBM design principles could help in the course of

implementation of an ESB, or a similar service integration
platform, then the model is usable.
179
Despite of the diversity of the latest projects of the companies,

involved in this research, they are all essentially focused on building a
service integration platform. However, this diversity can also substantially
benefit this research, by justifying the usefulness and usability of the
VESBM for designing platforms that integrate services for various
purposes, using different technologies. Moreover, given that the ESB can
be provided as a service in the Cloud (Popa and Vaida, 2015), the VESBM
design principles might turn to be suitable for both the on-premises and
Cloud use, as well.
The Subject Matter Experts (SME) of the six companies provided

their professional recommendations on the VESBM and the following
sections summarise the details of the two practical cases and the
feedback collected through the survey, which are the outcomes of this
collaboration.
6.3 Practical Cases

6.3.1 TeliaSonera
As was mentioned, the VEP supposed to integrate the existing

educational software of companys regional offices and provide them as
services. At the initial phase, the services planned to be provided through
the internal VPN, whilst at later stages they will be provided through the
Cloud. To satisfy the VEP needs, the VESBM was chosen to identify and
align the business design requirements and the technical design rationale
of this future platform.
The process of requirements elicitation involved multiple meetings

with the representatives of the company, including the software
developers, systems integrators, system architects and others. In the
course of the development of the VEP, the decision was made to use the
accessible business language in defining the business design
180
requirements, in order to avoid any confusion of the business stakeholders

with the technical and academic language of the VEP. Meanwhile, the
technical team extensively relied on the academic definitions of the
VESBM to outline the technical design rationale for the VEP. It is important
to mention that, whilst the VESBM was adapted to the needs of both the
business stakeholders and the technical team, the structure of the VESBM
remained intact. This approach proved to contribute to the better structure
of both the business requirements and the technical rationale, and
resulted in the alignment provided below (Table 6-1).
Table 6-1: Business Design Requirements and Technical Design Rationale

of the Virtual Education Platform
Business Design Technical Design VESBM Design

#
Requirements Rationale Principles
Purpose The virtual education platform that
The platform must consists of three main modules according
provide virtual to which the complimentary services need
education services. be designed: Active Training Module (that
is, profiles, courses and so on), Archived
1 Service Policy
Training Module (that is, past trainings,
earned points and so on) and eLibrary
Module (that is, study materials, induction
programs, orientation programs and so
on).
ROI The platform needs to provide complete
The platform must be interoperability between the services, to
able to handle the enable service orientation and further
necessary adaptation to the changing service
transformations without integration requirements.
the reimplementation
2 of the core Viability
functionality, to avoid
any additional
expenses and to
maximise the ROI by
leveraging on the
existing assets.
Business-driven The platform needs to maximise the reuse
Business benefits of of the existing services in the course of
the platform must be the development and integration of future
the primary drivers complex technologies, such as the: 3D
3 behind the trainings, augmented reality, telepresence Value Creation
development and the and so on.
further transformations
of the services being
provided.
181
Maintenance The services being provided through the

To preserve its value platform need to be repairable, so that
over time, the platform they can be further reused in the future Value
4
needs to be integrations. Preservation
continuously
maintained.
Multi-functionality An extendable platform with
The platform as a multifunctional capabilities that needs to
whole must be capable integrate a variety of services, including:
of providing various online enrolment programs for virtual
educational services classroom trainings; discussion platform
that can be extended (for example, forums, wikis); statistical
5 and added as information and reporting; e-trainings (that Variety
necessary. may include videos, along with online
interactive classrooms); testing-after-
training; online surveys; online training
evaluation; performance evaluation;
change notifications (for example,
reminders) and so on.
New Functionality Service discovery mechanisms need to be
The discovery and implemented in the platform, to extend the
inclusion of new pool of the base services by integrating
Service
6 services must help in new services outside of the system
Intelligence
extending the boundaries (for example, service
functional base of the directories, public APIs or other
platform. platforms).
Communication The platform needs to handle network
The platform must latency and be endowed with reliable,
have the capacity and secure and asynchronous messaging
capability to handle an service, and load balancers to provide:
extensive amount of automatic switch within and between
data throughput, in a video trainings (if there is a sequence in
secure and reliable the modules); messaging with other peers
7 manner. and administrators; uploading of training Channels
materials (for example, video, pdf, word,
excel, mp3, photos and so on); using
modules for distance learning, through
Lightweight Directory Access Protocol
(LDAP) and Active Directory (similar to
the Sharable Content Object Reference
Model (SCORM))
Resource Load The platform needs a mechanism for the
The platform must intelligent distribution, allocation and
8 Service Bargain
balance the resource release of resources across all services.
consumption.
Modularity To provide better governance of the
The platform must services being provided through the
have a modular design platform, the degree of coupling between
to provide better the services needs to be reduced, to
Service
9 governance of the increase the level of autonomy of each
Autonomy
entire service functional module the services comprise.
ecosystem and each
individual service being
provided.
10 Interruption To comply with the Service Level Service
182
Deviations in the Agreements, the platform needs to handle Deviation

services that may lead possible service interruptions and restore
to service interruptions the quality of the deviated services by
or quality reduction replacing them with alternatives (for
must be handled by the example, in a service composition).
platform.
Unusual Events Special alert mechanism needs to be
The platform must implemented in the platform to notify the
have an alert system in times of possible over-usage
mechanism for (for example, system overload, cost of
possible unusual service and so on), non-usage (for
11 Service Alert
events that might example, unrealised benefits, ROI and so
occur. on), policy violation or other unusual
behavior with the services being provided
and record such events in a special
registry for the further evaluations.
Performance The platform needs to incorporate
Monitoring management tools that would provide the
The platform must information on the performance of the
Service
12 monitor the services, service compositions, level of
Performance
performance of the service coupling and so forth.
services being
provided.
Awareness The platform needs to be endowed with
The operational state tools for automatic and infrequent checks
of the services in the of the state of the services against quality
13 platform must be parameters, and further generate the Service Audit
infrequently checked reports on the quality of each service.
for the quality control
purposes.
Economies of Scale The same platform design needs to be
Service
14 The platform must be implemented at all sites that will be
Recursion
replicated. integrated (that is, in the regional offices).
Consistency The platform needs to support
The platform must standardised integration for all of the
15 provide consistent existing and future services to be Black Box
integration for all provided.
services.
This alignment is the result of the teamwork and collaboration with

more than 15 SMEs of the company, and myself, supervised by Dr.
Edward Lewis. It must be noted that, in this practical evaluation of the
business requirements and the technical rationale of the VEP, the VESBM
design principles were refined through multiple iterations, adhering to the
design-evaluate cycle of the DSR. In every such iteration, the skilled
professionals were provided with the VESBM design principles that were
183
updated according to their recommendations. Examples of some of these

updates include:
1. Simplify the naming:
Requisite Variety -> Variety;
Deviation Control -> Service Deviation;
Regulatory Control -> Service Regulation -> Service

Bargain;
Service Management -> Service Performance;
Service Compliance -> Service Policy; and
Crisis Alert -> Service Alert.
2. Extend the Principle 10: Service Bargain (previous version)
ESB must regulate and minimise its resource

consumption to increase scalability potential, whilst
preserving autonomy and collect the feedback on the
service usage to compare service compositions and
converge them if necessary
The SMEs recommended to update and extend the Principle 10

and include the notion of the reuse of shared resources: to increase
their reusability. The name of the principle was also simplified based on
their recommendations. This kind of feedback helped in refining the other
VESBM design principles as well.
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
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.
6.3.2 Global Service Provider
As was mentioned, the GSP is implementing a large project for a

shipping company, the objective of which is to upgrade the obsolete on-
board navigation hardware equipment on 61 vessels. The outcome of the
integration of the obsolete software systems used on-board of these
vessels, for which the GSP is also responsible, is an ESB grid that will
interconnect 61 ESB units (that is, one ESB per vessel) into a cohesive
system. To streamline the integration process, the decision was made to
have a common design for all ESBs and provide their functionality as
services, in the future, through the Cloud. The VESBM was chosen to
define what features the potential ESB must have, so that it could meet
the integration needs.
In the course of defining the ESB features, multiple meetings with

the representatives of the GSP, including the software developers,
middleware engineers, system architects and others were conducted. In
this collaboration, the VESBM was analysed by the technical team and
was used to derive the features of the ESB. These studies proved to be
helpful and the outcome of this work resulted in the mapping (Table 6-2)
and the diagram (Figure 6-1) provided below.
Table 6-2: Identifying the ESB Features through the VESBM Design
Principles
ESB VESBM Design

#
Features Principles
The ESB is an integration unit that is a part of a future integration
1 grid, consisting of similar units, each of which integrates a legacy Service Policy
software system.
2 To support continuous integration and distribution, the standardised Black Box
185
interfaces need to be supported by exploiting the available open

standards provided or incorporated into the ESB.
The ESB needs to support the abstraction of functional endpoints
from the physical deployment to loosen the coupling and the
Service
3 segregation of system applications to enable autonomous
Autonomy
federation, in both centralised and decetralised integration
scenarios.
The functionality for the discovery of new services outside of system
boundaries needs to be incorporated into the ESB and Service
4
supplemented with the pub/sub pattern for the future service Intelligence
integrations.
To meet the variety of integration requirements and integrate the
whole breadth of legacy software systems, the ESB needs to be
5 Variety
extendable and support the plugin functionality for custom-
developed integration adapters.
To form a pervasive and consistent grid, the ESB needs to be
Service
6 replicated across the infrastructure, whilst providing its integration
Recursion
capabilities in a standardised manner.
For the successful implementation of the integration strategy, the
7 ESB needs to provide interoperability between the services, to Viability
accommodate possible changes and modifications in the services.
The integration strategy needs to include the tactical integration of
each individual software system, which requires ESB optimisation
8 Value Creation
and the reuse of resources needed in the course of formation of the
integration grid.
Components of the systems being integrated need to be repairable Value
9
within the ESB. Preservation
The ESB needs to handle all the deviations in the service
Service
10 operations, to avoid their possible escalation and prevent potential
Deviation
disruptions, interruptions or reduction in the quality of the services.
The ESB needs to control the resource allocation, load and release
11 Service Bargain
across services to increase scalability and reusability.
To provide exhaustive information on the performance of the
services and monitor the degree of coupling between them, a
Service
12 remote management and configuration tooling (for example, Java
Performance
Management Extensions (JMX)) needs to be incorporated into the
ESB.
The ESB needs to incorporate a special functional layer for non-
regulatory audits on the operational state of services that would
13 Service Audit
include tracking and aggregation points as well as data collection,
monitoring and reporting capabilities.
The ESB needs to incorporate a special functional layer for alerts
14 during possible anomalies, such as the disuse or overuse of Service Alert
services, unauthorised access, security breaches and so on.
The ESB needs to support secure and reliable messaging, using
established standards (for example, JMS) that would provide
15 Channels
capacity and capability for authentication, credential management,
asynchronous communications, transactional integrity and so forth.
186
Figure 6-1: VESBM-based ESB Design
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:
1. Change the naming:
From ESB-as-a-BlackBox to Black Box; and
From Resource Bargain to Service Bargain.
2. Consider the following SOA principles of service design:
187
Standardised Service Contract in Value Creation,

Service Policy;
Service Statelessness in Service Audit;
Service Orientation and Interoperability in

Channels; and
Service Loose Coupling in Service Recursion.
During this study, the VESBM brought attention to such design

principles as Service Recursion and Service Alert, which were initially
unforeseen because of the unclear design of the ESB.
The application of the VESBM design principles helped in

identifying the features of the ESB. This practical case demonstrated the
usefulness and usability of the VESBM, which was also indicated by the
invitation, to further collaborate with GSP in the forthcoming projects.
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.
During the last 10 months, multiple presentations were conducted

at the headquarters of the companies. The companies were also
constantly consulted through online conferences. The SMEs were
188
provided with the detailed introduction to the VESBM, copies of the

academic publications and the updates I was making to the design
principles, in the course of the research. Because the background of the
companies is in IT and Telecommunications, and the SMEs involved were
ranging from programmer analysts, software developers, middleware
engineers, ERP and CRM engineers to system architects, Cloud architects
and IT business analysts, their feedback could contribute to the quality of
the work being conducted.
After the negotiations with the University of New South Wales

(UNSW Canberra) and the six companies, the agreement to conduct the
survey was obtained and an invitation letter to participate in the survey
was sent to each respective company. The survey was reviewed and
approved by the High Research Ethics Advisory (HREA) panel of the
UNSW Canberra on March 17th, 2015. The survey met the requirements
as set out in the National Statement of Ethical Conduct and was allocated
an HREA panel reference number: A-15-07 (please, see Appendix A for
more information).
6.4.1 Feedback Data
The survey was volunteer, non-compulsory and anonymous. As the

survey was anonymous, participants did not need to provide their names,
whilst providing the names of their respective companies was optional.
The survey sample size was of 55 of full-time employees of the six

companies. The participants provided their feedback using a common
form (please, see Appendix B for more information), through which they
could provide comments, grade the VESBM design principles and answer
to a series of questions. The choice of the survey questions and their
relevance to the research question and the research objective will be
explained in the next section. The feedback provided by the respondents
contributed to defining the final version of the VESBM design principles
189
and the summary of this feedback is provided in the tables (Table 6-3-
Table 6-11) and the figure (Figure 6-2) below.
Table 6-3: Survey Clause #1: What is your occupation?
Occupation Number of Participants

1 System Architect 6
2 Software Developer 10
3 Programmer Analyst 7
4 Middleware Engineer 5
5 Systems Integrator 8
6 ERP and CRM Engineer 3
7 Cloud Architect 5
8 IT Coordinator 6
9 IT Business Analyst 3
10 Business Manager 2
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?
Years Number of Participants

4 1
5 10
6 5
7 7
8 5
9 10
10 6
11 2
190
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
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
appropriate naming of each design principle.
193
appropriate meaning of each design principle.
194
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
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?
Through this survey, the respondents answered to and graded

about 3685 items (that is, 66-67 per respondent) in the form. As per the
replies, the trend indicates the overall acceptance of the VESBM design
principles.
6.4.2 Feedback Analysis
In this survey, the participants were asked a series of questions,

which were selected because of their relevance to the research question
and the research objective. The relevance of each question is explained
below:
! Survey Clause #1: What is your occupation?
Because the VESBM was created for IT-intensive

systems, it was necessary to ensure that the
participants are of the relevant area of expertise.
196
! Survey Clause #2: In your organisation, can you regard IT as

a Main Output of the organisation or just as a Service Unit?
As was noted earlier, 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. 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. Therefore, it was necessary to determine the
role of IT in each company, to analyse the extent to
which the VESBM might be exploited.
! Survey Clause #3: How many years of work experience in IT

do you have?
To ensure the quality of the feedback being provided,

it was necessary to consider the SMEs with several
years of substantial work experience, so that their
replies could benefit the VESBM.
! 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.
To ensure that the VESBM design principles helped in

defining the design for an ESB, or a similar service
integration platform, the participants, based on their
experience, were asked whether they found the
197
VESBM to be useful. Adhering to the DSR, this

question directly justifies the usefulness of the
VESBM.

own vision on the usability of these principles for the design
of the ESB.
To ensure that the VESBM design principles helped in

the course of implementation of an ESB, or a similar
service integration platform, the participants, based on
their experience, were asked whether they found the
VESBM to be usable. Adhering to the DSR, this
question directly justifies the usability of the VESBM.

own vision on the appropriate naming of each design
principle.
To determine if the conducted presentations and the

consultancy work helped the participants thoroughly
comprehend the VESBM, it was necessary to ensure
that the naming of the design principles was
understood.

own vision on the appropriate meaning of each design
principle.
198
To determine if the conducted presentations and the

consultancy work helped the participants thoroughly
comprehend the VESBM, it was necessary to ensure
that the meaning of the design principles was
understood.
! 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)?
This question directly contributes to the first part of the

research objective, which emphasised development of
the generic design principles for the ESB, in a model
that would ensure the ESB survival.

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?
This question directly contributes to the second part of

the research objective, which emphasised necessity
to ensure the survival of the ESB, independent from
the technologies that may underpin the ESB.
! 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?
199
As was mentioned earlier, depending on the type of

organisation, survival of the ESB at the bottom can
become essential for the survival of the SOA at the
top and can partially contribute to the survival of the
whole enterprise. This question was clarifying if the
VESBM design principles can be reused at the
enterprise level.
During the survey, the respondents also provided a series of

comments, a sample of which is provided below:
! Changing the sequence of the design principles (starting with

the Service Policy, Service Intelligence, Service Audit and so
on) can improve their adaptation.
The design principles were ordered in a sequence

suitable for understanding the complexity of the
cybernetic concepts embedded into the VSM. Once
understood, the sequence can be changed to fit the
needs of an application. The change of the sequence
does not affect the VESBM.
! Could the naming of the Value Creation and the Value

Preservation be changed to Service Creation and Service
Preservation, respectively?
Changing the word Value to the word Service, in both

design principles, may lead to misconceptions.
Services are usually part of service compositions.
Often services are subject for the reuse in new
compositions. A value of a service in a composition
may change, but the service is not re-created each
time. Same logic applies to the value preservation.
200
! Change Variety to Service Variety?
ESB can provide its functions in the form of individual

services and Service Variety may reflect that.
However, the variety in the given context refers not
only to services, but also to various concepts that can
be implemented as future capabilities shared amongst
multiple services of the ESB.
! Is there an overlap between Service Recursion and Black

Box design principles?
Recursion implies the indefinite reoccurrence of the

exact replication of the systemic structure, whilst
Black Box is a cybernetic concept the nature of which
can be understood without a need to entering it. In the
VESBM, Recursion can be best associated with the
replication of the ESB design in a pervasive grid,
whereas Black Box can be best associated with the
support of standardised integration in the ESB. Thus,
there is no overlap and both design principles must be
used in combination with the other design principles of
the VESBM.
! How is the Resource Bargain different to Service Bargain?
Resource Bargain was the previous name of the

Service Bargain design principle that was later
changed based on the feedback obtained. The reason
for the name change was because of the fact that the
ESB can provide its functions in the form of individual
services, which can essentially be used as shared
resources across multiple ESBs, as in the case of the
201
Cloud of ESBs. Thus, the Resource Bargain and the

Service Bargain are similar, but the latter naming is
used, instead.
During the survey, similar comments were collected, responded and

distributed across the participants to assist them with the use of the
VESBM. This survey proved to benefit both the companies and the quality
of the work being conducted in this research.
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.
The next chapter summarises 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.
202
203
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
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.
To deepen the understanding of the problem context, Chapter 2

studied the SOA and the ESB in an in-depth literature review. 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
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. In the course of fulfilling the research objective, the
research proceeded with the review of the cybernetic concepts embedded
into the VSM to build a theoretical foundation.
205
To build a theoretical foundation, Chapter 3 reviewed the VSM and

the cybernetic concepts that underpin it. The review has shown that the
VSM structure could be adapted in various applications, justifying its
capability to define the way systems work. The chapter also highlighted
the relationship between the concepts of SOA and VSM, which was
analysed by Graves (Graves, 2014), and indicated that the VSM can
provide the structure for embedded services, which are needed for the
coordination of services in the service-oriented enterprise. Recalling the
potential overlap between the ESB and the VSM, including the early
correlations derived in the chapter, it was concluded that the VSM can be
suitable for providing the structure for the services embedded into the ESB
that is, those at the support level. It was stressed that, given that the
existing characteristics that influence the design of an ESB do not ensure
its survival, the VSM could be a reasonable model for developing the
generic design principles, which would guide the necessary design
considerations. The chapter positioned the ESB as the actual System-in-
focus and based on the established theoretical foundation proposed to
develop the generic design principles for the ESB. However, prior to
proceeding with the development, it was suggested to find a suitable
methodology that could help in answering the research question and
assist in achieving the research objective.
To find such a methodology, Chapter 4 investigated various

approaches in IS discipline, and particularly in the DSR. 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 proceeded with the development of
the actual artefact.
206
Following the DSR steps, Chapter 5 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
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 individuals in the system. 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, it was stressed that 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 research proceeded
with the evaluation of the VESBM in the real world settings, to validate its
usefulness and usability.
Adhering to the design-evaluate process, defined in the DSR,

Chapter 6 provided the details about how the novel VESBM artefact,
created in this research, was validated through two practical cases and a
survey. It was noted that, 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 that
207
was collected, during the evaluation, contributed to defining the final

version of the VESBM design principles and to answering the research
question and achieving the research objective. It was also highlighted that,
the diversity of the applications, in which the VESBM was used, indicates
its suitability for designing platforms that integrate services for various
purposes.
7.3 Answering the Research Question and

Achieving the Research Objective
After stressing the need for action in the domains of SOA and ESB,
in Chapter 1, which formulated the motivation for conducting the research,
the question being asked in this research was defined as:

approaches?
In accordance with the research question, Chapter 2 studied the

SOA and the ESB in an in-depth literature review to deepen the
understanding of the problem context and defined the objective of this
research as:
It was stressed that, the statement of the research objective has

two parts that needed to be addressed, in order to achieve it. The first part
emphasised development of the generic design principles for the ESB, in a
model that would ensure the ESB survival. The second part emphasised
necessity to ensure the survival of the ESB, independent from the
208
During the design of the VESBM, in Chapter 5, these two parts

were addressed in the following way:
! The communication and control is at the basis of both the

VSM and the ESB, and the early correlations identified
between them, indicate that the cybernetic concepts
embedded into the VSM could possibly be formed into the
generic design principles for the ESB, subsequently aligning
the characteristics that influence the ESB design. The VSM
can provide the structure for embedded services and in order
to build a model that would ensure the ESB survival, the
VSM structure needs to be used as the basis for combining
the generic design principles into a cohesive whole.
! ESB is a service-oriented middleware, which can provide its

functions, through service containers, in the form of
individual services. The application of the SOA principles of
service design can serve as a guideline towards identifying
the design of technology-independent services and in order
to ensure the survival of the ESB, independent from the
technologies that may underpin the ESB, these principles
could possibly be used to define the design characteristics in
the support level services of the ESB.
According to the design-evaluate process, defined in the DSR, the

VESBM had to be evaluated in the real world settings, to validate its
usefulness and usability.
During the evaluation of the VESBM, in Chapter 6, the validation of

the usefulness and usability of the VESBM, in practice, was determined in
the following way:
209
! If the VESBM design principles could help in defining the

design of an ESB, or a similar service integration platform,
then the model is useful; and
! If the VESBM design principles could help in the course of

implementation of an ESB, or a similar service integration
platform, then the model is usable.
The validation of the VESBM was done in multiple iterations, and

the two practical cases and the survey contributed to defining the final
version of the VESBM design principles. As such, in the survey, the
clauses #4 and #5, validated the usefulness and usability of the VESBM,
whereas the clauses #8 and #9, addressed the two parts of the research
objective, as outlined below:

own vision on the usefulness of these principles for the
design of the ESB.

own vision on the usability of these principles for the design
of the ESB.

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

extent) to 10 (most extent), do you think the VESBM
provides the design for the ESB, which will retain its design
210
(that is, survive) independently from the technologies that

may underpin the ESB?
The feedback that was collected, during the evaluation, indicated

the overall acceptance of the VESBM design principles.
During this research, substantial feedback was also received from

the reviewers of peer-reviewed conferences, journals, symposiums and
seminars, at which this research work was published and presented
(please, see Publications section for more information). Fulfilling the
research contribution and communication step, defined in the DSR, the
contribution to the knowledge base was done through publishing the
research findings in:
! Conference Papers
N. Jafarov, E. Lewis (2015a). Reinterpreting the

Principles of SOA through the Cybernetic Concepts of
VSM to Design the ESB as iPaaS in the Cloud, IEEE-
Springer Science and Information Conference.
London, United Kingdom.
N. Jafarov, E. Lewis (2014a). Mapping the Cybernetic

Principles of Viable System Model to Enterprise
Service Bus, (ISBN: 978-0-9803267-5-8), IEEE 9th
International Conference on Information Technology
and Applications, Academic Alliance International.
Sydney, Australia.
N. Jafarov, E. Lewis, G. Millar (2012b). Bringing

Viability to Service-Oriented Enterprises in Cloud
Ecosystems, (ISBN: 978-1-61208-237-0), The 6th
International Conference on Advanced Engineering
211
Computing and Applications in Sciences (ADVCOMP

2012), International Academy, Research and Industry
Association. Barcelona, Spain.
! Journal Papers
N. Jafarov, E. Lewis (2014c). Mapping the Cybernetic

Principles of Viable System Model to Enterprise
Service Bus (Extended), (ISSN (Print): 2204-0595,
ISSN (Online): 2203-1731), IT in Industry, vol. 2, no.
3. Melbourne, Australia.
! Symposiums, Seminars and Reprints
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.
N. Jafarov, E. Lewis, G. Millar (2012c). Bringing

Viability to Service-Oriented Enterprises in Cloud
Ecosystems, (ISBN: 978-1-61208-237-0), University
of New Orleans, ThinkMind and TechRepublic (CBS
Interactive). University of New Orleans Fund. New
Orleans, United States.
N. Jafarov (2012a). Service Oriented Architecture for

the Civil-Military Air Traffic Management Systems
Integration, DiscoverIT Symposium, Australian
Computer Society. Canberra, Australia.
Thorough examination of the VESBM by the professional

communities, in industry and academia, suggests that the VESBM is a
212
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.
The core contribution is the novel VESBM artefact, which is an

cybernetic concepts embedded into the VSM. Other unique contributions
are:
! The design principles derived from the cybernetic concepts

embedded into the VSM. These principles are developed to
be generic for any system that aims to survive and remain
viable.
! Applying the SOA principles of service design towards

identifying the design of technology-independent support
level services of the ESB.
! The use of the DSR in the development of the generic design

principles for the ESB.
These contributions can possibly provide the basis for the future
research in the field.
7.5 Limitations
213
During this research, a number of limitations were discovered in the

VESBM.
As was mentioned, 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 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. Although, this will require automation mechanisms that will
most probably rely on the Artificial Intelligence, designing such software
systems is feasible. Further research in this field is required to
compensate for this limitation.
Another noticeable limitation of this research is in the number of

practical cases in which the VESBM was used. As was mentioned in
Chapter 4, the IS being an applied discipline aims to create artefacts that
can solve problems and guide professionals in doing their work in the real
world settings (Peffers et al., 2007). Because the artefact supposed to be
used in the real world settings, there are situation that are not under the
complete control of the researcher. As a result, during the two practical
cases and the survey, this research experienced multiple delays, which
affected the number of trials that could possibly be carried out. To
compensate for this limitation, further evaluations, in more practical cases,
might need to be considered.
7.6 Future Research Prospects and Directions

In the course of this work, I identified several new prospects and
directions, which could potentially be suitable for the future research in the
field.
In addressing the purposeful role of individuals in the system, I

started working on the adaptation of the VESBM design principles in the
214
Scrum Agile Software Development Framework. The Scrum is one of the

most prominent frameworks for the management of people in the
continuous delivery of software products. Using the VESBM design
principles, I was able to align the team roles in the Scrum according to the
cybernetic concepts embedded into the VSM. The aim of that study, which
is beyond the current research, was to identify the balance between agility
and viability in the rapid development, delivery and deployment of software
products.
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.
During this research, I also started working on the application of the

Actor Model in defining the semantics for the interaction between the
support level services of the ESB. The Actor Model is a mathematical
model of concurrent computation, which treats actors as the universal
primitives of concurrent computation. Because of the recursive nature of
the VESBM, which is based on the VSM, the semantics of the Actor Model
215
could possibly be used in the VESBM design principles to provide

automation for the interaction between the embedded ESB services, the
service containers and ESBs as such. This study is also beyond this
research.
Because of the limited time of a PhD program, the focus of the

research needs to be narrowed and address only one heretofore-unsolved
problem. However, as this section demonstrates, during this research,
other important areas, that could potentially be suitable for the future
research in the field, were identified. As these areas require more
investigations, I will keep working on their applications and publish the
research findings in the future.
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
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
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
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
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
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/,
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,
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,
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
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,
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/,
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
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.
237
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
247

Jafarov 2016 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Jafarov 2016 PDF

Uploaded by

Copyright:

Available Formats

VIABLE ENTERPRISE

SERVICE BUS MODEL

Master of Business Administration

Bachelor of Applied Mathematics and Economic Cybernetics

A thesis submitted in partial fulfilment of the requirements for

Enterprise Service Bus (ESB) is a compound pattern of Service

This research uses the Design Science Research (DSR)

Cybernetics, Enterprise Service Bus, Service Oriented Architecture,

During this research I was blessed to work with amazing people,

I would like to express my sincere gratitude to Dr. Edward Lewis, for

I am thankful to the staff of all companies involved in this research

Special gratitude also goes to my colleagues and friends, whom I

Technology is an essential part of my life that defined me as an

As I grew, it was clear for me to keep pursuing my further education

Taking a business degree benefited me tremendously. MBA

Along with the possible effects on the integration strategies, the

I started my PhD with complex integration projects of Air Traffic

Whilst investigating the field of Cybernetics, thankfully to my

This thesis uses the Design Science Research (DSR) methodology

! Chapter 1 stresses the need for action and provides an

! Chapter 2 studies the SOA and the ESB in an in-depth

! Chapter 3 thoroughly analyses the VSM and builds a

! Chapter 4 outlines various research methods in Information

! Chapter 5 proceeds with the design process step, defined in

! Chapter 6 proceeds with the evaluation process step,

! Chapter 7 concludes this research by summarising the work

In the course of this research, some parts of this work were

N. Jafarov, E. Lewis (2015a). Reinterpreting the Principles of SOA

N. Jafarov, E. Lewis (2014a). Mapping the Cybernetic Principles of

N. Jafarov, E. Lewis, G. Millar (2012b). Bringing Viability to

N. Jafarov, E. Lewis (2014c). Mapping the Cybernetic Principles of

Symposiums, Seminars and Reprints

N. Jafarov, E. Lewis, G. Millar (2012c). Bringing Viability to

N. Jafarov (2012a). Service Oriented Architecture for the Civil-

Figure 1-1: The Effect of Disruptive Innovation 2

Figure 1-2: Cloud Service Models Association with Service Layers 5

Figure 1-3: Service-oriented Approach to the Use of Shared 8

Figure 1-4: Service Interaction Scenario in Service Oriented 11

Figure 1-5: ESB as a Layer between Integrated Applications 12

Figure 1-6: Use of Capabilities of Individual ESBs as Shared 19

Figure 2-1: Decomposition of Business Problem and Software 30

Figure 2-2: Typical Service Oriented Architecture Implementation 31

Figure 2-3: Typical Enterprise Service Bus Integration Scenario 33

Figure 2-4: Typical Message Oriented Middleware Architecture 35

Figure 2-5: Enterprise Service Bus can form a Pervasive Grid 45

Figure 2-6: Enterprise Service Bus can Integrate a Variety of 46

Figure 2-7: Process Flow and Process Orchestration can Span 48

Figure 2-8: Enterprise Service Bus is an Autonomous and 50

Figure 2-9: Enterprise Service Bus Configuration Blueprint can be 51

Figure 2-10: Value-added Services can enable Operational 53

Figure 2-11: Enterprise Service Bus can enable Continuous 54

Figure 2-12: Enterprise Representation Layers 64

Figure 3-1: Viable System Model 74

Figure 4-1: Research Methods in Information Systems 105

Figure 4-2: Available Forms of Science 106

Figure 4-3: Process Model of Design Science Research 114

Figure 4-4: Information Systems Research Framework 115

Figure 4-5: Cycles of the Design Science Research 116

Figure 4-7: Design Science Research Roadmap 121

Figure 5-1: Attenuators and Amplifiers of Management and 137

Figure 5-2: Vertical and Horizontal Scalability of System TWO 153

Figure 5-3: System ONE, TWO, THREE and THREE* 159

Figure 5-4: Homeostatic Relationship of System THREE and 163