Specification and validation of process constraints for flexible workflows☆
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)
- et al.
Repository support for multi-perspective requirements engineering
Inform. Systems
(1999) - 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...
ARIS—Business Process Modeling
(2000)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...
- et al.
Workflow evolution
Cited by (227)
Version control for asynchronous BIM collaboration: Model merging through graph analysis and transformation
2023, Automation in ConstructionMonitoring hybrid process specifications with conflict management: An automata-theoretic approach
2023, Artificial Intelligence in MedicineControlled flexibility in blockchain-based collaborative business processes
2022, Information SystemsPrognosis of multiple instances in time-aware declarative business process models
2020, Computers in IndustryOn the declarative paradigm in hybrid business process representations: A conceptual framework and a systematic literature study
2020, Information SystemsCitation 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.
- ☆
Recommended by Prof. Gottfried Vossen.