Business Process Flexibility in process modelling foundation:

The quest for flexibility can be regarded as the main driving force behind
business process management, both at an organizational level, where strategic
business processes are investigated, and at an operational level, where
human interaction workflows and system workflows are important concepts
for realizing business processes.
According to Wikipedia, flexibility refers to the �ability to easily bend
object or the ability to adapt to different circumstances.�
In todays dynamic market environments, �different circumstances�
induced by changes in the market environment of the company. Business processes
are objects that need to adapt easily to changes. Since products that
companies provide to the market are generated by business processes, flexible
business processes are an important asset for coping with market changes
an effective manner.Different aspects have to be taken into account when considering flexibility.
First of all, flexibility is provided by explicit representation of business
processes, because adaptations of explicit, graphically specified business processes
is much easier than adaptation of written organizational procedures or
business policies buried in software code.Enactment platforms, such as workflow management systems, provide
powerful mechanisms for enacting business processes in diverse technical and
organizational environments. One area specific to human interaction workflows
is the assignment of knowledge workers to process activities.In typical workflow environments, such as system workflows and human
interaction workflows, information systems are required for enacting workflow
activities. The interfaces to these systems might be hardcoded in the adapters
of the workflow management system. In dynamic software landscapes, where
functionality is provided through standardized interfaces, the ability to change
the binding of particular software to workflow activities is another source of
flexibility.

Organizational Modelling in business process:

The modelling of organizational aspects also provides flexibility in business
process management. In this section, role resolution in an intra-company setting
is discussed, in which different approaches are investigated to associate
knowledge workers with business process activities.
In the case of human interaction workflows, the enactment environment of
the business process has to take into account the organizational structure of
the company that runs the business process. Flexibility in organizational modelling
is achieved by assigning roles to process activities, and not to specific
individuals.
By associating roles with activity models at design time and mapping roles
to personnel that is skilled, competent, and available to perform the activity
at run time, flexibility is improved, because changes in the personnel structure
of the organization do not affect the business processes.For instance, absent knowledge workers are not with associated with specific
activity instances, as are persons who are currently available. Thereby, the dynamic aspect in the organization�knowledge workers might be temporarily
absent or there might be changes in the work force�can be represented
at the model level. Consequently, changes in the personnel are hidden from
the process, as long as the roles defined in the model can actually be filled by
persons in the organization.
A subset of these activities is assigned the same role. In the example,
a clerk is responsible for the first three activities, whereas the clerk�s boss
finally decides and submits the decision. This situation can be represented in
a business process model by associating the role Clerk and the role Boss with
their respective activities.
While this role resolution is correct from a formal point of view, this situation
is undesirable in most cases because each clerk needs to understand the
context of the case, which leads to longer process durations and potentially
incorrect decisions.
In the example, the handover of work from Peter to Charles and from
Charles to Anne leads to delays in process executions and should therefore
be avoided. In addition, Charles needs to get familiar with the case entered
by Peter, and Anne needs to get familiar with the case that Charles analyzed
beforehand.

Explicit Process Representations in modelling foundation:

Business process management systems are created to narrow the gap between
business goals and their realization by means of information technology. The
main way to provide this flexibility is based on explicit representations of
business processes at different levels. While organizational business processes
have a coarse-grained structure and are typically specified textually by forms,
operational business processes consist of process activities, and execution constraints
that relate them.Explicit process representations provide flexibility, since changes to the
current process can be discussed and agreed upon by the different stakeholders
involved in the design of the business process. In this context, flexibility isThis process features a sequence of activities, where the first activity
to store the order is preceded by a start event. After the order is stored,
the inventory is checked. This version of the business process rules that the
shipment is prepared only after the invoice is sent and the funds are received.
Finally, the goods are shipped and the process terminates.Due to the somewhat cautious policy realized by the business process�
prepare shipment only after receiving the funds�business process instances
based on this process model might suffer from long processing times, resulting
in insufficient customer satisfaction.
In order to solve this problem, the process owner starts a review of this
business process by inviting process participants and process consultants to
a joint workshop. The business process model is used as a communication
platform for these stakeholders at this workshop.
Discussing the problem of the process instances, the stakeholders find out
that concurrency can be exploited within the process. If activities can be
executed concurrently, their order of execution is irrelevant. For instance, the
preparation of the invoice can be started before the shipment is handled.Although in this example the deficits of the business process are obvious,
the improvement of the process by introducing concurrency shows quite well
how an explicit process model can foster response to change.
The translation of the business process model to the actual operational
environment can be realized in different ways. If the business process is realized
by a human interaction workflow, then the modified business process
model needs to be deployed in the workflow management system. Deployment
typically includes enrichment of the business process model with information
to make the process executable.
In particular, there needs to be a translation from the graphical model to
an executable format that is specified in a particular workflow language or�
in case the system workflow is realized in a service-oriented environment�in a service composition language. In any of these realizations, the explicit
representation of business process models provides the flexibility to change
the process and to finally enact the modified process.
New process instances would then follow the new, improved business
process model. If, on the other hand, business processes are enacted without
any system support, then the business process model is translated manually
to a consistent set of procedures and policies that the knowledge workers need
to follow.

Standardized Software Interfaces in modelling business process:

Standardized interfaces to existing software systems are another means of
flexibility in business process management. A variety of techniques to specify
software interfaces are known from software engineering and software architectures.
It is a key concept to decouple the use of a software component from its
implementation, i.e., to hide implementation details from usage information,
following the information hiding principle.
In the context of business process management, standardized software interfaces
are of crucial importance in system workflows, and also in human
interaction workflows, since the overall process structure can be decoupled
from the implementation of particular activities realized by software components.
A flexible association of process activities with software systems allows us
to change the implementation of specific process activities without changing
the overall business process. There are two variations: the software system
realizing a particular activity can be defined at design time of the process or at
run time of the process instances.
In the original implementation, an inventory
management system is used to realize the Check Inventory activity, and an
order management system is used to realize the Store Order and the Prepare
Invoice activity.
We assume that an ERP system is deployed to provide the functionality
of the order management system and of the inventory management system in
an integrated, robust, and scalable manner.
By standardized software interfaces, the business process activities can use
the functionality of the new system without changing the business process.
This enhances the flexibility of the business process implementation, because
the realization of particular process activities can be changed without modifying
the business process.
This discussion describes an ideal setting, in which activity realizations
can easily be exchanged. However, specific properties of legacy systems make
the definition of clean, standardized interfaces cumbersome, because legacy
systems offer their functionality typically by proprietary and often not well
documented interfaces.
discussed in Chapter 2.
In addition, the granularity with which legacy systems provide functionality
often does not match the granularity required by the business process. In
particular, legacy systems often realize complex subprocesses rather than individual
activities in a business process. Sometimes, the processes realized by
legacy systems and the modelled business processes are not immediately comparable.
These issues have to be taken into account when software interfaces
to existing information systems are developed.
One option to solving this problem is developing software interfaces that
make available the functionality provided by legacy systems with a granularity
that allows reuse of functionality at a finer level of granularity. The granularity
should match the granularity required at the business process level.
Depending on the legacy system, its complexity, software architecture,
and documentation, as well as the availability of knowledgeable personnel,
the required effort can be very high. If the need for finer-grained granularity
and efficient reuse of functionality is sufficiently high, then partial or complete
reimplementation can be an optio

Selection of Business Partners in Process Choreographies:

The modelling of organizational aspects in business process management
can be extended to business partners, which is important in the context of
business-to-business processes.
Consider a business process choreography with multiple business partners,
each of which plays a specific role in the choreography. If there is a role Shipper
specified according to the requirements for shipping goods, it can be bound to
specific enterprises that can perform the work. Additional flexibility is gained
because the organizations participating in a choreography are not hardwired,
but represented at the model level.
There are different options for selecting a particular shipper. The selection
can be done before a particular process instance starts. This alternative is
useful if sufficient information on the goods to be shipped is available before
the process starts.
In scenarios where only during run time of the process instance are the
goods and the sender and receiver determined, the dynamic selection of a
shipper is useful. Based on the information on the shipment and on its additional
properties�such as dangerous goods�an appropriate shipper can be
selected at run time.
Before the process choreography can be realized, the broker requires information
on the suppliers available. This information is gathered by the broker in a
separate process choreography, whose message flow is not shown in the figure.
The process choreography starts with the creating of an order by the customer.
Then, the customer sends a Request Supplier Info message to the broker.
The broker receives this message and uses local information to find the
supplier most suitable for fulfilling the order. In the Send Supplier Info message,
the broker informs the customer about this supplier.
The customer receives this message and uses the information received to
send an order to the selected supplier, Supplier-A in this case. When the
supplier has processed the order, the supplier sends the goods to the customer,
and the process completes.
In the example shown, the selection is performed using a third party, the
broker. While this is a valid option in scenarios where a broker has rich information
on a set of business partners, the selection can also be done locally,
i.e., without the involvement of a third party.
In this case, the actual selection can be performed as a manual activity,
using information on suppliers available and capable of fulfilling the order.
Role resolution in this case is not performed by the business process management
system, but by a knowledge worker. This task also matches the
service-oriented approach, where a service requestor (the knowledge worker)
uses the broker to select from among a set of services (supplier services) the
one that is suited best for the task at hand.

Event-driven Process Chains:

Event-driven process chains are an important notation to model the domain
aspects of business processes. The main focus of this rather informal notation
is on representing domain concepts and processes rather than their formal
aspects or their technical realization. Event-driven process chains are part
of a holistic modelling approach, called the ARIS framework; ARIS stands
for Architecture of Integrated Information Systems, and it was developed by
August-Wilhelm Scheer.
This approach is often denoted as the ARIS house with three pillars and
a roof, as shown in Figure 4.32. The pillars reflect data, control and function,
while the roof reflects the overall organization. In each area, three levels of
abstraction are identified: a concept level, an architecture level, and an implementation
level, characterized by the terms Requirements Definition, Design
Specification, and Implementation Description, respectively.
The concept level is the highest level of abstraction in which data, control
and function are modelled. This level looks at nontechnical requirements of
business processes and their execution environment. Business goals and functions
are typical artefacts in the function view at this level.
The main views are as follows.
� Functional View: The functional view represents the goals and subgoals of
the enterprise and their relationships. In general, one subgoal might contribute
to a number of goals at the higher level. For instance, the subgoal
�reduce business process execution time� contributes to the goals �increase
customer satisfaction� and �reduce overall cost.�
At a lower level of abstraction, each subgoal is associated with a set of
functions that contribute to goals and subgoals. Functions are then hierarchically
decomposed until the desired granularity of functions is achieved,
similarly to functional decomposition in value chains.
� Organizational View: The organizational view describes the organizational
structure of an enterprise at a type level and at an instance level. There
are detailed specifications of organizational entities, including their relationships
and positions, roles, skills, and individuals associated with them.
Administration information such as the address of an organizational entity
can be represented. The organizational view also includes organizational
aspects of information technology of the enterprise, including its main
operational information systems, its storage facilities, and its network infrastructure.
� Data View: The data view characterizes business relevant data objects that
are manipulated by functions during business process execution. Entity
Relationship diagrams are used for data modelling.
� Business Value View or Output View: The business value view describes
the outcome of business processes, i.e., the products and services the enterprise
generates. These can be physical goods like automobiles or electronic
devices, as well as intangible goods, such as a processed order or a flight
booking.

Architecture of Process Execution Environments:

business process
management system capable of controlling the enactment of business processes
based on business process models;

The architecture
model contains the Business Process Environment, a Business Process Modelling
subsystem, a Business Process Model Repository, a Process Engine, and
a set of Service Providers. The roles of these constituents of the architecture
model are characterized as follows.
� Business Process Modelling: The business process modelling subsystem
is used for creating business process models, containing information on
activities, their operations, and the structure of the business process. This
architecture subsystem can be realized by business process modelling tools.
� Business Process Environment: The business process environment triggers
the instantiation and enactment of process instances based on process
models.
� Business Process Model Repository: The business process model repository
holds business process models that are created by the business process
modelling component.
� Process Engine: The process engine is responsible for instantiating and
controlling the execution of business processes. It is the core component
of a business process management system. This component is triggered by
the business process environment. It uses process models to instantiate and
control the enactment of process instances. To execute a particular activity
instance, it calls entities that act as providers of the required functionality.
In a service-oriented architecture, service providers are called to execute
individual services that realize business process activities.
� Service Providers: Service providers host application services that realize
business process activities. In the architecture model, service providers
represent an abstract entity that subsumes not only Web service providers
but also knowledge workers that realize particular activities in business
processes. The organizational and technical information that the process
engine needs in order to determine and access the service provider is also
stored in the business process model repository.These components of the architectural model control the enactment of process
instances. To capture the distributed nature of business process executions,
the components and the service providers are represented by agents that communicate
by sending and receiving messages, i.e., the agents do not share
memory, but are distributed.Gateways are nodes in a process model that are used to guide the process
flow. Therefore, for each gateway node the process engine needs to perform
some action. This work that the process engine conducts is represented by
a gateway instance, just as the work defined by an activity model is represented
by an activity instance. A property of gateway instances is that the
process engine executes them, whereas activity instances are executed by service
providers, requiring nonlocal communication.
As will be detailed in the next chapter for more complex workflow patterns,
control flow patterns restrict the ordering of execution events for activities
involved in a business process. For instance, an AnalyzeOrder activity can
only be started after the initial event has occurred, and a SimpleCheck activity
can only be started after the exclusive or gateway has completed, and so on.
The execution semantics of a process instance based on a process model is
described by restrictions on the events and their ordering during the execution
of process instances.

Process Choreography Design in choregraphies:

The design of process choreographies involves a series of activities. In each
of these activities, artefacts are developed. These activities are described as
follows:
1. High-level Structure Design: In high-level choreography design, the participant
roles as well as their communication structures are identified. High

level structure design is conducted during the Participant identification
phase.
2. High-level Behavioural Design: High-level behavioural models specify the
milestones of the collaboration and the order in which the milestones
are reached. High-level behavioural design is done during the milestone
definition phase.
3. Collaboration Scenarios: High-level choreographies are refined by introducing
dedicated collaboration scenarios that relate the reaching of milestones
to the communication between process participants. Collaboration
scenarios are developed during the choreography definition phase, based
on the scenarios informally specified during scenario modelling.
4. Behavioural Interfaces: From these collaboration scenarios, for each participant
role, a behavioural interface is derived.
High-Level Design
High-level process choreography design involves structure design and behaviour
design. In high-level structure design, participant roles of the choreography
are defined, as part of the participant identification phase. Figure 5.5
shows a high-level structure diagram for participants involved in a bidding
scenario. This diagram identifies a seller, an auctioning service, and multiple
bidders as participants. It also shows that these participants are pairwise interconnected.
Therefore, any participant can interact directly with any other.
High-level behaviour design uses milestones that are achieved during the
collaboration; it is therefore part of the milestone definition phase. Each milestone
represents a state in the overall collaboration that has a business meaning,
represented by some business value. Milestones correspond to subgoals
reached during the collaboration on the way to reaching its ultimate goal.
For instance, the ultimate goal in the bidding scenario is that the offered
goods are sold, paid for, and delivered to the bidder with the highest bid. Several
intermediate steps can be distinguished: the initial setup of the auction,
the entry of potential bidders into the auction, the actual bidding process,
and the delivery and payment.

Business Process Modeling Notation:

In this section, the Business Process Modeling Notation (BPMN), developed
under the coordination of the Object Management Group, is introduced. The
focus of this section is not a complete presentation of the standard, but a
discussion of the main concepts of business process diagrams expressed in the
Business Process Modeling Notation.
The intent of the Business Process Modeling Notation in business process
modelling is very similar to the intent of the Unified Modeling Language for
object-oriented design and analysis. To identify the best practices of existing
approaches and to combine them into a new, generally accepted language.
The set of ancestors of BPMN include not only graph-based and Petri-netbased
process modelling languages, but also UML activity diagrams and eventdriven
process chains.
While these modelling languages focus on different levels of abstraction,
ranging from a business level to a more technical level, the Business Process
Modeling Notation aims at supporting the complete range of abstraction levels,
including business levels and software technology levels. This goal is also
laid out in the standards document, which states, �The primary goal of BPMN
is to provide a notation that is readily understandable by all business users,
from the business analysts that create the initial drafts of the processes, to
the technical developers responsible for implementing the technology that will
perform those processes, and finally, to the business people who will manage
and monitor those processes.�

Process Choreography Implementation:

After discussing the design of process choreographies, this section looks at the
implementation of choreographies. Behavioural interfaces serve as blueprints
for the internal realization of process orchestrations, because each process orchestration
needs to expose an externally visible behaviour that was specified
as the behavioural interface of the respective participant.
Assume that there is a set of behavioural interfaces compatible with each
other. These interfaces can now be refined to local process orchestrations. In
local process orchestrations, activities can be added or, in some cases, even
reordered, while the observable behaviour has to be preserved.
The relationship between the behavioural interface and the local process
orchestration needs to be investigated, so that the correctness of the overall
collaboration can be achieved. Each local process orchestration needs to be
consistent with the respective behavioural interface definition. This section
will introduce consistency criteria using a business-to-business collaboration
scenario the supplier to the buyer.
As in the example discussed above, the auction is not public, so that
only registered parties can participate. Therefore, suppliers need to request
permission to participate in the auction beforehand. Once the auction has
started, suppliers can place their bids. When the auction completes, the buyer
selects a supplier according to the lowest bid or according to some other
evaluation criterion. Finally, the goods are shipped and payment is processed.
In this sample scenario, there are two alternatives for selecting a shipper:
either the selected supplier determines the shipper that would deliver the
goods to the buyer, or the supplier provides a list of shippers with different
transportation costs and quality levels, from which the buyer can choose a
shipper.
Each participant role can be potentially played by several process participants.
Each of these process participants develops a process orchestration.
These process orchestrations need to be consistent with the behavioural interface
of the participant role. For instance, the process orchestration of supplier
Su1 needs to be consistent with the behavioural interface (or with the behavioural
interfaces) of the Supplier role.
Using consistency rules, each participant can check locally whether its local
business process orchestration fits its behavioural interface. If the behavioural
interfaces are compatible with each other and if, in addition, for each
participant, the internal business process orchestration is consistent with its
behavioural interface, then a successful collaboration between the process participants
is realized�additional checks involving the internal business process
orchestrations of the participants are then not required.
The behavioural interface of a participant role leaves room for multiple
process orchestrations, i.e., there are multiple process orchestrations consistent
with a given behavioural interface.

Service Interaction Patterns in business process:

choreographies are based on message exchange, and potentially many
participants interact in a choreography, while orchestrations are based on
control flow between the activities of a single process performed by a single
organization.
Service interaction patterns aim at filling this gap by proposing small granular
types of interactions that can be combined to process choreographies. As
with control flow patterns for process orchestrations, service interaction patterns
can also be used to benchmark languages for their ability to express
advanced conversations. Service interaction patterns can be classified according
to the following schemes.
� Number of participants involved: Bilateral interactions involve two participants,
whereas multilateral interactions involve more than two participants.
� Number of messages exchanged: Single transmission versus multi-transmission
interactions.
� Variations in message receiver : In case of two-way interactions, round-trip
interaction means that the receiver of the message is necessarily the same
as the sender, whereas routed interaction means that the receiver of the
message in general differs from the sender.
The Business Process Modeling Notation is used to provide graphical representations
of service interaction patterns. Since this notation is not specifically
tailored to the needs of service interaction patterns, the graphical representations
of the patterns are not complete. Together with the textual representation
of the patterns, the service interaction patterns are described properly.
Send
The send pattern represents a one-way interaction between two participants
seen from the perspective of the sender. There are different flavours of this
pattern, considering, for instance, the moment when the sender selects the
receiver: The receiver is known either at design time of the choreography or
only during the execution of a conversation.
Receive
The receive pattern also describes a one-way interaction between two participants,
but this time seen from the perspective of the receiver. In terms of
message buffering behaviour of the receiver, two cases can be distinguished.
Messages that are not expected are either discarded or stored until a later
point in time, when they can be consumed.
In the example shown in Figure 5.19 the facility management department
of a company receives a notification that the heating system in a building
does not work properly. The receipt of the message is represented by a start
message event. On occurrence of this event, a process orchestration is started
in the facility management that checks the heating system and tries to find
the source of the problem.
Send/Receive
In the send/receive pattern, a participant sends a request to another participant
who then returns a response message. Both messages belong to the same conversation. Since there could be several send/receive interaction instances
happening in parallel, corresponding requests and responses need to
be correlated.

Basic Control Flow Relating Interactions:

the basic execution constraints between

elementary interactions
are discussed.
As seen in the milestone example, a precedes

relationship between two
interactions means that an instance of the

target interaction can occur only
if the instance of the source interaction has

already occurred. If in a logistics
environment a delivery acknowledgment message

should be sent only after a
delivery notification has been received, a

precedes relationship between the
respective elementary interactions can be used

to represent this business rule.
An inhibits relationship indicates that an

instance of the target interaction
can occur only if no instance of the source

interaction has occurred yet. In
an example involving an order process, an

invoice should not be sent after an
order cancellation by the buyer has been

received.
Also, scenarios where two interactions inhibit

each other, i.e., an instance
where either one or the other interaction can

complete, are very common.
Consider, for instance, a travel agency that

either receives a confirmation
message from the customer or a cancellation

message from the airline. To
cater to these situations, a specific

notational element for vice-versa-inhibits
is introduced.
A weak precedes relationship means that an

instance of the target interaction
can occur only after the instance of the

source interaction has already
completed or was skipped. Imagine a project

management scenario where the
project leader expects status updates from a

subcontractor that are merged
into a status report for the employer.

However, in special cases the project
leader and the subcontractors can agree that

no status update is needed.
The lifecycle of interaction instances is

shown in Figure 5.37. Interaction
instances can be in the states initialized,

enabled, completed, and skipped. An
interaction instance becomes skipped if any of

the inhibiting instances has
completed.
An interaction instance becomes enabled if

there are no precedes or weak
precedes relationships targeting the

corresponding interaction or all preceding
instances are completed and all weakly

preceding instances have been
completed or were skipped.
An instance must execute, i.e., the actual

message exchange occurs, only
if it is enabled. After the message exchange,

the instance is in the completed
state. The conversation starts with the Seller

sending an Auction creation request
message to the Auctioning service. The

precedes relationship defines that, if
this message arrived, an Account creation

request message can be sent to the
Seller. Then, the Seller sends a Registration

info message to the Auctioning
service, which responds with an Registration

confirmation message.
The weak precedes relationship connecting the

last elementary interactions
defines that the Auctioning service can send

an Auction creation confirmation
to the Seller if it has either sent a

Registration confirmation message before or if

the sending of that message was skipped. The

latter is used to cater to
situations in which a Seller is already

registered at the Auctioning service.

Properties of Business Processes:

The investigation of properties of business

process models is an important
aspect of business process management. If a

certain property at the business
process model level can be shown, then all

process instances based on
that business process model expose this

property. In this chapter, the most
important properties for process models are

introduced and related to each
other.
While structural dependencies of processes are

important, dependencies
related to data processed during business

processes should be taken care of.
Structural properties of process models are at

the centre of attention; these
properties are neither application specific

nor domain specific. Conceptually,
the situation is similar to normalization in

database theory. If all tables in
a relational database schema are, for

instance, in third normal form, then
certain anomalies can no longer occur during

the run time of the database
applications.
Structural properties of business processes

have been investigated in the
context of Petri nets.
While soundness is an important criterion, it

appears to be too strong for
particular settings. Consequently, relaxed

soundness and weak soundness have
been introduced as less rigid properties that

are still helpful in analyzing business
process models.

Advanced Control Flow Relating Interactions;

In addition to the basic control flow

constructs, there are advanced control
flow constructs in Let�s Dance. Several

interactions can belong to a composite
interaction. None of the contained interaction

instances can become enabled
before the enclosing composite interaction

instance has become enabled, and
the composite interaction instance can only

complete after all contained interaction
instances have completed or been skipped.
Interactions can also be guarded, meaning that

at the moment an interaction
instance could become enabled, a guard

condition must be fulfilled. If this
condition is not fulfilled, the instance is

skipped. Finally, repetitions and parallel
branching with an unbounded number of branches

are modelled through
repeated interactions. There are four types of

repeated interactions, similar
to those in programming languages: while,

repeat, for each (sequential), and
for each (concurrent).
�For each� repetitions have an expression

attached that determines a collection
over which the repetition is performed. The

knowledge about how
many instances are to be created for this

interaction might be available at
design time or might be known only at run

time.
Repetitions can have stop conditions attached

to them. For instance, a
repeated receive interaction should be stopped

as soon as answers from ten
participants have arrived.
The expressions attached to guarded and

repeated interactions can be
written in plain English, as Let�s Dance is

not tied to any specific expression
language. However, it must be defined which

actor is going to check whether
a condition evaluates to true or which

collection results from a repetition
expression. This desired semantics of the

process choreography is expressed through
the inhibits relationship from the Order

Response interaction to the Cancel Order

interaction. If a cancellation is issued by

the buyer on time, the supplier
can decide whether it can still be cancelled

or not.
If cancellation is still possible, the

remaining order responses are skipped
and the buyer does not need to pay. In the

case where cancellation is not
possible, a corresponding rejection notice is

sent to the buyer and the buyer
has to pay for the order. The buyer notifies

the supplier through a payment
notice.

Advanced Service Composition:

So far, business process activities have been

described by simple terms. What
is actually meant by these terms, like

AnalzyeOrder, is determined by the
reader. The intention of the terms used by the

process designer and the semantics
associated with these terms by the process

participants is, hopefully,
similar.
To improve the understanding of business

process diagrams at a nontechnical
level, textual explanations are associated

with business process models,
expressed in, for instance, event-driven

process chains. In case there are
ambiguities in a process model or certain

process parts are not clear, the
process participant can ask the process

designer about the intended meaning.
The process designer will explain the

rationale, and the process participant
will comprehend. In some cases, these

discussions might lead to a refinement
of the process model, since the process

participant might have identified an
unclear and ambiguous part in the process

model.
In this book we are very much interested in

business processes that are
enacted in software. Services can only be

composed in a correct way, if they
operate on the same domain concepts. For

instance, a service that returns
customer data can be combined with a service

that takes customer data as
input. In this case, they both operate on the

same domain concept, i.e., the
customer.
As discussed in Section 7.3, WSDL provides a

syntactic interface description
language, detailling the data types of input

and output parameters. Since
the Web services that contribute to a service

composition have most likely
been developed independently of each other,

the data types of these services
will, in most cases, not match.
Typically, these syntactic differences are

identified and the resulting problems
are solved by system architects and software

developers, using, for instance,
data mapping techniques. If compositions

involving many services need
to be developed, considerable overhead can be

expected due to heterogeneous
data types used by the Web services.
A simple example shows that syntactic

integration is not sufficient for
integrating services with each other. We

assume that a certain product needs
to be purchased and that there are two

services that return the price of the
product. Assume also that the product can be

identified by a unique product
identifier.
A price-finding application invokes the

services with the identifier of the
desired product. Both services return values.

Assume the textual descriptions
of these services indicate that the services

return the price in euros. Note that
this information about the currency is not

available from the return parameter
price of the service in WSDL file.
Even parameter names like europrice do not

help much, since the user of
the service cannot be sure that the price is

really in the euros currency.
There might be additional semantic differences

in the data returned by
services. Assume that one service returns 120

and the other service returns
118. Since the concept of price is not agreed

upon by the providers of the
services, the following issue might occur. The

price 120 includes value-added
tax, VAT, while the price 118 does not.
As a result, the price that appears to be

lower turns out to be higher
because it does not include VAT. Due to the

different semantics of the return
parameters, the price-finding application

returns a wrong result. This problem
is due to the missing semantics comparability

of the two services. Since at a
software layer there are few options for

asking the service provider about the
exact semantics of their services�as at the

application process level�this is
a severe problem.

Data Dependencies in Properties of Business Processes:

Application data are an integral part of

business processes. Data can be created,
modified, and deleted during the execution of

business processes. Since
business processes consist of a set of

activities that are related, these activities
operate on an integrated set of application

data.
Data in business process models has two

aspects, both of which need to
be covered:
� Data that activity instances manipulate by

invoking applications or services.
� Data dependencies between process

activities.
The former issue is dealt with in the

operations subdomain. In service-oriented
systems architectures, for instance, the

parameters of service invocations are
specified, so that data can be communicated

correctly with software systems
at run time.
At the process level, data dependencies

between process activities is typically
described by data flow. An example of data

flow in a business process in
the financial sector is given. A credit

approval business process contains activities
to enter a credit request, to assess the risks

of granting the credit, and
to inform the customer about the decision made

by the financial institution.
The activities of this process model operate

on case data, in particular,
the credit request. The credit request can be

represented by a record data
type with fields for the name and address of

the credit requester, the amount
requested, and other information, such as the

risk related to granting the
credit.
There are data dependencies between the

activities mentioned. The Collect
Credit Info activity is the first activity

performed. Only when this data
is available, can the risk be assessed in the

Assess Risk activity, the final
decision be made(Decide), and the requestor be

notified (Notify). Therefore,
the ordering of the activities in the business

process is strongly related to the
data dependencies of the activities.
The process model is illustrated in Figure

6.1, using a graph-based process
language that explicitly represents input and

output parameters of activities
This diagram shows that data dependencies have

implications on the ordering
of activities in the process: the Assess Risk

activity can be started only
when the credit information is available.

Since this data object is provided as
output parameter CreditInfo of the Collect

Credit Info activity, this activity
needs to complete before the risk can be

assessed, implying an ordering
between these activities.
These considerations hold only if it is

assumed that an activity instance
requires its input parameters at the start. If

this constraint is relaxed and
input parameters can be consumed after an

activity instance has started,
then in a process with a data flow A ! B, B

can actually start before A
terminates. At some point�when the input

values are required�B needs to
wait for A to deliver the required data.
This assumption can also be relaxed at the

producer side of data. If we
allow activities to generate data while they

are running, then the generated
data can be taken by the follow-up activity,

so that activities can execute
concurrently, realizing a data value stream

between them.
While most workflow management systems assume

that input data is available
up front and that only on completion, does an

activity instance write
output data values, some approaches, for

instance, the BPMN, relax this assumption.
The use of data dependencies for process

enactment control will be discussed
in more detail in the context of case handling

in Section 7.5, where
data dependencies�and not the process

structures�are the driving force for
process control.

Preconditions and Postconditions:

Mapping of heterogeneous data is important in

any enterprise application
middleware. It provides the technical basis

for integrating services with each
other, so that the results returned by one

service can be used by follow-up
services.
The next level addresses the questions, about

under what conditions a
certain activity can be executed, and what the

result of an activity execution
is, i.e., preconditions and postconditions of

activities. Interestingly, in business
process modelling, preconditions and

postconditions are already captured. In
event-driven process chains, for instance,

preconditions and postconditions are
represented by events, although in a

relatively informal fashion.
For example, if the arrival of an order

message triggers an activity to
store the order, then an event order arrived

is connected by control flow to
a function store order. The outgoing edge of

this function is connected to an
event order is stored. The order arrived event

characterizes the precondition
of the function, This type of informally

specified precondition and postcondition of a

function
in a business process is suitable for

fostering the understanding of process
models by human stakeholders. To be usable for

composing services realized
by software, the preconditions and

postconditions need to be specified in a
more precise way.

Ontologies and Data Mappings:

Semantic service specifications are required

that are based on domain ontologies.
Domain ontologies can be considered to be data

models that all process
participants have agreed upon. Ontologies in

computer science are characterized
as data models that represent a set of

concepts within a domain and the
relationships between those concepts.
A domain ontology is always associated with a

set of stakeholders, who
need to agree on the domain ontology. An

ontology has been described in
Gruber (1993) as an explicit specification of

a conceptualization The domain ontology shown

can be used to integrate services provided
by software systems. In an enterprise

application integration scenario, typical
systems to integrate are customer relationship

management systems, or CRM
systems, and enterprise resource planning

systems, or ERP systems. For instance,
the full name data field of the customer

relationship management system is
mapped to the Name concept in the domain

ontology. Since the street address
is stored in two fields of the enterprise

resource planning system data structure,
the field Strasse is mapped to StName, and

Hausnummer is mapped to
the Number concept of the ontology.
If the data fields of the application systems

are mapped to the domain
ontology, then a mapping of the data can be

achieved automatically at run
time. Assume that there is a service of the

customer relationship management
system that returns a parameter of data type

Cust 234. This data can be fed
into a service that takes a parameter of data

type Adr32 if the appropriate
data mapping is performed.If there is a domain

ontology in place and the data structures of

the systems
are mapped to the domain ontology, then this

data mapping can be
performed automatically.

Static and Dynamic Service Binding;

The dynamic discovery of services is

illustrated by a set of examples in the
context of a composite application in the

travel domain. The travel application
allows customers to select trips, make

reservations, and confirm reservations by
providing credit card information. In order to

allow this, the travel application
invokes a credit card withdrawal service

provided by a bank.
This example is used to explain different

types of service matchmaking
and service binding, namely static binding and

dynamic binding; service composition
based on semantics will be discussed

afterwards.
In static binding, the service is bound to the

application at development
time. In the travel application example shown

in Figure 7.16, the service
invocation in the travel application is

represented by a rounded rectangle
marked CCW for credit card.
There are three service providers that have

implemented a credit card
withdrawal service, all of which can be used

by the travel application. These
providers are BankA, BankB, and BankC,

representing any institutions that
provide such a service. (The services provided

by the organizations are depicted
by small circles, as with interfaces in UML.)
The question that developers face now is which

of the three implementations
of the credit card withdrawal service should

they decide to use? And
when should this decision be made? The former

question is subject to existing
legal contracts between the organizations

involved as well as to costs associated
with using a particular credit card withdrawal

service implementation.
The latter question can be reformulated to the

question about when to bind
the credit card withdrawal service

specification to the service implementation.
In a static binding, the external service

implementation is bound to the
travel application at development time. This

means that the use of the credit
card withdrawal service by BankB is hardcoded

in the travel application.
Today�s Web services technologies provide

valuable information for coding
this integration. Service specifications in

the Web Services Description Language
provide the information on how a particular

service is invoked. Based
on the textual and technical description of

the service, the developer of the
travel application can provide the mapping of

the internal variables to the
data that the external service requires.
Ambiguities in service description are

effectively resolved by the programmer
of the travel application by the designing of

an interface to the external service. This

type of static binding is appropriate in

environments where the
service landscape is relatively static.

Advanced Service Composition by Example in business management architectures:

This section introduces advanced service

composition by an example. Our example
is from the call centre domain, where phone

calls by customers come in
and call centre agents serve these calls using

software systems, in particular, an
enterprise resource planning system and a

customer relationship management
system. These systems realize services that

make up a service composition
used by the call centre agents.
The scenario is described as follows. In a

call centre environment a customer
calls to request certain information. Using

the phone number of the incoming call, the

customer relationship management system gets

hold of the
customer address. This address information

is�after suitable data mapping
is performed�fed to the enterprise resource

planning system that provides
information on the customer calling the call

centre agent. This domain ontology allows us

to specify a service having a phone number
as input and an address as output, so that the

contact information returned is
not just any contact information, but the

contact information for the customer
with the specified phone number.
This information is required for a precise

specification of the service; otherwise
the relationship between input and output data

is imprecise. Another
service might exist that also has a phone

number as input and an address as
output, that returns the address of the phone

provider for the specified phone
number instead. Syntactically, service S3 is

equivalent to service S1 with regard to input
and output data, but instead of returning a

customer�s address it returns the
address of the phone provider supplying the

specified phone number. Such a
difference of functionality is not visible in

syntactic definitions, but can be
represented and distinguished by semantic

specifications. CRM system with the service
S2 provided by the ERP system is shown. In

this way, these services can
participate in a business process, shown in

the upper part of that figure. The
semantic information can be used to decide

whether two services actually match

semantically, so that they can be sequentially

executed in the context
of a given business process.

Data-Driven Processes: Case Handling:

Case handling aims at balancing process

orientation with data orientation to
control the execution of business processes.

The motivation can be derived
from business process reengineering, because

one of its main goals is to overcome
the fragmentation of the work in

organizations.
The introduction of this fragmentation of work

was useful in manufacturing
since the early days of industrialization,

where it led to massive increases in
productivity, because highly specialized

workers perform isolated pieces of
work with high efficiency. Once the worker has

finished a piece of work, the
manufactured artefact is handed over to the

next worker in line.
The fragmentation of work has been transferred

to the information society.
Workers are expected to conduct a single piece

of work in a highly efficient
manner, without a complete picture on the

contribution of the work to the company�s

goals. To control the combination of the

fragmented work, complex
organizational structures have been invented.
With the presence of information technology,

the role of workers has
changed. Now the knowledge worker is at the

centre, responsible for conducting
and organizing her work. The knowledge worker

is highly skilled, so
she can conduct a broad range of activities

required to fulfil business goals of
the company. An insurance claim, for example,

can be processed by a single
person, so that handover of work can be

avoided. Only in specific, seldom
occurring cases is expert support required.
Case handling takes into account this active

role of the knowledge worker
by accepting her expertise and experience to

drive and control the case. Since
traditional workflow technology prescribes the

activities and their execution
ordering, there is little room for knowledge

workers to deviate from the prescribed
process. As a result, traditional workflow

technology appears too restrictive
in these settings.
However, there is still support that flexible

business process management
systems can provide. Since knowledge-intensive

business processes typically
are centred on data processed in the context

of a particular case, the handling
of data requires specific attention.
A case is a product that is manufactured, and

at any time knowledge workers
should be aware of the overall case. Examples

of cases are the evaluation
of a job application, the verdict on a traffic

violation, the outcome of a tax
assessment, and the ruling for an insurance

claim. To illustrate the basic ideas of case

handling, consider the activities A and
B of a business process that are ordered by

control flow A ! B. As a result,
B can only be enabled (and therefore can only

start) after A has terminated.
This type of ordering constraint is a key

ingredient of business process
management in general and workflow management

in particular. While in
many business process scenarios this

traditional workflow approach is adequate,
in knowledge-intensive domains, where an

active role of the knowledge
worker drives the process, more flexible

approaches are required.
For instance, assume that A does not create

its data on termination, but
while it runs. Assume further that B can start

working once data values
created by A are available. Then, B can start

working on these data, while
A creates the remaining data values. In this

case, the control flow constraint
between A and B restricts a useful execution

ordering, in which B starts
working before A completes.
One could argue that the level of granularity

of the modelled activities
might not be adequate. If the generation of

each data value is represented by
a single activity in a business process, then

the same process instances can
be achieved. However, since the number of

activities would become very high,
complex process models that are hard to

understand and maintain would
result.