Service Orchestration as Organization: Building Multi-Tenant Service Applications in the Cloud

conferences.

Part One

Outline

1 Introduction

2 Motivational Scenario

3 Literature Review

1

Introduction

Business organisations have been increasingly adopting business process management (BPM) as a part of their core business strategy due to benefits such as improved business–information technology (IT) alignment and optimised operational efficiency. Service-oriented architecture (SOA) has emerged as an architecture style that provides a loosely coupled, reusable and standards-based way to integrate distributed systems. Both SOA and BPM are mutually complementary development approaches for enterprise architectures. By combining the benefits of these complementary developments, service orchestration approaches are providing methodologies and technologies to enable the creation of integrated IT systems that meet the needs of rapidly changing enterprises and market places.

Keywords

BPM; adaptability; SOA; orchestration; cloud computing; SaaS

Business organisations have been increasingly adopting business process management (BPM) as a part of their core business strategy due to benefits such as improved business–information technology (IT) alignment and optimised operational efficiency [1]. Service-oriented architecture (SOA) has emerged as an architecture style that provides a loosely coupled, reusable and standards-based way to integrate IT systems [2]. Both SOA and BPM are mutually complementary development approaches for enterprise architectures [3, 4]. By combining the benefits of these complementary developments, service orchestration approaches provide methodologies and technologies to enable the creation of integrated IT systems that meet the needs of rapidly changing enterprises and marketplaces.

Over the past few years, service orchestration methodologies have evolved. New business and IT paradigms have emerged. The online market places increasingly become open, diverse and complex as more computer-mediated services become available to consumers, and as demand for those services increases [5]. The repurposing of systems to open up new revenue channels is an emerging norm. In such service market places, the changes to systems become unpredictable and frequent while consumers expect the downtime to implement these changes to be zero.

These developments have challenged the existing service orchestration methodologies. This book introduces a service orchestration methodology called Serendip to address those challenges. In this chapter, we introduce the research context, research goals and an overview of the proposed approach. Sections 1.1 and 1.2 introduce the context of this research. In Section 1.1, we provide an overview of BPM and how BPM is applied in service-oriented systems. In Section 1.2, we discuss service orchestration in the context of novel requirements and challenges. The research goals are introduced in Section 1.3. An overview of the approach is presented in Section 1.4, whereas Section 1.5 lists the key contributions of this book. Finally, Section 1.6 provides an overview of the book structure.

1.1 Business process management

According to Gartner [6], the BPM¹ market in 2009 totalled US$1.9 billion in revenue, compared with $1.6 billion in 2008, which was an increase of 15%. This means that there has been a vast increase in adopting BPM as part of the core business strategies of business organisations.

Due to the cross-disciplinary nature, BPM has multiple definitions. These definitions have changed over time and varied from one discipline to another. One of the widely recognised definitions of BPM in IT was given by van der Aalst [7]. According to van der Aalst, ‘Business Process Management (BPM) includes methods, techniques, and tools to support the design, enactment, management, and analysis of operational business processes.’

This definition leads to the question, what is a business process? Curtis [8] in a broader context defines a process as a ‘partially ordered set of tasks or steps undertaken towards a specific goal.’ In the business context, Hammer and Champy [9] define a business process as a ‘set of activities that together produce a result of value to the customer.’ In the literature, there are many other definitions with slight variations. Irrespective of these variations, the fundamental characteristics of a business process is the ordering of activities that is required to achieve a business requirement/goal.

The attraction of BPM to business organizations is primarily driven by the requirement of managing the business processes and continuously optimising and leveraging their IT assets. BPM provides the management model to efficiently achieve this objective by using IT. Such efficiency becomes an important requirement as businesses demand shorter cycle times for executing processes [10]. Hence, the main objective of BPM can be seen as the provision of efficient business IT support, compared to its non-IT or manual counterparts, which helps the organisation to function in a productive manner [11].

The adoption of BPM in businesses also formalises the understanding of business processes. Formalised business process descriptions provide a unified view on the processes of a business organisation. A unified view helps identify the gaps and the required improvements in business strategies. Consequently, the business strategists can fill the gaps or find better ways of accomplishing tasks [11]. The Barings bank failure [12] is a good example that highlighted the disastrous effects on a business of unidentified gaps in business processes. The improvements and adoption of computing theories, notations and verification methodologies into BPM have assisted the communication, understanding and verification of defined business processes. Furthermore, the advancing capabilities of BPM suites such as logging, monitoring, visualisation and process analysis also assisted the adoption of BPM.

The ever-increasing competition within business environments forces business organisations to change their business processes frequently. According to Gartner, ‘more than two-thirds of organisations using BPM do so because they expect that they will have to change business processes at least twice per year’ [6]. The report also stated ‘18% of companies have said that they needed to change processes at least monthly and 10% said that their processes changed weekly.’ Manually adapting and verifying such frequent changes can be impractical; hence, proper IT support is a must.

In conclusion, the factors such as requirement for increased efficiency and the ability to support frequent changes have collectively forced business organizations to practice BPM methodologies as part of their core business strategy.

1.1.1 BPM in practice

Business organisations practice BPM in different ways. These practices are selected depending on the business and technical requirements of the organisation.

The most rudimentary use of IT support involves the computer-assisted drafting of process flows or business process definitions. Usually, a software tool is used by business strategists or policymakers to quickly draft the activity flows or the process definitions and distribute among a set of involved partners, e.g. business owners, line managers, clerks and labourers. The objective of this practice is to convey a specific business strategy captured via a process definition. The partners abide by the process definition. If a change is required, then the process definition is reloaded to the software tool to apply due changes. Later, the changed process definition is redistributed among the partners. The process definitions used in this practice are usually diagrammatic. The idea is to let humans understand the business strategy quickly and easily. There is no intention to automate the enactment via machines. During the early stages, business organisations developed their own proprietary notations to describe such process definitions. Both business strategists and partners were required to learn these notations. Later, in order to standardise the way such processes are modelled and communicated among different partners, many standard process modelling notations were proposed [13–17]. Yet, the process execution was carried out manually without any automation.

Due to the lack of efficiency in such manual execution, business organisations required executable languages [7, 18, 19]. Such languages allow machines to understand and automate the execution of the business processes. Many business process instances can be instantiated and executed simultaneously with little or no human involvement. The advent of business-to-business communication intensified the need for automated process execution. Subsequently, the emerging process executable languages demand business process execution engines. This requirement is backed by leading vendors such as Microsoft, IBM, BEA and SAP who created a number of process execution engines, usually as part of a complete BPM suite. This development paves the way to placing the business process execution engines and the BPM suites at the heart of the enterprise systems [20].

One of the potent catalysts for increased business process automation is the advancement in distributed computing [21]. In distributed computing, multiple automated systems that are geographically distributed communicate with each other over a network. With the advancement of SOA [2, 5] and wide adoption of service-oriented computing technologies such as Web services [22], the requirement for providing automated business process execution has further intensified [2, 23].

1.1.2 BPM in service-oriented systems

In recent years, service-oriented systems that compose reusable services in a loosely coupled manner have emerged as a new paradigm for modelling and enacting enterprise applications. SOA has been used either to consolidate and repurpose legacy applications or to combine them with new applications [5]. SOA provides a set of principles and architectural methodologies to integrate loosely coupled, distributed and autonomous software services.

The services in SOA can be described as well-defined, self-contained and autonomous computing modules that provide standard business functionality and are independent of the state or context of other services [2]. A business organisation may integrate a group of such services together to provide a combined business offering. The entity that aggregates these services is known as the service aggregator. Such an aggregation of services is known as a service composition. In a service ecosystem, such a composition also can be used as a service for further composition. In service composition, it is required to specify the logical coordination in which these services are invoked. The logical coordination of service invocations is known as a service orchestration, which is defined by the service aggregator.

Service orchestration differs from service choreography [24]. Service orchestration provides a participant’s or a service’s point of view of how it interacts with other services in collaboration, and a service orchestration is executable; in contrast, service choreography provides a global view among a set of participants or services and is not executable. A choreographic description is usually considered as a global contract or agreement that all participants commit [25–27]. Such a choreographic description is required to be mapped to a service orchestration description for execution purposes [28].

At the beginning, general-purpose programming languages such as Java and C++ were used for orchestrating services. However, such general-purpose programming languages lack the ease of redesign and the comprehensibility for business users. Such properties are essential to understand, analyse and iteratively refine the service orchestration. Consequently, a need developed for more specific service orchestration