Termination Handling in Inter-Organisational Workflows - An Exception

Management Approach
Heiko Ludwig
IBM Research Division, Zurich Research Laboratory
Saumerstrasse 4, 8803 Ruschlikon, Switzerland
hlu@zurich.ibm.com

Abstract
The co-ordination of business processes across organisational boundaries requires assigning responsibility for costs
to the involved business partners, in particular in case of
termination of a sub process that is outsourced to another
organisation. The circumstances in which business partners
can terminate ongoing prossesses and the assignment of
costs are usually specified in a contract. It defines who has
to pay which amount in specific situations. In many organisations Workflow Management Systems (WfMS) are used
to enact business processes, but current WfMS do not have
means to specify and apply rules that define responsibility
for costs or terms of termination. If WfMSs of outsourcing
partners should be connected cost assignment and supervision has to be done manually. This paper proposes a formal approach to extend WfMSs by a framework for termination management and cost assignment. Such a mechanism
reduces monitoring effort in cross-organisational workflow
management.

1 Introduction
The current trend in organisations of western economies
to outsource functions that are not considered to be part of
the core business as well as the grouping of several companies to form virtual organisations leads to an increasing
number of service relationships between companies [1], [2].
A service relationship means that a part of a business process of a service-requesting company is performed in another organisation. This might lead to parallel work in the
same process in two different organisations where one organisation depends on results achieved by another. In case
of termination of the work by one of the parties the business process might need to take another course or has to be
terminated altogether. Imagine a mail order company that
outsources the parcel delivery to UPS or the like. If a parcel

is sent to a wrong address it cannot be delivered. The parcel

has to be returned, the correct address has to be found out to
which it is sent again, or the whole business process needs
to be cancelled. Terminations can cause costs that have to be
assigned to an organisation. Usually, rules governing which
company is responsible for terminations in different circumstances are defined in a contract. E.g. the parcel company
ensures in the contract that it will be paid even if the delivery address was wrong, but agrees to pay compensation for
lost parcels.
Another trend in recent years is the proliferation of
Workflow Management Systems (WfMS) in organisations.
WfMS support organisations to manage the execution of
business processes by triggering the single activities that
constitute a process in a pre-defined order and by supervising its progress. This is achieved by having a schema of a
process, specified in advance, enacted by a central program,
the workflow engine, in the same way each time such a process instance has to be performed. Activities are assigned to
employees as workitems and put into their respective worklists. This functionality can be regarded as support for operational management in an organisation. The process and
the performer assignment is defined once at a schema level
and is then enacted in an automated way many times.
If two business partners, service requester and service
provider, use a WfMS to control their processes, they also
need an (automated) means of identifying and, as far as possible, resolving terminations with cross-organisational effect. The issue to be investigated in this paper is how to
deal with termination problems in the case where both companies use WfMS to enact their processes. In detail, this
means:
1. How are terminations of a business process managed,
if they take place within an organisation?
2. What is different if processes span organisations?
3. What are the implications where WfMS are used to
manage the business process.

The objective is to provide a means of connecting WfMS in

an way such that terminations across organisational boundaries can be dealt with.
This paper is organised in line with these issues. Section 2 introduces a model of cross-organisational process
management (issues 1 and 2). Section 3 discusses how the
model elements relate to elements of a WfMS, which problems can be handled by a WfMS and which need to be dealt
with outside a WfMS. Section 4 introduces an approach to
identify those cases and to notify the (human) management.
Section 5 discusses related approaches and the last section
summarises the paper and shows paths to further work.

2 A model of termination management in

business processes
This section introduces a model that describes how
(manual) business processes are carried out, how termination of the whole business processes or parts of it are managed and how this is usually done on an inter and intraorganisational level. The purpose of this (formal) model
is to analyse the interaction between the management of a
business process and its activities.

For the purpose of this paper we assume a very simple

model of the performance of a business process in an organisation. We want to focus on the termination handling
issue and choose to ignore many aspects that are relevant
for other issues like optimisation or concurrency.
A business process consists of two types of entities: One
Business Process Controller (BPC) that manages the performance of the process and a set of activities that do the
actual work.
Definition 1 A business process is a tuple
where
is the business process controller and
of activitites.

,
a set

Both activity and BPC are treated as autonomous entities

that interact using a protocol. We will introduce and define
activities, BPC and the way they interact.
Activity: An activity
is a piece of work assigned to
one performer. For example a van driver shipping a parcel
to a customer of a company. An activity has a state variable
. It can carry the value (initiatied), (running),
(completed) or (terminated). In this model, we assume
that the state variable of an activity is set pro-actively by
its performer. If an activity is created, its state is . If the
performer starts the activity, it is set to . If he thinks the
activity is completed its state is set accordingly. While the

activity is still in the state or has not even been started yet,
the performer may find out that it is impossible to complete
the task. In our example the van driver could find out that
the delivery address does not exist. In this case
is set
to . In the scope of this model, we call the state-changing
operations
,
and
. Each activity
has its own view of the world, independent of other activities or the BPC. We represent an activitys world view as the
set of objects . In our example, relevant objects would be
the parcel to be transported, the delivery address, etc. Each
object
has its respective domain
.
Definition 2 An activity is a tuple
where

is its state variable, the value being in

, the state set of activies
,
the set of relevant objects of the world,
the domains of the objects, and
is the set of operations

Business Process Controller: The BPC manages the

proceeding of a business process. The BPC initiates activities and assigns performers to them. It stores which activities it initiated and their current state. Several activities can
be in state at the same time. The sequence of the activities of the business process is the acyclic relation
. In
the same way as for activities, information about the environment of the process is represented as the set of objects
. This information is needed to decide to initiate new
activities, to ask them to terminate or to terminate the whole
business process. In the same way as activities, a business
process has a state
. When created,
is , is
set to while the process is ongoing and can finally be
or .
Definition 3 A Business Process Controller is a tuple
,
where
are the names of the activities in ,
is the set of activity states
each activity
,

that is known for

, the order of activities,

is the set of relevant objects of the process,
is the set of domains of the elements of
is in

is the state variable of

, and

the value of which

is the set of operations available to BPC.

:

All operations only have effect within the scope of BPC.

They do not directly effect the involved activities. Changes
of states and object values have to be communicated between activities and business process.
Interaction between Business Process Controller and
activities: In this model BPC and activities interact using
the operation tell that both types of model entities can use:
tell: The operation tell informs another entity that the value
of an object or the state of a process or activity
changed.

It is now up to the BPC to take the appropriate course

of action. In our example, to keep it simple, it terminates
. The right strategy depends on the application domain
and the objectives of the organisation. It might also be necessary to compensate the effects of previously completed
activities. In this model the termination handling strategy is
hidden in the BPC and not explicitly represented.
Summary of the intra-organisational business process model: The model represents a business process that is
performed and managed by people in the real world. The
model particularly points out that:
Changes of information in the environment of an activity or the BPC might lead to the situation in which
an activity cannot be completed.
Other activities could have been completed before
and parallel activities can be ongoing.
Handling terminations might be complex and requires knowledge of the application domain.

for
being the object set of the sender with its domains
, and
the relevant domain of the object
of the receiver.
For example the activity parcel delivery could tell its business process that the delivery address is void:

This interaction model reflects the behaviour of human

workers performing activities and reporting important results to their co-ordinator. As the model does not define
when changes are communicated, we have to take into account that updates might be deferred.
Behaviour in case of termination: How do a BPC and
its activities deal with terminations in this model? Let us extend our initial example: We assume a mail order business
process. The first actvity is to take the order on the telephone. Then follow two activities in parallel: the bill for
the customer is prepared and sent, while the ordered goods
are packaged and delivered to the customers address.
Figure 1 illustrates the interaction going on during the
performance of the business process mail order. The BPC
and the activities are represented as collums, the time proceeding from top to bottom. The state vector in the mail
order collumn represents the information of the BPC. The
state of the whole business process is the first vector entry, the subsequent ones are the known states of the activities in the sequence of collumns. The arrows represent
interactions between BPC and activities. After the successful completion of take call,
and
are initiated.
While
is it hits the false address problem
terminates the activity and informs mail order about the termination and the false address.

What is different if one of the activities is performed by

an external organisation? The main issue to be addressed, in
addition to intra-organisational businesses, is: Who covers
the consequences of a business processs termination, i.e.
the costs if either an activity cannot complete the work or a
business process requests an external activity to terminate?
If a process is performed completely within an organisation, the BPC is in charge of the costs of a business process.
The performers of activities usually do not need to recover
their costs of operation on a case-by-case basis and therefore, from a financial point of view, do not care too much
about the costs of terminations. If the performer of an activity is another company, however, it wants to get paid for
work on activities if their pre-mature termination has been
caused by the BPC or they have been completed but compensated by another activity later-on.
The relationship between two organisations are usually
defined in a contract. In addition to the definition of the
work to be done and its compensation, the contracting parties usually define how to proceed in case exceptional situations occur. We call such a clause of a contract an exception rule. How much money should be paid by whom
depends on the circumstances that caused the termination.
In our delivery example, a transport company performing
this activity will expect full payment even if it could not
complete the activity successfully. Exception rules can define different consequences for different reasons of termination. Speaking abstractly, the motiviation for performing
the
,
or
operation of an activity

Figure 1. Dealing with terminations

is the current information of the activity about the state
of its relevant environment, its object set .

therefore the predicate

was false
for
. We can now define an exception rule:

Definition 4 A predicate
, where

Definition 5 An

exception

is a predicate symbol and

is the domain of object

rule

is
a
, where

tuple

,
of the activity

according to definition 1,

is called a reason.

the state of

In our example, the reason that a parcel cannot be delivered is

if address = void
for D1 being the delivery address.
As the delivery address is wrong in our example, the predicate
is true and the van driver terminates his activity. But the predicate became only true after
the driver learnt, that the delivery address was wrong, the
value of the object address changed in the activity delivery. Prior to that, he believed he had a correct address and

before it was terminated,

and
, the modification to the agreed price for
the performance of the activity.
Activities that are performed outside the organisation are
initiated according to a contract that defines the price and
the exception rules.
Definition 6 A

contracted activity
, where

is

is an activity according to definition 1,

tuple

the initial amount of money for the completion

of the activity, and
a set of exception rules.
Let us assume the contracted activity delivery, regular
price is 100, includes the exception rule

If the activity learns that the delivery address is void while

the activity state is R, it decides to terminate. The price to
pay is increased by 50, e.g. for returning the parcel.
Figure 2 illustrates the modified interaction between
BPC and deliver. In addition to the current state, the BPC
stores the price it has to pay for a regular completion of
the contracted activity. As deliver learns that the address is
wrong, it applies the exception rule and terminates the activity. The application of the exception rule increases the
price of the activity. It informs the BPC about the termination, the modification of the value of the object
,
and about the exception rule it applied.
Summary: This extension to the business process model
allows the expression of rules how to assign cost in the case
of termination of an activity. The exception rule provides us
with a means to express consequences (in terms of money)
of termination of a process depending on the circumstances
of failure. This is essential for dealing with activities of a
business process that are performed outside an organisation.
However, if we want to actually represent all rules relevant for a business relationship, we will encounter problems: The number of exception rules can be quite large and
it will never be complete. In every western legislation there
are already a number of rules defined by law that cannot be
over-ruled by contractual clauses. In addition, as spelled out
by the economic transaction cost theory, contracts are never
complete [3], [4]. The bounded rationality of human beings
limits their ability to foresee all possible future reasons for
termination and leaves these situations for negotiation when
they arise.

3 The role of Workflow Management Systems

In which way do WfMSs support business processes? In
this section we want to understand the limitations of WfMSs
in cross-organisational business processes.
Even if there are many different WfMS on the market,
most of them consist of the same main components and
work in a similar way, following a metamodel and standard
architecture of the WfMC [5]: The main benefit of WfMS
is that an organiser can define a process schema once and
run instances of this schema whenever necessary. A process schema specifies which are the individual activities of a

process, in which sequence must they be performed, which

data do they need as input and which data do they produce.
Such a schema also contains a rule for each activity how to
determine the performer of an activity. The sequence of activities can also include alternatives and parallel branches.
When the specification is finished, the process model can
be loaded onto a workflow engine which enacts process instances at runtime. If an instance of a process is started
according to a schema,it is managed by the workflow engine until its final activity is finished. A workflow engine
also provides management functions to its users. Provided
proper authorisation, activities and process instances can be
re-routed or cancelled during runtime.
We can interpret a WfMS that enacts a process instance
as a pre-programmed BPC as defined in section 2. A running instance of a process initiates activities, has information about their state, their sequence, the data they use and
has a process state to reflect its progress. People communicate with the process instance through their worklist. The
data represented in the process instance is only up-to-date to
the extent that performers of activities reflect the progress of
their work in their worklists. The communication through
worklist is equivalent to the tell command.
What are the limitations of functionality of WfMSsupported processes?
1. Process schemas are pre-defined. The sequence of
activities can only be defined on the basis of specified output data of an activity. Unforeseen situations
cannot be taken into account by using more data for
decisions how to proceed.
2. Most WfMS do not provide default proceeding for
terminating activities. Usually a process designer has
to specify a data item for success - a sort of return
value - in the output data of an activity. This can be
used to define explicitly the exceptional situation as
an alternative branch of the process.
3. All aspects relating to contractual conditions of termination are not foreseen.
The first limitation is in the very nature of todays
WfMS. If situations should be managed in a pre-specified
way, they must be anticipated. The second limitation reduces ease of use of WfMS in the case where many different exceptions need to be handled. WfMS on the basis
of advanced transaction models [6], [7] that are able to deal
with compensation [8] promise improvement. The most important limitation is the third one. Current WfMS are not
designed to deal with external consequences of particular
states of processes, necessary for inter-organisational business processes. External effects of terminations have to be
organised using a different means, e.g. employees.

Figure 2. Interaction with contracted activities

4 Exception handling architecture for crossorganisational workflow management

We propose an architecture to connect WfMS of different organisation that is able to handle terminations according to contracts as introduced in section 2. The design approach taken here is to leave all functionality for the semantically correct treatment of terminations, i.e. which course
of action should be taken if a termination occurs, to the process instance as enacted by the WfMS. The architecture provides the additional functionality that is needed to deal with
the performance of external activities ruled by contracts.
Figure 3 shows an overview of the components of the
architecture in an example interaction. In this architecture
the WfMSs of the two companies do not interact directly.
An external activity that is processed without terminations
is handled by the Outsourcer on the side of the servicerequesting company and the Insourcer on the side where the
activity is performed. A detailed description of Insourcer
and Outsourcer is given in [9]. When a termination occurs, each side calls its Exception Rule Manager that either
comes back with the modified price or notifies human su-

pervisors to solve the termination problem.

Outsourcer: To pass an activity to an external performer, a contract needs to be available. If the Outsourcer
retrieves activities to be performed externally in the WfMS,
it identifies the corresponding business partner according to
its contracts. If the right partner is identified the relevant
Insourcer is sent a startActivity message. These activities
that are passed out are stored as outgoing contracted activities including its expected price. If an activityCompleted
message is received for an outgoing contracted activity, the
result in the form of output data is fed back to the WfMS
and the WfMS activity is declared completed.
Insourcer: On the side of company 2 that performs the
external activity the Insourcer has a corresponding role as
company 1s Outsourcer. If the Insourcer receives a startActivity message, it looks up whether there is a contract in
place. If so, it instantiates its process which corresponds to
the requested activity, and when it is completed, it reads the
output data and sends an activityCompleted message to the
requesting Outsourcer.
If the Outsourcer identifies that an activity has been terminated in its WfMS, it sends a terminateActivity message

Figure 3. Activity outsourcing with contract-based termination handling

to the Insourcer. The Insourcer terminates its WfMS activity, reads the output data and replies with an activityTerminated message that hands the output data to the Outsourcer
and confirms the termination. The activityTerminated message serves the purpose to synchronise the view of the world
of both companies (see section 2). If the Insourcer finds out
that an activity has been terminated in its WfMS, it also
reads the output and submits an activityTerminated message along with the output to the Outsourcer. Therefore,
no confirmation is needed, if the termination is caused in
the activity-performing company.
Insourcer - Outsourcer interaction: Outsourcer and
Insourcer communicate using four messages:
Outsourcer: startActivity(Activity, input)
Outsourcer: terminateActivity(Activity)
Insourcer: activityCompleted(Activity, output)
Insourcer: activityTerminated(Activity, output)
If either the Outsourcer submits a terminateActivity or
the Insourcer an activityTerminated message, both components forward the output of the terminated activity to their
Exception Rule Managers (ERMs) with an exception message to resolve this situation. Before the activity passing

took place, the ERMs have also been supplied with the
exception rules according to the contract. The party that
caused the termination tries to apply an exception rule to
the output data of the terminated activity. If a rule is found
it is sent to the counterpart in the other organisation. This
ERM either acknowledges the applicability of the rule and
its consequences, or rejects it. If the ERMs cannot resolve
the exception, they notify human supervisors. In case of
acknowledgment, the ERMs send a modifyPrice message
back to Insourcer and Outsourcer.
In the example scenario of figure 3, company 1 passes
the activity Shipping to company 2 in the steps (1), (2), (3).
Company 2 causes the termination because of our known
problem of the false delivery address. The Insourcer retrieves the termination (4) and notifies the outsourcer about
the fact (5). Subsequently, both, Insourcer and Outsourcer
pass the output of Shipping to their ERMs (6) while the Outsourcer also terminates the activity in its WfMS. If there is
an applicable rule identified by the ERM of company 2, it
is sent to the ERM of company 1 (7), which acknowledges
its applicability(8). When acknowledged, the price is increased by 50 (9).

5 Related work
Much research work has been done in the recent years
to define and enforce correctness conditions for Workflow
Mangement. Kamath et. al. [10] give a good overview of
approaches to deal with logical failures, that result in terminations. Most approaches extend the classical transaction
model by means of compensating activites/sub-transactions
that have already been completed/committed [8], [7], [6].
From the side of the industry, interfaces and products have
been developped to allow different WfMS to start, monitor and control processes on other systems. The Workflow
Management Coalition, a standardisation body of WfMS
vendors and users, defined a protocol which allows a WfMS
of different vendors to interoperate. the Interface 4 [11] But
both, research and industry development, did not take into
account the problem of responsability for costs in the area
of cross-organisational processes.

6 Conclusions
In this paper an architecture for the management of terminations in cross-organisational WfMS-enabled processes
has been proposed. We introduced a model of business processes that explained the differences of termination management within an organisation and across company boundaries: Activities, performed outside the organisation that
controls the process, are governed by a contract that, among
other issues, defines who covers the cost for the termination
of an activity. The key approach is to formalise the rules
of cost responsability for terminations in a contract so that
they can be checked automatically for applicability to a particular situation.
On both the service-requesting and the activityperforming side, a component performs the regular passing and receiving of activities and their results. These components, Outsourcer and Insourcer, identify exception situations and forward the issue to Exeption Rule Managers,
which try to resolve the cost assignment using the formal
exception rules of the contract. The exception rule management is the reason why the output data of an activity is
parameter of an activityTerminated message to the servicerequesting party. This is only needed for the evaluation of
exception rules. Because of the inherent incompleteness of
contracts, the architecture reflects the need for notification
of human supervisors, where an unforeseen situation occurs.
This architecture does not deal with the issue of how
to determine the right course of action in the case where
a termination occurs. This is left to the capabilities of the
WfMS. However, it enables organisations to outsource work
in a much more controlled way compared to todays solutions, which only deal with the technical problem of moving

an activity from one WfMS to another.

The architecture also allow for further extensions. Like
the identification of terminations and their forwarding to an
exception rule manager, other conditions of a contract could
also be formalised, identified and managed. But this is left
to future work.

References
[1] W. H. Davidow and M. S. Malone, The Virtual Corporation, HarperCollins Publishers, New York, 1992.
[2] B. R. Konsynski, Strategic control in the extended
enterprise, IBM Systems Journal, vol. 32, no. 1, pp.
111 142, 1993.
[3] R. H. Coase, The nature of the firm, Economica,
New Series, vol. IV, pp. 386 405, 1937.
[4] O. E. Williamson, Transaction cost economics,
in Handbook of Industrial Organisation, Vol. I,
R. Schmalensee and R. D. Willig, Eds. Elsevier Science Publishers, Amsterdam, 1989.
[5] Workflow Management Coalition, Terminology and
glossary, Tech. Rep. WfMC-TC-1011, The Workflow
Management Coalition, 1996.
[6] J. Gray and A Reuter, Transaction Processing: Concepts and Techniques, Morgan Kaufmann Publishers,
San Francisco, 1993.
[7] A. K. Elmagarmid, Ed., Database Transaction Models
for Advanced Applications, Morgan Kaufmann Publishers, San Mateo, 1991.
[8] F. Leymann and D. Roller, Workflow-based applications, IBM Systems Journal, vol. 36, no. 1, pp. 102
122, 1997.
[9] H. Ludwig and K. Whittingham, Virtual enterprise
co-ordinator - agreement-driven gateways for crossorganisational workflow management, in Proceedings of the 1st Conference on Work Activities Coordination and Collaboration (WACC 99)(to appear),
New York, 1999.
[10] M. Kamath and K. Ramamritham, Modeling, correctness & systems issues in supporting advanced
database applications using workflows, Tech. Rep.
TR 95-15, University of Massachusetts, Computer
Science Department, 1995.
[11] Workflow Management Coalition, Workflow standard - interoperability abstract specification, Tech.
Rep. WfMC-TC-1012, The Workflow Management
Coalition, 1996.