Interorganizational Workflow Management
Concepts, Requirements and Approaches
©2002
Diplomarbeit
162 Seiten
Zusammenfassung
Inhaltsangabe:Abstract:
Conventional workflow management focuses on improving the efficiency of business processes within one organization. However, processes should not only be supported within the enterprise, but also when crossing organizational boundaries, e.g. in order to support new forms of collaborations as virtual enterprises.
Due to the different nature of interorganizational workflows, conventional workflow technology cannot be directly applied. The most important requirement specific to interorganizational workflow systems is obviously that they are able to deal with heterogeneity and that it is not too expensive to achieve interoperability. Also maintaining the privacy of internal processes is a major concern, and security issues should be addressed.
This diploma thesis gives an introduction to conventional and interorganizational workflow management, their aspects and concepts. It elaborates the requirements relevant for interorganizational workflow systems, describes the most important approaches, projects, and initiatives that currently exist in the area of interorganizational workflows, including XML-based approaches, the standards of the WfMC, electronic marketplaces and electronic contracting.
An evaluation of these approaches based on criteria derived from the requirements and other characteristics shows the differing strengths and weaknesses. The XML-based approaches provide standards for the process interfaces, and can cope with heterogeneous environments very well. Some of them even allow spontaneous commerce with new trading partners without custom integration. Traditional EDI is in principle similar, but has many disadvantages. The standards of the WfMC enable integration with a very low effort, if they are followed by software providers. But privacy and security are potential problem areas and the models of interoperability that realistically can be supported are simple. Electronic marketplaces and electronic contracting are ideal, if a high number of business partners has to be supported and the services are chosen dynamically depending on the situation. But these services have to be comparable with rather simple interfaces.
Inhaltsverzeichnis:Table of Contents:
1.Introduction1
2.Workflow Management4
2.1Requirements on WfMSs6
2.2Workflow Modeling8
2.2.1The Functional Aspect: Workflows and Activities8
2.2.2The Operational Aspect: Applications9
2.2.3The Behavioral Aspect: Control Flow10
2.2.4The Informational […]
Conventional workflow management focuses on improving the efficiency of business processes within one organization. However, processes should not only be supported within the enterprise, but also when crossing organizational boundaries, e.g. in order to support new forms of collaborations as virtual enterprises.
Due to the different nature of interorganizational workflows, conventional workflow technology cannot be directly applied. The most important requirement specific to interorganizational workflow systems is obviously that they are able to deal with heterogeneity and that it is not too expensive to achieve interoperability. Also maintaining the privacy of internal processes is a major concern, and security issues should be addressed.
This diploma thesis gives an introduction to conventional and interorganizational workflow management, their aspects and concepts. It elaborates the requirements relevant for interorganizational workflow systems, describes the most important approaches, projects, and initiatives that currently exist in the area of interorganizational workflows, including XML-based approaches, the standards of the WfMC, electronic marketplaces and electronic contracting.
An evaluation of these approaches based on criteria derived from the requirements and other characteristics shows the differing strengths and weaknesses. The XML-based approaches provide standards for the process interfaces, and can cope with heterogeneous environments very well. Some of them even allow spontaneous commerce with new trading partners without custom integration. Traditional EDI is in principle similar, but has many disadvantages. The standards of the WfMC enable integration with a very low effort, if they are followed by software providers. But privacy and security are potential problem areas and the models of interoperability that realistically can be supported are simple. Electronic marketplaces and electronic contracting are ideal, if a high number of business partners has to be supported and the services are chosen dynamically depending on the situation. But these services have to be comparable with rather simple interfaces.
Inhaltsverzeichnis:Table of Contents:
1.Introduction1
2.Workflow Management4
2.1Requirements on WfMSs6
2.2Workflow Modeling8
2.2.1The Functional Aspect: Workflows and Activities8
2.2.2The Operational Aspect: Applications9
2.2.3The Behavioral Aspect: Control Flow10
2.2.4The Informational […]
Leseprobe
Inhaltsverzeichnis
ID 5471
Pargfrieder, Karin: Interorganizational Workflow Management: Concepts, Requirements and
Approaches / Karin Pargfrieder - Hamburg: Diplomica GmbH, 2002
Zugl.: Linz, Universität, Diplomarbeit, 2002
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die
der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen,
der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der
Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung,
vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im
Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der
Bundesrepublik Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem
Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche
Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten
wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können Fehler nicht
vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die Autoren oder
Übersetzer übernehmen keine juristische Verantwortung oder irgendeine Haftung für evtl.
verbliebene fehlerhafte Angaben und deren Folgen.
Diplomica GmbH
http://www.diplom.de, Hamburg 2002
Printed in Germany
Kurzfassung
Konventionelles Workflow Management beschränkt sich auf die Verbesserung der
Effizienz von Geschäftsprozessen innerhalb einer Organisation. Jedoch sollten
Prozesse auch dann elektronisch unterstützt werden können, wenn sie
organisationale Grenzen überschreiten, wie z.B. in virtuellen Unternehmen.
Wegen der speziellen Eigenschaften von interorganisationalen Workflows kann
konventionelle Workflow Technologie nicht direkt angewendet werden. Die
wichtigste Anforderung an interorganisationale Workflow Systeme ist klarerweise,
Interoperabilität zwischen heterogenen Systemen zu erreichen. Sehr wichtig sind
auch Vertraulichkeit der internen Prozesse und Sicherheit.
Die vorliegende Diplomarbeit gibt eine Einführung in interorganisationales
Workflow Management, seine Aspekte und Konzepte. Anforderungen an
interorganisationale Workflow Systeme werden ausgearbeitet und die wichtigsten
Ansätze, Projekte und Initiativen werden beschrieben: XML-basierte Ansätze, die
Standards der WfMC, elektronische Marktplätze und elektronische Verträge.
Eine Evaluierung dieser Ansätze anhand eines Kriterienkatalogs, der aus den
Anforderungen und anderen Eigenschaften der Ansätze abgeleitet wird, zeigt die
verschiedenen Stärken und Schwächen. Die XML-basierten Ansätze bieten
Standards für die Schnittstellen der Prozesse und eine gute Lösung bzgl.
Heterogenität. Manche von ihnen ermöglichen sogar die spontane Zusammenarbeit
mit neuen Geschäftspartnern ohne vorherige Absprache. Traditioneller
elektronischer Datenaustausch (EDI) ist vom Prinzip her ähnlich, hat aber viele
Nachteile. Die Standards der WfMC ermöglichen einen sehr geringen Aufwand bei
der Systemintegration, wenn sich die Anbieter daran halten. Aber Vertraulichkeit
und Sicherheit sind potentielle Problemfelder und nur einfache Kooperationsmodelle
werden unterstützt. Elektronische Marktplätze und elektronische Verträge sind ideal,
wenn die Anzahl der Geschäftspartner hoch ist oder die Geschäftspartner abhängig
von der jeweiligen Situation dynamisch gewählt werden sollen. Dazu müssen deren
Services aber leicht vergleichbar sein und einfache Schnittstellen haben.
Abstract
Conventional workflow management focuses on improving the efficiency of
business processes within one organization. However, processes should not only be
supported within the enterprise, but also when crossing organizational boundaries,
e.g. in order to support new forms of collaborations as virtual enterprises.
Due to the different nature of interorganizational workflows, conventional workflow
technology cannot be directly applied. The most important requirement specific to
interorganizational workflow systems is obviously that they are able to deal with
heterogeneity and that it is not too expensive to achieve interoperability. Also
maintaining the privacy of internal processes is a major concern, and security issues
should be addressed.
This diploma thesis gives an introduction to conventional and interorganizational
workflow management, their aspects and concepts. It elaborates the requirements
relevant for interorganizational workflow systems, describes the most important
approaches, projects, and initiatives that currently exist in the area of
interorganizational workflows, including XML-based approaches, the standards of
the WfMC, electronic marketplaces and electronic contracting.
An evaluation of these approaches based on criteria derived from the requirements
and other characteristics shows the differing strengths and weaknesses. The XML-
based approaches provide standards for the process interfaces, and can cope with
heterogeneous environments very well. Some of them even allow spontaneous
commerce with new trading partners without custom integration. Traditional EDI is
in principle similar, but has many disadvantages. The standards of the WfMC enable
integration with a very low effort, if they are followed by software providers. But
privacy and security are potential problem areas and the models of interoperability
that realistically can be supported are simple. Electronic marketplaces and electronic
contracting are ideal, if a high number of business partners has to be supported and
the services are chosen dynamically depending on the situation. But these services
have to be comparable with rather simple interfaces.
Table of Contents
1 Introduction... 1
2 Workflow
Management... 4
2.1. Requirements on WfMSs ... 6
2.2. Workflow
Modeling... 8
2.2.1. The Functional Aspect: Workflows and Activities... 8
2.2.2 The Operational Aspect: Applications... 9
2.2.3. The Behavioral Aspect: Control Flow ... 10
2.2.4. The Informational Aspect: Data Structures and Data Flow... 12
2.2.5. The Organizational Aspect: Structure and Population... 13
2.2.6. The Causal Aspect: Regulations and Dependencies... 14
2.2.7. The Historical Aspect: Logging... 15
2.2.8 The Transactional Aspect: Workflow Consistency ... 15
2.3. Workflow
Analysis ... 16
2.4. Workflow
Enactment ... 17
2.5. Architecture of WfMSs ... 19
2.5.1. Generic Workflow Product Structure of the WfMC... 20
2.6. Limitations ... 24
3
Introduction to Interorganizational Workflows ... 26
3.1. Concepts for Interorganizational Workflows derived from Conventional
Workflow Management... 27
3.1.1. Task
Assignment... 27
3.1.2. Interorganizational Control Flow... 27
3.1.3. Interorganizational Data Flow ... 28
3.2. Business
Scenario... 29
3.3. Partitioning of Workflows... 31
3.4. Models of Workflow Interoperability ... 32
3.4.1. Centralized Process Management or Capacity Sharing ... 33
3.4.2. Chained Subprocesses or Chained Execution... 34
3.4.3. Nested Subprocesses, Subcontracting or Service Outsourcing
... 35
Table of Contents
3.4.4. Transaction
Group... 36
3.4.5. Parallel Synchronized Model or Multi-Processes Interoperation
/ Federation ... 36
3.4.6. Case
Transfer ... 37
3.4.7. Extended Case Transfer ... 38
3.4.8. Loosely Coupled Processes... 39
3.4.9. Peer-to-Peer Collaborative Process Management... 40
3.4.10. Summary ... 42
4
Standardization for Interorganizational Workflows ... 44
4.1. Open-edi Reference Model ... 45
4.2. Levels of Standardization... 46
5
Requirements for Interorganizational Workflow Management ... 48
5.1. Relevance of Requirements for Conventional Workflow Systems... 49
5.2. Requirements
Catalog ... 50
5.2.1. Build-Time ... 51
5.2.2. Run-Time ... 52
5.2.3. Requirements Independent of the Phases... 55
6
Approaches, Projects and Initiatives ... 58
6.1. Traditional
EDI ... 59
6.2. Workflow Management Coalition (WfMC)... 60
6.3. OO-edi ... 65
6.4. Electronic Workflow Trading ... 67
6.4.1. Electronic Marketplace, ACE-Flow... 67
6.4.2. Electronic
Contracts,
Cross Flow Project ... 74
6.4.3. Event-Services,
EVE... 83
6.4.4. Process Model Fragments ... 89
6.5. XML-based Commerce Languages... 92
6.5.1. RosettaNet... 95
6.5.2. BizTalk... 97
6.5.3. eCo ... 99
6.5.4. ebXML ... 104
7 Evaluation... 109
7.1. Supported Models of Interoperability ... 109
7.2. BOV or FSV? ... 111
7.3. Build-Time ... 112
7.3.1. Automation... 112
7.3.2. Support for Collaborative Process Definition... 112
7.3.3. Privacy of Internal Processes ... 113
Table of Contents
7.3.4. Being able to cope with Heterogeneous Workflow Environments
... 113
7.3.5. Integration Effort and Integration Know-How ... 114
7.3.6. Support for a High Number of Partners ... 115
7.4. Run-Time ... 116
7.4.1. Automated Selection of Optimal Service... 116
7.4.2. Ensure Quality of the Outsourced Operation... 116
7.4.3. Security ... 117
7.4.4. Flexibility... 117
7.4.5. Document
Management ... 117
7.5. Autonomy of Partners ... 118
7.5.1. Design
Autonomy ... 118
7.5.2. Communication
Autonomy... 118
7.5.3. Execution
Autonomy ... 119
7.5.4. Association
Autonomy... 119
7.6. Transparency ... 119
7.7. Distribution... 119
7.8. Summary of Evaluation... 120
8
Summary, Contribution and Outlook ... 123
Appendix - Glossary... 126
References ... 138
List of Figures
Figure 2-1. Types of Data in Workflow Management Systems [WfMC99a]... 12
Figure 2-2. Generic Workflow Product Structure [Holl95] ... 20
Figure 3-1. Interorganizational Control Flow [DDDE00] ... 28
Figure 3-2. Processes at Telco and Logis [DDDE00]... 30
Figure 3-3. Horizontal and Vertical Partitioning ... 31
Figure 3-4. Centralized Process Management [Aals00b] ... 33
Figure 3-5. Chained Subprocesses [Aals00b] ... 34
Figure 3-6. Nested Subprocesses [Aals00b] ... 35
Figure 3-7. The Parallel Synchronized Model of Interoperability [WfMC96]... 37
Figure 3-8. Case Transfer [Aals00b]... 38
Figure 3-9. Example (Extended) Case Transfer... 38
Figure 3-10. Loosely Coupled Processes [Aals00b] ... 40
Figure 3-11. Example Loosely Coupled Processes... 40
Figure 3-12. Peer-to-Peer Collaborative Process Management [ChHs01] ... 41
Figure 3-13. Partitioning Dimensions of the Models of Workflow Interoperability42
Figure 3-14. Models of Workflow Interoperability ... 43
Figure 4-1. Open-edi Reference Model [EdiI96]... 45
Figure 4-2. Three Levels of Standardization [Huem01b] ... 46
Figure 6-1. The Workflow Reference Model [Holl95]... 61
Figure 6-2. ACE-Flow System [SRKT00]... 70
Figure 6-3. Sequence in Bidding and Execution [SRKT00]... 73
Figure 6-4. Contract and Workflow Level [KGV00]... 78
Figure 6-5. Making Contracts [KGV00]... 79
Figure 6-6. The CrossFlow Architecture [KGV00] ... 81
Figure 6-7. Architecture of EVE and Example Workflow System [GeTo98] ... 88
Figure 6-8. Multiple Vertical Connection [LiDe99]... 91
Figure 6-9. Horizontal Connection of Three Fragments [LiDe99] ... 91
Figure 6-10. Partner Interface Process (RosettaNet) [ChHs01]... 96
Figure 6-11. The Common Business Library [GTM99] ... 102
Figure 6-12. Fragment of an XML Service Definition [GTM99]... 103
List of Figures
Figure 6-13. Use of ebXML [Huem01b] ... 105
Figure 6-14. High-Level Overview of ebXML Interaction between two Companies
[Mert01] ... 107
Figure 7-1. Supported Models of Interoperability ... 111
Figure 7-2. Overview ... 121
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
Introduction
2
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.
Introduction
3
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
Workflow Management
5
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]
Workflow Management
6
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
Workflow Management
7
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.
Workflow Management
8
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
Workflow Management
9
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.
Workflow Management
10
·
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
Workflow Management
11
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]
Workflow Management
12
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]
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.
Workflow Management
13
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.
Workflow Management
14
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
Workflow Management
15
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.
Workflow Management
16
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
Workflow Management
17
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
Workflow Management
18
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]
Workflow Management
19
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
Workflow Management
20
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.
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]:
Workflow Management
21
·
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
Workflow Management
22
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
Workflow Management
23
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]
Workflow Management
24
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
Workflow Management
25
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]
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2002
- ISBN (eBook)
- 9783832454715
- ISBN (Paperback)
- 9783838654713
- DOI
- 10.3239/9783832454715
- Dateigröße
- 6.5 MB
- Sprache
- Englisch
- Institution / Hochschule
- Johannes Kepler Universität Linz – Wirtschaftsinformatik, Angewandte Informatik
- Erscheinungsdatum
- 2002 (Mai)
- Note
- 1,0
- Schlagworte
- virtual enterprise e-commerce business process
