Interorganizational Workflow Management

Table of Contents

1 Introduction

2 Workflow Management
2.1. Requirements on WfMSs
2.2. Workflow Modeling
2.2.1. The Functional Aspect: Workflows and Activities
2.2.2 The Operational Aspect: Applications
2.2.3. The Behavioral Aspect: Control Flow
2.2.4. The Informational Aspect: Data Structures and Data Flow
2.2.5. The Organizational Aspect: Structure and Population
2.2.6. The Causal Aspect: Regulations and Dependencies
2.2.7. The Historical Aspect: Logging
2.2.8 The Transactional Aspect: Workflow Consistency
2.3. Workflow Analysis
2.4. Workflow Enactment
2.5. Architecture of WfMSs
2.5.1. Generic Workflow Product Structure of the WfMC
2.6. Limitations

3 Introduction to Interorganizational Workflows
3.1. Concepts for Interorganizational Workflows derived from Conventional Workflow Management
3.1.1. Task Assignment
3.1.2. Interorganizational Control Flow
3.1.3. Interorganizational Data Flow
3.2. Business Scenario
3.3. Partitioning of Workflows
3.4. Models of Workflow Interoperability
3.4.1. Centralized Process Management or Capacity Sharing
3.4.2. Chained Subprocesses or Chained Execution
3.4.3. Nested Subprocesses, Subcontracting or Service Outsourcing
3.4.4. Transaction Group
3.4.5. Parallel Synchronized Model or Multi-Processes Interoperation / Federation
3.4.6. Case Transfer
3.4.7. Extended Case Transfer
3.4.8. Loosely Coupled Processes
3.4.9. Peer-to-Peer Collaborative Process Management
3.4.10. Summary

4 Standardization for Interorganizational Workflows
4.1. Open-edi Reference Model
4.2. Levels of Standardization

5 Requirements for Interorganizational Workflow Management
5.1. Relevance of Requirements for Conventional Workflow Systems
5.2. Requirements Catalog
5.2.1. Build-Time
5.2.2. Run-Time
5.2.3. Requirements Independent of the Phases

6 Approaches, Projects and Initiatives
6.1. Traditional EDI
6.2. Workflow Management Coalition (WfMC)
6.3. OO-edi
6.4. Electronic Workflow Trading
6.4.1. Electronic Marketplace, ACE-Flow
6.4.2. Electronic Contracts, Cross Flow Project
6.4.3. Event-Services, EVE
6.4.4. Process Model Fragments
6.5. XML-based Commerce Languages
6.5.1. RosettaNet
6.5.2. BizTalk
6.5.3. eCo
6.5.4. ebXML

7 Evaluation
7.1. Supported Models of Interoperability
7.2. BOV or FSV?
7.3. Build-Time
7.3.1. Automation
7.3.2. Support for Collaborative Process Definition
7.3.3. Privacy of Internal Processes
7.3.4. Being able to cope with Heterogeneous Workflow Environments
7.3.5. Integration Effort and Integration Know-How
7.3.6. Support for a High Number of Partners
7.4. Run-Time
7.4.1. Automated Selection of Optimal Service
7.4.2. Ensure Quality of the Outsourced Operation
7.4.3. Security
7.4.4. Flexibility
7.4.5. Document Management
7.5. Autonomy of Partners
7.5.1. Design Autonomy
7.5.2. Communication Autonomy
7.5.3. Execution Autonomy
7.5.4. Association Autonomy
7.6. Transparency
7.7. Distribution
7.8. Summary of Evaluation

8 Summary, Contribution and Outlook

Appendix - Glossary

References

List of Figures

Figure 2-1. Types of Data in Workflow Management Systems [WfMC99a]

Figure 2-2. Generic Workflow Product Structure [Holl95]

Figure 3-1. Interorganizational Control Flow [DDDE00]

Figure 3-2. Processes at Telco and Logis [DDDE00]

Figure 3-3. Horizontal and Vertical Partitioning

Figure 3-4. Centralized Process Management [Aals00b]

Figure 3-5. Chained Subprocesses [Aals00b]

Figure 3-6. Nested Subprocesses [Aals00b]

Figure 3-7. The Parallel Synchronized Model of Interoperability [WfMC96]

Figure 3-8. Case Transfer [Aals00b]

Figure 3-9. Example (Extended) Case Transfer

Figure 3-10. Loosely Coupled Processes [Aals00b]

Figure 3-11. Example Loosely Coupled Processes

Figure 3-12. Peer-to-Peer Collaborative Process Management [ChHs01]

Figure 3-13. Partitioning Dimensions of the Models of Workflow Interoperability

Figure 3-14. Models of Workflow Interoperability

Figure 4-1. Open-edi Reference Model [EdiI96]

Figure 4-2. Three Levels of Standardization [Huem01b]

Figure 6-1. The Workflow Reference Model [Holl95]

Figure 6-2. ACE-Flow System [SRKT00]

Figure 6-3. Sequence in Bidding and Execution [SRKT00]

Figure 6-4. Contract and Workflow Level [KGV00]

Figure 6-5. Making Contracts [KGV00]

Figure 6-6. The CrossFlow Architecture [KGV00]

Figure 6-7. Architecture of EVE and Example Workflow System [GeTo98]

Figure 6-8. Multiple Vertical Connection [LiDe99]

Figure 6-9. Horizontal Connection of Three Fragments [LiDe99]

Figure 6-10. Partner Interface Process (RosettaNet) [ChHs01]

Figure 6-11. The Common Business Library [GTM99]

Figure 6-12. Fragment of an XML Service Definition [GTM99]

Figure 6-13. Use of ebXML [Huem01b]

Figure 6-14. High-Level Overview of ebXML Interaction between two Companies [Mert01]

Figure 7-1. Supported Models of Interoperability

Figure 7-2. Overview

Chapter 1

Introduction

Conventional workflow management focuses on improving the efficiency of business processes within one organization. However, today’s corporations are challenged to cross organizational boundaries. Besides traditional business relations, as supplier, partner or customer, new forms of collaboration between enterprises come into existence due to increased competition and globalization, e.g. virtual enterprises or the trend to outsourcing.

Until recently, given the significant effort and investment required to deploy the necessary technology, business-to-business electronic commerce was a prerogative of large enterprises with well established commercial links. Nowadays, the advent of the Internet and the proliferation of inexpensive computing power in the form of clusters of workstations or PCs has changed this situation. Small and medium enterprises can now afford to engage in business-to-business electronic commerce by using the Internet to link their information processing systems. With the hardware infrastructure in place, there is a great demand for software support.

The benefits expected from supporting not only internal, but also cross-organizational processes are e.g. reduced costs due to automation, the possibility to redesign and optimize processes and to benefit from increased competition between service providers.

But conventional workflow systems are primarily designed for intra-enterprise process management, and they can hardly be used to handle processes with tasks and data separated by enterprise boundaries, for reasons such as security, privacy, sharability, firewalls, etc.

New concepts to support cross-organizational processes are needed. There are numerous research issues in the field of interorganizational workflows, such as how to model these workflows and the virtual enterprise in which they are executed, how to deal effectively with heterogeneous workflow environments, how to provide well-specified levels of autonomy of partners in a virtual enterprise, and how to support dynamic formation and dismantling of existing collaborations (a business partnership may be created dynamically and maintained only for the required duration such as a single transaction).

The approaches to interorganizational workflow are diverse: The work of the Workflow Management Coalition (WfMC) is focused on the technical level and provides a reference architecture and standard application programming interfaces (APIs) for workflow management systems (WfMSs). Traditional EDI and XML-based approaches are interface based, and usually connect different WfMS by exchanging messages. Approaches like electronic marketplaces or electronic contracts introduce market brokers that match business partners and mediate between them.

The aim of this diploma thesis is to provide a description and evaluation of the most important approaches to interorganizational workflow management. Requirements have to be elaborated, which will be used as criteria for the evaluation.

The diploma thesis is structured as follows:

Chapter 2 gives an introduction to conventional workflow management. Chapter 3 introduces into the area of interorganizational workflows and describes the different models of workflow interoperability in order to provide an overview, what different views on interorganizational workflows exist. It also contains examples for the different models.

Chapter 4 describes reference models for standardization activities in the area of EDI, which is closely related to interorganizational workflows.

In Chapter 5, the requirements on systems that support interorganizational workflows are elaborated. They are grouped into build-time of the interorganizational workflow system and run-time.

Chapter 6 describes the most important approaches, projects, and initiatives, which are evaluated in Chapter 7.

Finally, Chapter 8 concludes the diploma thesis with a summary, conclusion and outlook. Important terms are explained in a glossary.

Chapter 2

Workflow Management

In this chapter, the term workflow management is explained and different functional and qualitative requirements for workflow management systems are discussed. The two main services each WfMS should support are workflow modeling and enactment. In order to be able to reason about and to optimize business processes, a third service has to be provided by a WfMS: workflow analysis. Modeling, analysis, and enactment of workflows are not sequentially ordered steps one following after the other, but are rather interleaved and incremental subtasks of workflow management. Afterwards, architectural issues for WfMSs will be introduced and the limitations of WfMS will be listed.

Definition: A workflow is the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. [WfMC99a]

Definition: A workflow management system is a system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. [WfMC99a]

This definition of a workflow management system follows the Workflow Reference Model of the WfMC (see Section 6.2.) However, there is only little agreement on what workflow management means and which features a workflow management system should provide. Therefore, the introduction to workflow management in this chapter is not based on a certain system. Rather it is tried to describe the concepts independently from any system as far as possible. Therefore, it is an idealized view upon WfMS. Real WfMS will only offer parts of the functionality described.

Since workflow technology seems essential for so many organizations, great research efforts have been put on workflow management systems for several years. The story of workflow management systems - which originally have been named office information systems - goes back to the late 70ies, when Zisman presented a simple office procedure support system based on augmented petri-nets and e-mail technology [Zism77]. The boom, however, started almost ten years later, when technology was mature to meet at least some basic requirements of workflow management systems. Especially better hardware, computer networks, user-interfaces and databases provide a solid ground for workflow management systems. [Raus97]

Computer support of analysis and execution of business processes is becoming more and more important for today’s business organizations in order to survive. Workflow management systems provide the technical basis for the support of business processes, i.e., they enable its computer-supported modeling and drive its execution while keeping specified constraints. Among others, five basic improvements in the quality of the business process are expected from WfMS [Raus97]:

- Effectiveness: Since a business process is explicitly represented within a WfMS, it can be more easily adapted to changing situations.
- Efficiency: One of the most important criteria for efficient business processes is the reduction of the runtime of processes, e.g. by means of its parallelization, or by exchanging information between producer and consumer in-time.
- Transparency: In WfMSs, information about the business process as well as data processed by it is available within the whole organization independent from its storage location.
- Consistency: Due to control over processes and data, the WfMS is able to systematically maintain and monitor consistency requirements.
- Innovation: The installation of a WfMS within an organization requires reengineering of the organization’s basic business processes which usually results in improvements of their quality. [Raus97]

2.1. Requirements on WfMSs

According to [Rein93], the main goal of a WfMS is the transparent integration of applications running on different nodes of a distributed system by means of control flow and data flow mechanisms. The terms applications and distributed system in this respect are not further restricted in size, etc. but are used in its most general meaning. In this context, the integration of arbitrary existing software components with new ones is of major concern. According to these goals, the following requirements have been derived by Jablonski and Reinwald [JabI95], [Rein93]. [Raus97]

1. Distribution: Workflows are executed in a distributed environment. In big organizations, often a distributed system exists a priori, in which several WfMSs work together to execute the workflows of the organization. Thus, it has to be possible to transfer workflows from one WfMS to another for further execution.
2. Openness: The WfMS has to be open in that pre-existing infrastructure within an organization can be incorporated into the business processes. First, it is essential that available, possibly heterogeneous application programs are reused for new business process applications. Only then, the user is able to interact with software she or he is acquainted with. Second, parts of the system have to be easily replaceable by other parts with the same or more functionality without having to change large parts of the whole software architecture. Closely related to this requirement are reusability of legacy systems, and easy maintainability and extensibility of the business process applications realized by the WfMS.
3. Explicit Specification of a "Procedure Schema": This schema should contain a description of the pre-existing nodes of the distributed system where activities are performed, including their contexts in which they are to be performed, i.e. required data, and the order of execution of these activities. For the latter, sequential as well as parallel execution has to be supported. To perform a certain activity, a node may call an application program or simply inform a user to perform a manual activity.
4. Flexibility and Dynamic Change: Often it is necessary to change arbitrary aspects of the procedure schema, like the control flow, when the workflow is running. This should be possible without having to stop or to restart the workflow. Thus, concerning the control flow, the procedure schema must not be a "hard-coded" sequence of activities, but rather has to allow to flexibly choose an appropriate subsequent activity on the basis of actual data. In particular, this is necessary to allow flexible exception handling by means of alternative activities. Similar mechanisms are also needed for the flexible assignment of application programs or users to activities.
5. Support of Roles: Roles allow the specification of abstract organizational entities, i.e., a group of users from which a concrete user can be selected at run time according to the context of the activity to be performed. The support of roles, thus, allows the execution of activities of a workflow independently of the actual population of the organization.
6. Data Integration and Preparation: On every start of an activity, that activity has to be provided with the actual context of the workflow, i.e., the complete set of input data needed for the activity to perform. For an editing process, for instance, the corresponding activity might have to be provided with the document to be edited. Input data may be provided by former activities, and output data may be needed as input data by subsequent activities. Thus, data sources which are used by different activities in order to exchange data and which may be distributed and represented heterogeneously within these activities have to be logically integrated. The WfMS is responsible for an automated system-controlled data flow within the distributed system and for proper conversion of these data as expected by the different activities.
7. Synchronization of Activities: Several workflows which are instances of the procedure schema may be running at the same time and compete for shared resources to process required activities. Thus, upon start of an activity, active workflows requesting that activity have to be synchronized. Note, that this synchronization is independent from the workflow-internal synchronization of two parallel activities having a common successor activity (as in Subsection 2.2.3.).
8. Concurrency Control and Recovery: A workflow is inherently defined as cooperative task involving multiple users. Thus, consistency of data has to be ensured by means of concurrency control and recovery mechanisms similar to those of database systems.
9. Persistence: Typical workflows often last several months. In order to survive system crashes or temporary shutdowns of a WfMS, workflow relevant data including information about the current state of a workflow have to be persistent.
10. Security: Since workflows not only use public data, but also sensitive data, appropriate authorization mechanisms have to be provided to prohibit unauthorized access.
11. Scalability: For some application areas of WfMSs, a huge number of workflows has to be executed simultaneously. For example, in the area of electronic publishing [Blum93], [BQRT95], sometimes thousands of workflows are active concurrently. Also, the size of the distributed system is not restricted. Thus, scalability has to be a major concern.
12. Performance: WfMSs have to be performant to guarantee efficient execution within the distributed environment. An increase in workload must not result in a proportional decrease of the processing speed. [Raus97]

2.2. Workflow Modeling

This section presents a general model for the specification of workflows. In particular, the different aspects constituting a complete workflow description are discussed. [Raus97]

2.2.1. The Functional Aspect: Workflows and Activities

The functional aspect of a workflow description specifies what has to be executed. This is specified by means of workflow types which define logical units of execution. A workflow is an instance of a certain workflow type. It can be decomposed into smaller units, which can be further decomposed, and so on, until reaching elementary steps of execution. [Raus97]

A workflow which is used within another workflow is called subworkflow, and a workflow using another workflow is called superworkflow. A workflow at the outermost nesting level is called top-level workflow. Elementary workflows (or activities) are workflows at the lowest level of nesting and do not contain any subworkflow. They reference so-called applications (see Subsection 2.2.2.), whereas composite workflows contain further subworkflows. [Raus97]

Each workflow type is characterized by the following properties [Raus97]:

- Name: uniquely identifies the workflow type.
- Formal workflow parameters: Analogous to procedures in programming languages, input as well as output parameters can be distinguished. The parameters may be typed and may reference simple as well as complex data, like documents or drawings [KRSR97]

- Constraints: According to [Jabl95], constraints may be classified into workflow-internal and workflow-external constraints. Examples for workflow-internal constraints are maximal duration of the workflow, preconditions or postconditions. A typical example for a workflow-external constraint is the synchronization of two workflows: Only after the first (external) workflow has reached a certain state, the execution of the second (constrained) workflow may be continued.
- Workflow body: The workflow body contains the actual specification of the different aspects mentioned above, including the specification of subworkflows. [Raus97]

How these execution units are implemented is specified by the operational aspect discussed in the following subsection.

2.2.2 The Operational Aspect: Applications

Applications define how elementary workflows are implemented. Application in this context is used in its most general meaning, i.e. need not be a computer-supported task. Accordingly, several types of applications can be classified according to their implementation: First, there are applications realized by programs. The execution of such an application corresponds to the execution of the program or at least the call of a function. Programs are further classified into legacy programs and adaptable (or integratable) programs. While the former can hardly be integrated into a workflow since they cannot be modified a posteriori, the latter may easily be adapted to the WfMS’s interface. Whether a program is started automatically or by a certain user, is specified as part of the organizational aspect (Subsection 2.2.5.). Second, there are so-called free applications. These applications are not realized by means of predefined, implemented programs, but are rather simple descriptions of some piece of work. The user may decide, whether he or she uses a program or some computer-supported tool to accomplish the requested task. In this way, manual work can be integrated into a workflow type. [Raus97]

Analogous to a workflow type, an application is defined by means of several properties [Raus97]:

- Name, which uniquely identifies the application.
- Input and output parameters
- Constraints, further restricting the execution of the application analogous to workflow type constraints.
- Application body, which in case of programs simply references the program, and in case of manual tasks references the implementation of a wrapper that can be used to display parameters to the user or request them from the user. [Raus97]

2.2.3. The Behavioral Aspect: Control Flow

The behavioral aspect describes the control flow between the elements of a workflow, i.e. it defines when to execute a workflow or an activity in relation to each other, respectively. For the definition of such dependencies, several control flow constructs are used. Three basic control flow constructs are: sequence (serial execution), conditional branching (alternative execution) and unconditional branching (parallel execution). In case of alternative and parallel execution, some or all of the different execution paths are joined again at some later point. While in case of alternative execution no synchronization is necessary, parallel execution paths usually have to be synchronized at their ends, i.e. the subsequent activity may not be started before all preceding parallel activities have finished their execution. [Raus97]

However, often rather complex control flow descriptions have to be defined. In order to avoid large, confusing control flow descriptions realizing complex relationships between workflows and activities, it is thus inevitable to provide also higher level constructs. [Jabl95] suggests to provide macros which allow an application specific definition of higher level control flow constructs. They propose the following macros [Raus97]:

- Loops: like while-do, repeat-until and for loops, as also known from programming languages.
- Repetition: A subworkflow has to be repeated until a certain condition is true. The difference to a simple loop is that the various instances of the subworkflow may be initiated in parallel instead of executing them sequentially one after another.
- Optional Execution: Depending on the context, an optional subworkflow is executed or skipped. A generalization of conditional branching is reached by the construct m out of n allowing to execute m subworkflows selected from a set of n subworkflows.
- Series: This construct defines for a number of subworkflows to be executed sequentially and in any order, i.e., the order of execution is irrelevant. As example, [Jabl95] mentions security rules which forbid the parallel execution of critical tasks.
- Limitation: A subworkflow X which is limited by a subworkflow Y cannot be executed anymore, after Y has been started. Note, that this does not define that either X or Y necessarily have to be executed.
- Delay: If a subworkflow X is delayed by another subworkflow Y, its execution may start only after Y has been finished or as soon as it is sure that Y will not be executed at all. Again, the execution of both, X and Y, is optional.
- Existential Dependency: This dependency, which has been originally introduced for extended transaction models [ChRa92], specifies that a subworkflow X which is existentially dependent on another subworkflow Y only may be executed, if Y has already been executed or will be executed sometime in the future. [Raus97]

This set of constructs is not complete. Rather, it should show some examples of frequently needed control flow constructs. A WfMS need not support them necessarily as basic constructs, but should allow the user to define them by some means. In order to specify the semantics of the different macros, [JabI95] uses state transition diagrams showing possible states of a workflow (e.g., ready, running, etc.) and operations (e.g., start, execute) responsible for changing these states [Raus97].

This discussion of control flow constructs assumes a procedure-oriented approach. Another possibility for specifying the behavioral aspect of a workflow is an event-based specification. In an event-based approach, activities are triggered by events, which in their turn may be signaled due to actual processing states of the workflow. In this way, relationships between activities as described above can be realized. In addition, temporal events can be used to explicitly specify absolute points in time for starting activities, which is not possible in the procedure-oriented approach. Since both approaches have their advantages, at the conceptual level the workflow designer should have the possibility to use control flow constructs, which are well known and easier to understand than event-based ordering of activities, as well as time-events for the specification of absolute starting times of activities. [Raus97]

2.2.4. The Informational Aspect: Data Structures and Data Flow

Every workflow and every activity consume and produce data, which may be shared with each other. The informational aspect describes, on the one hand, the data flow between subworkflows or activities, respectively (horizontal data flow), and on the other hand the data flow between a superworkflow and its subworkflows (vertical data flow). Moreover, data can be classified into control data and production data [Jabl95]. Control data is data which is managed and controlled by the WfMS. They include data about the actual state of a workflow execution as well as the execution history of the workflow (see also Subsection 2.2.7.). Production data, on the contrary, are data which are managed by and used only within the control spheres of applications. They exist also in the absence of a WfMS, although they sometimes are used to control the workflow. In that case, they have to be exchanged between application and WfMS. By means of mapping such workflow relevant production data to control data (e.g., by mapping a document to a handle referencing this document) and vice versa, data flow between applications is controlled via the WfMS. [Raus97]

Abbildung in dieser Leseprobe nicht enthalten

Figure 2-1. Types of Data in Workflow Management Systems [WfMC99a]

The WfMC distinguishes control data, workflow relevant data and application data. (Figure 2-1.) Workflow relevant data (equal to workflow relevant production data above) is generated or updated by workflow application programs but serves as basis for navigation decisions or other control operations within the workflow engine. Application data is not accessible by the WfMS, although the workflow engines may be responsible for transferring such data between applications. [Holl95]

The proper transfer of documents (incl. document type mapping) needs to be handled [LiDe99]. Since the applicability of a WfMS is so many-fold and spans various application domains, a WfMS has to be able to support complex data types including the dynamic definition of new data types and integrity constraints for data types [ShMe88]. Moreover, due to the possibility to use a subworkflow as component in several different superworkflows, often data incompatibilities may arise. Either the types do not fit, or data are interpreted differently. In both cases, data has to be converted accordingly. Data conversions may be performed before or after the execution of a workflow or an activity. [Raus97]

Many WfMSs support the notion of a folder which groups control data and workflow relevant production data together. Every workflow type is assigned a certain folder type defining the kind and amount of data to be processed by the workflow type. Upon start of a workflow a new folder of the corresponding type is created and initialized. This folder, then, is passed from one activity to another providing input data for them and collecting output data from them. In this way, the folder provides a uniform and generic means for passing data between the various activities. [Raus97]

In [DiGr95], an enterprise-wide data model is suggested to be supported by a WfMS. This avoids, that different departments use data models which are not tuned with each other and often result in redundant data. The enterprise-wide data model may be divided into smaller submodels, which are maintained by the different departments. For the coordination of the datatypes within different submodels so-called interface-object types are introduced, which are created and maintained in a certain submodel and may be exported to other submodels. There, this interface-object type can be imported and used for the derivation of other object types. However, an enterprise-wide data model can comprise only control data and production data of new applications. The compatibility problems described above still exist as soon as legacy applications have to be integrated into the WfMS. [Raus97]

2.2.5. The Organizational Aspect: Structure and Population

Whereas the former aspects deal with the description of the functional aspects of a workflow model, this section discusses organizational aspects relevant for WfMSs. The organization of any enterprise is defined by its structure and by its population, i.e., personal and technical resources of the enterprise. In order to define who is intended to perform a certain activity, the organization has to be mapped onto the workflow model. The use of a WfMS must not depend on the organizational structure of a certain company, but rather the WfMS should allow to model arbitrary structures as they may appear in arbitrary companies. Unfortunately, many WfMSs assume a hierarchical structure and do not allow to configure it differently. [Raus97]

In order to define an arbitrary structure, only two generic concepts which may be combined arbitrarily have to be supported: organizational objects and organizational relationships. Organizational objects are further classified into agents and non-agents. Agents represent, e.g. employees, machines, server processes, or roles, while non-agents comprise virtual objects like departments, roles, or working groups. Agents are the "executors" of activities. Non-agents are primarily used to group agents. Organizational relationships define possible relationships between organizational objects. Typical examples for such relationships are is-member-of, is-manager-of, etc. [Raus97]

To specify who has to perform a certain activity, agents have to be assigned to activities. The use of an elementary resource, e.g., a certain employee, as agent often results in a workflow specification which is too inflexible to organizational changes. For example, what if the employee falls ill, or if its job is replaced by another person? Such organizational changes would result in a change of the workflow, too. In order to avoid these changes of workflows, the concept of roles has been introduced [BuJa94] which abolishes the static assignment between activity and agent. A role is described by a set of skills and competences, and in this way defines a set of resources able to play this role. As soon as an activity has to be performed for which a role has been specified as agent, one or more resources playing that role have to be selected. [Raus97]

As soon as one or more agents are selected to perform a certain activity, they have to be notified. This may, for instance, be done via e-mail, or via appropriate entries into a file, or by means of worklists used to manage a number of activities to be performed by the agent. [Raus97]

2.2.6. The Causal Aspect: Regulations and Dependencies

The causal aspect of a workflow model describes, why a certain workflow is specified in a certain way, and why it is executed at all. The first category of causalities is concerned with the general or company-specific legal basis of a workflow. For example, a business might state that at least two managers have to approve a business trip of an employee. Such rules have to be mapped to the organizational policies of the workflow. A change in a business rule may be reflected in a change of the policy. The second category of causalities describes dependencies between business processes, i.e. between different workflows. For instance, if the reason (e.g. the request of a customer) for a business trip is cancelled later so that the business trip is no longer necessary, the workflow realizing the business trip should be cancelled also. The WfMS should keep track of such causalities, e.g., verify the necessity of the execution of activities and workflows. Little work has been done in this respect so far. [Raus97]

2.2.7. The Historical Aspect: Logging

The historical aspect of a WfMS defines which data should be logged at which points in time. In general, the history of a certain workflow execution may contain data from all aspects of a workflow, including when it started and when it finished or when it was stopped, which control data it uses, which agents perform its activities, and which applications are called. [Raus97]

WfMSs should keep track of important data in this way for three reasons: First, similar to database systems, the log can be used to reset a workflow into a consistent state upon failure. If the WfMS is integrated with a database system, it can make use of the recovery mechanism of the database system itself for that purpose. Second, the functionality of workflows can be extended. For example, if a customer re-establishes some business relationship, clerks could be found that have former been in contact with that customer. And third, the execution of activities can be optimized by, e.g., (re)assigning an agent to an activity who has performed that activity earlier or who was involved in a related activity. [Raus97]

2.2.8 The Transactional Aspect: Workflow Consistency

In database systems, transactions are used to define atomic execution units consisting of a sequence of database operations in order to guarantee consistent and reliable data even if multiple users access some data concurrently, and even if failures occur. Within WfMSs, transactions can be used to guarantee the consistent execution of whole workflows as well as of single activities [GaSa94]. Besides data consistency, the consistent resumption of the control flow is of major concern. Leymann [Leym95], in this respect, distinguishes two viewpoints which pose different requirements to the transaction model [Raus97]:

- System-Oriented Transaction Concepts: From the technological viewpoint of a system engineer a WfMS is a tool for developing large, distributed systems consisting of independently developed subsystems. In this respect, transaction support is primarily concerned with the recoverability of operational data.
- Process-Oriented Transaction Concepts: From the business-oriented viewpoint of a workflow modeler the WfMS is seen as tool to describe and guarantee the workflow within an enterprise. In this respect, long lasting activities and workflows, the need for recovering process states, and the possibility of activities which cannot be undone have to be considered. Thus, the correction as well as the repetition of parts of the business process have to be supported by the transaction model. [Raus97]

Other approaches even go a step further and suggest that every workflow can be seen as transaction [RuSh95], [ShRu93]. In any case, extended transaction models are required [Elma92], which allow to define arbitrary relationships between transactions. In the context of a WfMS, thus, dependencies between workflows can be mapped to dependencies between transactions. For example, control flow constructs like series, limitation, delay, and existential dependency can directly be reflected by appropriate transaction dependencies. But still, there are some subtle differences: Whereas control flow constructs explicitly define a partial order on the execution of activities of a single workflow, transaction dependencies primarily focus on the correct synchronization of accesses to shared data from probably different workflows and in this way implicitly define some ordering constraints of the activities. This ordering implied by transaction dependencies, however, may not violate the ordering imposed by the control flow specification. Both concepts together ensure a consistent and correct execution of workflows. [Raus97]

2.3. Workflow Analysis

A workflow model ensures a consistent specification of (parts of) business processes by including various integrity constraints. On the basis of this specification business processes can be analyzed to identify inefficiencies and misconceptions, before the WfMS is used for their execution. Analysis and subsequent optimization of business processes is also known as business process reengineering. Much work ranging from socio-economic aspects to technological issues of business process reengineering can be found in the literature [Parr94], [Sole94]. In [DiGr95] three main techniques of workflow analysis have been proposed [Raus97]:

- Simulation:. The most important means to study the effects and consequences of a workflow is its simulation. Within a workflow simulation real resources are not consumed. The participation of agents as well as the processing of data are only simulated. As a result, a certain impression of the modeled business process is gained. For instance, the development of work lists can be observed, and the overall execution time can be computed. Also, activities which contribute to the overall processing time, i.e. the critical path, can be identified for later optimization.
- Analysis of Process Models: If the WfMS uses petri-nets or similar concepts for process modeling, the semantics of these petri-nets can be used to analyze the process against deadlocks, invariants, and subworkflows which are not executable [Gruh91].
- Interpretation of Protocolled Data: During execution of a workflow, information about processed activities, data, and consumed resources is logged (see Subsection 2.2.7.). After termination of the process this data can be used to get hints for improving the workflow. For example, the degree of parallelism as well as the utilization of resources can be determined. [Raus97]

2.4. Workflow Enactment

The run-time phase of a WfMS, which is also called workflow enactment, comprises two main tasks: First, business processes which have been specified by means of a corresponding workflow type including all the aspects described in Section 2.2. are executed, and second, their execution is monitored. End-users of a WfMS, i.e., the agents, are responsible for the execution of a workflow, while workflow administrators are responsible for the monitoring task. The latter in addition control the utilization of different system components and resources and may manually change agent-activity assignments to balance the workload of agents. [Raus97]

Many WfMSs take a tightly coupled approach from workflow specification to workflow implementation, i.e., the WfMS uses the specification directly as input to either generate code or interpret it for controlling workflow execution. This implies that there is no strict separation between concepts for modeling and concepts for the execution of workflows. Thus, many concepts directly influencing the execution of a workflow, like agent assignment policies, have already been discussed in Section 2.2. This section tries to give an overview about the basic execution cycle of the workflow engine, i.e. the component of a WfMS responsible for workflow execution, including exception handling mechanisms. [Raus97]

Execution Cycle: As soon as the start of a new workflow is requested, an instance of the corresponding workflow type has to be generated, and all necessary control data have to be initialized. Usually, not every agent may start a certain workflow. Rather, there is some kind of authorization mechanism which allows to restrict the set of agents authorized for a workflow. For this specification, also the organizational policies described in Section 2.2.5. can be used. After starting the workflow, the WfMS prepares the required control data for the first activity within the workflow (data preparation), selects appropriate agents according to the defined policies (agent selection) and notifies them (agent notification). If the agent is a software agent (i.e. an agent that controls the automatic execution of programs), the application program connected to the activity is provided with input data and started. For other agents, the activity is added to the set of activities be performed, e.g., within the agents worklist. On every start of an activity, the WfMS may check by means of eventually defined causal dependencies, whether there is still a reason for executing the workflow. After the activity has been successfully processed by the agent(s), the WfMS is responsible for converting and storing output data as necessary and for selecting the subsequent activities according to the specified control flow. As described in Subsection 2.2.3., two parallel execution paths occasionally have to be synchronized at their end. Consequently, the WfMS might have to wait for further activities to finish their execution, before continuing with agent selection for the subsequent activity, which restarts the execution cycle. [Raus97]

Worklist Management: Assuming that agents are notified by means of a worklist, users represented by agents have to log into the WfMS in order to process activities within their worklist. The interaction between an agent and the WfMS usually is handled by means of a user interface that displays the worklist of the agent, i.e. all activities which have to be processed. In general, an agent may process the assigned activities in arbitrary order. However, this is not always desirable. For example, activities might be assigned priorities. In case that an activity with a high priority arrives at a worklist, activities with lower priorities which have not yet begun to be processed, might be deactivated for selection. Thus, the agent would have to select the more important activity first. [Raus97]

Exception Handling: During workflow execution, exceptions may arise, e.g. no agent found (no agent might be found which fits the specification of the organizational policy), no subsequent activity (in case of conditional executions, at run-time occasionally no activity succeeding a finished one might be found, since the condition does not hold) or activity failure (e.g. due to an application failure or due to a system failure, like a system crash or a disk failure. [Raus97]

2.5. Architecture of WfMSs

There is a great variety of architectural concepts used in existing WfMSs. The Workflow Management Coalition (WfMC, see Section 6.2.) developed a referential architecture which should be used as standard for future developments. This section introduces the basic concepts for the architecture of WfMSs. Different architectures of existing WfMSs can be roughly classified according to the mechanisms used for communication [Schw95], [Raus97]:

- E-Mail-Based Systems: Systems building on e-mail as a medium for transport of data and coordination are easier to realize and can be applied universally. Also early approaches in the area of office information systems have been developed on top of e-mail [Zism77]. The main disadvantage of WfMSs based on e-mail is the lack of an appropriate exception handling mechanism since no transaction mechanisms are available, which has been identified as essential requirement. Another problem is the decentralized control of the workflow in some of these systems, which makes it very difficult to keep an overview of the work progress. E-mail-based systems, thus, are appropriate only for very simple workflows, like administrative workflows with low complexity.
- Database-Based Systems: This class of WfMSs uses a shared common data space for communication. Most database-based WfMSs are realized either within a client/server environment or on top of a distributed database system. The database system can be used as uniform data dictionary storing meta data about different workflow types, control data used within the workflows, and historical information about the execution of workflows. Moreover, they can use the various services of the underlying database system, like transaction mechanisms and authorization control to cope with consistency and security requirements. Since database systems are designed for large systems maintaining a huge amount of data, scalability of WfMSs is better supported. Nevertheless, the configuration of a database-based WfMS and the implementation of activity control is more complex and needs fundamental knowledge about the system. Appropriate tools are needed to simplify these tasks. [Raus97]

2.5.1. Generic Workflow Product Structure of the WfMC

The Workflow Management Coalition has published a generic workflow product structure (see Figure 2-2.), which assumes a database-based WfMS.

Abbildung in dieser Leseprobe nicht enthalten

Figure 2-2. Generic Workflow Product Structure [Holl95]

It identifies the main functional components within a workflow system and the interfaces between them as an abstract model. It is recognized that many different concrete implementation variants of this abstract model will exist and therefore the interfaces specified may be realized across a number of different platform and underlying distribution technologies. [Holl95]

The generic model has three types of component [Holl95]:

- Software components which provide support for various functions within the workflow system (shown in dark fill)
- Various types of system and control data (shown unfilled) which are used by one or more software components
- Applications and application databases (shown in light fill) which are not part of the workflow product, but which may be invoked by it as part of the total workflow system. [Holl95]

The roles of the major functional components within this system are the following [Holl95]:

The process definition tool is used to create the process description in a computer processable form. This may be based on a formal process definition language, an object relationship model, or in simpler systems, a script or a set of routing commands to transfer information between participating users. The definition tool may be supplied as part of a specific workflow product or may be part of a business process analysis product, which has other components to handle analysis or modeling of business operations. In this latter case there must be a compatible interchange format to transfer the process definitions to/from the run-time workflow software.

The process definition contains all necessary information about the process to enable it to be executed by the workflow enactment software. This includes information about its starting and completion conditions, constituent activities and rules for navigating between them, user tasks to be undertaken, references to applications which may to be invoked, definition of any workflow relevant data which may need to be referenced, etc.

The process definition may refer to an organization / role model which contains information concerning organizational structure and roles within the organization (e.g. an organizational directory). This enables the process definition to be specified in terms of organizational entities and role functions associated with particular activities or information objects, rather than specific participants. The workflow enactment service then has the responsibility of linking organizational entities or roles with the specific participants within the workflow runtime environment.

The workflow enactment service interprets the process description and controls the instantiation of processes and sequencing of activities, adding work items to the user work lists and invoking application tools as necessary. This is done through one or more cooperating workflow management engines, which manage(s) the execution of individual instances of the various processes. The workflow enactment service maintains internal control data either centralized or distributed across a set of workflow engines; this workflow control data includes the internal state information associated with the various process and activity instances under execution and may also include checkpointing and recovery/restart information used by the workflow engines to coordinate and recover from failure conditions.

The process definition, in conjunction with any (run-time) workflow relevant data is used to control the navigation through the various activity steps within the process, providing information about the entry and exit criteria for individual activity steps, parallel or sequential execution options for different activities, user tasks or IT applications associated with each activity, etc. This may require access to organization / role model data, if the process definition includes constructs relating to these entity types. The workflow engines also include some form of application tool invocation capability to activate applications necessary to execute particular activities. The generality of such mechanisms may vary greatly, with some simple systems only offering support of a single fixed tool such as a form or document editor, whereas others may provide methods for the invocation of a wider range of tools, both local and remote to the workflow engine.

Where user interactions are necessary within the process execution, the workflow engine(s) place items on to worklists for attention by the worklist handler, which manages the interactions with the workflow participants. This process may be invisible to the workflow participants with the worklist maintained within the workflow software and the user being presented sequentially with the next task to be performed. On other systems the worklist may be visible to the user, who has the responsibility of selecting individual items of work from the list and progressing them independently, with the worklist being used to indicate task completions.

The worklist handler is a software component which manages the interaction between workflow participants and the workflow enactment service. It is responsible for progressing work requiring user attention and interacts with the workflow enactment software via the worklist. In some systems, this may be little more than a desktop application providing a simple in-tray of work items awaiting user attention. In other systems this may be far more sophisticated, controlling the allocation of work amongst a set of users to provide facilities such as load balancing and work reassignment. In addition to these worklist handling functions, workflow engines typically support a wider range of interactions with client applications, including sign-on and -off of workflow participants, requesting the commencement of an instance of particular process types, requesting work items queued for particular participants, etc. The term “workflow client application” reflects this wider range of potential usage, which includes process control functions as well as worklist manipulation.

In the diagram the user interface is shown as a separate software component, responsible for the look and feel of the user dialog and control of the local interface with the user. In certain systems this may be combined with the worklist handler into a single functional entity. It is also expected that some client applications will interact with several different workflow services, enabling work items from such services to be consolidated into a unified task list for presentation to participants via a common user interface. Invocation of local applications may be necessary to support the user in the particular tasks to be undertaken. There is a distinction between application invocation at the worklist handler / user interface (which is not directly controlled from the workflow engine and may not be visible to it) and direct application invocation by the workflow enactment software.

Within a workflow system there are a number of supervisory functions which are normally provided; these are typically supported on the basis of supervisory privilege to a particular workstation or user(s). These functions may enable supervisors to alter work allocation rules, to identify participants for specific organizational roles within a process, to track alerts for missed deadlines or other forms of event, to trace the history of a particular process instance, to enquire about work throughput or other statistics, etc. Where distributed workflow engines are used there may need to be specific commands to transfer such control operations or (partial) responses between different workflow engines to provide a single administrative interface.

Exposed and Embedded Interfaces: Whilst the majority of workflow products can be related to the above structure, not all products offer exposed interfaces between the various individual system functional components; some products may implement several functional components together as a single logical entity with the interfaces embedded within the software component and not available for third party product use. The WfMC specifications (see also Section 6.2.) will identify, for each interface, the role of that interface in achieving interoperability, so that individual products can identify conformance against particular interoperability criteria. (For example, a particular product might offer an exposed interface for worklist manipulation but not for process definition interchange.) [Holl95]

2.6. Limitations

However, most systems are capable of controlling simple business processes, only. Concerning the support of complex business processes, there are a number of reasons why workflow management systems still are not successful. These problem areas include [Raus97]:

Insufficient Support for Legacy Systems: Organizations which plan to introduce a workflow management system often have well established legacy applications which make up considerable parts of the business process that should be automated. Much efforts, experience, and money has been put into their development. Consequently, they cannot simply be thrown away and replaced by new ones. Existing workflow management systems, however, can hardly cope with the integration of legacy applications.

Reusability: With the need of integrating legacy applications, also reusability comes into mind. Similar to the reuse of already existing applications, "new" applications and other elements of the business process should be specified in such a way, that they can be easily reused for other business processes which may be introduced as the organization evolves.

Flexibility: Current workflow management systems do not entirely fulfill the requirements of flexibly reacting to changes in the organizational environment. Most of them do allow to adapt the static specification of a business process when the environment changes. But firstly, not all aspects of business processes, like control flow specification or organizational aspects, may be changed, and secondly, changes may not be done dynamically, i.e., on the fly.

Organizational Support: Organizational issues are still handled only rudimentarily in existing systems. This is partly due to the fact that workflow management systems focus on technological issues, emphasizing on information processing and functional aspects, while other aspects like organizational and social aspects have been left to research within the area of computer supported cooperative work (CSCW).

Correctness and Reliability: When multiple data items are accessed by the execution of a business process, data consistency problems known from database research can arise. Most commercial workflow management systems provide limited capabilities to deal with these problems. The transaction and recovery support from an underlying database system often is not enough, since it addresses the consistency of individual tasks only. A workflow management system, however, must ensure the consistency of individual business processes that comprise several tasks processed by people and programs in cooperation as well as of concurrent execution of several business processes. [Raus97]

Chapter 3

Introduction to Interorganizational Workflows

This chapter gives an introduction to interorganizational workflows and discusses the concepts for interorganizational workflows that can be derived from conventional workflow management.

An example is given and the different models of workflow interoperability are described in order to provide an overview, what different views on interorganizational workflows exist. It is the basis for understanding the assumptions that underlie the different approaches to interorganizational workflow management.

Definition: An interorganizational workflow is a workflow that crosses organizational boundaries.

This does not necessarily mean that different enterprises are involved, also processes spanning different divisions of the same enterprise may require an interorganizational workflow solution to be supported. Interorganizational workflows are characterized by heterogeneous systems, distributed control and increased security and privacy issues.

3.1. Concepts for Interorganizational Workflows derived from Conventional Workflow Management

Most of the concepts described in Chapter 2 can be extended to interorganizational workflows. Here, task assignment and interorganizational control and data flow will be described in detail.

3.1.1. Task Assignment

An important characteristic of interorganizational workflows is that activities are not only assigned to internal resources. Also external resources that offer to execute single activities or major parts of a workflow can be assigned the execution of these activities. The abstract specification of the amount of work that a resource promises to carry out is also called a service [KWA99a]. If a service is provided by an external organization, it is called external service, if it is associated with an internal resource, it is called internal service.

If activities are outsourced to an external resource, the concrete agent will be determined by the workflow system of this external organization.

3.1.2. Interorganizational Control Flow

In interorganizational workflow, the control flow between the parts of the process executed in different organizations has to be specified. To connect these process fragments, events can be used.

There are two types of events for modeling the control flow: Control events can be sent by the service requester to the service provider in order to influence the processing of the service, and notification events are used to inform the service requester about the state of the processing of the external service. They can be sent as a result of an internal event of the service provider or as a reaction to an inquiry of the service requester. [KWA99a]

Abbildung in dieser Leseprobe nicht enthalten

Figure 3-1. Interorganizational Control Flow [DDDE00]

According to the complexity of the control flow, different models of interaction can be distinguished [DDDE00]:

- The black box represents a provider process with just one activity. No interaction is defined.
- The glass box provides the consumer the ability to look at multiple activities of the provider process. However, no incoming or outgoing control flow is defined.
- The open box - outward provides synchronization of outgoing control flow (from provider to consumer). The outgoing control flow preserves the independence of the execution at the provider and therefore the provider can guarantee the contractual obligations.
- The open box - inward provides synchronization of incoming (inward) control flow. Incoming control flow (consumer to provider) could hinder the provider to fulfill its tasks according to the contract.
- The broken box includes both incoming and outgoing control flow. [DDDE00]

3.1.3. Interorganizational Data Flow

All kinds of data flow can also be found in interorganizational workflows. The main problem is to describe the structure and the semantics of the exchanged documents in detail in the interface description. The sender has to describe what documents he will provide and the receiver has to describe what documents he needs. In several application domains there exist standards that describe documents (see also Sections 6.1. Traditional EDI and 6.5. XML-based Commerce Languages). In other application domains no standards exist. [LiDe99]

Interface-object types for data flow between organizational units as suggested in Subsection 2.2.4. can also be used at interfaces between different organizations.

3.2. Business Scenario

The Logis – Telco scenario described in [DDDE00] is derived from the real life cooperation between a logistics and a telecom company. Part of the delivery of equipment from Telco Telecom to customers is carried out by Logis Logistics. This involves purchases by telephone or by Internet.

The most interesting part of the scenario deals with the handling of cellular phone orders. Logis takes care of the warehousing, distribution, delivery and payment, based on orders from Telco. Therefore, Telco acts as the service consumer whereas Logis is the service provider. The details of the scenario will be described with the help of Figure 3-2.

The flow diagram is divided into two sides, a Telco and a Logis side. It represents a single order for telecom equipment. The control flow starts, when a Telco customer requests a service, be it either a telecom connection or equipment. On order entry, customer and order data are checked for completeness. After that the order data is checked at Logis. If it is not ok, Logis refuses the order and Telco has one more chance of completing the data. If this succeeds, Logis will accept the order after all, otherwise the order is cancelled.

If the requested equipment concerns a GSM (cellular) phone, the left branch at Logis will be taken, otherwise the right branch will be chosen. This right branch is straightforward, no more interactions with Telco are necessary before the product can be delivered.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3-2. Processes at Telco and Logis [DDDE00]

The left branch shows the assignment of a phone number to the physical telephone. Logis provides Telco with a unique identifier of the physical phone (the GSM serial number), which is used by Telco to assign a phone number to. This phone number is included in the parcel to be delivered. This way, the customer is ready to use the phone immediately after delivery. After delivery, Logis arranges the billing (not detailed in the diagram) and a proof of delivery is returned to Telco. Telco finishes the order and may contact the customer to check his satisfaction.

3.3. Partitioning of Workflows

Before the models of workflow interoperability are described in detail, some partitioning issues are considered. Interorganizational workflows are always partitioned in some way, and interoperability between these partitions has to be achieved.

Basically, there are two partitioning dimensions: the case dimension and the process dimension.

For reasons of analogy with vertical and horizontal partitioning as known from distributed database design [ÖzVa99], this classification is not taken over as described in [Aals00b], but reversed.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3-3. Horizontal and Vertical Partitioning

Vertical partitioning is based on the process dimension, i.e. the process is cut into pieces and cases are not allocated to specific business partners (in fact several business partners may be working on the same case at the same moment in time)

Horizontal partitioning uses the case dimension to distribute the workflow, i.e. the cases are distributed over several business partners but the process is not cut into pieces.

An advantage of a horizontal partitioning is that at any time the whole case resides at one location, i.e., many concurrency problems are avoided. Another advantage is the fact that the interaction between the enactment services of the organizations involved is simple and can be realized using today’s generation of workflow management systems: The only mechanism that is needed is a swap-in/swap-out facility.

The horizontal partitioning has some drawbacks: The same process description, or variants of the same description, needs to be replicated over all business partners involved. Moreover, the degree of potential parallelism is reduced because a case cannot be processed by two organizations at the same time.

Vertical partitioning allows for the parallel processing of one case in multiple organizations at the same time. Moreover, each organization is only confronted with the relevant part of the workflow process. However, the coordination costs of vertical partitioning can be high. Causal relations between tasks in different organizations need to be maintained, exceptions become more difficult to handle, and all kinds of concurrency problems can occur (e.g. conflicting decisions in different organizations). [Aals00b]

Different models of workflow interoperability are distinguished by the ways how a workflow is partitioned and how complex the interactions between the resulting parts are.

3.4. Models of Workflow Interoperability

This section describes the different models of workflow interoperability in order to provide an overview, what different views on interorganizational workflows exist. It is the basis for understanding the assumptions that underlie the different approaches to interorganizational workflow management.

For each model of workflow interoperability an example workflow process is given and its applicability in e-commerce is judged.

3.4.1. Centralized Process Management or Capacity Sharing

This form of interoperability assumes centralized control. The execution of tasks may be distributed, i.e. resources of several business partners execute tasks. [Aals00b] But the actions are scheduled and coordinated by a centralized workflow engine. This model attempts to use conventional workflow management in the context of interorganizational workflows. It is no area of application of approaches to interorganizational workflow management.

Abbildung in dieser Leseprobe nicht enthalten

Figure 3-4. Centralized Process Management [Aals00b]

An example for application of this scenario is an insurance agent, who works essentially independent and cooperates with various insurance companies. After closing a new insurance contract, he connects with the system of the respective insurance company and transmits the data.

Typically a business process includes a data packet (or folder, see also Subsection 2.2.4.) containing the process data for flow control and data flow, and tasks can manipulate the process state by updating these data. However, consider a purchase process involving tasks belonging to different enterprises, e.g. the buyer and the seller. It is unrealistic to have the buyer and the seller coordinated by a single workflow engine, and it is unreasonable for them to put their private data (e.g. negotiation threshold) into the common process data packet for flow control. [ChHs01]

Centralized process management may be applied in some cases, but in general its use for interorganizational workflows is limited.

3.4.2. Chained Subprocesses or Chained Execution

The workflow process is split into a number of disjunct subprocesses, which are executed by different business partners in a sequential order. This form of interoperability requires that a partner transfers or initiates the flow for a case after completing all the work. In contrast to centralized process management, the control of the workflow is distributed over the business partners. [Aals00b]

This model assumes that the process instance being enacted on Workflow Engine A triggers the creation and enactment of a subprocess instance on Workflow Engine B. Once enactment of the subprocess instance has begun on Workflow Engine B, Workflow Engine A may terminate or may continue with the enactment of its own process instance. It takes no further interest in the newly created subprocess instance. [WfMC96]

Abbildung in dieser Leseprobe nicht enthalten

Figure 3-5. Chained Subprocesses [Aals00b]

An example is an insurance company that receives an insurance claim. It checks the policy and classifies the damage, afterwards the data is transferred to an agency that examines the damage and makes a decision. Finally, the case is transferred a last time for handling the payment or writing a rejection letter.

Chained subprocesses are only useful for applications where the process is composed of sequentially ordered parts (each part is executed by a different business partner). In e-commerce applications there is often interaction between the business partners following a protocol which is much more complicated than just sending the case. Therefore, chained subprocesses will often be not suitable either. [Aals00b]

3.4.3. Nested Subprocesses, Subcontracting or Service Outsourcing

There is one business partner, which subcontracts subprocesses to other business partners. The subprocesses provide information back to their parent process. For the top-level business partner the subcontracted subprocesses appear to be atomic. However, for the business partners executing subcontracted work, these can be very complex. [Aals00b]

The process instance enacted on workflow engine A causes the creation and enactment of a subprocess instance on workflow engine B and then waits for its termination before carrying on with its own enactment. [WfMC96]

The outsourced subprocess can also be called an external service. The service requester has only a limited possibility to get information on the state of an external service execution and to influence this execution (see also Subsections 2.2.3. and 3.1.2. about control flow). [KWA99a] The control is hierarchical; it is distributed in a tree-like fashion. [Aals00b]

Abbildung in dieser Leseprobe nicht enthalten

Figure 3-6. Nested Subprocesses [Aals00b]

An example is an insurance company that subcontracts the examination of damages to an expert.

Nested subprocesses are more useful in the context of e-commerce. In traditional e-commerce applications based on EDI, the hub-and-spoke model, with a dominant business partner (the hub) gradually surrounding itself with suppliers, customers and collaborators (the spokes), is used [Zwas96]. Nested subprocesses can be useful for such applications. However, they can only be applied in an environment with clearly hierarchical structured business partners, the architecture is fairly straightforward and can be realized using conventional technology. For the top-level business partner the subcontracted processes can be seen as normal tasks. [Aals00b]

[...]