AGENT-BASED BUSINESS PROCESS MANAGEMENT
N. R. JENNINGS
1
, P. FARATIN
1
, M. J. JOHNSON
1
, T. J. NORMAN
1
, P. O’BRIEN
2
and M. E. WIEGAND
2
1
Dept. Electronic Engineering, Queen Mary & Westfield College, Mile End Road, London E1 4NS, UK.
2
BT Research Labs, Martlesham Heath, Ipswich, Suffolk IP5 7RE, UK.
Received
Revised
This paper describes work undertaken in the ADEPT (Advanced Decision Environment for Proc-
ess Tasks) project towards developing an agent-based infrastructure for managing business proc-
esses. We describe how the key technology of negotiating, service providing, autonomous agents
was realised and demonstrate how this was applied to the BT (British Telecom) business process
of providing a customer quote for network services.
Keywords: Intelligent agents; Business process management; Negotiation; Information sharing.
1. Introduction
Company managers make informed decisions based on a combination of judgement and
information from marketing, sales, research, development, manufacturing and finance
departments. Ideally, all relevant information should be brought together before judge-
ment is exercised. However obtaining pertinent, consistent and up-to-date information
across a large company is a complex and time consuming process. For this reason, organi-
sations have sought to develop a number of Information Technology (IT) systems to assist
with various aspects of the management of their business processes. Such systems aim to
improve the way that information is gathered, managed, distributed, and presented to peo-
ple in key business functions and operations. In particular, the IT system should:
• allow the decision maker to access relevant information wherever it is situated in the
organisation (this should be possible despite the fact that information may be stored in
many different types of system and in many different information models);
• allow the decision maker to request and obtain information management services from
other departments within the organisation (and in some cases even from outside the
organisation);
• proactively identify and deliver timely, relevant information which may not have been
explicitly asked for (e.g. because the decision maker is unaware of its existence);
• inform the decision maker of changes which have been made elsewhere in the business
process which impinge upon the current decision context;
• identify the parties who may be interested in the outcome and results of the decision
making activity.
Analysis of a number of business processes, from various industrial and commercial
domains, resulted in several common characteristics being identified:
• Multiple organisations are often involved in the business process. Each organisation
attempts to maximise its own profit within the overall activity.
• Organisations are physically distributed. This distribution may be across one site,
across a country, or even across continents. This situation is even more apparent for vir-
tual organisations
1
which form allegiances for short periods of time and then disband
when it is no longer profitable to stay together.
• Within organisations, there is a decentralised ownership of the tasks, information and
resources involved in the business process.
• Different groups within organisations are relatively autonomous—they control how
their resources are consumed, by whom, at what cost, and in what time frame. They
also have their own information systems, with their own idiosyncratic representations,
for managing their resources.
• There is a high degree of natural concurrency—many interrelated tasks are running at
any given point of the business process.
• There is a requirement to monitor and manage the overall business process. Although
the control and resources of the constituent sub-parts are decentralised, there is often a
need to place constraints on the entire process (e.g. total time, total budget, etc.).
• Business processes are highly dynamic and unpredictable—it is difficult to give a com-
plete a priori specification of all the activities that need to be performed and how they
should be ordered. Any detailed time plans which are produced are often disrupted by
unavoidable delays or unanticipated events (e.g. people are ill or tasks take longer than
expected).
Given these characteristics, it was decided that the most natural way to view the busi-
ness process is as a collection of autonomous, problem solving agents which interact
when they have interdependencies. In this context, an agent can be viewed as an encapsu-
lated problem solving entity which exhibits the following properties
2
:
• Autonomy: agents perform the majority of their problem solving tasks without the
direct intervention of humans or other agents, and they have control over their own
actions and their own internal state.
• Social ability: agents interact, when they deem appropriate, with other artificial agents
and humans in order to complete their problem solving and to help others with their
activities. This requires that agents have, as a minimum, a means by which they can
communicate their requirements to others and an internal mechanism for deciding what
and when social interactions are appropriate (both in terms of generating requests and
judging incoming requests).
• Proactiveness: agents take the initiative where appropriate.
• Responsiveness: agents perceive their environment and respond in a timely fashion to
changes which occur in it.
The choice of agents as a solution technology was motivated by the following observa-
tions: (i) the domain involves an inherent distribution of data, problem solving capabili-
ties, and responsibilities (conforms to the basic model of distributed, encapsulated,
problem solving components); (ii) the integrity of the existing organisational structure and
the autonomy of its sub-parts needs to be maintained (appeals to the autonomous nature of
the agents); (iii) interactions are fairly sophisticated, including negotiation, information
sharing, and coordination (requires the complex social skills with which agents are
endowed); and (iv) the problem solution cannot be entirely prescribed from start to finish
(the problem solvers need to be responsive to changes in the environment and to unpre-
dictability in the business process and proactively take opportunities when they arise).
When taken together, this set of requirements leaves agents as the strongest solution can-
didate—(distributed) object systems have the encapsulation but not the sophisticated rea-
soning required for social interaction or proactiveness, and distributed processing systems
deal with the distributed aspect of the domain but not with the autonomous nature of the
components.
The remainder of this paper describes the work undertaken to conceptualise business
process management as a collection of intelligent agents. Section 2 describes the key con-
cepts of agents which offer services to one another. Section 3 details the application of
ADEPT agents in British Telecom’s (BT’s) customer quote business process. Section 4
contrasts the ADEPT view with that of other common techniques for business process
management. Finally, section 5 describes the ongoing work and the open issues which still
need to be addressed.
2. The Business Process as a Community of Negotiating Agents
Each agent is able to perform one or more services (figure 1). A service corresponds to
some unit of problem solving activity (section 2.2). The simplest service (called a task)
represents an atomic unit of problem solving endeavour in the ADEPT system. These
atomic units can be combined to form complex services by adding ordering constraints
(e.g. two tasks can run in parallel, must run in parallel, or must run in sequence) and con-
ditional control. The nesting of services can be arbitrarily complex and at the topmost
level the entire business process can be viewed as a service.
Services are associated with one or more agents which are responsible for managing
and executing them. Each service is managed by one agent, although it may involve exe-
cution of sub-services by a number of other agents. Since agents are autonomous there are
no control dependencies between them; therefore, if an agent requires a service which is
managed by another agent it cannot simply instruct it to start the service
a
. Rather, the
agents must come to a mutually acceptable agreement about the terms and conditions
under which the desired service will be performed (such contracts are called service level
agreements (SLAs)—see section 2.3). The mechanism for making SLAs is negotiation—a
joint decision making process in which the parties verbalise their (possibly contradictory)
demands and then move towards agreement by a process of concession or search for new
alternatives
3
.
To negotiate with one another, agents need a protocol which specifies the role of the
current message interchange—e.g. whether the agent is making a proposal or responding
with a counterproposal, or whether it is accepting or rejecting a proposal. Additionally,
agents need a means of describing and referring to the domain terms involved in the nego-
tiation—for example, both agents need to be sure they are describing the same service
even though they may both have a different (local) name for it and represent it in a differ-
ent manner. This heterogeneity is inherent in most organisations because each department
typically models its own information and resources in its own way. Thus when agents
interact, a number of semantic mappings and transformations may need to be performed
to create a mutually comprehensible information sharing language (see section 2.4).
2.1. The ADEPT Agent Architecture
All ADEPT agents have the same basic architecture (figure 2). This involves a responsible
agent which interacts with peers and the subsidiary agencies and tasks within its agency.
An agent’s agency represents its domain problem solving resources. The responsible agent
a.
This is one of the major features which distinguishes multi-agent systems from more traditional forms of dis-
tributed processing
4
.
Fig. 1. An ADEPT environment.
Intelligent
Information
Sharing
Design
Marketing
Legal
Sales
Team
Department
Negotiation
Agent
Team
Team
Services
Protocol
Service
Level
Agreements
has a number of functional components concerned with each of its main activities—com-
munication, service execution, situation assessment, and interaction management (see
description below for more details). This internal architecture is broadly based on the
GRATE
5, 6
and ARCHON
7
agent models. The domain resources can either be atomic
tasks or agents representing subsidiary agencies (sub-agents). The latter case allows a
nested (hierarchical) agent system to be constructed in which higher-level agents realise
their functionality through lower level agents (the lower level agents have the same struc-
ture as the higher level ones and can, therefore, have sub-agents as well as tasks in their
agency). For example, the higher level agent may represent a legal department whose
work is carried out by a number of lawyers (the lower level agents!). This structure ena-
bles flat, hierarchical, and hybrid organisations to be modelled in a single framework
b
.
The differences between an agent in an agency (i.e. an agent that is responsible for a sub-
sidiary agency) and a peer agent (i.e. an agent that is responsible for a peer agency) relate
to the levels of autonomy and helpfulness. In both cases the agents negotiate to reach
agreements. However in the former case: (i) the agent cannot reject the proposal outright
(although it can counter propose until an acceptable agreement is reached); and (ii) the
agent must negotiate in a cooperative (rather than a competitive) manner since there is a
degree of commonality of purpose. In summary, there is a tight coupling between an agent
and it’s agency and a loose coupling between an agent and it’s peers
8
.
2.1.1. Communication Module
The communication module routes messages between an agent and its agency and
between peer agents. During task execution and management (e.g. the activation, suspen-
sion, or resumption of a task), messages are routed between the agent’s Service Execution
Module (SEM) (figure 2) and the tasks managed by that agent. During service execution
management (e.g. the initiation of a service to be provided by another agent under some
agreement, or a report of the results of a completed service), messages are routed between
the agent’s SEM and the SEM of another agent. During negotiation, messages are routed
between the agent’s Interaction Management Module (IMM) (figure 2) and the IMM of
the agent or agents being negotiated with.
2.1.2. Interaction Management Module
The interaction management module provisions services through negotiation. The Situa-
tion Assessment Module (SAM) invokes the IMM to begin negotiation for services the
agent needs. The IMM’s decision making capabilities are supported by three types of
information: scheduler constraints emanating from the SAM; knowledge an agent has
about itself and it’s own domain (represented in the Self Model (SM)); and knowledge the
agent holds about peer agents (represented in the Acquaintance Model (AM)). Based on
these sources of knowledge and the negotiation model (section 2.3), the IMM generates
b.
This modelling ability is important because commercial environments are founded on organisational models
where an enterprise is logically divided into a collection of services. The agent-agency concept draws upon this
principle to group services and tasks where it makes pragmatic sense.
