Elsevier

Information Systems

Volume 30, Issue 5, July 2005, Pages 349-378
Information Systems

Specification and validation of process constraints for flexible workflows

https://doi.org/10.1016/j.is.2004.05.002Get rights and content

Abstract

Workflow systems have traditionally focused on the so-called production processes which are characterized by pre-definition, high volume, and repetitiveness. Recently, the deployment of workflow systems in non-traditional domains such as collaborative applications, e-learning and cross-organizational process integration, have put forth new requirements for flexible and dynamic specification. However, this flexibility cannot be offered at the expense of control, a critical requirement of business processes.

In this paper, we will present a foundation set of constraints for flexible workflow specification. These constraints are intended to provide an appropriate balance between flexibility and control. The constraint specification framework is based on the concept of “pockets of flexibility” which allows ad hoc changes and/or building of workflows for highly flexible processes. Basically, our approach is to provide the ability to execute on the basis of a partially specified model, where the full specification of the model is made at runtime, and may be unique to each instance.

The verification of dynamically built models is essential. Where as ensuring that the model conforms to specified constraints does not pose great difficulty, ensuring that the constraint set itself does not carry conflicts and redundancy is an interesting and challenging problem. In this paper, we will provide a discussion on both the static and dynamic verification aspects. We will also briefly present Chameleon, a prototype workflow engine that implements these concepts.

Introduction

Workflow technology is being applied in quite diverse areas. This diversity has had a strong impact on workflow research. We can find in the literature, several categories of workflow types, such as production, collaborative, ad hoc, etc. To determine the suitability of workflow technology, process characteristics such as functional complexity, predictability and repetitiveness are often considered, especially in the general class of production workflows. However, the predictability and repetitiveness of production workflows cannot be counted upon, in the dynamic business environments of today, where processes are being continually changed in response to new methods and practices, and changes in laws and policies. Furthermore, these processes are often confronted by exceptional cases, and need to deviate from prescribed procedures without loosing control. These exceptional cases may or may not be foreseen.

At the same time, there is a complementary school of thought, which often speaks of ad hoc workflows, or workflows where the process cannot be completely defined prior to execution [1]. Although we do not advocate ad hocism in workflow processes to the extent of a complete relaxation of coordination constraints, it is obvious that ad hocism is meant to promote flexibility of execution. There is sufficient evidence that process models that are too prescriptive introduce a rigidity that compromises the individualism and competitive edge of the underlying business procedures.

Processes which undergo frequent change cannot be completely pre-defined, or simply have too many instance types, require a specification framework which is in tune with the flexible nature of these processes. Processes which depend on the presence of such flexibility for the satisfactory attainment of process goals can be found in many applications, for example:

  • A typical example of flexibility is healthcare, where patient admission procedures are predictable and repetitive, however, in-patient treatments are prescribed uniquely for each case, but nonetheless have to be coordinated and controlled.

  • Another application is higher education, where students with diverse learning needs and styles are working towards a common goal (degree). Study paths taken by each student need to remain flexible to a large extent, at the same time providing study guidelines and enforcing course level constraints is necessary to ensure a certain quality of learning.

  • Effective customer relationship management (CRM), a critical component in enterprise solutions, also signifies the need to provide a flexible means of composing call center activities according to the available resources and data, by integrating CRM systems with core organizational workflow processes and underlying applications.

  • Customizable product manufacturing also requires a flexible means of coordination of production processes, since the requirements of individual customers cannot be pre-determined. Here, made-to-order products are produced against customer requirements which are made available for individual items or batches, and may vary from case to case.

The key issue in flexible workflows is the specification of the partial process, from which a complete workflow specification may be derived. Thus rather than enforcing control through a rigid, or highly prescriptive language that attempts to capture every step and every option within the process, the process is defined in a “flexible” manner, that allows individual instances to determine their own (unique) processes. How to achieve such a means of requirements specification is the main focus of this paper.

In the subsequent sections, we will present a unique, generic and practical approach for the specification of flexible workflows. It is important to clarify that this paper does not present a new language for workflow specification. Instead, we will only make use of simple, generic and well-established constructs, such as sequence, fork, choice, etc. [32]. To establish a common understanding of these constructs and notation, we have given in the Appendix, a short explanation of the semantics. Basically, a Workflow is defined as a directed graph W. There are two types of nodes in W, namely activity nodes (rectangle) and coordinator nodes (ellipse). Fig. 1 gives the graphical representation.

We will use the above notation to demonstrate various examples in this paper. The remaining paper is structured as follows: We first present the specification framework, followed by a discussion on achieving the right balance between flexibility and control. This will demonstrate how this specification framework facilitates the attainment of such a balance. We then present in detail our approach to constraint specification, which is a fundamental notion in the framework. Then in the following section, a discussion on constraint validation is presented. We first define various properties of the constraint specification approach, namely transitivity, redundancy and conflicts, and then provide a procedure for achieving a minimal and conflict-free specification. In the next section, the verification of templates built under the given specification framework is discussed. We provide the verification algorithms as well as some discussion on template building support from a system/usability point of view. Finally, we present a short introduction to a flexible workflow engine, Chameleon, which implements the above concepts, before presenting related work and conclusions.

Section snippets

Specification framework

It is a long established notion that requirements specification involves the modeling of real-world knowledge and not just functional specification [2]. This representation takes many forms, such as formal specification languages, reactive systems modeling, and conceptual modeling [3]. Several modeling perspectives exist [4] such as notion oriented (e.g. UML) and domain oriented (e.g. ARIS [5]).

Many workflow specification languages have origins in the Petri-net formalism, and process algebra

Balancing flexibility and control

In Section 2.1, we have defined the flexible workflow as having the following components: a core process (with normal activities as well as special build activities representing pockets of flexibility), fragments, and build constraints. On a continuum of workflow specification, there is the completely defined model on one end, and the model with no pre-definition on the other. Thus, the former only has strong constraints, e.g. B must follow A, and the latter no constraints at all. Finding the

Constraint specification

We identify two main classes of constraints, namely structural class and containment class. The constraints belonging to the structural class impose restriction on how fragments can be composed in the templates. We will discuss three constraint types under the structural class, namely serial, order and fork. The constraints belonging to the containment class identify conditions under which fragments can and cannot be contained in the resulting templates. We will discuss two constraint types

Constraint validation

An important aspect of the above framework is the validation of the set of constraints. Since these constraints are the basis for controlling subsequent dynamic building, it is vital that the constraints themselves do not impose a restriction which cannot be met. In other words, can we say that possible structures allowable under a given constraint set are acceptable? Below we give a few examples of such violations:

  • Suppose that a fork constraint is given as F({A, B, C}), however, there is a

Template verification

The set of five constraints discussed above provide a minimum set of meta-definitions for constraints, which once populated according to given domain requirements, will be used to verify an arbitrary construct built within a pocket in a given language. This takes verification to a new dimension, i.e. template verification under (3). Typically verification in workflow specification provides (1) and (2) only.

  • 1.

    Syntactic verification: The model constructed is correct with respect to the grammar of

Chameleon: flexible workflow engine

The concept of pockets of flexibility has been implemented in a prototype flexible workflow engine: Chameleon (www.dstc.edu.au/praxis). Chameleon is supported by a process editing and verification tool FlowMake (www.dstc.edu.au/praxis).

Related work

Workflow technology has typically been deployed in domains with processes that have obvious coordinative requirements. As such, the flow of control and data offered by this technology is easily mapped to process effectiveness. However, there is growing evidence that workflow technology must deliver in domains where coordinative requirements are less obvious, dynamic, prone to frequent change or exceptions. As such, research and development in this area has been diverse, and spanned several

Conclusions

Inspite of many good results from the research community, the issue of flexibility in workflows remains a problem in commercial solutions, and a limiting factor in the wider scale applicability of this technology.

It is apparent that change is an inherent characteristic of today's business processes. In this paper, we present an approach that recognizes the presence of change, and attempts to integrate the process of defining a change into the workflow process itself. Our basic idea is to

Acknowledgements

The work reported in this paper has been funded in part by the Cooperative Research Centres Program through the Department of the Prime Minister and Cabinet of the Commonwealth Government of Australia.

References (34)

  • H.W. Nissen et al.

    Repository support for multi-perspective requirements engineering

    Inform. Systems

    (1999)
  • W. Sadiq et al.

    Analysing process models using graph reduction techniques

    Inform. Systems

    (2000)
  • M. Klein, C. Dellarocas, A knowledge-based approach to handling exceptions in workflow systems, Workshop on Adaptive...
  • S.J. Greenspan, J. Mylopoulos, Capturing more world knowledge in the requirements specification, Proceedings of the...
  • S.M. Easterbrook, An Introduction to Formal Modeling in Requirements Engineering Tutorial at the 10th Joint...
  • A.W. Scheer

    ARIS—Business Process Modeling

    (2000)
  • S.R. Rakitin

    Software Verification and Validationa Practitioner's Guide

    (1997)
  • W. Sadiq, M.E. Orlowska, On correctness issues in conceptual modeling of workflows, in: Proceedings of the Fifth...
  • O. Thomas, Constraint specification and verification in flexible workflows, Honors Thesis, The University of...
  • F. Casati et al.

    Workflow evolution

  • S. Sadiq, O. Marjanovic, M. Orlowska, Managing change and time in dynamic workflow processes, Int. J. Coop. Inform....
  • G. Joeris, O. Herzog, Managing evolving workflow specifications, Proceedings of the Third IFCIS International...
  • W.M.P. van der Aalst, T. Basten, Inheritance of workflows: an approach to tackling problems related to change, in:...
  • M. Kradolfer, A. Geppert, Dynamic workflow schema evolution based on workflow type versioning and workflow migration,...
  • C. Liu, M. Orlowska, Hui Li, Automating handover in dynamic workflow environments, Proceedings of the 10th...
  • S. Sadiq, Handling dynamic schema changes in workflow processes, 11th Australian Database Conference (ADC), Canberra,...
  • W.M.P. van der Aalst, A.P. Barros, A.H.M. ter Hofstede, B. Kiepuszewski, Advanced workflow patterns, in: O. Etzion, P....
  • Cited by (227)

    • On the declarative paradigm in hybrid business process representations: A conceptual framework and a systematic literature study

      2020, Information Systems
      Citation Excerpt :

      Using the same concept, Mangan and Sadiq [75,76] extend this work and propose a HBPR combining basic imperative modeling constructs with dynamic constraints (cf. Section 5.4). The later is further elaborated in [25]. Similarly, Lu et al. [57] present a HBPR combining pre-defined model parts with loosely coupled model parts using a constraint-based approach.

    View all citing articles on Scopus

    Recommended by Prof. Gottfried Vossen.

    View full text