A Cloud-driven View on Business Process as a Service

org Domaschka, Frank Griesinger, Daniel Seybold and Stefan Wesner

Institute of Information Resource Management, Ulm University, Albert-Einstein-Allee 43, 89081 Ulm, Germany

Keywords:

Business Process as a Service, BPaaS, Cloud Computing, Business-IT Alignment, Workﬂow, Modelling.

Abstract:

Cloud computing is the promise to provide ﬂexible IT solutions. This correlates with an increasing demand

in ﬂexibility of business processes in companies. However, there is still a huge gap between business and

IT management. The evolution of cloud service models tries to bridge this by bringing up ﬁne grained and

multi-dimensional service models. One of the new service models is Business Process as a Service (BPaaS),

which promises to bridge the gap from business process to cloud computing. Yet, the BPaaS paradigm is

not thoroughly classiﬁed with respect to the cloud computing characteristics. In this paper we introduce a

ﬁrst classiﬁcation of the BPaaS paradigm with the focus on the common cloud characteristics. Therefore, we

analyze the traditional path from a business process model to its execution via on-demand resources and derive

a leveled model for BPaaS. For each level, we introduce the entities on that level in terms of (i) correlation

to cloud characteristics, (ii) concepts and (iii) tools, and evaluate its cloudiﬁcation options, i.e. the ability to

support the provision of a business process as a service. The presented work enables the categorisation of items

in the BPaaS paradigm and outlines how traditional business processes can be enabled for cloud delivery. This

classiﬁcation and analysis will be extended, once the BPaaS paradigm reached wider acceptance in academia

and industry, and more standards evolved.

1 INTRODUCTION

The cloud computing paradigm has evolved from

its initial compute-oriented service models (IaaS,

PaaS, SaaS) (Mell and Grance, 2009; Foster et al.,

2008) to more ﬁne grained and multi-dimensional

service models (Kachele et al., 2013) capturing

amongst others the storage and networking dimen-

sion. Along with this evolution cloud computing has

become a large driver of business models and inno-

vation. While adopters of cloud computing originally

were IT-oriented companies, SaaS also allows non-

technological companies to beneﬁt from cloud com-

puting.

Yet, SaaS offerings are usually inﬂexible and their

vendors expect them to be one-size-ﬁts-all solutions

for their customers often ignoring that they need to in-

tegrate into the users’ existing business processes. In

order to work around this inﬂexibility, new and inno-

vative cloud service models are needed that support

non-IT customers with a business-ﬁrst view (Smith,

2012) and due to that allow support existing business

processes. Furthermore, offered solutions should be

able to grow (and shrink) with the size of a company.

Here, a promising approach is the Business Pro-

cess as Service (BPaaS) service model (Papazoglou

and van den Heuvel, 2011). Despite its use in several

publications (Papazoglou and van den Heuvel, 2011;

Barton and Seel, 2014; Woitsch and Utz, 2015b), and

even the deﬁntion of an architecture and release of an

implementation (Woitsch and Utz, 2015a), the term

BPaaS has never been deﬁned. In consequence, it is

unclear what are the true capabilities and features of-

fered by this service model.

The main contribution of this paper is a ﬁrst

attempt to close this gap by re-visiting classical

and widely-accepted deﬁnitions of cloud computing

and investigating the steps executed in traditional

business-IT alignment which executes the necessary

steps to support business processes with IT solutions.

From these considerations, we derive a hierarchy of

ﬁve different levels of a business process with vary-

ing technical complexity. We then deﬁne BPaaS

that offers at least a distributed, multi-tenant capable

workﬂow engine where users can upload custom ex-

ecutable business processes that may even access ex-

ternal services. This type of business processes con-

stitutes the lowest layer of our hierarchy. However,

we also state that a BPaaS platform should also have

support for the respective other layers and in particu-

Domaschka, J., Griesinger, F., Seybold, D. and Wesner, S.

A Cloud-driven View on Business Process as a Service.

DOI: 10.5220/0006393107670774

In Proceedings of the 7th International Conference on Cloud Computing and Services Science (CLOSER 2017), pages 739-746

ISBN: 978-989-758-243-1

739

lar for both vertical and horizontal transitions between

individual processes.

The remainder of this paper is structured as fol-

lows: Section 2 introduces related terms, Section 3

provides a technical overview on BPaaS and its rela-

tion to the cloud characteristics. Section 4 discusses

the concepts and tools for the cloud-enabling of busi-

ness processes. Section 5 presents related work. Fi-

nally, Section 6 concludes.

2 TERMINOLOGY

This section sets the basis for classiﬁcation of BPaaS

by introducing basic concepts and terms for the busi-

ness process and cloud context.

2.1 Clouds and Services

The NIST standard on cloud computing (Mell and

Grance, 2009) deﬁnes the three well-known cloud ser-

vice models (IaaS, PaaS, SaaS) and private and pub-

lic cloud deployment models. It also introduces a hy-

brid deployment model where multiple cloud environ-

ments generate a higher-level service. Besides these

descriptive aspects of cloud computing, the standard

also demands these ﬁve essential characteristics from

any cloud offering: on-demand self-service, broad

network access, resource pooling and multi-tenancy,

rapid elasticity, and measured service.

While all cloud offerings are provided as a ser-

vice, the term service can be used with a wider mean-

ing. In general, we assume that a (remote) service is a

software entity providing a well-deﬁned functionality

through a service interface and is realised through a

service implementation. The service interface deﬁnes

the protocol to use and the API (available operations

and input/output to them). A cloud service is a remote

service providing the ﬁve cloud characteristics.

From an inside perspective, a service implemen-

tation consists of 1. . . n software components. In

order to operate the service, software deployment

ensures that the components are instantiated by in-

stalling them over a set of physical or virtual ma-

chines. When the service itself shall be run over

cloud resources, Cloud Orchestration Tools (COTs)

can automate the deployment in terms of communi-

cating with cloud provider APIs and the life-cycle

processing of the software component and its respec-

tive actions, such as installation, startup, shutdown

and adaptations, such as scaling or service substitu-

tion (Baur et al., 2015).

2.2 Business Process Terminology

Business Processes (BPs) are seen as a graph of man-

ual, semi-automatic, and automatic actions, aiming

to achieve an organisational goal. Their goal is to

align all actions within an organisation with the busi-

ness goals, independent from who performs them (hu-

mans, machines). Actions are typically described de-

pendant on time, role, and place; and every ”hand-

over” of a task is seen as the border of an activity.

Consequently, a Business Process Model (BPM) is

an abstract representation of a business process, often

deﬁned formally, e.g. through a modelling language

such as BPMN (Group, 2011).

Using BPMs, business process management deals

with improving corporate performance by managing

and optimising the BPs of a company. Business pro-

cess management sees BPs as important assets of

an organization that must be understood, managed,

and developed to announce value-added products and

services to clients or customers. Traditionally, the

business process management lifecycle comprises the

steps design, modelling, execution, and monitoring.

BPs can best and most ﬂexible be managed, ex-

ecuted, and improved once large parts of them have

been automatised through the use of IT systems.

Here, business-IT alignment aims at using IT in the

most efﬁcient way to achieve business objectives

and to improve ﬁnancial performance or marketplace

competitiveness (Woitsch et al., 2009).

In addition, business IT-alignment enables

the transformation from domain-centric BPs to

technology-centric workﬂows (WFs) leveraging au-

tomation. Hence, a WF represent a BP as a sequence

of tasks that interact with technical services. The

automated execution of WFs is realised by Work-

ﬂow Engines (WFEs) that handle the deployment,

execution, and management of different WFs. Con-

sequently, they realise the interaction with remote

services and provide an interface to users.

A workﬂow instance represents an instantiation of

a WF in a WFE including its current state (e.g. coun-

ters, path take in execution ﬂow, return values of in-

voked services, . . .) and context (e.g. triggering event

or person, parent workﬂow, . . .).

2.3 Cloud-enabled Business Processes

Business Process as a Service (BPaaS) introduces a

cloud service model for BPs. In consequence, any

BPaaS implementation needs to support the ﬁve es-

sential NIST characteristics. Broad network access

requires that BPaaS is offered over a Web-based in-

terface and the servers hosting the service provide suf-

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

740

ﬁcient network capacity. On-demand self-service de-

mands that all actions a BPaaS offering provides to its

users are fully automatised. Similarly, rapid elasticity

requires a high degree of automation to allow users

to acquire more resources on demand. In particular, it

is needed that the software components implementing

the BPaaS platform are scalable and elastic by them-

selves.

From a provider perspective, resource pooling is

a key feature to realise the functionality. In con-

sequence, this means that all resources used by all

BPs are pooled over one or more pools of resources

(which may themselves be physical or virtual) while

still isolating users from each other. Hence, any

BPaaS implementation requires support for multi-

tenancy. Finally, measured services are the founda-

tion for the provider to optimise resource usage and

for offering pay-per-use billing models. In conse-

quence, also monitoring, ﬁne-grained accounting, and

ﬂexible billing models are needed in order to beneﬁt

from this kind of feature.

From these demands and constraints it becomes

clear that the realisation of BPaaS only works in

highly automated environments and has huge impact

on business-IT alignment. In particular, the business-

IT alignment for a single BP does not have to be static

any more. Through a cloud-oriented approach, the

size of the IT infrastructure can grow and shrink as

needed and also potential third party services used to

implement and automatise a business process are not

necessarily statically bound. We refer to a BP/WF

that supports these characteristics and can be run in a

BPaaS environment as Cloud-enabled Business Pro-

cess (CeBP).

3 TECHNICAL VIEW ON BPaaS

Leveraging the ﬂexibility of business-IT alignment as

described in Section 2.3, requires to identify the de-

grees of freedom that exist when aligning a high-level

BP to IT environments. For that purpose, we ﬁrst

provide an overview of business IT-alignment from

a more traditional non-cloud perspective. In a second

step, we divide business IT-alignment into ﬁve levels

that can be mapped to cloud computing features.

3.1 Executing Business Processes

BPs represent the basis for all companies and can be

executed through IT services. Traditionally a busi-

ness expert acquires and retains the BPs of a com-

pany. Then, the company assigns internal and exter-

nal IT experts to automatise as many parts of the BP as

possible and aligns the BPs to their IT infrastructure

to operate the BP in a cost and performance efﬁcient

way.

The business-IT alignment (cf. Figure 1) com-

prises the mapping from BPs to WFs. WFs orches-

trate services which have to be selected and allo-

cated. Service selection includes steps such as on/off-

premise decision, hardware sizing and acquisition,

continuous (manual) monitoring and adaptation of the

service execution. As these steps are company- and

BP-speciﬁc, changing business demands have to be

answered by an updated BPs and WFs which is only

possible to a certain extent, as the ﬂexibility of the

manual process is limited.

Since the business IT-alignment is cumbersome

and includes many manual steps, a direct and auto-

mated mapping to cloud offerings is not possible.

3.2 CeBP for BPaaS

Realising BPaaS requires ﬂexibility for many of the

steps executed in the business-IT alignment to sup-

port both the pay-as-you-go model, but also the elas-

ticity demanded from cloud services. In order to iden-

tify sources of ﬂexibility and approaches to cloud-

enabling, this section formalises business-IT align-

ment and divides it into steps that—starting from a

non-technical BP—enriches the BP with technical de-

tails. More precisely, we introduce a novel hierarchy

of ﬁve levels of CeBPs depicted in Figure 2.

In the following, we present for each level a high-

level deﬁnition and describe how level n can be de-

rived from level n − 1.

Off-premises Service E

Action A Action B Action C

Business

Process

Service B1 Service B2

Service Provider C

Service Provider D

Service Provider E

On-premises Service D

Workflow

Instance

Instance n

Workflow

Engine

Business

-IT alignment

Figure 1: Traditional view on business process execution.

Level I (business process level) deals with domain-

speciﬁc business processes that describe the business

activities of a worker in a non-technical manner. The

BP on this level is not technically executable.

On Level II, technical workﬂows enhance the Level-I

description with technical details, enabling automa-

tion and the allocation of services (Van Der Aalst

et al., 2003) by deciding how to map BP actions to

A Cloud-driven View on Business Process as a Service

741

IaaS Provider Z

Action A Action B Action C

Level-I CeBP

(Business Process)

Service B1 Service B2

Level-II CeBP

(Technical Workflow)

Level-III CeBP

(Executable Workflow)

Software component @

SaaS provider

Software component @

PaaS provider

Software component @

IaaS provider

Level-IV CeBP

(Deployed Workflow)

PaaS Provider Y

container

Level-V CeBP

(Workflow Instance)

Instance n

Workflow

Engine

Figure 2: Levels of a Cloud-enabled business process.

service calls. Hence, it is decided which service inter-

faces are being used and how the different (so far ab-

stract) services interact with each other. Each Level-II

WF realises a Level-I process, but a Level-I process

can be realised by multiple Level-II WFs. They vary

depending on the desired level of automation, the ser-

vices to use, and other non-functional properties that

shall be respected.

Level III comprises executable workﬂows. These dif-

fer from technical WFs, as they not only capture the

types of services to be used in the workﬂow imple-

mentation, but also deﬁne which concrete available

service shall be used. Hence, it is on this level where

it is decided if the workﬂow uses a particular commer-

cial SaaS offer, one of the company’s legacy services,

or a self-hosted service. A self-hosted service is a

service instantiated on a public or private PaaS, IaaS,

or bare metal platforms. Hence, on this level the in-

formation required to access the service is speciﬁed.

For self-instantiated services, additional information

on how and where to create a service instance is spec-

iﬁed as well. We refer to this information as deploy-

ment description. As before, multiple executable WPs

can realise the very same technical WF. The selection

of service instances and selection of PaaS and SaaS

providers respectively deﬁnes the SLAs, pricing, and

other non-functional properties of the executable WF.

Pushing an executable WF to production moves it

to Level IV and by instantiating a deployed work-

ﬂow. This step includes the deployment of services,

if needed (cf. Level III) including the acquisition of

required resources from cloud platforms. Therefore,

a major part of the cloud-enabling process takes place

here. Users can make use of Level-IV deployed work-

ﬂows. Obviously, a Level III workﬂow can have been

instantiated multiple times.

Level V deﬁnes the workﬂow instances that are trig-

gered by users, run in a WFE, and exploit the pro-

visioned services. This level captures the instance-

speciﬁc details with respect to monitoring and rule

enforcements. An arbitrary number of instances of

a deployed WF can exist accessing the same services.

3.3 Dimensions of BPaaS

This section discusses possible features of a BPaaS

offering and identiﬁes on which of the levels this fea-

ture has to be implemented. It is up to Section 4 to in-

troduce the necessary tools needed to realise the fea-

tures.

As discussed in Section 3.2, business processes

exist on different technical levels. In consequence,

there is no intuitive semantics of the BP part of

BPaaS. The two most obvious options are the follow-

ing: (i) Offering a web-based design tool for Level

I processes. This would classify BPaaS as a spe-

ciﬁc kind SaaS, but would not allow the deployment

and execution of the BP. (ii) Offering a workﬂow en-

gine capable of executing uploaded processes. Here,

BPaaS would be a special kind of PaaS that provides

an platform for the execution of customer logic.

From these two options, we use (ii) as the starting

point for our discussion, as it seems more beneﬁcial

to its users. However, just as other PaaS offerings are

commonly enhanced with IDE integration or even on-

line programming environments, an option-(ii) based

offering should be enhanced with designer support or

even an option-(i) online designer. This could be en-

hanced with the user interface that has to be provided

by the WFE in order to allow users of the business

process (e.g. case workers) to access the process in-

stances and e.g. check completed tasks.

Traditional PaaS providers offer additional ser-

vices such as databases and message queues to the

applications they host. Yet, with their focus on com-

puting and particularly on the processing of web re-

quests, it is commonly not expected nor supported

to access external services hosted by other opera-

tors. Scalability for applications is achieved by giv-

ing more compute resources to the executed applica-

tion which requires a scalable runtime environment

and/or a limited programming model. Due to the lim-

ited execution model of BPs, a BPaaS does neither

require message queues nor databases as additional

services. In case the BPaaS operator provides a dis-

tributed, multi-tenant WFE, the setting is scalable, as

workﬂow instances are independent from each other

and can run on any instance of the WFE.

The fact that BPs and their workﬂows depend on

external or even self-hosted services introduces more

degrees of freedom and hence, more ﬂexibility for

BPaaS operators with respect to service quality and

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

742

deployment. This is the case due to the 1 : n relation-

ships between all levels and their sub-levels. In par-

ticular, the following options exist: (a) On workﬂow

instance-level, limits on the allowed number of Work-

ﬂow Instances per time can be changed; (b) On the

level of a Deployed Workﬂow, the resources allocated

to a self-hosted service can be changed as well as the

hoster of these resources; (d) On the level of an Ex-

ecutable Workﬂow, the SaaS operators of an external

service can be changed or the a used SaaS might be

changed to self-hosting and vice-versa; on the same

level (e) scaling rules for the enacting Level-IV can

be changed; (f) on the level of a Technical Workﬂow,

the workﬂow itself can be changed so that BP actions

are broken down into different steps; Finally, (g) on

Level-I the entire BP can be changed.

3.4 Supported Cloud Properties

Section 3.3 has identiﬁed that at its core any BPaaS

should realise support for executing workﬂows in a

workﬂow engine (Level V). However, in order to re-

ally beneﬁt from the ﬂexibility offered by a cloud-

based solution, a BPaaS should also add support for

higher layers and it is the task of the operator of such a

service to ﬁnd the right balance between the power of

supporting many levels and making the system easy to

use for the customers. In the following, we investigate

which of the ﬁve cloud properties can be supported

at what level of the CeBP. For each level, we anal-

yse the necessity of the cloud characteristics based on

mandatory (!) or optional (or not applicable) (0) to

cloud-enable the business process on that level. The

result of this analysis is shown in Table 1.

The need for the cloud characteristics is evaluated

based on the deﬁnition phase (def) of the CeBP, i.e.

when the speciﬁcation of the BPaaS happens on the

respective level, and its execution phase (exec), i.e.

running the fully speciﬁed Deployed Workﬂow.

For supporting Level I, the BPaaS operators need

to offer broad network access and allow rapid elas-

ticity in terms of an easy way to change requirements

and process descriptions. Measured services are re-

quired throughout the life-cycle of a CeBP to support

multi-tenancy.

Level II requires support for broad network access

and rapid elasticity to allow the ﬂexibility of changing

market situations, such as new services are available.

Further, to allow rapid elasticity for the BPaaS, dif-

ferent technical implementations must be deﬁnable as

alternatives. As this is a connection point for experts

of different areas, we see multi-tenancy as mandatory

in terms of resource pooling of different actors work-

ing on the same technical WFs. During execution,

new services can occur on the market that better ﬁt

the needs for the BPs. Hence, it is mandatory that

the tools allow rapid elasticity and provide measured

services in order to quickly re-allocate the tools and

change the task-service mapping.

Level III requires support for measured services as

this is part of a BPaaS provider and will be needed to

calculate the price for offering a BPaaS. Other char-

acteristics, such as elasticity and self-service are not

mandatory as the steps on Level III happen ofﬂine.

During the execution of the business process, this

level supports the cloud-enabling in terms of choosing

service implementations and service providers that

are conform with the NIST characteristics. A major

aspect for the technologies is the ability to handle this.

Level IV focuses on the execution phase, therefore

no changes happen during the BPaaS deﬁnition phase.

The engaged tools have to support all cloud charac-

teristics as they are used for orchestrating the cloud

services, i.e. deployment, conﬁguration and run-time

management. The resulting services are interlinked

with the respective WF. Hence, the tools have to sup-

port the enactment of on-demand self-service, broad

network access, resource pooling, rapid elasticity and

measured service of the employed services. Concern-

ing the cloud-enabling, the same possibilities of Level

IV hold true for Level V as it uses the previously de-

ployed services.

4 CONCEPTS AND TOOLING

For all ﬁve levels of Business Processes as supported

by a BPaaS offering, this section discusses existing

concepts and tools that may be built upon for realis-

ing a BPaaS offering. This is necessary to be able to

identify them and classify them in terms of their re-

quirements towards the cloud-enabling process.

4.1 Business Process

As the landscape of business process technologies is

extensive, we select two common technologies which

can be exploited for the business level of BPaaS.

The Business Process Model and Notation

(BPMN) is a standardised ﬂowchart based notation

for deﬁning BPs (Group, 2011). The notation aims

to be comprehensible for managers, business analysts

as well as developers. BPMN models may be deﬁned

on a variable level of detail: from high-level process

landscapes down to a detail level allowing the trans-

formation into an executable language.

The Decision Model and Notation

(DMN) (Group, 2015) standard supports mod-

A Cloud-driven View on Business Process as a Service

743

Table 1: Business process cloudiﬁcation.

Cloud Characteristics (NIST)

CeBP level

On-demand

self-service

Broad net-

work access

Resource

pooling

Rapid elas-

ticity

Measured

service

def exec def exec def exec def exec def exec

I: Business Process

0 0 ! 0 0 0 ! 0 ! 0

II: Technical Workﬂow

0 0 ! 0 ! 0 ! ! ! !

III: Executable Workﬂow

0 0 0 0 0 0 0 0 ! 0

IV: Production Workﬂow

0 ! 0 ! 0 ! 0 ! 0 !

V: Workﬂow Instance

0 ! 0 ! 0 ! 0 ! 0 !

elling and automating of business decisions and is

understood by business experts and technical experts.

Several web-based tools exist to apply the pre-

sented technologies and create business process mod-

els such as Adonis

, ADOxx

or Bonita BPM

. Tools

such as ADOxx or the Camunda modeler

support

creating DMN models.

4.2 Technical Workﬂow

The BPMN standard (Group, 2011) of the prior level

can be exploited on this level as well. Further tech-

nologies are commonly exploited to integrate services

into executable workﬂows. The Service Modeling

Language (SML) is used to model complex services

and systems, including their structure, constraints,

policies, and best practices (W3C, 2009). Mapping

services to task and integrating them into a techni-

cal WF, the service interfaces have to be described,

e.g. with WSDL (Christensen et al., 2001). Stan-

dards to describe the execution of WFs of BPs, e.g.

BPEL (Alves et al., 2007) reside on this level. They

are used for an automatic execution of WFs.

There are a plethora of WFEs available that run

BPMN processes. The Activiti Platform

is an exam-

ple of an open-source tool that is able to create BPMN

with concrete services and also run/instantiate them.

There are no established tools that support the

mapping of tasks to services.

4.3 Executable Workﬂow

Various modelling languages exist for describing an

application and its deployment conﬁguration, e.g.

hardware requirements and installation scripts with

respect to cloud resources. Such technologies cater

http://en.adonis-community.com/

https://www.adoxx.org/live/home

http://www.bonitasoft.com/

https://camunda.org/dmn/simulator/

https://www.activiti.org/

for the automation of the deployment and manage-

ment process in the sense of the DevOps paradigm.

Furthermore repositories hosting those models for

ﬂexibility and reusage are beneﬁcial for the support of

the cloud characteristics. Because those can be used

to assemble new technical WF descriptions.

Conﬁguration management tools, widely known

as DevOps tools, come with languages to describe the

conﬁguration of a software component and a system

to ensure the correct installment of the component in a

local scope (i.e. mostly in the view of a single node).

They ease the description of application installation

and dependencies.

Cloud modelling approaches such as CloudML

CAMEL

, CAMP (Durand et al., 2014) or

TOSCA (Palma and Spatzier, 2013) are results

of research efforts. They aim to cater for the re-

usability and ﬂexibility needed for the descriptions

of cloud applications. Repositories for cloud-enabled

application descriptions are emerging, such as the

Vinothek for TOSCA or the social network for

the CAMEL language.

A web-based tool for the

model-based description of cloud applications is

juju

that also provides a service catalogue.

4.4 Deployed Workﬂow

COTs (Baur et al., 2015) are managing the holistic

life-cycle of the cloud application, i.e. the topology

of the software components, providing application-

wide self-service and care for the accessibility of ser-

vices. Resource pooling is done in respect to the man-

agement of connected cloud providers. COTs gather

monitoring data, which can be exploited for rapid

elasticity in terms of adaptation actions and to a cer-

tain degree for measured services.

http://cloudml.org/

http://camel-dsl.org/

http://www.paasage.eu/training-materials/the-paasage-

social-network

https://www.ubuntu.com/cloud/juju

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

744

The models@runtime paradigm (Ferry et al.,

2014) can be applied to synchronise the cloud appli-

cation model and the real world model by correlating

actual monitoring data with the cloud model.

Common COTs are Brooklyn

, Scalr

Cloudiator

. As their properties and abilities to-

wards their intended usage varies heavily we recom-

mend (Baur et al., 2015) for more technical details.

Monitoring data can be gathered and processed by

tools such as InﬂuxDB

, yet there exist a plethora of

applicable options. The synchronisation of the actual

and the ideal application model of a running deploy-

ment is currently still a research target. One exam-

ple is CloudMF (Ferry et al., 2014) for the CloudML

modelling language.

4.5 Workﬂow Instance

The tools on this level have the same signiﬁcance on

the cloud-enabling as the previous level. From the

execution view of the BPaaS, Level V must support

all cloud characteristics, which should be the case as

the deployed services of Level IV are used.

5 RELATED WORK

There are well adopted classiﬁcations for the com-

mon cloud service models (Mell and Grance, 2009)

as well as more ﬁne grained classiﬁcations, e.g.

for Data-as-a-Service (DaaS) or Storage-as-a-Service

(STaaS) (Rimal et al., 2009; Kachele et al., 2013).

Yet, the term BPaaS is not considered in these

classiﬁcations. While the BPaaS term came up

in 2011 and has gained a growing interest since

2013 (Barton and Seel, 2014), the term BPaaS not

yet standardised (Mell and Grance, 2009) nor exist

a common classiﬁcations or taxonomy for BPaaS.

In 2011, (Papazoglou and van den Heuvel, 2011)

introduce the concept of BPaaS with respect to the

cloud service levels, by introducing the BPaaS layer

on top of the common cloud service levels IaaS, PaaS

and SaaS. In their concept the BPaaS level is deﬁned

via blueprints, mapping business processes and work-

ﬂows to cloud services. In introducing the BPaaS con-

cept, this approach focuses on the modelling aspects

while our presented classiﬁcation considers the full

BPaaS lifecycle including deﬁnition and execution.

Focusing on cloud integration an extended con-

cept of the previously described BPaaS approach is

https://brooklyn.apache.org/

http://www.scalr.com/

http://cloudiator.org/

https://www.inﬂuxdata.com/

presented by (Papazoglou, 2012). Here the BPaaS

paradigm is expressed via an extended blueprint mod-

elling language, combining different cloud services

into one common view without focusing the BP and

WF speciﬁc levels as our classiﬁcation does.

A conceptual framework for categorising cloud

services as BPaaS is presented in (Lynn et al., 2014).

This framework aims at identifying potential value of

adopting the BPaaS model and its implications for the

realisation of business values from cloud computing.

With the need to clarify the term BPaaS, the basic

terms from business process management and cloud

computing are set in relation and possible challenges

are derived. This framework follows a similar ap-

proach in placing BPaaS into the cloud context as our

classiﬁcation does, while the framework only builds

upon a theoretical bases and our classiﬁcation builds

upon an technical BPaaS implementation.

A ﬁrst approach to implement BPaaS happens in

the CloudSocket project (Woitsch and Utz, 2015b).

This approach introduces a ﬁrst step into deﬁning dif-

ferent levels in the BPaaS paradigm and outlines an

architecture for implementing these levels. While this

work focuses on the business-IT alignment with re-

spect to BPaaS, a cloud-centric classiﬁcation of the

overall BPaaS paradigm is not in its focus.

6 CONCLUSIONS

The evolution of cloud computing moves from the

traditional cloud service models to multi-dimensional

services models, which focus on technical aspects as

well as on business aspects. In this context an up-

coming service model is Business Process as a Ser-

vice (BPaaS), which has gained attention but is not

yet classiﬁed in the common terms of the cloud ser-

vice models (Mell and Grance, 2009). We present a

novel classiﬁcation for BPaaS with respect to the well

adopted cloud service models, deﬁning a hierarchy of

ﬁve levels of business processes with an increasing

technical speciﬁcation. We argue that at its core any

BPaaS offering has to enable support for the lowest

of the ﬁve layers which can be achieved by proving

a distributed and multi-tenant capable workﬂow en-

gine. Yet, only support for higher layers in the hier-

archy support leveraging the ﬂexibility and dynamic

that is a main property of cloud offerings. Finally, we

discussed available tools and technologies that can be

used for realising support for each of the ﬁve layers in

a prototype implementation of a BPaaS platform.

Future work targets the completion of a reference

implementation for a BPaaS platform in the Cloud-

A Cloud-driven View on Business Process as a Service

745

Socket project

. Other work will encompass a vali-

dation of our classiﬁcation based on advanced BPaaS

implementations. Further, the classiﬁcation will in-

clude human actors and roles, and extend the existing

levels by more ﬁne-grained sub-levels.

ACKNOWLEDGEMENTS

The research leading to these results has received

funding from the European Community’s Framework

Programme for Research and Innovation HORIZON

2020 (ICT-07-2014) under grant agreement number

644690 (CloudSocket).

We thank the entire CloudSocket consortium for

the valuable and constructive discussion on the matter

and for feedback on earlier versions of this paper.

REFERENCES

Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B.,

Curbera, F., Ford, M., Goland, Y., Guzar, A., Kartha,

N., et al. (2007). Web services business process exe-

cution language version 2.0 (oasis standard). ws-bpel

tc oasis.

Barton, T. and Seel, C. (2014). Business process as a

service-status and architecture. In EMISA, pages 145–

158.

Baur, D., Seybold, D., Griesinger, F., Tsitsipas, A., Hauser,

C. B., and Domaschka, J. (2015). Cloud orchestra-

tion features: Are tools ﬁt for purpose? In 2015

IEEE/ACM 8th International Conference on Utility

and Cloud Computing (UCC), pages 95–101.

Christensen, E., Curbera, F., Meredith, G., Weerawarana,

S., et al. (2001). Web services description language

(wsdl) 1.1.

Durand, J., Otto, A., Pilz, G., and Rutt, T. (2014). Cloud

Application Management for Platforms Version 1.1.

OASIS Committee Speciﬁcation.

Ferry, N., Song, H., Rossini, A., Chauvel, F., and Sol-

berg, A. (2014). Cloudmf: Applying mde to tame the

complexity of managing multi-cloud applications. In

UCC, 2014 IEEE/ACM 7th International Conference

on, pages 269–277.

Foster, I., Zhao, Y., Raicu, I., and Lu, S. (2008). Cloud

computing and grid computing 360-degree compared.

In Grid Computing Environments Workshop, 2008.

GCE’08, pages 1–10. Ieee.

Group, O. M. (2011). Business process model

and notation 2.0. Technical report, OMG,

http://www.omg.org/spec/BPMN/2.0/PDF.

Group, O. M. (2015). Decision model

and notation. Technical report, OMG,

http://www.omg.org/spec/DMN/1.1/.

https://www.cloudsocket.eu/

Kachele, S., Spann, C., Hauck, F. J., and Domaschka, J.

(2013). Beyond iaas and paas: An extended cloud tax-

onomy for computation, storage and networking. In

UCC, 2013 IEEE/ACM 6th International Conference

on, pages 75–82. IEEE.

Lynn, T., OCarroll, N., Mooney, J., Helfert, M., Cor-

coran, D., Hunt, G., Van Der Werff, L., Morrison,

J., and Healy, P. (2014). Towards a framework

for deﬁning and categorising business process-as-a-

service (bpaas). In Proceedings of the 21st Inter-

national Product Development Management Confer-

ence.

Mell, P. and Grance, T. (2009). The nist deﬁnition of cloud

computing. National Institute of Standards and Tech-

nology, 53(6):50.

Palma, D. and Spatzier, T. (2013). Topology and Orchestra-

tion Speciﬁcation for Cloud Applications Version 1.0.

OASIS Standard.

Papazoglou, M. P. (2012). Cloud blueprints for integrat-

ing and managing cloud federations. In Software

Service and Application Engineering, pages 102–119.

Springer.

Papazoglou, M. P. and van den Heuvel, W.-J. (2011).

Blueprinting the cloud. IEEE Internet Computing,

15(6):74–79.

Rimal, B. P., Choi, E., and Lumb, I. (2009). A taxonomy

and survey of cloud computing systems. INC, IMS

and IDC, pages 44–51.

Smith, D. M. (2012). Hype cycle for cloud computing,

2012. Gartner Inc., Stamford.

Van Der Aalst, W. M., Ter Hofstede, A. H., and Weske, M.

(2003). Business process management: A survey. In

International conference on business process manage-

ment, pages 1–12. Springer.

W3C (2009). Service modelling language. Technical

report, W3C, http://www.w3.org/TR/2009/REC-sml-

20090512/.

Woitsch, R., Karagiannis, D., Plexousakis, D., and Hinkel-

mann, K. (2009). Business and it alignment: the it-

socket. e & i Elektrotechnik und Informationstechnik,

126(7-8):308–321.

Woitsch, R. and Utz, W. (2015a). Business process as a ser-

vice (bpaas). In Conference on e-Business, e-Services

and e-Society, pages 435–440. Springer.

Woitsch, R. and Utz, W. (2015b). Business process as a

service: Model based business and it cloud alignment

as a cloud offering. In Enterprise Systems (ES), 2015

International Conference on, pages 121–130. IEEE.

CLOSER 2017 - 7th International Conference on Cloud Computing and Services Science

746