Cloud Business Process Management means more than moving of a Process Editor and an Execution Engine into a Cloud infrastructure. Although it is possible to use IaaS or PaaS to operate a BPM infrastructure in the Cloud, virtualization of these servers does not give a big advantage over classic IT management. Hence, in the following we focus on SaaS based solutions.
CBPM should focus on creating (modeling) and using Processes rather than implementingand operating the services. Therefore, we see a clear separation of duties between the two stakeholders involved:
• The Cloud operator is responsible for running and maintaining the Business Process environment in the Cloud together with the connected SOA9services. This includes setting up new or updating existing services and applications. • The (Cloud)customerof CBPM designs, tests and uses their Business Processes
orchestrating the selected Cloud services.
As a consequence from this separation of duties, privileged accounts for the underlying operating systems, databases and so on are not issued to the Cloud customer. Even the execution of foreign or uncertified code by the Cloud operator
may be legally problematic and dangerous. Uncertified code provided by the cus- tomer could harm the system health of the Cloud infrastructure or contain vul- nerabilities of any kind. Thus a Business Process designed and used in the Cloud may only consist of predefined and by the Cloud operator certified building blocks. Designing a Business Process goes through some development steps, well known from software development techniques (cf. Fig. 1). In the beginning a Process is typically designedin a graphical notation. This step is iteratively per- formed and can be accompanied by internal simulation phases, which help the designer evaluating his newly created or altered Process model. The design phase is usually followed by a test phase. During the test phase a Process model can be executed. If necessary the Process model and depending artifactsfirst have to be deployed. In most Execution environments the deployment of new Process models is simply based on XML files. More complex is the preparation of all services referenced by a Process model. If a service hasn’t been used by a Process model before, it must be installed and configured before usage. Often the Process model has to be updated to reflect the current IP or URL of the newly deployed service. An execution of a Process in the test phase must be clearly marked preventing misinterpretations of Process data and incoming or outgoing signals to external systems. Any error found while testing may lead to another design phase. After a successful test phase the Process changes to theproductivephase and can be used as desired. Any errors found in the productive phase will also lead to a new design phase. At the end of its lifetime a Process model isundeployed, saving computing resources and preventing the creation of new Process instances.10 The physical
Fig. 1 Business Process Lifecycle
undeployment of a Process model usually has to wait until all running Process instances have been completed. Through the agility of this method a newer version of a Process model may be deployed, tested or live executed, even while the predecessor version is still in operation. Therefore Business Process Management needs a built in Version management for Process models.
Additional support is required from a Process’s services and applications in different phases of the Business Process Lifecycle. Typically for testing purposes special test instances of applications are used to distinguish between productive and test data. Demanding a cost reduction in the Cloud, this duplication of systems is undesirable. A better way is to find a way to mark Process instances and corre- sponding data as test data using only one service instance during test and productive phases. This allows also merging test and productive execution at the same time.
With the lack of privileged accounts for the Cloud customer the Execution environment and Process services have to support the monitoring of a Process execution. This monitoring is needed in the test phase to make sure everything works as desired. During the productive phase the monitoring is required to analyze any problems which might occur during Process execution. While a broken Process instance may be ignored during a test phase, in productive mode the Cloud cus- tomer has to deal with these instances. For the handling of broken Process instances a specialized repair function must be provided by the Cloud environment. With the help of these functions corrupted data must be updated and a Process execution is reset into a prepared state so that the execution can be continued.
Another challenge in CBPM is to connect the Cloud environment with external systems. Only considering Cloud based systems will narrow the application area. Especially in the Logistics domain a lot of physical hardware outside the Cloud has to be included into a Business Process. Starting from barcode scanning and printing, a Cloud process must communicate with external Enterprise Resource Planning tools or Warehouse Management Systems. A specialized Gateway has to deal with incoming and outgoing messages and data, assigning incoming data to the corresponding Cloud customer and Process instance.
We can summarize the key challenges of CBPM as follows:
• Elasticity and SaaS: this outlines the Cloud Computing aspect of CBPM (“just use”metaphor extended to processes and connected services).
• Executability of building blocks: CBPM assembles only executable and certified building blocks. These building blocks especially support the different Business Process Lifecycle phases with monitoring and repair functionalities.
• Compatibility: the compatibility of data exchanged by building blocks must be guaranteed.
• Connectivity: with the help of a Cloud gateway [7] the communication to the outside world can be established. The Gateway configuration is a part of the Process definition.