mamba: automatic customization of computerized business processes

MAMBA: AUTOMATIC CUSTOMIZATION OF COMPUTERIZED BUSINESS PROCESSES St. Kirn, R. Unland, U. Wanka Institut für Wirtschaftsinformatik Westfälische Wilhelms-Universität Münster Grevener Straße 91, D-48159 Münster, Germany. {KirnS|UnlandR|Wanka}@uni-muenster.de

ABSTRACT Due to recent market challenges organizational researchers have developed a variety of strategies how organizations can continuously survive in highly dynamic, sometimes even hostile environments. One of the most important strategies aims to enhance the flexibility of enterprises through widespread decentralization, while another well-known approach advocates customer orientation through systematic business process (re-) engineering. This paper addresses organizational flexibility and business process orientation from the perspective of information systems. It starts from a requirements analysis which investigates the challenges of contemporary organizational strategies and then proceeds towards an approach that supports the flexible modeling of business processes by linking decentralized organizational procedures. For this purpose a set of process modeling and process interaction operators is defined. These operators also allow to automatically create and customize configurations of computerized business processes. This progress in cooperative information processing technology contributes significantly to the recently emerged concept of the computerized enterprise. The concepts are presented in the context of a banking application, namely the Credit Advisory Subsystem of our banking application MAMBA.

1 INTRODUCTION Today, organizations are faced with permanently changing markets, global competition, rapidly decreasing cycles of technological innovations, worldwide (and just in time) availability of information, and considerable changes in their cultural, social, and political environments. The ability of enterprises to achieve competitive advantages and to continuously survive in dynamic, sometimes even hostile environments largely depends on their organizational flexibility, and thus on their organizational information processing and problem solving capabilities. While the former can be achieved by implementing organizational networks and virtual organizational structures, the latter makes great demands on computer-based data management and knowledge processing capabilities. From research on organizational networks and virtual organizations it is known that one of the most important problems in such settings is how to efficiently coordinate sequences of activities which are under decentralized local control. Furthermore, business process (re-) engineering not only redesigns organizational processes but also involves a significant shift of tasks from human workers to so-called computational agents. As a consequence, whenever business process (re-) engineering is done, we are increasingly concerned with adapting and combining software-based sequences of organizational procedures instead of modeling these procedures from scratch. This evolution has been accompanied by some promising advances in information technology (IT), which have emerged recently. Client Server Computing has proven to be very successful in breaking down even wellestablished and centralized systems, i.e. hierarchical information system architectures. Another breakthrough has been the definition of the CORBA standard (Common Object Request Broker Architecture) by the Object Management Group in 1991 [32]. Within this context, the concept of Cooperative Information Systems advocates a cooperative approach to coordinate the activities of decentralized, autonomous and heterogeneous information systems. These advances, together with the availability of high-speed communication networks, open the perspective to concentrate our efforts on how organizational networking and decentralized (computerized) organizational procedures can effectively be supported by innovative software architectures. It is our strong believe that, within the context described above, the discipline of Distributed Artificial Intelligence (DAI) can contribute significantly to this challenge. Hence, in this paper we rely on the approach of so-called 'organizational' multi agent systems [25]. Organizational multi-agent systems are well suited —

to dynamically adapt themselves to organizational aims and objectives, structures, processes, and constraints,

—

to provide efficient IT support to an organization's "cognitive" skills, such as organizational perception, learning, problem solving and communication, and

2

—

to actively contribute to business process orientation and the processing of computer-based organizational procedures through a toolbox of decentralized coordination mechanisms by which a broad variety of organizational structures and coordination principles can be supported.

Within the framework of a computerized enterprise [39] organizational multi-agent systems are taking charge of explicit organizational roles [25]. This means that they will mutate to self-contained organizational agents no longer restricted to the inertia of today's business information systems [21]. It has been recognized that one of the most important advantages of organizational multi-agent systems is their capability to support customer orientation through a significant increase of organizational flexibility. Within this paper we address on the issue of process orientation, namely that of automated configuration and customization of computerized workflows and business processes. Due to the conceptual equivalence of multi-agent plans and (formally represented) organizational procedures our technical approach relies on multi-agent planning. We suggest a plan coordination approach that provides for customizing intra- and inter-organizational configurations of software-based, adaptable organizational procedures. This can be achieved by providing a diversity of mechanisms to plan and control the activities of decentralized, autonomous organizational units. For this purpose we introduce a set of generic operations by which multi-agent plan creation via plan modeling can be supported. The power of the approach is demonstrated through a plan refinement example taken from a credit application in private customer-banking. The contribution of this paper can be summarized in four points: —

It transforms the recently emerged organizational strategies of networking, virtual enterprises, and business process orientation into a requirements description for information system design.

—

It introduces the technical concepts by which these requirements can be translated into specifications and implementations of the respective information system architectures.

—

It intertwines business process orientation and multi-agent planning, and thus, contributes to make DAI techniques more operational for business applications.

—

Finally, it demonstrates how multi-agent planning improves the flexibility of computerized organizational processes, and, by this way, of the underlying human organization as well.

The remainder of this paper is organized as follows: Section 2 introduces the problem through an investigation of organizational requirements in the context of the decentralized banking application MAMBA (Multi-Agent Münster Banking Application). Section 3 provides a concise review of recent progress in multi-agent planning, together with a presentation of basic design decisions (agent model, multi-agent organization architecture, standardization of interfaces) within MAMBA. Section 4 develops towards the concept of process modeling in organizational multi-agent systems and demonstrates the usefulness of the approach through a credit decision scenario. Finally, section 5 concludes this paper.

3

2 CONTEXT Any research on business processes needs to refer to a particular organizational theory [17], [28]. As far as computational entities are involved, the role of information technology within that organizational theory needs to be clarified (section 2.1). On this basis, section 2.2 presents the credit advisory subsystem of the private banking application MAMBA which essentially may be characterized as a process-driven, cooperative decision support system.

2.1

THE MAMBA ORGANIZATIONAL THEORY

The MAMBA organizational theory involves an organizational model (structure and processes) together with a model of information systems which describes their role in the computerized, process-oriented enterprise of the future. This approach excludes several issues that are important in organizational theory in general (e.g. interactions between organizations and their environment, organizational behavior, etc.), but it helps to focus our work on computational entities within (human) organizations. In other words: the approach pursued here may be considered as the information technology complement to the concept of the computerized, information-integrated enterprise as it has emerged in contemporary organizational theories.

2.1.1

Organizational Model

Within MAMBA the organizational structure is built on four different types of agents: (single) agents — (informal) social groups — (formal) organizational units — enterprise. On this basis, (at least) four different organizational layers can be identified (see figure 1). Additional layers can easily be introduced, e.g. if organizational units (recursively) include one or more other organizational units.

4

Figure 1: Symbolic Representation of a 4-Layered Organization

To integrate the aspect of business process orientation into this organizational model we need to distinguish three different types of processes which refer to the four different organizational levels mentioned above: —

(Organizational) procedure: Sequence of atomic operations performed by one individual agent. From the viewpoint of an individual agent the operations within an organizational procedure are presumed to be atomic. Organizational procedures are part of the operative layer of an enterprise.

—

Workflow: Network of procedures on the level of groups thus involving the work of one or more individual agents. Groups are "workflow providers". Workflows are part of the operative layer of an enterprise, too.

—

Business process: Network of workflows (thus involving the work of one or more groups) and procedures (thus involving the work of one or more individual agents) on the level of a single organizational unit. Organizational units are "process providers" (see figure 2). Business processes within a single organizational unit are part of the tactical layer of the organization; they represent exactly one single product (i.e. satisfying basic customer preferences). We also use the notion business processes in order to refer to an enterprise-wide network of business processes, which involves one or more organizational units working together on a common problem. Within MAMBA, enterprise-wide business processes represent a product bundle (i.e. satisfying complex portfolios of customer preferences). Business processes on the level of the enterprise belong to the strategic layer of the enterprise.

It may be mentioned, that this taxonomy of (organizational) processes already address the need to model processes on different levels of abstractions. At this point, the reader may also recognize that organizational

5

procedures necessarily include a lot of very detailed informations about particular (atomic) activities, while business processes need not to be operational at all.

Organizational Unit A

Organizational Unit B

AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA Organizational AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Unit C AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAAAAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA configurable, AAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA adaptable AAAAAAAA AAAAAAAA AAAAAAAAAAAA AAAAAAAA processes AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Figure 2: Organizational Units Representing Configurable, Adaptable Processes

2.1.2

Organizational Information Processing System

The organizational model introduced above involves the concept of computational agents. This extension of classical organizational theory significantly changes the role of information systems within the organizational model of an enterprise. Instead of being more or less passive components of the enterprise-wide information processing system they are assumed to rise to self-contained, autonomous agents that apply to formal organizational roles. As such, they may be under decentralized control, primarily providing local services. However, since they are part of the overall organization they are also assumed to work cooperatively. To do so, they need to coordinate their individual plans to meet and satisfy global goals (e.g. profit, turnover, market share of the whole company). This, in turn, requires the agents to behave in a way that the preferences of diverse types of customers can be efficiently addressed (supposed, this is one of the strategic aims of the enterprise). Thus, we need a technical approach that enables the computational agents to dynamically create what we call customized (business) processes. Within the context of MAMBA, the basic idea is to provide a small set of well-shaped computerized organizational processes (lean process management) and to define powerful operators to create customized workflow and (business) process configurations (smart process management) by which also complex portfolios of customer preferences can be satisfied (see figure 3).

6

Figure 3: Customized Business Process

2.1.3

Emergent Organizational Strategies

The research approach being developed within MAMBA takes an information system's perspective in order to develop towards the aim of the computerized organization. To this purpose, three different but interacting issues need to be considered: —

Fractalization: Emerging from increased decentralization and autonomy (not only) the future bank will increasingly involve intelligent and self-referencing departments (organizational fractals), which are equipped with self-organization skills thus being able to recursively form complex, well-organized organizational bodies. Organizational fractals exhibit intelligent local and global coordination skills. Thus, fractalization makes large organizations more flexible and adaptive. It also (re-) implements learning capabilities into organizations [41].

—

Business Processes: In general, it is supposed that within an organization the time, knowledge and competence is available to fully describe enterprise-wide business processes. It is also supposed that, through an iterative procedure of process refinement, these descriptions can be augmented to more detailed descriptions of (partial) processes and fully expanded specifications of the respective workflows. This, however, requires a centralized approach to business process engineering which is in direct conflict to the strategy of decentralization and the allocation autonomy to organizational subunits. Instead, within decentralized settings the design of business processes requires cooperation among mutual independent individual agents and organizational units, which, for the rest of this paper, are both assumed to be pure computational entities.

7

—

Information Integration: Self-referencing, self-control, and self-organization skills require extensive coordinative capabilities of each organizational unit. Going far beyond today's concept of workflow management, future process management systems must be capable to control fully decentralized processes and to make the process management much more flexible as it is today. These issues presuppose a deep integration of the organizational and machine-based information processing systems of an enterprise [30], [37].

These three issues are the key points to be investigated throughout the project. They span the range of problems to be addressed, they determine the research approach to be developed, and they provide the success criteria by which the research results are to be evaluated.

2.2

MAMBA: COOPERATIVE BANKING APPLICATION

PROCESS

MANAGEMENT

IN

A

PRIVATE

In a banking environment, products are services and as such can be represented by the (standardized) processes necessary to produce and sell them. Thus, constructing product bundles requires to combine these (back office) processes. Therefore, an effective support of customer consultants of a bank can be achieved by providing system assistance in constructing such bundles through bank-wide search for and assessment of appropriate processes and a set of operations to combine and adapt the most promising ones (see also section 4). This is, in short, a description of the basic function of MAMBA. Because an overview of the whole application, which is a fine-grained integration of a credit and an investment advisory system, goes beyond the scope of this paper, we restrict ourselves to the basic concepts of one part, namely the Credit Advisory System (MAMBA/CAS). MAMBA/CAS provides a customer consultant with advice as to how a particular customer credit ought to be best arranged. The system architecture reflects a real bank organization with its different departments by modeling each individual agent and each organizational unit as a computational agent. In case, that a complex consulting task requires a cooperative solution, the agents need to take into account both the individual goals of the customer as well as those of the departments involved, and the aims, rules and constraints of the bank as such. The agents within MAMBA are autonomous, but they are supposed to be benevolent in their cooperative behavior. The necessary coordination of decentralized activities is ensured by multi-agent planning, that is on the one hand driven by the desire to achieve one's aims and on the other hand controlled by a benevolent attitude towards each other. MAMBA/CAS starts from a stereotypical customer profile and specializes it through consultation to accurately capture the respective peculiarities. Based on this and additional product-specific information provided by the customer, like payback pattern, available securities and so forth, MAMBA/CAS will recommend a particular credit arrangement. This is proffered on the one hand by fulfilling the requirements given by the customer and on the other hand by minimizing the risk of the credit and maximizing the profits of the bank in question.

8

Figure 4: The Credit Advisory System within MAMBA

The evaluation of such circumstances is complex since it involves several discrete areas of expertise. Figure 4 provides a high-level picture of the interactions of the agents involved. Figure 5 provides a more detailed view of two of these agents, namely the Customer Profile and the Credit Rating Agent. The task of the former is to keep the customer profile up to date with respect to the corporate aims and to the information acquired about the customer during the consultation process. This profile is to be exported to other agents that make use of it through instantiating certain variables according to the respective values recorded for the customer in question. The job of the latter is to analyze whether the customer is credit-worthy and to arrange a distribution of the securities for the credit that meet the requirements of the bank. In this context each possible security must be assessed by

9

determining a variety of values (i.e. declaration of value, risk rating, potential win / loss, etc.) in order to come to a profound decision. AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Customer Profile Agent AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Customer AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Customer Models AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Profile AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Marketing AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Department AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Current AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Customer Corporate Aims & Objectives AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Model AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA Credit Agent AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAARating AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA xP + yP zP AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAA AAAA AAAA 4+ 15 AAAA AAAAAAAA AAAAAAAA AAAASecurity AAAAAAAA AAAAAAAA AAAAAAAAAAAA1AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAADatabase AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA Consultant AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA Security distribution AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAA AAAAAAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAInformation AAAAAAAA Security AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA

Customer

Assessing Specialist

Figure 5: The Customer Profile and Credit Rating Agent

10

3 MULTI-AGENT PLANNING

3.1

BASIC CONCEPTS

Planning is one of the most thoroughly investigated fields within AI. In AI, planning means that there is usually a set of goals given together with an initial state and a set of allowable actions in a planning environment. The planning task is to find a sequence of actions that fulfills the respective constraints and that allows the system to achieve all of the desired goals. Well-known AI planning systems are STRIPS [10] and NOAH [35]. However, AI planning is not applicable to typical multi-agent settings because of its restrictive assumptions [29]: —

the world is assumed to be static and only affected by the actions of one single agent (the planner),

—

there is only one agent who designs the sequence of actions (=plan) necessary to solve that task, and who itself is responsible for carrying out the actions represented in that plan,

—

plans are concerned with prevention of local conflicts, not with coordination of cooperative or competitive local behavior of multiple agents,

—

single agent planners are not capable of solving complex tasks collaboratively,

—

single agents are not capable of reasoning about actions that are not under their local control, and

—

there is no concept of concurrent activities.

These limitations have stimulated research on multi-agent planning, i.e. on developing towards planning approaches where one or multiple agents cooperatively design multi-agent plans to coordinate the activities of a set of autonomous computational entities [1]. Multi-agent planning refers to the process of creating a multi-agent plan (see figure 6). In distributed planning we distinguish goal-driven planning (tasks [goals] are decomposed into subtasks [subgoals], plans are constructed from scratch) from plan coordination, where pre-existing plans are to be coordinated through cooperative plan reconciliation before they are executed. The input for a plan coordination problem consists of several (partial) plans. In a distributed environment these plans belong to decentralized, autonomous and — to varying degrees — self-contained agents which may act as planners and/or as executors. In addition, a description of (the state of) the world is required in which the individual plans and the global plan are to be executed (coordination environment). To coordinate individual plans the agents must be able to modify them with respect to a set of (globally agreed) goals (e.g. long-term profit maximization). The outcome of the multi-agent planning task (i.e. the solution to the actual plan coordination problem) consists of a set of coordinated individual plans which, subsequently, are to be executed under decentralized control.

11

Figure 6: AI Planning Categories [29] Thus, besides having communication skills, the (group of) coordinating agent(s) must be capable and legitimated to perform the following principle operations: —

to identify and reason about the interferences between plans,

—

to develop solutions for the problem of plan coordination and, thus

—

to modify the plans of other computational agents.

Any multi-agent planning approach requires the establishment of an agent model, a concept of individual and multi-agent plans, and a model of the relevant plan interactions. Table 1 presents an overview of some of the most well-known planning approaches in Distributed AI.

12

category

domain

agent model

plan

plan interactions

main problem addressed

STRIPS, 1971; NOAH, 1977

SAP

—

AI planner

individual

—

plan creation

distributed NOAH, 1979, [4]

DP

—

NOAH-like AI planner

individual plan MA plan

parent-child relationships

extending SAP to DP

Konolige & Nilsson 1980, [26]

CP

—

STRIPS-like AI planner

individual plan MA plan

interacting (sub-) goals

modeling MA plans

Cammarata et al., 1983, [3]

CP

air traffic control

DAI planner, simple individual plan body MA plan

interactions between activity sequences

detect/resolve resource conflicts

Georgeff, 1983, [15]

CP

—

DAI planner, simple individual plan body MA plan

harmful (resource access) interactions

plan synchronization

DPS

distributed vehicle monitoring

horizontal (node node; PGP - PGP),

achieving global consistency in dynamic environments

partial global planning (PGP), 1987, [6], [8]

DAI planner, blackboard-based problem solver

local plan - node plan - partial global plan

vertical (local - node - PGP) plan coordination, 1992, [29]

PC

office

DAI planner, simple individual plan body MA plan

positive / harmful interactions

plan coordination protocol

Table 1: Selected Single AI / Multi-Agent Planning Concepts

As far as organizational structures and dynamic plan interactions are concerned, the approach of MAMBA primarily draws from the concept of generalized partial global planning [6]. As far as plan adaptation issues are concerned, the MAMBA approach develops on top of the plan coordination concept suggested by v. Martial [29]. On this basis, the following two subsections introduce the MAMBA agent model together with the architecture of the MAMBA multi-agent organization to the reader. It shall be mentioned here that, referring to the concept of the computerized organization, both the agent model and the architecture of the MAMBA multi-agent organization are tightly coupled to organizational theory.

13

3.2

AGENT MODEL

3.2.1

Requirements

The agents of MAMBA are intelligent, autonomous problem solvers, which have their own aims, resources, skills, and knowledge. Resources are inherited from the organization. Some of their goals may be private (informal goals), others have been defined by the organization (formal goals). Formal goals may (positively, negatively) interact with each other and with (local) informal goals as well. The definition of formal individual goals must guarantee that the agents perform their actions such that global goals are to be addressed as well. Within MAMBA, this requires the agents to exhibit, at least to some degree, a customer-oriented problem solving behavior. In case of goal conflicts (within one single agent, or between different agents on the same level, or between local and global goals) each agent behaves cooperatively. That is, the agents involved in a goal conflict set up a planning process in order to search for an appropriate compromise. This process may also involve bargaining about transfer payments from one agent to another or from the enterprise to an organizational unit, etc. MAMBA agents are benevolent, i.e. they tell the truth about their plans, and they are willing to cooperate in order to improve the outcome of the whole system or to resolve conflicts within the system. Thus, the agents have a cordial relationship and do not behave in a hostile manner. Agents may incorporate the actions of other agents as part of their own plans (multi-agent planning). This requires the agents to exchange their plans before execution in order to allow other agents having access to their anticipated behavior.

3.2.2

Agent Architecture

Any cooperative agent within MAMBA consists of the modules Dialogue Management Subsystem, Competence Knowledge Subsystem, Domain Knowledge Subsystem, and Coordination Management Subsystem (see figure 7). With the exception of the Domain Knowledge Subsystem all other subsystems are implemented as knowledgebased systems. The Dialogue Management Subsystem provides the interface to the human user. He or she may be interested in a dialogue (request, update) with the Domain Knowledge Subsystem as well as with the Competence Knowledge Subsystem, which provides the agent´s autoepistemic knowledge. Modifications of the domain knowledge of an agent may enforce consistency checks and updates of the agent's autoepistemic knowledge as well. The Coordination Management Subsystem is charged with planning and control of those local activities, that have been recognized to interact with the environment of the MAMBA multi-agent organization or with the activities of other agents.

14

The different agents differ from each other mainly with respect to their Domain Knowledge Subsystems (which, within MAMBA, may be a data base, a conventional application, or an intelligent system as well) and their Competence Knowledge Subsystems, while the Dialogue and the Coordination Management Subsystem are standardized (shell-like) software modules. This architectural approach originates from the FRESCO agent model [22] which has been further improved in the STRICT project [23].

End-User

AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAADialogue AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA Management Subsystem AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Domain AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Competence AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Knowledge AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Knowledge AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Subsystem AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA Subsystem (local) AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA Coordination Management Subsystem AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAA AAAAAAAAAAAA AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAA AAAA AAAA AAAA ISO/OSI Layer AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA AAAATransportation AAAAAAAA AAAAAAAA AAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAA

Figure 7: Agent Architecture

3.3

ARCHITECTURE OF THE MAMBA MULTI-AGENT ORGANIZATION

Organizational multi-agent systems differ from other types of DAI systems in that they are integrated with a human enterprise. Within the context of MAMBA, this enterprise is supposed to be a bank. Typically, bank organizations involve deep functional (i.e. product-oriented) hierarchies, in general combined with a second structure, typically that of a geographic hierarchy. By this way, the basic structure of a typical bank organization can be described as a two-dimensional lattice, which exhibits one single central root node (headquarters, global responsibility for all bank products). The design of the structure of a bank requires organizational designers to develop an appropriate concept of roles (i.e. triples of the form [task, competence, responsibility]) and to assign roles to agents, to establish a network of communication channels, to provide a set of coordination mechanisms, to define control flows across the organization, to implement organizational barriers within the enterprise and between the enterprise and its environment, and to design those constraints that determine to which degree the bank is able to reorganize its internal structure according to the needs imposed by the market and its social and political environment. The MAMBA multi-agent organization addresses these requirements as far as they make sense with respect to the design of a DAI system. Thus, the design of MAMBA simulates the functional structure of a bank in that it provides a three-layered, product-oriented architecture: the enterprise layer, the organizational units layer, and the

15

individual agents layer. The architecture of the multi-agent organization represents the decomposition of tasks, the division of labor, and, as such, it serves as a long-term coordination framework [12] for the whole system.

Figure 8: The MAMBA Multi-Agent Organizational Structure (Schematic Representation)

The schematic representation of the multi-agent organization depicted in figure 8 indicates: —

The artificial enterprise represented by the MAMBA overall architecture can be characterized as a global search space, which spans over the set of processes provided by the different departments and individual actors together with the set of operators that allow to interconnect, and to modify these processes.

—

Departments are embedded into the MAMBA multi-agent banking organization. For reasons of simplicity, the relevant components on the level of the enterprise as such have been omitted (see figure 3). As the MAMBA multi-agent organization is a computational entity, it does not include (informal) social groups. However, it is still consistent with the organizational model outlined in section 2.1.

—

The architecture of the departments (which are computational l organizational units) refers to the concept of planning in autonomous systems, which distinguishes strategic planning from tactical planning and plan execution [19]. Thus, within MAMBA, the aims and objectives agent represents the level of strategic planning, the product design agent is responsible for tactical planning, and the execution level is represented by the contract processing agent.

16

—

Each department is able to act as an autonomous, self-contained organizational unit which provides a particular class of products to the market (e.g. different types of credits within MAMBA/CAS).

—

Each department comprises several agents which exhibit different organizational roles. One of these agents acts as the head of the department, the others provide the necessary (local) functions.

—

Departmental agents are allowed to engage the department into a particular task, they provide the departmental interface to its environment, and they act as a coordinating agent [29] within their local organizational unit. Individual agents plan and act on their own, their plans comprise a set of individual activities (i.e. each individual plan refers to a different organizational procedure).

The problem solving capability of the MAMBA multi-agent organization depends on its ability to select and involve the best suited agents for the problem at hand, to instantiate the appropriate organizational structure, and to apply (and to adapt!) different types of coordination mechanisms. These criteria define the flexibility of the MAMBA multi-agent organization. Within MAMBA, organizational flexibility is basically achieved by multiagent planning, which may be coordinated by the respective departmental agents or which may also evolve as a collaborative activity among single agents being members of different departments. Figure 9 depicts a virtual department that was installed as a result of the creation of a (partial) global plan (i.e. a business process) on the enterprise level. The different agents involved in that virtual department are still connected to their local organizational units; i.e. they are still obliged to approach the respective local aims, to perform the respective local reporting procedures, etc. At this point it should be mentioned that the organizational model of MAMBA can no longer be covered by conventional organizational theories, which primarily focus on the structuring of organizational bodies. Instead, the problem solving behavior of MAMBA fully relies on its ability to dynamically create virtual departments (i.e. task forces). And, the creation of these virtual bodies relies on the ability of MAMBA to configure and modify formal representations of business processes which are performed by (centralized or decentralized) multi-agent planning.

17

Figure 9: Virtual Department within MAMBA (Schematic Representation)

3.4

CORBA: IMPLEMENTING AGENT INTERFACES

Computational agents in our model are capable of coherent, distributed communication that is independent of the internal structure, resources and capabilities of their underlying information systems. They interact with one another by viewing the network as a single dedicated knowledge object space and ignoring any spatial distribution of objects or agents, respectively[33]. This implies, first of all, the existence of some standard communication network to interconnect the computational agents and the ability of these agents to communicate by exchanging messages. In our model interconnection is provided on the basis of an implementation of CORBA which can be seen as the communication backbone of the Object Management Architecture (OMA) [32]. OMA was defined by the Object Management Group (OMG), a consortium of more than 350 companies which among others wish to standardize (transparent) access to objects within a heterogeneous network. CORBA is the first component of the OMA to be standardized. In the object model of the OMG a request and the appropriate result are the central means of communication between objects (in the terminology of this paper we can equate objects and agents). A

18

request consists of an operation name and the appropriate parameters. Such signatures of operations must be defined with the help of the interface definition language (IDL); i.e. the means of communication are signatures written in IDL. Objects are identified by a unique object identity. They can react to a number of object-specific messages. After objects have made themselves known to the system, message passing is performed transparently; i.e. the message sending object does neither need to know the location of the receiving object nor any implementational issues. If pre-existing information systems are to be included into our network of computational agents, they first have to meet the specification of the CORBA standard. However, this solves only the problem of pure communication. But agents must not only be able to receive messages; they also must understand the message and react to it. Therefore, we must further attach appropriate front-end extensions to the pre-existing information systems to enable them to actively participate in a cooperative problem solving process: each pre-existing information system needs to be equipped with some (epistemic) knowledge of other ones. Another issue here concerns the integration of information systems. On the organizational level two distinct concepts of integration can be identified. The first one considers the pre-existing information system as being a passive data storage medium only. That is, the information system is supposed to provide standard data access facilities which can be used by individual agents to improve or broaden their knowledge. The second one refers to the concept of organizational autonomy. It requires the information system to behave as an intelligent computational agent. In that case the integration of the information system requires an agent shell which encapsulates the database [37]. As a consequence, each data request needs to be addressed to the respective agent which then decides on its own whether it is able and willing to participate in a cooperative task and if, how it wants to fulfill the request. Whenever we are concerned with the modeling of business processes and workflows these different concepts of integration play an important role for the task of organizational design. On the technical level the first concept refers to loose coupling of a computational agent and a (set of) data base(s); i.e. loose coupling implies that agent and the databases are autonomous systems which run independently from each other. The second approach is usually bound up with tight coupling between the agent shell and its local data base; i.e. the database and its intelligent shell form an integrated whole (e.g. see figure 3 above).

19

4 ENGINEERING AND CUSTOMIZATION BUSINESS PROCESSES

4.1

OF

COMPUTERIZED

THE MAMBA PLANNING APPROACH

Within MAMBA, we aim to develop of what one may call an artificial enterprise, i.e. a fully computational bank organization. This requires us to establish an appropriate regime of coordination mechanisms which are flexible enough to support different types of organizational structures, depending on the current coordination situation and the problem at hand. Further, the coordination mechanisms need to support the organizational concept of business processes and workflows. As a result of an evaluation of various process representation concepts we have, due to their conceptual equivalents, decided to formally represent (organizational) processes as multi-agent plans. Such an approach offers some useful advantages: it allows us to understand business process engineering as a kind of multi-agent planning which is quite useful in the context of decentralized organizational settings. By this way, we inherit a diversity of multi-agent planning algorithms by which quit different types of planning problems can be addressed. Thus, for the remainder of the paper the notion of plans and that of processes are used as synonyms. The planning approach being developed within MAMBA draws from the organizational background of the project. Thus, the first issue to be addressed was the simulation of the different organizational layers within an organization. This has given rise to involve the concept of generalized Partial Global Planning (gPGP, [6]). To this purpose, we have established a three-layered, vertically integrated hierarchy of multi-agent plans: organizational procedures refer to local plans (within one single agent), they can be abstracted to node plans which refer to the concept of workflows, thus hiding those details that are not relevant to the environment of an agent. Node plans are coordinated through partial global plans, which, within MAMBA, represent business processes. Partial global plans represent an holistic view to a self-contained organizational task, and they may involve one or more departments of MAMBA. On this basis, the gPGP approach provides the conceptual framework together with the respective design decisions needed to implement the coordination concept. The second problem to be addressed is the task of business process re-engineering. This requires to provide mechanisms by which already existing processes (plans) can be modified in order to adapt them to the current coordination situation, which is made up of four different components: (1) the current status of the environment of the multi-agent organization, (2) the current status of the multi-agent organization as such, (3) the current status of the planning agent, and (4) the planning task at hand. E.g., the status of the multi-agent organization involves the agents that are available, the set of currently active problem solving processes, and the resources that can be bound to the plan under development. With respect to business process re-engineering the concept of plan coordination has proven useful [29].

20

Table 2 relates the MAMBA multi-agent planning approach to the planning concepts discussed in section 3.1. It essentially integrates generalized Partial Global Planning with plan coordination. However, it differs from other DAI planning concepts in that it grounds on a sound organizational theory, i.e. it is directly intertwined with processes and process management on the level of the (human) banking enterprises. This must be considered being the most important advance of the MAMBA multi-agent planning concept.

MAMBA, 1994

category

domain

agent model

plan

DPS/ PC

private banking

DAI-based plan coordination skills, computational agents

org. procedure - workflow business process

plan interactions

main problem addressed

parent-child and PGP- (plan) process like horizontal/ engineering and vertical relationships, re-engineering, positive / harmful interactions

Table 2: The MAMBA Planning Concept

4.2

BUSINESS PROCESS ENGINEERING THROUGH COOPERATIVE PROCESS MODELING

With respect to modeling devices coming along with current workflow management systems two shortcomings can generally be observed: —

Processes can not be modeled comfortably because of the underlying models being flat. This means that processes can only be built out of elementary (atomic) actions that are unable to refer to already existing and modeled processes. Therefore, it is difficult to appropriately handle process complexity since these models can not reflect different levels of abstraction with respect to the same process.

—

Processes can not be modeled completely because of the underlying models not being expressive enough. These models only allow for the isolated modeling of processes, because interactions between different processes can not be represented.

To overcome these drawbacks and to arrive at an efficient process modeling by using plans, four categories of process modeling operations must be supported by plan operators. These are the categories of modification and abstraction of single processes and, on a somewhat higher level, the modeling of interactions (dependencies) between different processes and dependencies of processes on their environment. Due to limited space we can just give an idea of what these categories mean by naming a few operations as examples for the whole category. The way how this can be achieved by using plans is shown in the subsequent section where plans will be introduced on a formal basis. However, in this section we shall already use them in a simplistic way as something that abstractly stands for a process. Thus we are going to illustrate what should be realized for process modeling.

21

Moreover, this motivates, how plans are formalized in the next section. Plans are represented by upper case letters, while representations of actions (process elements) are represented by lower case letters. Modification of Processes This is the most elementary category of process modeling. One must be able to comfortably construct or modify a plan for any given process independently of its logical structure. Comfortably in this context means, for example, that it must be possible to construct new plans out of given ones, what enables the modeling of complex processes without being forced to build them only out of atomic actions. —

A and B are composed to make configuration C. A simple example is the sequence.

—

A is removed from B resulting in the model C. E.g. caused by a reorganization. A, so long a part of B, is to be removed from it.

Abstractions on Processes and Actions In almost every planning domain where complex products have to be constructed anew it is usual that specification goes top down, i.e. from more abstract to more detailed versions. Exactly the opposite, bottom up, is important for reasons of interactions with other participants. To communicate as efficiently as possible it is necessary to enable the selection of the appropriate level of abstraction so that details that are not relevant to the partner can be left out. —

C is the refinement of B, with b2 ∈ B having been refined by A. There is one element which is refined by A. In section 4.4 an example will be given for this operation (refine (a, P´) (P)).

—

B is the generalization of C, with A having been removed from C. Exactly the inverse operation to "refine".

Figure 10: Refinement and Generalization of Processes

22

Modeling of Interactions among Processes The realization of this category should remedy the second drawback introduced in the beginning of this section. Using plans as representation for processes must enable the explicit modeling of interactions between different processes. —

Action b ∈ B calls A and halts B´s execution until A is completed. Most simplistic kind of a mutual dependency (e.g. subprocedure call).

—

A and B interact synchronously. Interactions might relate to message passing, mutual exclusive use of resources, etc. As a consequence the executions of A and B have to be synchronized. In other words: A interferes with the execution of B by means of synchronization (et vice versa).

Modeling of Interactions of Processes with their Environment This category ensures to have processes as a whole being explicitly made dependent on certain external conditions (situatedness). This applies, for example, to a process that is dependent on the validity of a special law. —

In a certain situation s A must not be executed. Precondition for A: ¬ s

—

In a certain situation s A and B are exclusive alternatives. Precondition for A: ¬ s ∨ ¬ running (B), Precondition for B: ¬ s ∨ ¬ running (A)

4.3

PLAN MODEL FOR MAMBA/CAS

The operations introduced above are to be used to implement the planning procedure within MAMBA. In order to have a formal basis for them a plan model is needed that is expressive enough to represent the independent dimensions implied by the first two categories and the requirements implied by the last two. The basic concepts of our model were derived from a similar formalism first introduced by v. Martial [29].

23

Modification of Processes ⇒ Process dimension We have to describe processes that are made of actions and knowledge about these actions, i.e. their ordering with respect to certain conditions (logical structure). Consequently the plans representing them consist of two sets. The first set, A, contains the actions that the respective process is made of and the second set, CON, is filled with constraints and conditions (e.g. pre- / postcondition) for the actions together with the relationships (e.g. sequential / parallel) between them. plan_model´ ::= (A, CON) There are two kinds of actions: Actions that are atomic with respect to their domain and actions that have to be refined (made more concrete) in order to become operational. These non-atomic elements that correspond to processes together with the operation refine enable the composition of more complex processes out of less complex given ones. Abstractions on Processes and Actions ⇒ Granularity dimension The planning procedure mainly consists of repeated refinements of actions that are part of a certain process and are not yet atomic. This iteration stops as soon as a process exclusively consists of atomic actions. The history of this procedure is reflected by the granularity of actions being inserted through refinement. It may be visualized by a tree that represents processes at various levels of abstraction. The nodes are actions and the edges show the refinement relationships from more abstract (coarse-grained) to more concrete (fine-grained) actions. So the leaves of our tree might be viewed as the most operational actions reached at this stage of planning. The operation refine corresponds to adding a part of a new leaf level to our tree, whereas the operation generalize corresponds to removing a part of the old leaf level from our tree (see figure 10).

Figure 11: Process Model Dimensions [29]

24

To reflect the second granularity dimension as stated above we have to insert the set REF for the refinement relationships to our plan_model´ and arrive at: plan_model ::= (A, REF, CON) with REF 5 A % A The set REF consists of tuples of actions representing the refinement relation or granularity dimension between those actions (edges in the respective tree). Modeling of Interactions among Processes Since interactions among processes necessitate a fine-grained control these interactions have to be modeled on the level of actions (i.e. plan elements). Special atomic actions, like call and wait, were introduced and can be used like the basic actions of a process. Modeling of Interactions of Processes with their Environment The set CON contains preconditions for the actions on every level of abstraction of the plan. This is also true for the top level action that stands for the whole process and in the case that no such action exists can always be introduced. Therefore a precondition for this action corresponds to a precondition of the process. The predicate SEQ(a, b) mentions a sequence of the actions a and b, the predicate PRE(a, pc) stands for a precondition pc that must be fulfilled in order to make action a executable. Let P = (A, REF, CON) be a plan representing process p with a being the only top level action in P and pc be a precondition for p. Then the expression P´= (A, REF, CON ∪ {PRE(a, pc)}) with root (a, P´) ⇔ ¬ ∃ a´∈ A:(a´, a) ∈ REF models that the process p represented by P´ can only be executed iff pc is true.

4.4

EXAMPLE:

PLAN REFINEMENT IN MAMBA/CAS

Let P = (A, REF, CON) and P´= (A´, REF´, CON´) be plans. Then the refinement of action a by the plan P´ is defined by refine (a, P´) (P) = (A∪A´, REF∪REF´∪{(a, a´)|a´∈A´ ∧ root(a´, P´)}, CON∪CON´) To make it more clear the planning procedure will be explained by refining a process model describing the necessary actions to be executed by the Credit Advisory System (see section 2.2).

25

Figure 12: Plan Refinement

In order to perform a comprehensive task, e.g. a credit application, that exceeds the capabilities of a single agent a group of agents approaches this task cooperatively. This is illustrated in figure 12 by the overlapping rectangles which represent the respective tasks or actions of the credit design agent, the credit rating agent and the departmental aims & objectives agent. The agent we will focus upon is the credit rating agent, a member of the credit department, the head of which is the credit manager agent. We will not elaborate on the necessary consultation process between different agents, but on how a single agent produces his local process model for those actions he wants to perform by himself. At planning phase n the top part of the model presented in figure 12 has been constructed. For our example we will concentrate on the actions ai11 and ai12. The first one „call for security“ is atomic and can be realized by a letter generated automatically. The second action may be refined by action ai121 and depending on the kind of security the customer did provide dynamically by actions ai122, ai123, ai124. Because dynamics and context-sensitivity of process model refinement is beyond the scope of this paper, we will not elaborate on this. Instead, within this example, we assume static planning. Therefore, action ai12 can be refined

26

by the action ai121 together with one of the three alternative checking procedures ai122, ai123 and ai124 each of them being specialized to the respective kind of security (paintings, real estate or deposits) the customer may provide. Supposed ai12∈A and P = (A, REF, CON) is the plan before refinement. The non-atomic action ai12 is to be refined by plan P´ = ({ai121, ai122, ai123, ai124}, ∅, {SEQ(ai121, ai122), SEQ(ai121, ai123), SEQ(ai121, ai124), PRE(ai122, painting(security_object)), PRE(ai123, deposit(security_object)), PRE(ai124, real_estate(security_object))}). So refine (ai12, P´) (P) = (A∪{ai121, ai122, ai123, ai124}, REF∪{(ai12, ai121), (ai12, ai122), (ai12, ai123), (ai12, ai124)}, CON∪{SEQ(ai121, ai122), SEQ(ai121, ai123), SEQ(ai121, ai124), PRE(ai122, painting(security_object)), PRE(ai123, deposit(security_object)), PRE(ai124, real_estate(security_object))}).

5 CONCLUSION Today´s enterprises are challenged by a rapidly increasing demand to flexibilize their internal structures. They urgently need to customize their internal processes in order to be able to provide competitive products to the market. These requirements have already stimulated huge research efforts in organizational theory, whilst information technology research on how to support customization of computer-based business processes has not been adequately investigated yet. This paper has addressed the question of how coordination in decentralized, process-oriented organizations can effectively be supported by modern information technology. More specifically, it addresses the issue of cooperative organizational problem solving within such settings in that it suggests to base system design on the concept of multi-agent planning. The approach presented in this paper allows us to apply multi-agent planning as a tool to achieve, at least partially, automated business process (re-) engineering and, via an appropriate design of local and global aims, to proceed towards automatic process customization. To model and modify multi-agent plans two sets of interaction types (interactions among process models, interactions among a process model with its environment) and two sets of modeling operations (modifications, abstractions), which can be performed on process models, were introduced. The validity of this approach was demonstrated by a credit application example which shows how a multi-agent system can create a multi-agent plan through plan refinement instead of starting such a task from scratch as it is necessary in most other multi-agent systems. The results of this paper extend current Distributed AI research in that they contribute to make Distributed AI planning techniques more operational for applications like enterprise integration and business process management. Moreover, our research approach contributes to the integration of organizational theory and the design of distributed and cooperative information systems. This has been achieved by taking the information

27

system's perspective of organizational multi-agent systems which is exactly complementary to the computerized organization perspective in recent organizational theory. A first prototype of MAMBA is currently under development. It is implemented on a network of SUN workstations on the basis of HP Distributed Smalltalk which is an extension of VisualWorks of ParkPlace Systems in the direction of distributed computing. HP Distributed Smalltalk fully implements the CORBA standard. Future work within the MAMBA project will concentrate on three key issues: (1) development of a multi-agent planning toolkit in order to support problem-related selections of multi-agent planning strategies, (2) investigation of the interactions between the different planning concepts and dynamically instantiated organizational structures of the MAMBA multi-agent organization, and (3) empirical evaluation of the applicability of the conceptual and technical approach of MAMBA to real-world bank settings.

ACKNOWLEDGMENTS This work was funded in part through the DAAD Anglo-German Academic Research Grant (ARC, 313-ARC-VII93/89/scu) entitled Multi-Agent INtentionality (MAIN) and through a Research Grant donated by the German Research Foundation (DFG, Un 94/1-1).

REFERENCES [1] Bond, A.; Gasser, L.: Readings in Distributed Artificial Intelligence, Morgan Kaufmann Publishers, San Mateo, CA., 1988. [2] Chaib-draa, B., Moulin, B., Mandiau, R., and Millot, R.P., Trends in Distributed Artificial Intelligence, Artificial Intelligence Review, 6, pp. 35-66, 1992. [3] Cammarata, D., McArthur, R., Steeb, R., Strategies of Cooperation in Distributed Problem Solving, IJCAI-83, pp. 767-770. [4] Corkill, D., Hierarchical Planning in a Distributed Environment, IJCAI-79, pp. 168-175. [5] Davenport, H., Innovating Processes, Harvard Business Press, 1993. [6] Decker, K., Lesser, V., Generalizing the Partial Global Planning Algorithm; International Journal of Intelligent & Cooperative Information Systems ;Vol. 1, No. 2; June 1992, pp. 319-346. [7] Decker, K., Lesser, V., Designing a Family of Coordination Algorithms, Technical Report, University of Massachusetts, Amherst, MA, May 27, 1994.

28

[8] Durfee, E.H., Lesser, V.R., Using Partial Global Plans to Coordinate Distributed Problem Solvers, IJCAI-87, pp. 875-883. [9] Farhoodi, F., Proffitt, J., Woodman, P., and Tunnicliffe, A., Design of Organisations in Distributed Decision Systems, AAAI-Workshop on Cooperation Among Heterogeneous Intelligent Systems, 1991. [10] Fikes, R.E., Nilsson, N., STRIPS: a new approach to the application of theorem proving to problem solving, Artificial Intelligence, 3(3-4), pp. 189-208, 1971. [11] Fox, M.S., An Organizational View of Distributed Systems, IEEE Transactions on Systems, Man and Cybernetics, SMC-11, 1981, pp. 70-80. [12] Gasser, L., DAI Approaches to Coordination, in: Avouris, N.M & Gasser, L., (eds.), Distributed Artificial Intelligence: Theory and Praxis, pp 9-30, Computer and Information Science Vol 5, Kluwer Academic Publishers, 1992, p. 31-52. [13] Gelernter, D., Carriero, N., Coordination Languages, Communications of the ACM, 35:2, February 1992. [14] Ginsberg, M., Decision Procedures, in: M. Huhns (ed.), Distributed Artificial Intelligence, Morgan Kaufman Publishers, 1987, pp. 3-28. [15] Georgeff, M., Communication and Interaction in Multiagent Planning, AAAI 83, pp. 125-129. [16] Hammer, M., Reengineering Work: Don't Automate, Obliterate, Havard Business Review, July-August 1990, pp. 104-112. [17] Hastings, C., The New Organization: Growing the Culture of Organizational Networking. McGraw Hill, London et.al., 1993. [18] Hern, L. E. C., On Distributed Artificial Intelligence, The Knowledge Engineering Review, Cambridge University Press, 1988. [19] Hertzberger, L.O., Groen, F.C.A. (eds.), Intelligent Autonomous Systems, North-Holland, 1987. [20] de Jong, P., A Framework for the Development of Distributed Organizations, Proc. of the IJCAI-91 Workshop on Intelligent & Cooperative Information Systems: Bringing AI & Information Systems Technology Together, Darling Harbour, Sydney, Australia, August 25, 1991, pp. 1-27. [21] Kirn, St., and O’Hare, G. M. P. (eds.), Towards The Intelligent Organization: The Coordination Perspective, Springer-Verlag London, 1995 (forthcoming). [22] Kirn, St., Scherer, A., and Schlageter, G., Problem Solving in Federative Environments: The FRESCO Concept of Cooperative Agents, in: Papazoglou, M. & Zeleznikow, J. (eds.): The Next Generation of Information Systems: From Data to Knowledge. Springer-Verlag, Berlin et.al., LNAI 611, 1992, pp185203.

29

[23] Kirn, St., and Schneider, J., STRICT: A Blackboard-Based Tool Supporting the Design of Distributed PPC Applications. Expert Systems with Applications, Special Issue on “Blackboard Paradigm and ist Applications”, Vol. 7, 1994, pp. 131-146. [24] Kirn, St., Supporting Human Experts Collaborative Work: Modelling Organizational Context Knowledge in Cooperative Information Systems, in: John H. Connolly, Ernest Edmonds (eds.): CSCW and AI. Springer Series on CSCW. 1994, pp. 127-139. [25] Kirn, St.: Competitive Knowledge Processing in Banking: State of the Art and Future Developments, in: Cooperative Knowledge Processing: The Competitive Edge in Banking IT. Special Issue of the International Journal of Intelligent Systems in Accounting, Finance and Management. Wiley & Sons. Issue 2, 1995. To appear. [26] Konolige, K., Nilsson, N.J., Multiple-Agent Planning Systems, AAAI 80, pp. 138-142. [27] Malone, T., Organizing Information Processing Systems: Parallels Between Human Organizations and Computer Systems, in: W. Zachary, S. Robertson, J. Black (eds.), Cognition, Cooperation, and Computation, Ablex Publishing Corporation, Norwood, NJ, 1988. [28] Malone, T. W., Crowston, K., Lee, J., Pentland, B., Tools for inventing organizations: Toward a handbook of organizational processes, CCS WP #141, Sloan School WP #3562-93. Massachusetts Institute of Technology, Sloan School of Management, Cambridge, Mass., May 1993. [29] v. Martial, F., Coordinating Plans of Autonomous Agents; Lecture Notes in Artificial Intelligence, No. 610. Springer-Verlag, Berlin, Heidelberg; Germany 1992. [30] Matsuda, T., Organizational Intelligence: Its Significance as a Process and as a Product, in: Proceedings of the International Conference on Economics/ Management and Information Technology 92, Tokyo, Japan, August 31-September 4, pp. 219-222, 1992. [31] Masini, G., Napoli, A., Colnet, D., Leonard, D. and Tombre, K., Object Oriented Languages, The A.P.I.C. Series, Harcourt, Brace, Jovanovich Publishers, 1991. [32] Object Management Group, 1st Object Management Architecture Guide; Document 92.11.1, edited by R. Solely. Framingham, MA 01701, USA 1993. [33] Papazoglou, M. P., Laufmann, S. C., and Sellis, T. K., An Organizational Framework for Cooperating Intelligent Information Systems, International Journal of Intelligent & Cooperative Information Systems Vol. 1, No. 1, March 1991, pp. 169-202. [34] Pattison, H.E., Corkill, G.G., and Lesser, V.R., Instantiating Descriptions of Organizational Structures, in: Huhns, M. (ed.): Distributed AI, 1987, pp. 311. [35] Sacerdoti, E.D., A., Structure for Plans and Behavior, New York, Elsevier Publishers, North-Holland, 1977. [36] Shoman, Y., Agent-Oriented Programming, Artificial Intelligence, 60 pp. 51-92, 1993.

30

[37] Steiner, D.; Mahling, D.; Haugeneder, H., Human Computer Cooperative Work, in: Proceedings of the 10th International Workshop on Distributed Artificial Intelligence, MCC Technical Report ACT-AI-355-90, Austin, Texas, 1990. [38] Stephens, L., Merx, M., Agent Organization as an Effector of DAI System Performance, Ninth Workshop on Distributed Artificial Intelligence, Rosario Resort, Eastsound, Washington, September 12-14, 1989, pp. 263-292. [39] Tapscott, D.; Caston, A., Paradigm Shift — The New Promise of Information Technology, McGraw-Hill Inc., New York et.al., 1993. [40] Wooldridge, M.J., O'Hare, G.M.P., Deliberate Social Agent, Proc. 10th U.K. Planning Workshop, University of Cambridge, April 1991. [41] Warnecke, H.-J., Die Fraktale Fabrik — Revolution der Unternehmenskultur, Springer-Verlag, 1991 (in German). [42] Yonezawa, A., (ed.), ABCL: An Object-Oriented Concurrent System, MIT Press, Cambridge, Mass., 1990.

31