You are on page 1of 279

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
This Page is Left Blank Intentionally

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
This Page is Left Blank Intentionally

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
This Page is Left Blank Intentionally

xvi
Any sufficiently advanced technology is
indistinguishable from magic.
Sir Arthur Charles Clarke

xvii
This Page is Left Blank Intentionally

xviii
Preface

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
This Page is Left Blank Intentionally

xxv
Table of Contents

Originality Statement.........................................................................................v
Copyright Statement ....................................................................................... vii
Authenticity Statement ..................................................................................... ix
Abstract ............................................................................................................ xi
Keywords ........................................................................................................ xii
Acknowledgements ........................................................................................ xiv
Preface........................................................................................................... xix
Thesis Outline ......................................................................................xxii
Publications ......................................................................................... xxiii
Table of Contents......................................................................................... xxvi
List of Figures .............................................................................................. xxxi
List of Tables.............................................................................................. xxxiv
List of Acronyms ........................................................................................ xxxvi
Chapter 1. Introduction The Need for Action ................................................ 1
1.1 Introduction..................................................................................... 1
1.2 Disruptive Innovation and Cloud Computing .................................. 1
1.3 Service Oriented Architecture ...................................................... 10
1.4 Enterprise Service Bus ................................................................. 11
1.5 Challenges of Implementation ...................................................... 13
1.6 Research Motivation and Research Question .............................. 20
1.7 Conclusion.................................................................................... 22
Chapter 2. Literature Review Service Oriented Architecture and
Enterprise Service Bus .................................................................................. 25
2.1 Introduction................................................................................... 25
2.2 Review of the Existing Literature .................................................. 26
2.2.1 What is SOA? ........................................................................ 29
2.2.2 What is ESB?......................................................................... 32
2.3 SOA Principles of Service Design ................................................ 36
2.3.1 Standardised Service Contract .............................................. 37
2.3.2 Service Loose Coupling ......................................................... 37
2.3.3 Service Abstraction ................................................................ 38
2.3.4 Service Reusability ................................................................ 38
2.3.5 Service Autonomy.................................................................. 39
2.3.6 Service Statelessness ........................................................... 39
2.3.7 Service Discoverability........................................................... 40
2.3.8 Service Composability ........................................................... 40
2.3.9 Service Orientation and Interoperability................................. 40

xxvi
2.4 Characteristics Influencing ESB Design ....................................... 43
2.4.1 Pervasiveness ....................................................................... 44
2.4.2 Standardised Integration........................................................ 45
2.4.3 Distributed Integration and Selective Deployment ................. 46
2.4.4 Distributed Data Transformation ............................................ 46
2.4.5 Extensibility through Layered Services .................................. 47
2.4.6 Event-driven SOA .................................................................. 47
2.4.7 Process Flow ......................................................................... 48
2.4.8 Security and Reliability .......................................................... 49
2.4.9 Autonomous and Federated Environment ............................. 49
2.4.10 Remote Configuration and Management ............................. 50
2.4.11 Native Data Type ................................................................. 52
2.4.12 Real-time Throughput of Business Data .............................. 52
2.4.13 Operational Awareness ....................................................... 52
2.4.14 Incremental Adoption ........................................................... 53
2.5 Research and Applications........................................................... 54
2.6 Research Objective ...................................................................... 62
2.7 Conclusion.................................................................................... 66
Chapter 3. Theoretical Foundation Cybernetics and Viable System
Model ............................................................................................................. 69
3.1 Introduction................................................................................... 69
3.2 Cybernetics .................................................................................. 69
3.2.1 Requisite Variety.................................................................... 70
3.3 Viable System Model.................................................................... 71
3.3.1 Viability .................................................................................. 75
3.3.2 Recursion............................................................................... 76
3.3.3 Black Box ............................................................................... 78
3.4 Systems of the VSM ..................................................................... 79
3.4.1 System ONE Operations .................................................... 79
3.4.2 System TWO Coordination ................................................. 83
3.4.3 System THREE Management............................................. 86
3.4.4 System FOUR Intelligence ................................................. 89
3.4.5 System FIVE Policy ............................................................ 94
3.5 Adaption of the VSM .................................................................... 98
3.6 Critiques of the VSM .................................................................. 102
3.7 Conclusion.................................................................................. 102
Chapter 4. Methodology Design Science Research ................................. 105
4.1 Introduction................................................................................. 105
4.2 Research in Information Systems .............................................. 105
4.3 Design Science Research .......................................................... 108
4.4 DSR Approaches........................................................................ 112
4.4.1 Common Steps .................................................................... 114
4.4.2 Rigour and Relevance ......................................................... 116
4.4.3 Theory in the DSR ............................................................... 119
4.4.4 Knowledge Generation ........................................................ 120

xxvii
4.5 Summary of the DSR ................................................................. 121
4.6 Use of the DSR in this Research................................................ 123
4.7 Conclusion.................................................................................. 125
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus
Model ........................................................................................................... 127
5.1 Introduction................................................................................. 127
5.2 Viable Enterprise Service Bus Model ......................................... 127
5.3 Structure for the Design Principles ............................................. 132
5.4 VESBM Design Principles .......................................................... 135
5.4.1 Management of Complexity, Homeostasis and Requisite
Variety.............................................................................................. 137
5.4.1.1 Principle 1: Variety ........................................................ 140
5.4.2 Viability ................................................................................ 140
5.4.2.1 Principle 2: Viability ....................................................... 141
5.4.3 Value Creation ..................................................................... 141
5.4.3.1 Principle 3: Value Creation............................................ 141
5.4.4 Value Preservation .............................................................. 142
5.4.4.1 Principle 4: Value Preservation ..................................... 142
5.4.5 Black Box ............................................................................. 142
5.4.5.1 Principle 5: Black Box ................................................... 143
5.4.6 Communication Channels, Channel Capacity and
Transduction .................................................................................... 144
5.4.6.1 Principle 6: Channels .................................................... 147
5.4.7 Operations, Recursion, Invariance, Cohesion and Meta-
system ............................................................................................. 147
5.4.7.1 Principle 7: Service Recursion ...................................... 149
5.4.8 Autonomy and Self-reference .............................................. 150
5.4.8.1 Principle 8: Service Autonomy ...................................... 152
5.4.9 Coordination and Anti-oscillation ......................................... 152
5.4.9.1 Principle 9: Service Deviation ....................................... 155
5.4.10 Resource Bargain, Accountability, Regulation Centre,
Comparator, Feedback and Convergence....................................... 155
5.4.10.1 Principle 10: Service Bargain ...................................... 158
5.4.11 Management ...................................................................... 158
5.4.11.1 Principle 11: Service Performance .............................. 160
5.4.12 Audit................................................................................... 161
5.4.12.1 Principle 12: Service Audit .......................................... 162
5.4.13 Intelligence and Self-awareness ........................................ 162
5.4.13.1 Principle 13: Service Intelligence ................................ 165
5.4.14 Policy and Ethos ................................................................ 165
5.4.14.1 Principle 14: Service Policy ......................................... 166
5.4.15 Algedonic Signals .............................................................. 167
5.4.15.1 Principle 15: Service Alert ........................................... 167
5.5 VESBM Summary ...................................................................... 168
5.6 Conclusion.................................................................................. 171

xxviii
Chapter 6. Evaluating the Artefact VESBM Validation.............................. 174
6.1 Introduction................................................................................. 174
6.2 The Use of the VESBM .............................................................. 174
6.3 Practical Cases .......................................................................... 180
6.3.1 TeliaSonera ......................................................................... 180
6.3.2 Global Service Provider ....................................................... 185
6.4 Survey ........................................................................................ 188
6.4.1 Feedback Data .................................................................... 189
6.4.2 Feedback Analysis............................................................... 196
6.5 Conclusion.................................................................................. 202
Chapter 7. Conclusion ................................................................................. 204
7.1 Introduction................................................................................. 204
7.2 Summary .................................................................................... 204
7.3 Answering the Research Question and Achieving the Research
Objective ............................................................................................. 208
7.4 Contributions .............................................................................. 213
7.5 Limitations .................................................................................. 213
7.6 Future Research Prospects and Directions................................ 214
7.7 Conclusion.................................................................................. 216
Bibliography ................................................................................................. 218
Appendix A Survey Approval by the High Research Ethics Advisory
Panel of the UNSW Canberra ...................................................................... 239
Appendix B Survey Form .......................................................................... 241

xxix
This Page is Left Blank Intentionally

xxx
List of Figures
Title Page

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.

Table 6-6: Survey Clause #5: Please grade the following VESBM 191
design principles from 1 (bad) to 10 (good), according to your own
vision on the usability of these principles for the design of the ESB.

Table 6-7: Survey Clause #6: Please grade the following VESBM 192
design principles from 1 (bad) to 10 (good), according to your own
vision on the appropriate naming of each design principle.

Table 6-8: Survey Clause #7: Please grade the following VESBM 193
design principles from 1 (bad) to 10 (good), according to your own
vision on the appropriate meaning of each design principle.

Table 6-9: Survey Clause #8: To what extent, grading from 1 (least 194
extent) to 10 (most extent), do you think the VESBM can ensure
that the ESB, designed upon it, will retain its design (that is,
survive)?

Table 6-10: Survey Clause #9: To what extent, grading from 1 194
(least extent) to 10 (most extent), do you think the VESBM
provides the design for the ESB, which will retain its design (that
is, survive) independently from the technologies that may underpin
the ESB?

Table 6-11: Survey Clause #10: How strong, grading from 1 (least 195
strong) to 10 (very strong), do you think the VESBM design
principles can be reused in the development of policies,
procedures and guidelines for the governance, management,
maintenance and implementation of IT, at the whole enterprise
level?

xxxv
List of Acronyms
Abbreviation Title
AJAX Asynchronous JavaScript and XML
aPaaS Application Platform as a Service
API Application Programming Interfaces
BPEL4WS Business Process Execution Language for Web Services
BPM Business Process Management
COTS Commercial-off-the-shelf
CORBA Common Object Request Broker Architecture
CRM Customer Relationship Management
DSR Design Science Research
EAI Enterprise Application Integration
EA Enterprise Architectures
ERP Enterprise Resource Planning
ESB Enterprise Service Bus
EaaS/XaaS Everything as a Service
XML eXtensible Markup Language
GSP Global Service Provider
HREA High Research Ethics Advisory
IS Information Systems
IaaS Infrastructure as a Service
iPaaS Integration Platform as a Service
IoT Internet of Things
JCA/J2CA J2EE Connector Architecture
JBI Java Business Integration
JMX Java Management Extensions
JMS Java Message Service
JSR Java Specification Request
JSON JavaScript Object Notation
LDAP Lightweight Directory Access Protocol
MOM Message Oriented Middleware
NIST National Institute of Standards and Technology
PaaS Platform as a Service
RPC Remote Procedure Calls
REST REpresentational State Transfer
ROI Return on Investment
SCA Service Component Architecture
SOA Service Oriented Architecture
SCORM Sharable Content Object Reference Model
SOAP Simple Object Access Protocol
SaaS Software as a Service
SME Subject Matter Expert

xxxvi
TOGAF The Open Group Architecture Framework
UDDI Universal Description, Discovery and Integration
USB Universal Serial Bus
VESBM Viable Enterprise Service Bus Model
VGM Viable Governance Model
VSM Viable System Model
VEP Virtual Education Platform
VPN Virtual Private Network
WoT Web of Things
WSBPEL Web Services Business Process Execution Language
WSDL Web Services Description Language
WCF Windows Communication Foundation

xxxvii
This Page is Left Blank Intentionally

xxxviii
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

! 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
Chapter 1. Introduction The Need for Action!

(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
Chapter 1. Introduction The Need for Action!

reveals that the impact of API on the global IT market is already visible
(Gat and Succi, 2013) with 77% of the current top 50 freeware and top 50
shareware applications connected to backend services, and 23%
remaining standalone. APIs are also launched as the core delivery
strategy in most organisations and out of 1000 APIs in global directory,
11% are oriented on mobile platforms, 38% are oriented on non-mobile
platforms, and the remaining 51% are shared between them (Gat and
Succi, 2013). By 2016 the number of public APIs will raise from the current
8,826 to 30,000 and 86.5% of organisations will have an API program in
place within 5 years (Layer7, 2013).

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
Chapter 1. Introduction The Need for Action!

paradigms, terms and approaches on the horizon in the coming years and
all these developments represent the impact of disruptive innovation on IT.

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

economic recession (Manes, 2009). Some of the key reasons that led to
such a claim were (Linthicum, 2009b):

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

ESBs for the IoT (Negash et al., 2015), which indicate the ongoing
evolution of the ESB. Most importantly, the ESB is also positioned as a
tool that can converge SOA and API, whilst being agnostic to the
technology platform that is, support different integration methods
(Moore, 2013). For example, the Fiorano Cloud Platform, which utilises the
Fiorano ESB, lets companies integrate SaaS, PaaS and on-premises
resources to gain centralised control over them all, and supports the Web
Services, XML Services, REST, JSON as well as various other
technologies to meet different integration needs (Fiorano, 2013).

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

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
Chapter 1. Introduction The Need for Action!

During the last years the ESB was being steadily accepted more as
a technology concept and there is an increasing awareness that it is not a
product, but an architecture style or a pattern (Chappell, 2004; Erl, 2008;
Kress et al., 2013), which was also supported by the evidence that:

! 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
Chapter 1. Introduction The Need for Action!

(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
Chapter 1. Introduction The Need for Action!

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
This Page is Left Blank Intentionally

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

Information Economy
32 (Edwards, 2011) Service Component Architecture
33 (Issarny et al., 2011) Service-oriented Middleware for the Future Internet:
State of the Art and Research Directions
34 (Haddad, 2012) Deploy ESB as a Service
35 (Gartner, 2012) Gartner IT Glossary Integration Platform as a
Service
36 (MuleSoft, 2012) What is iPaaS? Gartner Provides a Reference Model
37 (Earls, 2012) Old SOA versus new SOA? Open APIs Change the
Game
38 (Microsoft, 2012) What is Windows Communication Foundation?
39 (Kress et al., 2013) Enterprise Service Bus
40 (Moore, 2013) ESB Persists As Application Integration Tool
41 (Benosman et al., 2013) Design and Implementation of a Massively Parallel
ESB
42 (Nalini and Sanjay, 2013) Study on Web service Implementation in Eclipse
using Apache CXF on JBoss Platform Towards
Service Oriented Architecture Principles
43 (Shezi et al., 2013) Analysis of Open Source Enterprise Service Buses
toward Supporting Integration in Dynamic Service
Oriented Environments
44 (Chandrasekhar, 2013) Software AG Announces Launch of Integration Live
iPaaS Solution
45 (MuleSoft, 2013) Open Source ESB The Best Choice for SOA
46 (Boleng and Sward, 2013) Service Oriented Architecture Concepts and
Implementations
47 (Thompson, 2013) Who is Who among Providers of Enterprise Service
Bus Open-source Software
48 (Pan et al., 2014) Pervasive Service Bus: Smart SOA Infrastructure for
Ambient Intelligence
49 (Utomo and Wellem, 2014) The Implementation of Enterprise Service Bus in
Graduation Business Process Integration
50 (Roche, 2014) Integrating Service Orientated Architecture Design
Principles into Software as a Service Applications
51 (IBM, 2014) SOA Design Principles and the Internet of Things
52 (Orlowski et al., 2014) Enterprise Service Bus Architecture for the Big Data
Systems
53 (Negash et al., 2015) LISA: Lightweight Internet of Things Service Bus
Architecture
54 (Yin et al., 2015) JTangCSB: A Cloud Service Bus for Cloud and
Enterprise Application Integration
55 (Popa and Vaida, 2015) Enterprise Bus as a Service An Ideal Cloud
Connectivity Model

These publications, which are used and cited throughout this thesis,
indicate the importance of the ESB for SOA and Cloud Computing.
However, despite a decade-long research in the domain of ESB, the
number of publications that address its design is low. This suggests that
this area is still in its infancy and needs investigation. However, prior to

28
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

(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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

about as basic as stating that services must exist (Erl, 2007, p.74).
Examples of how each of the eight principles contributes and supports the
interoperability are given below (Erl, 2007, p.74):

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

Figure 2-5: Enterprise Service Bus can form a Pervasive Grid across Global
Enterprise Network (Chappell, 2004)

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

Service, API and SOAP technologies, and can integrate components that
are created using the C/C++, C#, .NET and so forth.

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

ESB, as applications often do not share the same data format. The
purpose of transformation services is to transform messages sent from a
source into a format that could be readable and understood at a
destination. More complex scenarios may often include protocol
transformations and involve various types of translators, content enrichers,
normalisers and similar services that interact with databases and other
resources to enhance messages with additional information required for
the transformation.

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

! 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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

! 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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

Protocol
Java Message
Y Y Y Y(P)
Service
File Transfer Protocol Y Y Y Y
Email Y Y Y Y
Java Database
Y(R) N Y Y(P)
Connectivity
REpresentational
N N Y Y(P)
State Transfer
Transmission Control
N N Y Y
Protocol
User Datagram
N N Y Y
Protocol
Virtual File System N Y Y N
Extensible
Messaging and N Y Y N
Presence Protocol
Rich Site Summary N Y N Y
Enterprise
Y Y Y N
JavaBeans
Java Connector
Y Y N N
Architecture
Simple Object
Y Y Y Y
Access Protocol
Web Services
Y Y Y Y(P)
Security
Service Component
N C N N
Architecture
Java Business
N Y C N
Integration
Windows
Communication N N N Y
Foundation
Business Process
N Y Y Y
Execution Language
Legend: Y Included; N Not Included; C Container Available; (R) Read
Access Only; (S) Separately Available; (P) Partial Support

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

! 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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
survival of the designed ESB, despite of the changes in technologies that
may underpin it. It was suggested to investigate the domain of
Cybernetics, and the prominent VSM in particular, to identify its suitability
for developing the generic design principles for the ESB, which would
ensure its survival.

To achieve the objective of this research, the next chapter starts the
investigation of the domain of Cybernetics, and the prominent Stafford

66
Chapter 2. Literature Review Service Oriented Architecture and Enterprise Service Bus!

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
This Page is Left Blank Intentionally

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

(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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

information and so on), what goes out of it and what are the relations
between the inputs and the outputs (Christopher, 2007).

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
(Christopher, 2007).

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
(Christopher, 2007).

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

with the ability to visualise alternative futures and invent them (Beer,
1979, p.243). To project the identity of the organisation onto its
environment, the intelligence function may use such activities, as public
relations and market research (Espejo and Gill, 1997).

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

Using these three functions, System FOUR can do the job that is
crucial for the continued organisations success on the market, in the
future. System FOUR scans the environment, does the research and
development, including planning and innovation, to assure that the
changes, required for the creation of the desired future state of the
organisation, can be achieved. These functions of the System FOUR
remain the same, regardless of the level of recursion inside the
organisation (Christopher, 2007).

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

(Beer, 1985). System FIVE defines the rules that determine the criteria of
relevance for the patterns that need to be recognised by System FOUR
and filtered from less relevant ones in the unknown space of continuously
changing future. It also attenuates the variety of System THREE, as it is
aware of what the existing business the organisation is in. In other words,
the corporate ethos, in some sense, has the awareness of what kind of
business the organisation might fall in as well as what kind of patterns
need more attention, thus putting constraints on both System THREE and
System FOUR (Beer, 1979). However, flexibility, rather than rigidity, shall
always prevail in all these undertakings, as steering corporate course in
the unknown, future and always changing environment is virtually
impossible. Hence, System FIVE is a mechanism that intervenes the
balancing activity of the System THREE and System FOUR homeostasis.
Thus, the organisational effectiveness is dependent on how System
THREE and System FOUR functions are interconnected and organised,
so that the issues that arise are initially checked in between them before
reaching the System FIVE (Beer, 1979).

It must be noted that System FIVE does not have sufficient variety
to absorb the combined variety of System THREE and System FOUR,
and, by design, the policy-making must be a low variety process (Espejo
and Harnden, 1989, p.84). Thus, to handle variety System THREE and
System FOUR functions must provide a complementary perspective on
the definition, implementation and adjustment of the organisational identity
and therefore must be given enough weight in the policy-making process
(Beer, 1985). In other words, both System THREE and System FOUR can
act as effective attenuators of complexity that can bring it to the range of
response capacity of System FIVE (Espejo and Reyes, 2011). This
attenuation can help in creating effective interaction between the groups,
in each as well as between the functions, which can reach decisions
through cross-functional debates and sharing perspectives on relevant

95
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

issues (Beer, 1985). For this, System THREE and System FOUR must
also provide information about their current states in a language that is
understandable by System FIVE (Beer, 1979). Although, this might
simplify the role of System FIVE to the mere monitoring of System THREE
and System FOUR interaction, System FIVE is still expected to possess
sufficient requisite variety to regulate the System THREE and System
FOUR loop (Millar, 2009). A failure to do so would lead policy makers in
the invidious position of deciding issues that are beyond their competence
(Espejo and Reyes, 2011, p.106) and result in very costly and sometimes
irreversible decisions that could undermine the accountability for
organisational policies (Christopher, 2007). A system design that
considers these interactions, interconnections and organisation of
functions, will lead to more effective policy-making (Beer, 1979).

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

(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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

then the elements of the organisation that provide these services should
be modelled as embedded operational units.

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

strategy team; the Change the Business is the kind of work typically
done by a Project Management Office or individual project-managers; and
the Run the Business is literally, run-time coordination (Graves, 2014).

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

ensure that the actual ESB designed upon them will survive despite of the
possible disruptive technologies, such as new integration methods or
paradigms, which may arise in the future.

3.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
Chapter 3. Theoretical Foundation Cybernetics and Viable System Model

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
This Page is Left Blank Intentionally

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
Chapter 4. Methodology Design Science Research

(Fischer and Gregor, 2011; Gregor, 2007; Hevner et al., 2004; Peffers et
al., 2007). As a result, the problems it aims to solve are at the intersection
of technology, people and organisations (Davis and Olson, 1984; Hevner
et al., 2004; Lee, 1999).

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

Design Science and the routine design is summarised in the table (Table
4-1) below (Alturki et al., 2012).

Table 4-1: Comparison between the Design Science and the Routine Design
(Alturki et al., 2012)

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

Peffers et al. (Peffers et al., 2007) state that the DSR, although
being structured sequentially, can still be started at almost any desirable
step, as required by the nature and venue of the research. The sequence
given above describes a problem-centred approach, but similar objective-
centred, development-centred and client-centred approaches can be
chosen to create novel solutions for problems in both industrial and
academic settings.

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

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
Chapter 4. Methodology Design Science Research

4.7 Conclusion
This chapter outlined various research methods in IS discipline. It
was concluded that the DSR is a suitable methodology for conducting this
research, because of its profound characteristics. Amongst the various
comprehensive DSR approaches, the approach by Hevner et al. was
chosen to define the set of steps for conducting this research. According
to the defined steps, the next chapter proceeds with the development of
the actual artefact.

125
This Page is Left Blank Intentionally

126
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

amalgamates the SOA, the ESB and the VSM, it is necessary to clarify the
definition of a model.

A model is 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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

Throughout this chapter, the support level services of the ESB and
the embedded ESB services refer to the same category of services, and
are used interchangeably. To further proceed with the VESBM design
principles, it is necessary to adhere to the common standards and
practices for defining principles, so that they could be developed in a
consistent manner.

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

organisation, there are two types of the design principles that are
developed in the course of this research:

1. The VSM design principles that are directly derived from the
cybernetic concepts embedded into the VSM. Each principle
is presented in the form of a proposition and they are all
generic for any system, including organisations. Therefore, if
the system aims to remain viable, and thus survive, it must
comply with these principles.

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

Reduction below the threshold will not allow the system respond
appropriately and exhibit as expected. On the other hand, low variety is
associated with amplification it needs to be increased to a number of
possible states, so that the system can handle it. Similarly to attenuation,
amplification shall not imply to the generation of variety above the required
level, although as in case of attenuation, a system has a capability to do
so. However, generation of redundant variety usually leads to the creation
of states a system might not ever need to enter to preserve its viability. As
a result, generation of variety above the threshold will require additional
regulation and control, which in turn might jeopardise overall effectiveness
and efficiency of the system. It is therefore necessary to keep a balance
between what needs to be reduced and what needs to be increased, so
that the system could operate responsively and handle the variety it can
accommodate (Figure 5-1). This is the main reasoning behind the
Requisite Variety.

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

only variety can absorb (that is, destroy) variety (Ashby, 1956). The Law of
Requisite Variety influences:

! 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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

noted that not the variety is getting transmitted, but data with little
redundancy itself, which holds instructions for either attenuation or
amplification of variety, assuming that the instructions formulated by data
are appropriate to the relevant variety selection. To interpret whether data
transmitted is appropriate, it needs to be transduced.

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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 can help organisations in building federated environments with
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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

shall initially transduce it. Therefore, systems take actions based on the
interpretation of the given purpose that eventually leads to the change of
their own initial states to the resultant ones, as the purpose of a system is
what it does (Beer, 1985, p.99). However, given that the purpose can
morph there is an obvious possibility for the disequilibrium. This issue can
be resolved by engaging a mechanism, in the form of a comparator, which
analyses the states of the system.

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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.
ESB can help organisations in building federated environments with
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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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.
ESB provides operational awareness through an infrastructure that
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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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.
ESB provides the means for the monitoring, logging, audit,
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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

Beta loop as well, with only one remark that the external environment it is
concerned of is of unknown future (Beer, 1985).

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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 provides operational awareness through an infrastructure that
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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

only the essential information about the support level services.


ESB provides the means for the monitoring, logging, audit,
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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

Awareness
Incremental
14 X X X X
Adoption

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

SOA

Value Creation

Service Policy
Service Audit
Performance
Principles of

Service Alert
Preservation

Intelligence
Recursion

Autonomy
Black Box

Channels

Deviation
Viability

Bargain
Service

Service

Service

Service

Service

Service

Service
Variety

Value
Design /
VESBM
Design
Principles
Standardised
1 Service X X X X X
Contract
Service Loose
2 X X X X
Coupling
Service
3 X X X
Abstraction
Service
4 X X X
Reusability
Service
5 X X X X
Autonomy
Service
6 X X X
Statelessness
Service
7 X X X
Discoverability
Service
8 X X X X
Composability
Service
9 Orientation and X X X X X X X X
Interoperability

Given that the scope of the VSM is wider than that of the VESBM,
there are acknowledged limitations in the VESBM design principles, which
underplay the purposeful role of individuals in the system. The reason for
this is based on the assumption that, ESBs can ultimately be designed as
autonomous units, which can make decisions without human intervention.
This limitation is discussed in the last chapter.

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
Chapter 5. Designing the Artefact The Viable Enterprise Service Bus Model

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
This Page is Left Blank Intentionally

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

focus of the projects was on the service integration platforms, such as the
ESB, for both the on-premises and Cloud use.

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

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

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

These facts led to the growing need to address the design of the
ESB from a generic perspective. This perspective had to investigate what
set of essential functions, in the form of generic design principles, rather
than a particular technology, must be defined in the ESB. It was noted
that, these generic design principles could possibly be combined in a
model that would replicate the ESB, so that it could be useful and usable
for designing various service integration platforms and ensure that the
actual ESB designed upon it would survive despite of the possible
disruptive technologies, such as new integration methods or paradigms,
which may arise in the future. It was highlighted that, these generic design
principles, that form the model, must be agnostic to the technology,
product and vendor.

As was noted, given that the ESB can be an integral part of the
SOA, the survival of the ESB at the bottom can become essential for the
survival of the SOA at the top. Survival at each of these levels, can
recursively scale and partially contribute to the survival of the whole
enterprise, ultimately becoming necessary for organisations whose
business purpose is to provide IT services as well as for organisations
whose IT departments are operating as independent units.

This formulated the motivation for conducting this research and led
to the research question being asked:

Can the design of an ESB be improved so that it enables systems


to be integrated without depending upon particular technology or vendor
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
Chapter 6. Evaluating the Artefact VESBM Validation

transformation, protocol transformation, message encryption and so on.


Based on the assertions in Chapter 1, the objective of this research was
defined as:

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.

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
technologies that may underpin the ESB.

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

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

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

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

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

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

for designing not only the VEP, but also possibly other similar service
integration platforms. The most convincing demonstration of the regard for
the use of the VESBM design principles was the invitation to continue the
collaboration with the company to assist them in future projects.

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

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

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

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

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

and the summary of this feedback is provided in the tables (Table 6-3-
Table 6-11) and the figure (Figure 6-2) below.

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

12 3
14 2
15 2
17 1
18 1

Table 6-5: Survey Clause #4: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the
usefulness of these principles for the design of the ESB.

191
Chapter 6. Evaluating the Artefact VESBM Validation

Table 6-6: Survey Clause #5: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the usability
of these principles for the design of the ESB.

192
Chapter 6. Evaluating the Artefact VESBM Validation

Table 6-7: Survey Clause #6: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the
appropriate naming of each design principle.

193
Chapter 6. Evaluating the Artefact VESBM Validation

Table 6-8: Survey Clause #7: Please grade the following VESBM design
principles from 1 (bad) to 10 (good), according to your own vision on the
appropriate meaning of each design principle.

194
Chapter 6. Evaluating the Artefact VESBM Validation

Table 6-9: Survey Clause #8: To what extent, grading from 1 (least extent) to
10 (most extent), do you think the VESBM can ensure that the ESB, designed upon
it, will retain its design (that is, survive)?

Table 6-10: Survey Clause #9: To what extent, grading from 1 (least extent)
to 10 (most extent), do you think the VESBM provides the design for the ESB,
which will retain its design (that is, survive) independently from the technologies
that may underpin the ESB?

195
Chapter 6. Evaluating the Artefact VESBM Validation

Table 6-11: Survey Clause #10: How strong, grading from 1 (least strong) to
10 (very strong), do you think the VESBM design principles can be reused in the
development of policies, procedures and guidelines for the governance,
management, maintenance and implementation of IT, at the whole enterprise level?

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

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

VESBM to be useful. Adhering to the DSR, this


question directly justifies the usefulness of the
VESBM.

! Survey Clause #5: Please grade the following VESBM


design principles from 1 (bad) to 10 (good), according to your
own vision on the usability of these principles for the design
of the ESB.

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.

! Survey Clause #6: Please grade the following VESBM


design principles from 1 (bad) to 10 (good), according to your
own vision on the appropriate naming of each design
principle.

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.

! Survey Clause #7: Please grade the following VESBM


design principles from 1 (bad) to 10 (good), according to your
own vision on the appropriate meaning of each design
principle.

198
Chapter 6. Evaluating the Artefact VESBM Validation

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.

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

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

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

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

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
This Page is Left Blank Intentionally

203
Chapter 7. Conclusion

Chapter 7. Conclusion
As we know, there are known knowns; there are things we know we
know. We also know there are known unknowns; that is to say, we
know there are some things we do not know. But there are also
unknown unknowns the ones we do not know we do not know.
Donald Henry Rumsfelds adaptation of the Domains of
Ignorance by Ann Kerwin

7.1 Introduction
This chapter concludes our journey in this research by summarising
the work that has been done in this thesis. The chapter investigates
whether the research question was answered and whether the research
objective was achieved. This chapter also outlines the outcomes of this
research, the contributions made, the limitations discovered, as well as
provides an insight on the future research prospects and directions in the
field, and concludes the thesis.

7.2 Summary
This research started with stressing the need for action in the
domains of SOA and ESB, in Chapter 1, which formulated the motivation
for conducting this research and defined the research question. It was
highlighted that both SOA and ESB, despite their emergence more than a
decade ago, remain essential for the implementation of service-oriented
systems, but face a range of challenges, associated with the various
misconceptions, that can amplify their failure, especially in the era of
Cloud. These misconceptions resulted in the development of dozens of
distinct ESBs that support the notion of SOA differently. It was also shown
that, Cloud Computing led to the evolution of the ESB, from an on-
premises middleware technology, which is essentially behind the ERP,
CRM, Supply Chain, Retail Management and other similar platforms that

204
Chapter 7. Conclusion

integrate services for various purposes, to iPaaS that can converge SOA,
API and possibly other emerging paradigms. All these facts led to the
increasing awareness that the design of the ESB needed to be addressed
from a generic perspective that is, agnostic to the technology, product
and vendor. It was suggested to position the ESB as a technology concept
to investigate what set of essential functions, in the form of generic design
principles, rather than a particular technology, must be defined in the ESB.
It was also proposed to combine these design principles in a model that
would replicate the ESB, so that it can be useful and usable for designing
various service integration platforms and ensure that the actual ESB
designed upon it would survive despite of the possible disruptive
technologies that may arise in the future. After formulating the motivation
for conducting the research and defining the research question, the
research proceeded with an in-depth literature review of the SOA and the
ESB.

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
survival of the designed ESB, despite of the changes in technologies that
may underpin it. It was suggested to investigate the domain of
Cybernetics, and the prominent VSM in particular, to identify its suitability
for developing the generic design principles for the ESB, which would
ensure its survival. 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
Chapter 7. Conclusion

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

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

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:

Can the design of an ESB be improved so that it enables systems


to be integrated without depending upon particular technology or vendor
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:

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.

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
technologies that may underpin the ESB.

208
Chapter 7. Conclusion

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

! 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:

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

! Survey Clause #5: Please grade the following VESBM


design principles from 1 (bad) to 10 (good), according to your
own vision on the usability of these principles for the design
of the ESB.

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

! 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

210
Chapter 7. Conclusion

(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
Chapter 7. Conclusion

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

model that can ensure the ESB survival, independent from the
technologies that may underpin it, which indicates that the research
question being asked is answered and the research objective being
pursued is achieved.

7.4 Contributions
During this research, multiple contributions were made to the
knowledge base.

The core contribution is the novel VESBM artefact, which 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. 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
Chapter 7. Conclusion

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

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

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
This Page is Left Blank Intentionally

217
Bibliography
Abolfazli, S., Sanaei, Z., Sanaei, M.H., Shojafar, M., Gani, A., 2015.
Mobile Cloud Computing: The-state-of-the-art, Challenges, and
Future Research.
Abrams, C., Schulte, R.W., 2008. Service Oriented Architecture Overview
and Guide to SOA Research. Gart. Res.
Adner, R., 2002. When are Technologies Disruptive? A Demand-based
View of the Emergence of Competition. Strateg. Manag. J. 23, 667
688.
Agarwal, S., 2013. API vs. SOA? Are they Different?,
https://blog.akana.com/api-vs-soa-different/, Accessed: July 15,
2015. AKANA.
Alturki, A., Bandara, W., Gable, G.G., 2012. Design Science Research
and the Core of Information Systems, in: Design Science Research
in Information Systems. Advances in Theory and Practice. Springer,
pp. 309327.
Alturki, A., Gable, G.G., Bandara, W., 2011. A Design Science Research
Roadmap, in: Service Oriented Perspectives in Design Science
Research. Springer, pp. 107123.
Alwadain, A., Fielt, E., Korthaus, A., Rosemann, M., 2013. Service-
oriented Architecture Integration within Enterprise Architecture: A-
priori Model, in: 24th Australasian Conference on Information
Systems (ACIS). RMIT University, pp. 111.
Amazon, 2006. Amazon EC2, http://aws.amazon.com/ec2/, Accessed:
July 15, 2015. Amazon.
Andrikopoulos, V., Strauch, S., Leymann, F., 2013. Decision Support for
Application Migration to the Cloud. Proc. CLOSER13 149155.
Andriole, S.J., 2012. Seven Indisputable Technology Trends that Will
Define 2015. Commun. Assoc. Inf. Syst. 30, 4.
APIGEE, 2012. Extending Your SOA in the API Economy,
https://pages.apigee.com/extend-soa-ebook.html, Accessed: July
15, 2015. APIGEE.
Armbrust, M., Fox, A., Griffith, R., Joseph, A.D., Katz, R., Konwinski, A.,
Lee, G., Patterson, D., Rabkin, A., Stoica, I., others, 2010. A View
of Cloud Computing. Commun. ACM 53, 5058.
Arsanjani, A., 2004. Service Oriented Modeling and Architecture. IBM Dev.
Works 115.
Arsanjani, A., Ghosh, S., Allam, A., Abdollah, T., Ganapathy, S., Holley,
K., 2008. SOMA: A Method for Developing Service Oriented
Solutions. IBM Syst. J. 47, 377396.
Ashby, W.R., 1956. An Introduction to Cybernetics. Chapman and Hall
London.
Atzori, L., Iera, A., Morabito, G., 2010. The Internet of Things: A Survey.
Comput. Netw. 54, 27872805.

218
Bai, X., Xie, J., Chen, B., Xiao, S., 2007. DRESR: Dynamic Routing in
Enterprise Service Bus, in: E-Business Engineering, 2007. ICEBE
2007. IEEE International Conference on. IEEE, pp. 528531.
Banerjee, P., Bash, C., Friedrich, R., Goldsack, P., Huberman, B.A.,
Manley, J., Patel, C., Ranganathan, P., Veitch, A., 2011. Everything
as a Service: Powering the New Information Economy. Computer
44, 3643.
Bannerman, P., 2010. Cloud Computing Adoption Risks: State of Play.
Governance 3, 20.
Barcia, R., Brown, K.G., Peterson, R.R., Reinitz, R.M., 2014. Aspect-
oriented Application of a Mediator in an Enterprise Service Bus of a
Service-oriented Architected Data Processing System. Google
Patents.
Baroudi, C., Halper, F., 2006. Executive Survey: SOA Implementation
Satisfaction. Hurwitz Assoc.
Barrios, J., Nurcan, S., 2004. Model Driven Architectures for Enterprise
Information Systems. Sprigner, Lecture Notes in Computer Science
3084, 319.
Barry, R., 2010. ESBs in the Cloud: Tricky in the Early Going,
http://searchsoa.techtarget.com/news/1514427/ESBs-in-the-cloud-
Tricky-in-the-early-going, Accessed: July 15, 2015. TechTarget.
Beckford, J., 2002. Quality. Psychology Press.
Beer, S., 2002. What is Cybernetics? Presented at the Kybernetes,
Emerald, pp. 209219.
Beer, S., 1985. Diagnosing the System for Organizations. Chichester:
John Wiley & Sons.
Beer, S., 1981. Brain of the Firm (2nd ed.). Chichester: John Wiley &
Sons.
Beer, S., 1979. The Heart of Enterprise: Companion volume to Brain of the
Firm. Chichester: John Wiley & Sons.
Beer, S., 1972. Brain of the Firm: The Managerial Cybernetics of
Organizations. London: Allen Lane and Penguin Press.
Benatallah, B., Nezhad, H.R.M., 2008. Service Oriented Architecture:
Overview and Directions, in: Advances in Software Engineering.
Springer, pp. 116130.
Benbasat, I., Zmud, R.W., 2003. The Identity Crisis within the IS
Discipline: Defining and Communicating the Disciplines Core
Properties. MIS Q. 183194.
Benbasat, I., Zmud, R.W., 1999. Empirical Research in Information
Systems: The Practice of Relevance. MIS Q. 316.
Benosman, R., Barkaoui, K., Albrieux, Y., 2013. Design and
Implementation of a Massively Parallel ESB, in: Programming and
Systems (ISPS), 2013 11th International Symposium on. IEEE, pp.
8995.
Berkem, B., 2008. From the Business Motivation Model to Service
Oriented Architecture. J. Object Technol. 7, 5770.

219
Bertolino, A., De Angelis, G., Polini, A., Sabetta, A., 2011. Trends and
Research Issues in SOA Validation. IGI Glob. Perform.
Dependability Serv. Comput. Concepts Tech. Res. Dir.
Bharadwaj, S.S., Chauhan, S., Raman, A., 2015. Achieving Business
Agility through Service Oriented Architecture in Recovering
Markets, in: Managing in Recovering Markets. Springer, pp. 1526.
Biffl, S., Schatten, A., Zoitl, A., 2009. Integration of Heterogeneous
Engineering Environments for the Automation Systems Lifecycle,
in: Industrial Informatics, 2009. INDIN 2009. 7th IEEE International
Conference on. IEEE, pp. 576581.
Birman, K., Chockler, G., van Renesse, R., 2009. Toward a Cloud
Computing Research Agenda. ACM SIGACT News 40, 6880.
Biswas, A.R., Giaffreda, R., 2014. IoT and cloud Convergence:
Opportunities and Challenges, in: Internet of Things (WF-IoT), 2014
IEEE World Forum on. IEEE, pp. 375376.
Blake, M.B., Wei, Y., 2010. Service Oriented Computing and Cloud
Computing: Challenges and Opportunities. IEEE Internet Comput.
14.
Boleng, J., Sward, R., 2013. Service Oriented Architecture Concepts and
Implementations. ACM, Proceedings of the 2013 ACM SIGAda
Annual Conference on High Integrity Language Technology, pp.
1112.
Borenstein, N., Blake, J., 2011. Cloud Computing Standards: Wheres the
Beef? Internet Comput. IEEE 15, 7478.
Bower, J.L., Christensen, C.M., 1995. Disruptive Technologies: Catching
the Wave. Harvard Business Review.
Brebner, P., 2009. Service Oriented Performance Modeling the Mule
Enterprise Service Bus Loan Broker Application, in: Software
Engineering and Advanced Applications, 2009. SEAA09. 35th
Euromicro Conference on. IEEE, pp. 404411.
Brocke, J. vom, Simons, A., Niehaves, B., Riemer, K., Plattfaut, R.,
Cleven, A., others, 2009. Reconstructing the Giant: On the
Importance of Rigour in Documenting the Literature Search
Process, in: ECIS. pp. 22062217.
Brocklesby, J., Cummings, S., Davies, J., 1995. Demystifying the Viable
Systems - Model as a Tool for Organizational Analysis. Asia-Pac. J.
Oper. Res. 12, 6586.
Brown, P., 2006. Reference Model for Service Oriented Architecture,
http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.doc, Accessed: July
15, 2015.
Buckl, S., Matthes, F., Schweda, C.M., 2009. A Viable System Perspective
on Enterprise Architecture Management, in: Systems, Man and
Cybernetics, 2009. SMC 2009. IEEE International Conference on.
IEEE, pp. 14831488.

220
Buschle, M., Ekstedt, M., Grunow, S., Hauder, M., Matthes, F., Roth, S.,
2012. Automating Enterprise Architecture Documentation using an
Enterprise Service Bus. AMCIS.
Buyya, R., Yeo, C.S., Venugopal, S., 2008. Market-oriented Cloud
Computing: Vision, Hype, and Reality for Delivering IT Services as
Computing Utilities, in: High Performance Computing and
Communications, 2008. HPCC08. 10th IEEE International
Conference on. IEEE, pp. 513.
Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I., 2009. Cloud
Computing and Emerging IT Platforms: Vision, Hype, and Reality
for Delivering Computing as the 5th Utility. Future Gener. Comput.
Syst. 25, 599616.
Bygstad, B., Gronli, T.-M., 2011. Service Oriented Architecture and
Business Innovation, in: System Sciences (HICSS), 2011 44th
Hawaii International Conference on. IEEE, pp. 110.
Cambridge University Press, 2015. Cambridge University Press,
http://dictionary.cambridge.org/dictionary/british/model, Accessed:
July 15, 2015. Cambridge University Press.
Catteddu, D., 2010. Cloud Computing: Benefits, Risks and
Recommendations for Information Security, in: Web Application
Security. Springer, pp. 1717.
Chandrasekhar, D., 2013. Software AG Announces Launch of Integration
Live (iPaaS) Solution,
http://www.softwareag.com/blog/reality_check/index.php/integration
-insights/software-ag-announces-launch-of-integration-live-ipaas-
solution/, Accessed: July 15, 2015. Software AG.
Channabasavaiah, K., Holley, K., Tuggle, E., 2003. Migrating to a Service
Oriented Architecture. IBM Dev. 16.
Chappell, D., 2009. Introducing Windows Communication Foundation in
.NET Framework 4, http://msdn.microsoft.com/en-
us/library/ee958158.aspx, Accessed: July 15, 2015. Microsoft.
Chappell, D., 2004. Enterprise Service Bus: Theory in Practice. OReilly
Media, Inc.
Checkland, P.B., 1980. Are Organisations Machines? Futures 12, 421
424.
Cherbakov, L., Galambos, G., Harishankar, R., Kalyana, S., Rackham, G.,
2005. Impact of Service Orientation at the Business Level. IBM
Syst. J. 44, 653668.
Christensen, C., 2015. Disruptive Innovation: Key Concepts,
http://www.claytonchristensen.com/key-concepts/, Accessed: July
15, 2015.
Christensen, C., 1997. The Innovators Dilemma: When New Technologies
Cause Great Firms to Fail. Harvard Business Review Press.
Christensen, C.M., Overdorf, M., 2000. Meeting the Challenge of
Disruptive Change. Harv. Bus. Rev. 78, 6677.

221
Christopher, W.F., 2007. Holistic Management: Managing what Matters for
Company Success. John Wiley & Sons.
Chun, B.-G., Maniatis, P., 2009. Augmented Smartphone Applications
Through Clone Cloud Execution, in: HotOS. pp. 811.
Chung, J.-Y., Chao, K.-M., 2007. A View on Service Oriented Architecture.
Serv. Oriented Comput. Appl. 1, 9395.
Creeger, M., 2009. CTO Roundtable: Cloud Computing. Commun. ACM
52, 5056.
Crockford, D., 2001. JavaScript Object Notation, http://www.json.org/,
Accessed: July 15, 2015. JSON.
Cucinotta, T., Mancina, A., Anastasi, G.F., Lipari, G., Mangeruca, L.,
Checcozzo, R., Rusin, F., 2009. A Real-time Service Oriented
Architecture for Industrial Automation. Ind. Inform. IEEE Trans. On
5, 267277.
Curbera, F., Duftler, M., Khalaf, R., Nagy, W., Mukhi, N., Weerawarana,
S., 2002. Unraveling the Web Services Web: An Introduction to
SOAP, WSDL, and UDDI. IEEE Internet Comput. 6, 8693.
Curry, E., 2004. Message Oriented Middleware. Middlew. Commun. 128.
Das, D., Kundu, P., 2012. Application of Service Oriented Architecture in
Implementing a CRM Process: A Conceptual Approach. Res. High.
Educ. Comput. Sci. Inf. Technol. 148152.
Davis, G.B., Olson, M.H., 1984. Management Information Systems:
Conceptual Foundations, Structure, and Development. McGraw-
Hill, Inc.
Dawson, B., 2007. The Impact of Technology Insertion on Organisations,
http://www.hfidtc.com/research/process/reports/phase-2/HFIDTC-2-
12-2-1-1-tech-organisation.pdf, Accessed: July 15, 2015.
de Deugd, S., Carroll, R., Kelly, K.E., Millett, B., Ricker, J., 2006. SODA:
Service Oriented Device Architecture. IEEE Pervasive Comput. 5,
9496.
De Leusse, P., Periorellis, P., Watson, P., 2007. Enterprise Service Bus:
An Overview. University of Newcastle upon Tyne, Computing
Science.
Demirkan, H., Harmon, R.R., Goul, M., 2011. A Service-oriented Web
Application Framework. IT Prof. 1521.
Desmet, S., Volckaert, B., Van Assche, S., Van Der Weken, D., Dhoedt,
B., De Turck, F., 2007. Throughput Evaluation of Different
Enterprise Service Bus Approaches, in: Proceedings of SERP2007,
the 2007 International Conference on Software Engineering
Research & Practice (part of the 2007 World Congress in Computer
Science, Computer Engineering, and Applied Computing). pp. 378
384.
Dillon, T., Wu, C., Chang, E., 2010. Cloud Computing: Issues and
Challenges, in: Advanced Information Networking and Applications
(AINA), 2010 24th IEEE International Conference on. Ieee, pp. 27
33.

222
Dodge, G.E., Webb, H.W., Christ, R.E., 1999. Impact of Information
Technology on Battle Command: Lessons From Management
Science and Business. DTIC Document.
Earls, A., 2012. Old SOA versus new SOA? Open APIs Change the
Game, http://searchsoa.techtarget.com/feature/Old-SOA-versus-
new-SOA-Open-APIs-change-the-game, Accessed: July 15, 2015.
TechTarget.
Edwards, M., 2011. Service Component Architecture (SCA), http://oasis-
opencsa.org/sca, Accessed: July 15, 2015. OASIS.
Encyclopaedia Britannica, 2015. Encyclopaedia Britannica,
http://www.britannica.com/EBchecked/topic/682073/operations-
research/68178/Model-construction, Accessed: July 15, 2015.
Encyclopaedia Britannica.
Erl, T., 2008. SOA Design Patterns. Prentice Hall.
Erl, T., 2007. SOA: Principles of Service Design. Prentice Hall.
Erl, T., 2005. Service Oriented Architecture (SOA): Concepts, Technology,
and Design.
Ermagan, V., Krger, I.H., Menarini, M., 2008. Aspect Oriented Modeling
Approach to Define Routing in Enterprise Service Bus
Architectures, in: Proceedings of the 2008 International Workshop
on Models in Software Engineering. ACM, pp. 1520.
Espejo, R., 2011. Epistemological Considerations of VSM Case Studies,
in: Grey Systems and Intelligent Services (GSIS), 2011 IEEE
International Conference on. IEEE, pp. 899901.
Espejo, R., Gill, A., 1997. The Viable System Model as a Framework for
Understanding Organizations. Phrontis Ltd. SYNCHO Ltd.
Espejo, R., Harnden, R., 1989. The Viable System Model: Interpretations
and Applications of Stafford Beers VSM. Wiley Chichester.
Espejo, R., Reyes, A., 2011. Organizational Systems: Managing
Complexity with the Viable System Model. Springer.
Fiondella, L., Gokhale, S.S., Mendiratta, V.B., 2013. Cloud Incident Data:
An Empirical Analysis, in: Cloud Engineering (IC2E), 2013 IEEE
International Conference on. IEEE, pp. 241249.
Fiorano, 2013. Fiorano ESB, http://www.fiorano.com/products/ESB-
enterprise-service-bus/Fiorano-ESB-enterprise-service-bus.php,
Accessed: July 15, 2015.
Fischer, C., Gregor, S., 2011. Forms of Reasoning in the Design Science
Research Process, in: Service Oriented Perspectives in Design
Science Research. Springer, pp. 1731.
Flood, R.L., Carson, E.R., 1993. Dealing with Complexity. Springer.
Flurry, G., 2007. Exploring the Enterprise Service Bus, Part 1: Discover
How an ESB Can Help You Meet the Requirements for Your SOA
Solution. IBM.
Fowler, M., Lewis, J., 2014. Microservices,
http://martinfowler.com/articles/microservices.html, Accessed: July
15, 2015.

223
Fox, A., Griffith, R., Joseph, A., Katz, R., Konwinski, A., Lee, G.,
Patterson, D., Rabkin, A., Stoica, I., 2009. Above the Clouds: A
Berkeley View of Cloud Computing. Dept Electr. Eng Comput Sci.
Univ. Calif. Berkeley Rep UCBEECS 28, 13.
Frigg, R., Hartmann, S., 2009. Models in Science. Stanf. Encycl. Philos.
Galliers, R.D., Land, F.F., 1987. Viewpoint: Choosing Appropriate
Information Systems Research Methodologies. Commun. ACM 30,
901902.
Garces-Erice, L., 2009. Building an Enterprise Service Bus for Real-time
SOA: A Messaging Middleware Stack, in: Computer Software and
Applications Conference, 2009. COMPSAC09. 33rd Annual IEEE
International. IEEE, pp. 7984.
Garrison, G., Kim, S., Wakefield, R.L., 2012. Success Factors for
Deploying Cloud Computing. Commun. ACM 55, 6268.
Gartner, 2012. Gartner IT Glossary - Integration Platform as a Service
(iPaaS), http://www.gartner.com/it-glossary/information-platform-as-
a-service-ipaas/, Accessed: July 15, 2015. Gartner Research.
Gartner, 2011. Gartner Reference Model for Integration PaaS,
https://www.gartner.com/doc/1729256/gartner-reference-model-
integration-paas, Accessed: July 15, 2015. Gartner Research.
Gat, I., Succi, G., 2013. A Survey of the API Economy. Cut. Consort.
Geric, S., 2010. The Potential of Service Oriented Architectures, in:
Information Technology Interfaces (ITI), 2010 32nd International
Conference on. IEEE, pp. 471476.
Girbea, A., Suciu, C., Nechifor, S., Sisak, F., 2014. Design and
Implementation of a Service Oriented Architecture for the
Optimization of Industrial Applications. Ind. Inform. IEEE Trans. On
10, 185196.
Goel, A., 2006. Enterprise Integration EAI vs. SOA vs. ESB. Infosys
Technol. White Pap. 87.
Goldkuhl, G., Lind, M., 2010. A Multi-grounded Design Research Process,
in: Global Perspectives on Design Science Research. Springer, pp.
4560.
Golnam, A., Regev, G., Wegmann, A., 2011. On Viable Service Systems:
Developing a Modeling Framework for Analysis of Viability in
Service Systems, in: Exploring Services Science. Springer, pp. 30
41.
Google, 2006. Google Apps,
http://www.google.com/intx/en_au/enterprise/apps/business/,
Accessed: July 15, 2015. Google.
Gottschalk, K., Graham, S., Kreger, H., Snell, J., 2002. Introduction to
Web Services Architecture. IBM Syst. J. 41, 170177.
Graves, T., 2014. Services and Enterprise Canvas Review 3B:
Coordination, http://weblog.tetradian.com/2014/10/18/services-and-
ecanvas-review-3b-coordination/, Accessed: July 15, 2015.

224
Graves, T., 2009. The Service Oriented Enterprise: Enterprise Architecture
and Viable Services. Tetradian Books.
Gray, P., 2014. SOA vs. APIs to Deliver IT Services: Is There a Difference,
and Does it Matter?, http://www.techrepublic.com/article/soa-vs-
apis-to-deliver-it-services-is-there-a-difference-and-does-it-matter/,
Accessed: July 15, 2015. TechRepublic.
Gregor, S., 2009. Building Theory in the Sciences of the Artificial, in:
Proceedings of the 4th International Conference on Design Science
Research in Information Systems and Technology. ACM, p. 4.
Gregor, S., 2007. Design Theory in Information Systems. Australas. J. Inf.
Syst. 10.
Gregor, S., 2006. The Nature of Theory in Information Systems. Mis Q.
611642.
Gregor, S., 2002. A Theory of Theories in Information Systems. Inf. Syst.
Found. Build. Theor. Base 120.
Gregor, S., Hevner, A.R., 2013. Positioning and Presenting Design
Science Research for Maximum Impact. MIS Q. 37, 337356.
Gronbaek, I., 2008. Architecture for the Internet of Things (IoT): API and
Interconnect, in: Sensor Technologies and Applications, 2008.
SENSORCOMM08. Second International Conference on. IEEE,
pp. 802807.
Guangyao, P., Xinju, L., Keda, L., 2014. An Applied Research in MULE on
Public Service Platform of Regional Modern Logistics Information.
J. Wuzhou Univ. 3, 003.
Guinard, D., Trifa, V., Karnouskos, S., Spiess, P., Savio, D., 2010.
Interacting with the SOA-based Internet of Things: Discovery,
Query, Selection, and On-demand Provisioning of Web Services.
Serv. Comput. IEEE Trans. On 3, 223235.
Guinard, D., Trifa, V., Mattern, F., Wilde, E., 2011. From the Internet of
Things to the Web of Things: Resource-oriented Architecture and
Best Practices, in: Architecting the Internet of Things. Springer, pp.
97129.
Hacking, I., 1983. Representing and Intervening: Introductory Topics in the
Philosophy of Natural Science. Cambridge Univ Press.
Haddad, C., 2012. Deploy ESB as a Service,
http://blog.cobia.net/cobiacomm/2012/07/05/deploy-esb-as-a-
service/, Accessed: July 15, 2015.
Harcuba, O., Vrba, P., 2015. Unified REST API for Supporting the
Semantic Integration in the ESB-based Architecture, in: Industrial
Technology (ICIT), 2015 IEEE International Conference on. IEEE,
pp. 30003005.
Haslett, T., Sarah, R., 2006. Using the Viable Systems Model to Structure
a System Dynamics Mapping and Modeling Project for the
Australian Taxation Office. Syst. Pract. Action Res. 19, 273290.
Hrault, C., Thomas, G., Lalanda, P., 2005. Mediation and Enterprise
Service Bus: A Position Paper, in: Proceedings of the First

225
International Workshop on Mediation in Semantic Web Services
(MEDIATE 2005). pp. 6780.
Herring, C., Kaplan, S., 2001. The Viable System Architecture, in: System
Sciences, 2001. Proceedings of the 34th Annual Hawaii
International Conference on. IEEE, p. 10pp.
Hevner, A., Chatterjee, S., 2010. Design Science Research in Information
Systems. Springer.
Hevner, A., March, S.T., Park, J., Ram, S., 2004. Design Science in
Information Systems Research. MIS Q. 28, 75105.
Hevner, A.R., 2007. A Three Cycle View of Design Science Research.
Scand. J. Inf. Syst. 19, 4.
He, W., Da Xu, L., 2014. Integration of Distributed Enterprise Applications:
A Survey. Ind. Inform. IEEE Trans. On 10, 3542.
Higgins, J.P., Green, S., others, 2008. Cochrane Handbook for Systematic
Reviews of Interventions. Wiley Online Library.
Hilder, T., 1995. The Viable System Model. Retrieved June 28, 2005.
Hou, H., 2010. Application and Research of Service Oriented Architecture
in Constructing the Urban Geographic Information Public Service
Platform. Shanghai Geol. 2, 2629.
Hoverstadt, P., 2011. The Fractal Organization: Creating Sustainable
Organizations with the Viable System Model. John Wiley & Sons.
Huhns, M.N., Singh, M.P., 2005. Service Oriented Computing: Key
Concepts and Principles. Internet Comput. IEEE 9, 7581.
IBM, 2014. SOA Design Principles and the Internet of Things, in: IBM.
Presented at the IBM SOA Architect Summit.
IBM, 2007. Service Component Architecture Overview,
https://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/index.jsp
?topic=/com.ibm.iea.wpi_v6/wpswid/6.0.2/SCA.html, Accessed:
July 15, 2015. IBM Press.
Iivari, J., Hirschheim, R., Klein, H.K., 1998. A Paradigmatic Analysis
Contrasting Information Systems Development Approaches and
Methodologies. Inf. Syst. Res. 9, 164193.
Inaganti, S., Aravamudan, S., 2007. SOA Maturity Model. BP Trends April
2007, 123.
Irani, Z., Themistocleous, M., Love, P.E., 2003. The Impact of Enterprise
Application Integration on Information System Lifecycles. Inf.
Manage. 41, 177187.
Issarny, V., Caporuscio, M., Georgantas, N., 2007. A Perspective on the
Future of Middleware-based Software Engineering, in: 2007 Future
of Software Engineering. IEEE Computer Society, pp. 244258.
Issarny, V., Georgantas, N., Hachem, S., Zarras, A., Vassiliadist, P., Autili,
M., Gerosa, M.A., Hamida, A.B., 2011. Service-oriented Middleware
for the Future Internet: State of the Art and Research Directions. J.
Internet Serv. Appl. 2, 2345.
Jackson, M.C., 2003. Systems Thinking: Creative Holism for Managers.

226
Jadeja, Y., Modi, K., 2012. Cloud Computing - Concepts, Architecture and
Challenges, in: Computing, Electronics and Electrical Technologies
(ICCEET), 2012 International Conference on. IEEE, pp. 877880.
James, A., Chung, J.-Y., 2015. Business and Industry Specific Cloud:
Challenges and Opportunities. Future Gener. Comput. Syst. 48,
3945.
Ji-chen, J., Ming, G., 2006. Enterprise Service Bus and an Open Source
Implementation, in: Management Science and Engineering, 2006.
ICMSE06. 2006 International Conference on. IEEE, pp. 926930.
Jones, D., Gregor, S., 2007. The Anatomy of a Design Theory. J. Assoc.
Inf. Syst. 8, 1.
Jung, M., Weidinger, J., Kastner, W., Olivieri, A., 2013. Building
Automation and Smart Cities: An Integration Approach based on a
Service Oriented Architecture, in: Advanced Information Networking
and Applications Workshops (WAINA), 2013 27th International
Conference on. IEEE, pp. 13611367.
Kaplan, R.S., Norton, D.P., 2006. Alignment: Using the Balanced
Scorecard to Create Corporate Synergies. Harvard Business Press.
Keen, M., Acharya, A., Bishop, S., Hopkins, A., Milinski, S., Nott, C.,
Robinson, R., Adams, J., Verschueren, P., 2004. Patterns:
Implementing an SOA using an Enterprise Service Bus. IBM,
International Technical Support Organization.
Keen, M., Adinolfi, O., Hemmings, S., Humphreys, A., Kanthi, H.,
Nottingham, A., 2005. Patterns: SOA with an Enterprise Service
Bus. IBM Redb.
Khajeh-Hosseini, A., Sommerville, I., Sriram, I., 2010. Research
Challenges for Enterprise Cloud Computing. ArXiv Prepr.
ArXiv10013257.
Klein, H.K., 2003. Crisis in the IS Field? A Critical Reflection on the State
of the Discipline. J. Assoc. Inf. Syst. 4, 10.
Knippel, R., 2005. Service Oriented Enterprise Architecture. IT Univ. Cph.
Komoda, N., 2006. Service Oriented Architecture in Industrial Systems, in:
Industrial Informatics, 2006 IEEE International Conference on.
IEEE, pp. 15.
Kress, J., Maier, B., Normann, H., Schmeidel, D., Schmutz, G., Trops, B.,
Utschig, T.W., 2013. Enterprise Service Bus. Oracle.
Krueger, I.H., Meisinger, M., Menarini, M., Pasco, S., 2006. Rapid
Systems of Systems Integration - Combining an Architecture-centric
Approach with Enterprise Service Bus Infrastructure, in: Information
Reuse and Integration, 2006 IEEE International Conference on.
IEEE, pp. 5156.
Kuechler, B., Vaishnavi, V., 2008. On Theory Development in Design
Science Research: Anatomy of a Research Project. Eur. J. Inf.
Syst. 17, 489504.

227
Kuechler, W., Vaishnavi, V., 2012. A Framework for Theory Development
in Design Science Research: Multiple Perspectives. J. Assoc. Inf.
Syst. 13, 395423.
Kyusakov, R., Eliasson, J., Delsing, J., Van Deventer, J., Gustafsson, J.,
2013. Integration of Wireless Sensor and Actuator Nodes with IT
Infrastructure using Service Oriented Architecture. Ind. Inform.
IEEE Trans. On 9, 4351.
Lankhorst, M.M., 2004. Enterprise Architecture Modelling - The Issue of
Integration. Adv. Eng. Inform. 18, 205216.
Layer7, 2013. API Security and Management Today,
www.layer7tech.com/infographic, Accessed: July 15, 2015. Layer7.
Lee, A., 1999. Inaugural Editors Comments. Mis Q. 23, 1.
Leonard, A., Beer, S., 1994. The Systems Perspective: Methods and
Models for the Future. ACUNU Proj.
Lewis, E., 2013. Layrib: Planning Viable Systems, http://www.layrib.com/,
Accessed: July 15, 2015.
Lewis, E., Millar, G., 2010. The Viable Governance Model: A Theoretical
Model for the Corporate Governance of IT. Int. J. ITBusiness
Alignment Gov. IJITBAG 1, 1935.
Lewis, G.A., Morris, E., Simanta, S., Wrage, L., 2007. Common
Misconceptions about Service Oriented Architecture, in:
Commercial-off-the-Shelf (COTS)-Based Software Systems, 2007.
ICCBSS07. Sixth International IEEE Conference on. IEEE, pp.
123130.
Lewis, G.A., Smith, D.B., Kontogiannis, K., 2010. A Research Agenda for
Service Oriented Architecture: Maintenance and Evolution of
Service Oriented Systems.
Linthicum, D.S., 2013. SOA dead? Not if youre using PaaS for App Dev.
InfoWorld.
Linthicum, D.S., 2009a. Cloud Computing and SOA Convergence in Your
Enterprise: A Step-by-step Guide. Pearson Education.
Linthicum, D.S., 2009b. Burton Group: SOA is Dead; Long Live Services.
CIO.
Linthicum, D.S., 2008. Are ESBs Evil?,
http://www.ebizq.net/topics/soa_management/features/10093.html,
Accessed: July 15, 2015.
Linthicum, D.S., 2006. Why ESB will be Dead in a Year,
http://www.ebizq.net/blogs/linthicum/2006/03/why_esb_will_be.php,
Accessed: July 15, 2015.
Linthicum, D.S., 2000. Enterprise Application Integration. Addison-Wesley
Professional.
Liu, X.-M., Liu, Q., Xu, F., 2009. Research of Enterprise Application
Integration Model based on SOA. Comput. Eng. Des. 30, 3790
3793.
Liu, Y., Gorton, I., Zhu, L., 2007. Performance Prediction of Service
Oriented Applications based on an Enterprise Service Bus, in:

228
Computer Software and Applications Conference, 2007.
COMPSAC 2007. 31st Annual International. IEEE, pp. 327334.
Li, Z., Yang, B., 2013. Application of Enterprise Service Bus (ESB)
Technology in Large Enterprises. Inf. Technol. 2, 044.
Lojka, T., Miskuf, M., Zolotova, I., 2014. Service Oriented Architecture for
Remote Machine Control in ICS, in: Applied Machine Intelligence
and Informatics (SAMI), 2014 IEEE 12th International Symposium
on. IEEE, pp. 327330.
Lundblad, M., 2015. Information Logistics Service Router - an ESB for
Integrating Enterprise Services.
Luo, M., Goldshlager, B., Zhang, L.-J., 2005. Designing and Implementing
Enterprise Service Bus (ESB) and SOA Solutions, in: Services
Computing, 2005 IEEE International Conference on. IEEE, p. xiv
vol.
Manes, A.T., 2009. SOA is Dead; Long Live Services. Burton Group.
Manes, A.T., 2007. Enterprise Service Bus: A Definition. Burton Group 1
35.
March, S.T., Smith, G.F., 1995. Design and Natural Science Research on
Information Technology. Decis. Support Syst. 15, 251266.
Marchaux, J.-L., 2006. Combining Service Oriented Architecture and
Event-driven Architecture using an Enterprise Service Bus. IBM
Dev. Works 12691275.
Markus, M.L., Majchrzak, A., Gasser, L., 2002. A Design Theory for
Systems that Support Emergent Knowledge Processes. Mis Q.
179212.
Mateescu, G., Gentzsch, W., Ribbens, C.J., 2011. Hybrid Computing -
Where HPC Meets Grid and Cloud Computing. Future Gener.
Comput. Syst. 27, 440453.
McKay, J., Marshall, P.H., 2005. A Review of Design Science in
Information Systems, in: ACIS. p. EJ.
Mei, L., Chan, W.K., Tse, T.H., 2008. A Tale of Clouds: Paradigm
Comparisons and Some Thoughts on Research Issues, in: Asia-
Pacific Services Computing Conference, 2008. APSCC08. IEEE.
Ieee, pp. 464469.
Menge, F., 2007. Enterprise Service Bus, in: Free and Open Source
Software Conference. pp. 16.
Merriam-Webster, 2015. Merriam-Webster, http://www.merriam-
webster.com/dictionary/model, Accessed: July 15, 2015. Merriam-
Webster.
Microsoft, 2012. What is Windows Communication Foundation (WCF)?,
http://msdn.microsoft.com/en-
us/library/ms731082%28v=vs.110%29.aspx, Accessed: July 15,
2015. Microsoft.
Microsoft, 2010. Windows Azure, https://www.windowsazure.com/en-us/,
Accessed: July 15, 2015. Microsoft.

229
Microsoft, 2003. What is RPC?, http://technet.microsoft.com/en-
us/library/cc787851%28v=ws.10%29.aspx, Accessed: July 15,
2015. Microsoft.
Millar, G., 2009. The Viable Governance Model: A Theoretical Model of IT
Governance within a Corporate Setting. DIT Published Doctoral
Dissertation, University of New South Wales, Canberra.
Miller, K.W., Voas, J., 2010. Ethics and the Cloud. IT Prof. 12, 45.
Mingers, J., Rosenhead, J., 2001. An Overview of Related Methods: VSM,
System Dynamics and Decision Analysis.
Moore, J., 2013. ESB Persists As Application Integration Tool. CIO.
Moreno-Vozmediano, R., Montero, R.S., Llorente, I.M., 2013. Key
Challenges in Cloud Computing: Enabling the Future Internet of
Services. Internet Comput. IEEE 17, 1825.
Mueller, B., Viering, G., Legner, C., Riempp, G., 2010. Understanding the
Economic Potential of Service Oriented Architecture. J. Manag. Inf.
Syst. 26, 145180.
MuleSoft, 2014. MuleSoft Named a Leader in the Gartner Magic
Quadrant for Enterprise Integration Platform as a Service (iPaaS),
http://www.mulesoft.com/gartner-leaders-ipaas, Accessed: July 15,
2015. MuleSoft.
MuleSoft, 2013a. Open Source ESB - The Best Choice for SOA,
https://www.mulesoft.com/resources/esb/open-source-esb-best-
choice-soa, Accessed: July 15, 2015.
MuleSoft, 2013b. CloudHub iPaaS Cloud-based Integration,
https://www.mulesoft.com/platform/saas/cloudhub-ipaas-cloud-
based-integration, Accessed: July 15, 2015. MuleSoft.
MuleSoft, 2012. What is iPaaS? Gartner Provides a Reference Model,
https://www.mulesoft.com/resources/cloudhub/what-is-ipaas-
gartner- provides-reference-model, Accessed: July 15, 2015.
MuleSoft.
Nalini, T., Sanjay, M., 2013. Study on Web service Implementation in
Eclipse using Apache CXF on JBoss Platform Towards Service
Oriented Architecture Principles. Int. J. Comput. Technol. Appl. 4,
115.
Namjoshi, J., Gupte, A., 2009. Service Oriented Architecture for Cloud-
based Travel Reservation Software as a Service, in: Cloud
Computing, 2009. CLOUD09. IEEE International Conference on.
IEEE, pp. 147150.
Natis, Y., Schulte, W., 2003. Introduction to Service Oriented Architecture,
https://www.gartner.com/doc/391377, Accessed: July 15, 2015.
Gartner Research.
Negash, B., Rahmani, A.-M., Westerlund, T., Liljeberg, P., Tenhunen, H.,
2015. LISA: Lightweight Internet of Things Service Bus
Architecture. Presented at the The 6th International Conference on
Ambient Systems, Networks and Technologies (ANT-2015), the 5th

230
International Conference on Sustainable Energy Information
Technology (SEIT-2015), Elsevier, pp. 436443.
Niglas, K., 2001. Paradigms and Methodology in Educational Research,
in: European Conference on Educational Research on.
NIST, 2011. The NIST Definition of Cloud Computing,
http://www.nist.gov/itl/csd/cloud-102511.cfm, Accessed: July 15,
2015. Natl. Inst. Stand. Technol.
Noran, O., Bernus, P., 2008. Service Oriented Architecture vs. Enterprise
Architecture: Competition or Synergy?, in: On the Move to
Meaningful Internet Systems: OTM 2008 Workshops. Springer, pp.
304312.
OASIS Committee, 2007. Web Services Business Process Execution
Language, https://www.oasis-
open.org/committees/tc_home.php?wg_abbrev=wsbpel, Accessed:
July 15, 2015.
Object Management Group, 2012. Common Object Request Broker
Architecture (CORBA), http://www.omg.org/spec/CORBA/3.3/,
Accessed: July 15, 2015. Object Management Group.
Oduntan, O.O., Park, N., 2012. Enterprise Viability Model: Extending
Enterprise Architecture Frameworks for Modeling and Analyzing
Viability under Turbulence. J. Enterp. Transform. 2, 125.
Okoli, C., Schabram, K., 2010. A Guide to Conducting a Systematic
Literature Review of Information Systems Research. Available
SSRN 1954824.
Oliver, A., 2012. Long Live SOA in the Cloud Era. CIO.
Olliffe, G., 2014. Time to Get Off the Enterprise Service Bus?,
http://www.gartner.com/webinar/2855231, Accessed: July 15, 2015.
Gartner Research.
ONeill, M., 2015. SOA Is (Still) Not Dead (and Shouldnt Be),
https://www.axway.com/en/blog/2015/03/soa-still-not-dead-and-
shouldn%E2%80%99t-be, Accessed: July 15, 2015. Axway.
Oracle, 2009. Oracle SCA The Power of the Composite,
http://www.oracle.com/technetwork/topics/entarch/whatsnew/oracle
-sca-the-power-of-the-composi-134500.pdf, Accessed: July 15,
2015. Oracle.
Oracle, 1995. About the Java Technology,
http://docs.oracle.com/javase/tutorial/getStarted/intro/definition.html
, Accessed: July 15, 2015. Oracle.
Orlikowski, W.J., Iacono, C.S., 2001. Research Commentary: Desperately
Seeking the IT in IT Research - A Call to Theorizing the IT Artifact.
Inf. Syst. Res. 12, 121134.
Orlowski, C., Szczerbicki, E., Grabowski, J., 2014. Enterprise Service Bus
Architecture for the Big Data Systems. Manag. Prod. Eng. Rev. 5,
2831.
Ortiz, S., 2007. Getting on Board the Enterprise Service Bus. Computer
40, 1517.

231
OShaughnessey, S., 2013. ESB Does Not Equal SOA; Learn the Real
Equation, http://www.tibco.com/blog/2013/08/22/esb-does-not-
equal-soa-learn-the-real-equation/, Accessed: July 15, 2015.
TIBCO Software.
Pan, G., Zhang, L., Wu, Z., Li, S., Yang, L., Lin, M., Shi, Y., 2014.
Pervasive Service Bus: Smart SOA Infrastructure for Ambient
Intelligence. Intell. Syst. IEEE 29, 5260.
Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F., 2008. Service
Oriented Computing: A Research Roadmap. Int. J. Coop. Inf. Syst.
17, 223255.
Papazoglou, M.P., Van Den Heuvel, W.-J., 2007. Service Oriented
Architectures: Approaches, Technologies and Research Issues.
VLDB J. 16, 389415.
Patel, P., Ranabahu, A.H., Sheth, A.P., 2009. Service Level Agreement in
Cloud Computing.
Peffers, K., 2008. IS Research using Theory from Elsewhere. J. Inf.
Technol. Theory Appl. JITTA 9, 2.
Peffers, K., Tuunanen, T., Rothenberger, M.A., Chatterjee, S., 2007. A
Design Science Research Methodology for Information Systems
Research. J. Manag. Inf. Syst. 24, 4577.
Peirce, C.S., 1931. The Collected Papers. Cambridge, MA: Harvard
University Press.
Pezzini, M., Lheureux, B.J., 2011. Integration Platform as a Service:
Moving Integration to the Cloud, http://www-
304.ibm.com/industries/publicsector/fileserve?contentid=250736,
Accessed: July 15, 2015. IBM.
Popa, S., Vaida, M.-F., 2015. Enterprise Bus as a Service An Ideal
Cloud Connectivity Model. Acta Tech. Napoc. 56, 29.
Poulin, J., Himler, A., 2006. The ROI of SOA based on Traditional
Component Reuse. LogicLibrary Inc.
Purao, S., 2002. Design Research in the Technology of Information
Systems: Truth or Dare. Online Pa. State Univ. Httppurao Ist Psu
Eduworking-Pap.-Purao Pdf.
Rainbow, P., Sullivan, W., 1979. Interpretive Social Science: A Reader.
Berkeley, CA: University of California Press.
Rane, D., Lomow, G., 2008. SOA Governance: More than Just Registries
and Repositories. BearingPoint.
Rao, B., Angelov, B., Nov, O., 2006. Fusion of Disruptive Technologies::
Lessons from the Skype Case. Eur. Manag. J. 24, 174188.
Red Hat JBoss, 2006. Why ESB and SOA? Red Hat JBoss.
Ren, K., Wang, C., Wang, Q., 2012. Security Challenges for the Public
Cloud. IEEE Internet Comput. 6973.
Riad, A.M., Hassan, A.E., Hassan, Q.F., 2010. Design of SOA-based Grid
Computing with Enterprise Service Bus. AISS 2, 7182.
Richardson, L., Ruby, S., 2007. RESTful Web Services. OReilly Media.

232
Roche, J., 2014. Integrating Service Orientated Architecture Design
Principles into Software as a Service Applications.
Rodriguez, A., 2008. RESTful Web Services: The Basics,
https://www.ibm.com/developerworks/webservices/library/ws-
restful/, Accessed: July 15, 2015.
Roshen, W., 2011. Enterprise Service Bus with USB-like Universal Ports,
in: Web Services (ECOWS), 2011 Ninth IEEE European
Conference on. IEEE, pp. 177183.
Roshen, W., 2009. SOA-based Enterprise Integration: A Step-by-step
Guide to Services-based Application. McGraw-Hill, Inc.
Rubinstein, D., 2012. SOA (the Term) is Dead, but SOA (the Architecture)
Lives On. Software Development Times.
Rubinyi, P., 1998. Unchaining the Chain of Command. Thomson Crisp
Learning.
Ruh, W.A., Maginnis, F.X., Brown, W.J., 2002. Enterprise Application
Integration: A Wiley Tech Brief. John Wiley & Sons.
Sachs, K., Kounev, S., Bacon, J., Buchmann, A., 2009. Performance
Evaluation of Message Oriented Middleware using the
SPECjms2007 Benchmark. Perform. Eval. 66, 410434.
Sanaei, Z., Abolfazli, S., Gani, A., Buyya, R., 2014. Heterogeneity in
Mobile Cloud Computing: Taxonomy and Open Challenges.
Commun. Surv. Tutor. IEEE 16, 369392.
Sanders, D.T., Hamilton Jr, J.A., MacDonald, R.A., 2008. Supporting a
Service Oriented Architecture, in: Proceedings of the 2008 Spring
Simulation Multiconference. Society for Computer Simulation
International, pp. 325334.
Sayer, P., 2013. Software AG Goes All-out for In-memory Data
Processing. CIO.
Schmidt, M.-T., Hutchison, B., Lambros, P., Phippen, R., 2005. The
Enterprise Service Bus: Making Service Oriented Architecture Real.
IBM Syst. J. 44, 781797.
Schulte, W., 2003. The Growing Role of Events in Enterprise Applications,
https://www.gartner.com/doc/399662/growing-role-events-
enterprise-applications, Accessed: July 15, 2015. Gartner
Research.
Schulte, W., Natis, Y., 1996. Service Oriented Architectures, Part 1,
https://www.gartner.com/doc/302868, Accessed: July 15, 2015.
Gartner Research.
Shanks, G., Arnott, D., Rouse, A., 1993. A Review of Approaches to
Research and Scholarship in Information Systems. Department of
Information Systems, Faculty of Computing and Information
Technology, Monash University.
Shezi, T., Jembere, E., Adigun, M.O., Nene, M.T., 2013. Analysis of Open
Source Enterprise Service Buses toward Supporting Integration in
Dynamic Service Oriented Environments, in: E-Infrastructure and E-
Services for Developing Countries. Springer, pp. 115125.

233
Sholler, D., Smith, D., 2005. New SOA Specification will Fill Niche among
Java Users,
http://www.gartner.com/resources/136600/136687/new_soa_specifi
cation_will_f_136687.pdf, Accessed: July 15, 2015. Gartner
Research.
Siegeln, H., 2015. The ESB is dead, long live the ESB,
https://www.integrationmatters.com/integration/blog/detail/the-esb-
is-dead-long-live-the-esb.html, Accessed: July 15, 2015.
Simon, H.A., 1969. The Sciences of the Artificial. MIT press.
Skyttner, L., 2005. General Systems Theory: Problems, Perspectives,
Practice. World scientific.
Sonnenberg, C., Brocke, J. vom, 2012. Evaluations in the Science of the
Artificial Reconsidering the Build-Evaluate Pattern in Design
Science Research, in: Design Science Research in Information
Systems. Advances in Theory and Practice. Springer, pp. 381397.
Sriram, I., Khajeh-Hosseini, A., 2010. Research Agenda in Cloud
Technologies. ArXiv Prepr. ArXiv10013259.
Steen, M.W., Strating, P., Lankhorst, M.M., Doest, H. ter, Iacob, M.-E.,
2005. Service Oriented Enterprise Architecture. Serv. Oriented
Syst. Eng. Hershey 132154.
Succi, G., Remencius, T., 2013. Profiting in the API Economy,
http://www.cutter.com/itjournal/fulltext/advisor/2013/itj131002.html,
Accessed: July 15, 2015. Cut. Consort.
Sward, R.E., Whitacre, K.J., 2008. A Multi-language Service Oriented
Architecture using an Enterprise Service Bus, in: ACM SIGAda Ada
Letters. ACM, pp. 8590.
Swoyer, C., 1991. Structural Representation and Surrogative Reasoning.
Synthese 87, 449508.
Takeda, H., Veerkamp, P., Yoshikawa, H., 1990. Modeling Design
Process. AI Mag. 11, 37.
Tang, L., Dong, J., Peng, T., 2008. A Generic Model of Enterprise Service
Oriented Architecture, in: Service Oriented System Engineering,
2008. SOSE08. IEEE International Symposium on. IEEE, pp. 17.
Trneberg, W., Mehta, A., Tordsson, J., Kihl, M., Elmroth, E., 2015.
Resource Management Challenges for the Infinite Cloud, in: 10th
International Workshop on Feedback Computing at CPSWeek
2015.
Tesch, R., 1990. Qualitative Research: Analysis Types and Software
Tools. Psychology Press.
The Economist, 2012. Agent of change - The Future of Technology
Disruption in Business. The Economist.
The Java Community Process, 2013. JSR 343: Java Message Service
(JMS) Specification,
https://jcp.org/aboutJava/communityprocess/final/jsr343/index.html,
Accessed: July 15, 2015. JCP.

234
The Java Community Process, 2005. JSR 208: Java Business Integration
(JBI) Specification, https://jcp.org/en/jsr/detail?id=208, Accessed:
July 15, 2015. JCP.
The Open Group, 2012. The Open Group Architecture Framework
(TOGAF) Version 9, http://www.opengroup.org/togaf/, Accessed:
July 15, 2015. Open Group 1.
The Open Group, 2009. Service Oriented Architecture: What Is SOA?,
http://www.opengroup.org/soa/source-book/soa/soa.htm, Accessed:
July 15, 2015. The Open Group.
Thompson, J., 2013. Whos Who among Providers of Enterprise Service
Bus Open-source Software,
https://www.gartner.com/doc/2599517/whos- providers-enterprise-
service-bus, Accessed: July 15, 2015. Gartner Research.
Thramboulidis, K., 2015. Service Oriented Architecture in Industrial
Automation Systems - The case of IEC 61499: A Review. ArXiv
Prepr. ArXiv150604615.
TIBCO, 2012. Service Component Architecture,
https://docs.tibco.com/pub/activematrix_businessworks_service_en
gine/5.9.3_march_2012/html/tib_amx_concepts/wwhelp/wwhimpl/c
ommon/html/wwhelp.htm#href=c_BWSE.htm&single=true,
Accessed: July 15, 2015. TIBCO Software.
Tigli, J.-Y., Lavirotte, S., Rey, G., Hourdin, V., Riveill, M., 2011.
Lightweight Service Oriented Architecture for Pervasive Computing.
ArXiv Prepr. ArXiv11025193.
Toosi, A.N., Calheiros, R.N., Buyya, R., 2014. Interconnected Cloud
Computing Environments: Challenges, Taxonomy, and Survey.
ACM Comput. Surv. CSUR 47, 7.
Tranfield, D.R., Denyer, D., Smart, P., 2003. Towards a Methodology for
Developing Evidence-informed Management Knowledge by Means
of Systematic Review. Br. J. Manag. 14, 207222.
Tripathi, A., Mishra, A., 2011. Cloud Computing Security Considerations,
in: Signal Processing, Communications and Computing (ICSPCC),
2011 IEEE International Conference on. IEEE, pp. 15.
Tsai, W.-T., Sun, X., Balasooriya, J., 2010. Service-oriented Cloud
Computing Architecture, in: Information Technology: New
Generations (ITNG), 2010 Seventh International Conference on.
IEEE, pp. 684689.
UDDI Technical Committee, 2004. Universal Description, Discovery and
Integration, http://uddi.org/pubs/uddi-v3.0.2-20041019.htm,
Accessed: July 15, 2015.
Ulrich, W., 1989. Critical Heuristics of Social Systems Design, in:
Operational Research and the Social Sciences. Springer, pp. 79
87.
Ulrich, W., 1981. A Critique of Pure Cybernetic Reason: The Chilean
Experience with Cybernetics. J. Appl. Syst. Anal. 8, 3359.

235
Utomo, W.H., Wellem, T., 2014. The Implementation of Enterprise Service
Bus in Graduation Business Process Integration. J. Theor. Appl. Inf.
Technol. 62.
Vaishnavi, V.K., Kuechler, W., 2007. Design Science Research Methods
and Patterns: Innovating Information and Communication
Technology. CRC Press.
Vaishnavi, V., Kuechler, W., 2004. Design Research in Information
Systems.
Valipour, M.H., AmirZafari, B., Maleki, K.N., Daneshpour, N., 2009. A Brief
Survey of Software Architecture Concepts and Service Oriented
Architecture, in: Computer Science and Information Technology,
2009. ICCSIT 2009. 2nd IEEE International Conference on. IEEE,
pp. 3438.
van Aken, J.E., 2004. Management Research based on the Paradigm of
the Design Sciences: The Quest for Field-tested and Grounded
Technological Rules. J. Manag. Stud. 41, 219246.
Vescoukis, V., Doulamis, N., Karagiorgou, S., 2012. A Service Oriented
Architecture for Decision Support Systems in Environmental Crisis
Management. Future Gener. Comput. Syst. 28, 593604.
Vidgen, R., 1998. Cybernetics and Business Processes: Using the Viable
System Model to Develop an Enterprise Process Architecture.
Knowl. Process Manag. 5, 118131.
Vollmer, K., Gilpin, M., Rose, S., 2006. The Forrester Wave: Enterprise
Service Bus. Forrester Res.
Vouk, M.A., 2008. Cloud computing - Issues, Research and
Implementations. CIT J. Comput. Inf. Technol. 16, 235246.
W3C, 2008. Extensible Markup Language, http://www.w3.org/TR/REC-
xml/, Accessed: July 15, 2015.
W3C, 2007. SOAP Version 1.2 Part 1: Messaging Framework (Second
Edition), http://www.w3.org/TR/soap12-part1/, Accessed: July 15,
2015. W3C.
W3C, 2004. Web Services Architecture, http://www.w3.org/TR/ws-arch/,
Accessed: July 15, 2015.
W3C, 2001. Web Services Description Language,
http://www.w3.org/TR/wsdl, Accessed: July 15, 2015.
Whner, K., 2015. Do Good Microservices Architectures Spell the Death
of the Enterprise Service Bus?,
https://www.voxxed.com/blog/2015/01/good-microservices-
architectures-death-enterprise-service-bus-part-one/, Accessed:
July 15, 2015.
Walls, J.G., Widermeyer, G.R., Sawy, O.A. El, 2004. Assessing
Information System Design Theory in Perspective: How Useful was
Our 1992 Initial Rendition? J. Inf. Technol. Theory Appl. JITTA 6, 6.
Walls, J.G., Widmeyer, G.R., Sawy, O.A. El, 1992. Building an Information
System Design Theory for Vigilant EIS. Inf. Syst. Res. 3, 3659.

236
Walsh, S.T., Kirchhoff, B.A., Newbert, S., 2002. Differentiating Market
Strategies for Disruptive Technologies. Eng. Manag. IEEE Trans.
On 49, 341351.
Weber, R., 1987. Toward a Theory of Artifacts: A Paradigmatic Base for
Information Systems Research. J. Inf. Syst. 1, 319.
Webster, J., Watson, R.T., 2002. Analyzing the Past to Prepare for the
Future: Writing a Literature Review. Manag. Inf. Syst. Q. 26, 3.
Weiner, N., 1948. Cybernetics. New York: Wiley.
Werth, D., Leyking, K., Dreifus, F., Ziemann, J., Martin, A., 2007.
Managing SOA through Business Services A Business Oriented
Approach to Service Oriented Architectures, in: Service Oriented
Computing ICSOC 2006. Springer, pp. 313.
Winter, R., 2008. Design Science Research in Europe. Eur. J. Inf. Syst.
17, 470475.
Wu, B., Liu, S., Wu, L., 2008. Dynamic Reliable Service Routing in
Enterprise Service Bus, in: Asia-Pacific Services Computing
Conference, 2008. APSCC08. IEEE. IEEE, pp. 349354.
Xiao, J., Wu, J., Yang, J.G., 2013. A New Integrated Front Platform of
Financial Self-service Equipment Based on ESB, in: Advanced
Materials Research. Trans Tech Publ, pp. 11801184.
Xing, H., Zhai, W., 2015. Design and Implementation of Service Bus in the
Multi-mission System, in: Proceedings of the 27th Conference of
Spacecraft TT&C Technology in China. Springer, pp. 513522.
Xu, J., Xu, W., 2005. Summarization of Message Oriented Middleware.
Comput. Eng. 16, 029.
Yin, J., Lu, X., Pu, C., Wu, Z., Chen, H., 2015. JTangCSB: A Cloud
Service Bus for Cloud and Enterprise Application Integration. IEEE
Internet Comput. 3543.
Zadeh, M.E., Millar, G., Lewis, E., 2012. Mapping the Enterprise
Architecture Principles in TOGAF to the Cybernetic Concepts An
Exploratory Study, in: System Science (HICSS), 2012 45th Hawaii
International Conference on. IEEE, pp. 42704276.
Zarvi, N., Wieringa, R., 2014. An Integrated Enterprise Architecture
Framework for Business-IT Alignment. Des. Enterp. Archit.
Framew. Integrating Bus. Process. IT Infrastruct.
Zhang, L.-J., Zhang, J., Fiaidhi, J., Chang, J.M., 2010. Hot Topics in Cloud
Computing. IT Prof. 12, 1719.
Zhang, Q., Cheng, L., Boutaba, R., 2010. Cloud Computing: State-of-the-
art and Research Challenges. J. Internet Serv. Appl. 1, 718.
Ziyaeva, G., Choi, E., Min, D., 2008. Content-based Intelligent Routing
and Message Processing in Enterprise Service Bus, in:
Convergence and Hybrid Information Technology, 2008. ICHIT08.
International Conference on. IEEE, pp. 245249.

237
This Page is Left Blank Intentionally

238
Appendix A Survey Approval by the High
Research Ethics Advisory Panel of the UNSW
Canberra

239
240
Appendix B Survey Form

241
242
243
244
245
246
This Page is Left Blank Intentionally

247