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 Erl’s SOA principles of service design and David Chappell’s characteristics that influence the ESB design with the design principles that are derived from the cybernetic concepts embedded into Stafford Beer’s 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 Tuček 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 Innovator’s 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; Tärneberg 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; O’Neill, 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: “it’s 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 (O’Shaughnessey, 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” (O’Neill, 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: Salesforce’s 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 doesn’t 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; Wähner, 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 (O’Shaughnessey, 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 Beer’s 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 service’s 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 (Hérault 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 Microsoft’s proprietary .NET Framework’s 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 (Maréchaux, 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 (O’Shaughnessey, 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!
Beer’s 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 Ashby’s 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).
Ashby’s 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 organisation’s
• 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 organisation’s long-term viability (Beer, 1985).
Ashby’s 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 Ashby’s 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 Ashby’s 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 organisation’s 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 Beer’s 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 Ashby’s 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 organisation’s 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 doesn’t 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 enterprise’s 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 organisation’s 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 organisation’s 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 organisation’s 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 company’s 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 organisation’s 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 organisation’s 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 organisation’s 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-Exupéry
§ 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 artefact’s 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. Ashby’s 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 other’s 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 Ashby’s 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 organisation’s 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 organisation’s 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 Beer’s 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 subsidiary’s regulatory centre, which is the local management’s 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 organisation’s 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 unit’s 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
ESB Design
Characteristics e № / VESBM Value Value Value Policy Variety Service Service Service Service Service Service Service Servic Viability Design Bargain Creation Deviation Channels Black Box Black Recursion Autonomy Intelligence Preservation Service Alert Service
Principles Performance Service Audit Service 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
Principles of
Service № Design / Value Value Variety
VESBM Service Service Service Service Service Service Viability Bargain Deviation Channels Black Box Black Recursion Autonomy Intelligence Preservation
Design Alert Service Performance Service Audit Service Service Policy Service Principles Creation Value 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 (O’Shaughnessey, 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 company’s 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 (O’Shaughnessey, 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 company’s 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 Rumsfeld’s 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 (O’Shaughnessey, 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. 309–327. Alturki, A., Gable, G.G., Bandara, W., 2011. A Design Science Research Roadmap, in: Service Oriented Perspectives in Design Science Research. Springer, pp. 107–123. 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. 1–11. 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. CLOSER’13 149–155. 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, 50–58. Arsanjani, A., 2004. Service Oriented Modeling and Architecture. IBM Dev. Works 1–15. 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, 377–396. 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, 2787–2805.
• 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. 528–531. 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, 36–43. Bannerman, P., 2010. Cloud Computing Adoption Risks: State of Play. Governance 3, 2–0. 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, 3–19. 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. 209–219. 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. 116–130. Benbasat, I., Zmud, R.W., 2003. The Identity Crisis within the IS Discipline: Defining and Communicating the Discipline’s Core Properties. MIS Q. 183–194. Benbasat, I., Zmud, R.W., 1999. Empirical Research in Information Systems: The Practice of Relevance. MIS Q. 3–16. 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. 89–95. Berkem, B., 2008. From the Business Motivation Model to Service Oriented Architecture. J. Object Technol. 7, 57–70.
• 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. 15–26. 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. 576–581. Birman, K., Chockler, G., van Renesse, R., 2009. Toward a Cloud Computing Research Agenda. ACM SIGACT News 40, 68–80. 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. 375–376. 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. 11–12. Borenstein, N., Blake, J., 2011. Cloud Computing Standards: Where’s the Beef? Internet Comput. IEEE 15, 74–78. 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. SEAA’09. 35th Euromicro Conference on. IEEE, pp. 404–411. 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. 2206–2217. Brocklesby, J., Cummings, S., Davies, J., 1995. Demystifying the Viable Systems - Model as a Tool for Organizational Analysis. Asia-Pac. J. Oper. Res. 12, 65–86. 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. 1483–1488.
• 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. HPCC’08. 10th IEEE International Conference on. IEEE, pp. 5–13. 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, 599–616. Bygstad, B., Gronli, T.-M., 2011. Service Oriented Architecture and Business Innovation, in: System Sciences (HICSS), 2011 44th Hawaii International Conference on. IEEE, pp. 1–10. 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. 17–17. 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. O’Reilly 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, 653–668. Christensen, C., 2015. Disruptive Innovation: Key Concepts, http://www.claytonchristensen.com/key-concepts/, Accessed: July 15, 2015. Christensen, C., 1997. The Innovator’s 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, 66–77.
• 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. 8–11. Chung, J.-Y., Chao, K.-M., 2007. A View on Service Oriented Architecture. Serv. Oriented Comput. Appl. 1, 93–95. Creeger, M., 2009. CTO Roundtable: Cloud Computing. Commun. ACM 52, 50–56. 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, 267–277. 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, 86–93. Curry, E., 2004. Message Oriented Middleware. Middlew. Commun. 1–28. 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. 148–152. 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, 94–96. 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. 15–21. 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., Krüger, 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. 15–20. Espejo, R., 2011. Epistemological Considerations of VSM Case Studies, in: Grey Systems and Intelligent Services (GSIS), 2011 IEEE International Conference on. IEEE, pp. 899–901. 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 Beer’s 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. 241–249. 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. 17–31. 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, 901–902. Garces-Erice, L., 2009. Building an Enterprise Service Bus for Real-time SOA: A Messaging Middleware Stack, in: Computer Software and Applications Conference, 2009. COMPSAC’09. 33rd Annual IEEE International. IEEE, pp. 79–84. Garrison, G., Kim, S., Wakefield, R.L., 2012. Success Factors for Deploying Cloud Computing. Commun. ACM 55, 62–68. 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. 471–476. 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, 185–196. 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. 45–60. 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, 170–177. 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. 611–642. Gregor, S., 2002. A Theory of Theories in Information Systems. Inf. Syst. Found. Build. Theor. Base 1–20. Gregor, S., Hevner, A.R., 2013. Positioning and Presenting Design Science Research for Maximum Impact. MIS Q. 37, 337–356. Gronbaek, I., 2008. Architecture for the Internet of Things (IoT): API and Interconnect, in: Sensor Technologies and Applications, 2008. SENSORCOMM’08. Second International Conference on. IEEE, pp. 802–807. 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, 223–235. 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. 97–129. 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. 3000–3005. 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, 273–290. Hérault, 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. 67–80. Herring, C., Kaplan, S., 2001. The Viable System Architecture, in: System Sciences, 2001. Proceedings of the 34th Annual Hawaii International Conference on. IEEE, p. 10–pp. 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, 75–105. 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, 35–42. 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, 26–29. 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, 75–81. 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, 164–193. Inaganti, S., Aravamudan, S., 2007. SOA Maturity Model. BP Trends April 2007, 1–23. Irani, Z., Themistocleous, M., Love, P.E., 2003. The Impact of Enterprise Application Integration on Information System Lifecycles. Inf. Manage. 41, 177–187. 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. 244–258. 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, 23–45. 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. 877–880. James, A., Chung, J.-Y., 2015. Business and Industry Specific Cloud: Challenges and Opportunities. Future Gener. Comput. Syst. 48, 39–45. Ji-chen, J., Ming, G., 2006. Enterprise Service Bus and an Open Source Implementation, in: Management Science and Engineering, 2006. ICMSE’06. 2006 International Conference on. IEEE, pp. 926–930. 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. 1361–1367. 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. 1–5. 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. 51–56. Kuechler, B., Vaishnavi, V., 2008. On Theory Development in Design Science Research: Anatomy of a Research Project. Eur. J. Inf. Syst. 17, 489–504.
• 227 •
Kuechler, W., Vaishnavi, V., 2012. A Framework for Theory Development in Design Science Research: Multiple Perspectives. J. Assoc. Inf. Syst. 13, 395–423. 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, 43–51. Lankhorst, M.M., 2004. Enterprise Architecture Modelling - The Issue of Integration. Adv. Eng. Inform. 18, 205–216. Layer7, 2013. API Security and Management Today, www.layer7tech.com/infographic, Accessed: July 15, 2015. Layer7. Lee, A., 1999. Inaugural Editor’s 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, 19–35. 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. ICCBSS’07. Sixth International IEEE Conference on. IEEE, pp. 123–130. 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 you’re 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. 327–334. 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. 327–330. 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, 251–266. Maréchaux, J.-L., 2006. Combining Service Oriented Architecture and Event-driven Architecture using an Enterprise Service Bus. IBM Dev. Works 1269–1275. Markus, M.L., Majchrzak, A., Gasser, L., 2002. A Design Theory for Systems that Support Emergent Knowledge Processes. Mis Q. 179–212. Mateescu, G., Gentzsch, W., Ribbens, C.J., 2011. Hybrid Computing - Where HPC Meets Grid and Cloud Computing. Future Gener. Comput. Syst. 27, 440–453. 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. APSCC’08. IEEE. Ieee, pp. 464–469. Menge, F., 2007. Enterprise Service Bus, in: Free and Open Source Software Conference. pp. 1–6. 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, 4–5. 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, 18–25. Mueller, B., Viering, G., Legner, C., Riempp, G., 2010. Understanding the Economic Potential of Service Oriented Architecture. J. Manag. Inf. Syst. 26, 145–180. 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. CLOUD’09. IEEE International Conference on. IEEE, pp. 147–150. 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. 436–443. 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. 304–312. 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, 1–25. 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. O’Neill, M., 2015. SOA Is (Still) Not Dead (and Shouldn’t 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, 121–134. Orlowski, C., Szczerbicki, E., Grabowski, J., 2014. Enterprise Service Bus Architecture for the Big Data Systems. Manag. Prod. Eng. Rev. 5, 28–31. Ortiz, S., 2007. Getting on Board the Enterprise Service Bus. Computer 40, 15–17.
• 231 •
O’Shaughnessey, 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, 52–60. Papazoglou, M.P., Traverso, P., Dustdar, S., Leymann, F., 2008. Service Oriented Computing: A Research Roadmap. Int. J. Coop. Inf. Syst. 17, 223–255. Papazoglou, M.P., Van Den Heuvel, W.-J., 2007. Service Oriented Architectures: Approaches, Technologies and Research Issues. VLDB J. 16, 389–415. 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, 45–77. 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, 174–188. 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. 69–73. Riad, A.M., Hassan, A.E., Hassan, Q.F., 2010. Design of SOA-based Grid Computing with Enterprise Service Bus. AISS 2, 71–82. Richardson, L., Ruby, S., 2007. RESTful Web Services. O’Reilly 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. 177–183. 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, 410–434. Sanaei, Z., Abolfazli, S., Gani, A., Buyya, R., 2014. Heterogeneity in Mobile Cloud Computing: Taxonomy and Open Challenges. Commun. Surv. Tutor. IEEE 16, 369–392. 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. 325–334. 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, 781–797. 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. 115–125.
• 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. 381–397. 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 132–154. 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. 85–90. Swoyer, C., 1991. Structural Representation and Surrogative Reasoning. Synthese 87, 449–508. 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. SOSE’08. IEEE International Symposium on. IEEE, pp. 1–7. Tärneberg, 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. Who’s 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, 207–222. Tripathi, A., Mishra, A., 2011. Cloud Computing Security Considerations, in: Signal Processing, Communications and Computing (ICSPCC), 2011 IEEE International Conference on. IEEE, pp. 1–5. 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. 684–689. 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, 33–59.
• 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. 34–38. 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, 219–246. Vescoukis, V., Doulamis, N., Karagiorgou, S., 2012. A Service Oriented Architecture for Decision Support Systems in Environmental Crisis Management. Future Gener. Comput. Syst. 28, 593–604. Vidgen, R., 1998. Cybernetics and Business Processes: Using the Viable System Model to Develop an Enterprise Process Architecture. Knowl. Process Manag. 5, 118–131. 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, 235–246. 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. Wähner, 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, 36–59.
• 236 •
Walsh, S.T., Kirchhoff, B.A., Newbert, S., 2002. Differentiating Market Strategies for Disruptive Technologies. Eng. Manag. IEEE Trans. On 49, 341–351. Weber, R., 1987. Toward a Theory of Artifacts: A Paradigmatic Base for Information Systems Research. J. Inf. Syst. 1, 3–19. 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. 3–13. Winter, R., 2008. Design Science Research in Europe. Eur. J. Inf. Syst. 17, 470–475. Wu, B., Liu, S., Wu, L., 2008. Dynamic Reliable Service Routing in Enterprise Service Bus, in: Asia-Pacific Services Computing Conference, 2008. APSCC’08. IEEE. IEEE, pp. 349–354. 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. 1180–1184. 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. 513–522. 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. 35–43. 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. 4270–4276. 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, 17–19. Zhang, Q., Cheng, L., Boutaba, R., 2010. Cloud Computing: State-of-the- art and Research Challenges. J. Internet Serv. Appl. 1, 7–18. 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. ICHIT’08. International Conference on. IEEE, pp. 245–249.
• 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 •