«Pockets of Flexibility in Workflow Specification Shazia Sadiq, Wasim Sadiq*, Maria Orlowska1 School of Computer Science and Electrical Engineering ...»
Pockets of Flexibility in Workflow Specification
Shazia Sadiq, Wasim Sadiq*, Maria Orlowska1
School of Computer Science and Electrical Engineering
*Distributed Systems Technology Center2
The University of Queensland
QLD 4072 Australia
Abstract: Workflow technology is currently being deployed in quite diverse
domains. However, the element of change is present in some degree and form in
almost all domains. A workflow implementation that does not support the process of change will not benefit the organization in the long run. Change can be manifested in different forms in workflow processes. In this paper, we first present a categorization of workflow change characteristics and divide workflow processes into dynamic, adaptive and flexible processes. We define flexibility as the ability of the workflow process to execute on the basis of a loosely, or partially specified model, where the full specification of the model is made at runtime, and may be unique to each instance. To provide a modeling framework that offers true flexibility, we need to consider the factors, which influence the paths of (unique) instances together with the process definition.
We advocate an approach that aims at making the process of change part of the workflow process itself. We introduce the notion of an open instance that consists of a core process and several pockets of flexibility, and present a framework based on this notion, which makes use of special build activities that provide the functionality to integrate the process of defining a change, into the open workflow instance.
1 Introduction Workflows have emerged as a powerful technology for automating the coordinative and collaborative aspects of business processes. 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 suitability of workflow technology, process characteristics such as functional complexity, predictability and repetitiveness are often considered, especially in the general class of production 1 Prof. Maria Orlowska is currently a visiting professor at the Department of Computer Science, Hong Kong University of Science and Technology.
2 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.
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 advances in technology, 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, proponents of CSCW  often speak of adhoc workflows, where the process cannot be completely defined prior to execution. 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.
The necessity for the support of change in workflow systems is well recognized.
Providing support for changing processes in workflow systems is, and has been for a few years, an active area of research , , , . In the following sections, we will first provide a categorization of change characteristics in workflow processes, dividing them into dynamic, adaptive and flexible workflows.
This paper primarily deals with the last. In the subsequent sections, we will present a unique, generic and practical approach for the handling of flexible workflows. Our approach is based on the principle of recognizing change as an ongoing process, and integrating the process of change into the workflow process itself. The framework presented in this paper introduces the concept of a flexible workflow comprising of a core process and one or more pockets of flexibility within the core process. These pockets are concretized at runtime using special build activities. Building defines a template for a particular instance to follow and as such provides a means of flexible process definition, which as we shall demonstrate, would not be possible in a typical production-style workflow modeling framework.
2 Dimensions of Change in Workflows
We first introduce basic terminology for the sake of clarity. By a workflow Model we mean a definition of the tasks, ordering, data, resources, and other aspects of the process. Most, if not all, workflow models are represented as graphs which depict the flow of the process tasks, together with a description of other task properties. A workflow Instance is a particular occurrence of the process. An Instance Type is a set of instances that follow the same execution path within a given process model.
The first dimension represents dynamism - which is the ability of the workflow process to change when the business process evolves. This evolution may be slight as for process improvements, or drastic as for process innovation or process reengineering. In any case, the assumption is that the workflow processes have predefined models, and business process change, causes these models to be changed.
The biggest problem here is the handling of active workflow instances, which were initiated in the old model, but need to comply now with the new specification. The issue of compliance is rather a serious issue, since potentially thousands of active instances may be affected by a given process change. Achieving compliance for these affected instances may involve loss of work and therefore has to be carefully planned .
A typical example of dynamic workflows can be found in university admissions.
Consider a scenario of a large tertiary institute that processes thousands of admission applications every year. The procedure for application, review and acceptance is generally well defined and understood. Suppose that the office of postgraduate studies revises the admission procedure for postgraduate students, requiring all applicants to submit a statement of purpose together with their application for admission. To implement this change, there can be two options available; one is to flush all existing applications, and apply the change to new applications only. Thus all existing applications will continue to be processed according to the old process model. This requires the underlying workflow system to at least provide some version management support . The second option to implement the change is to migrate to the new process. It may be decided that all applicants, existing and new, will be affected by the change. Thus all admission applications, which were initiated under the old rules, now have to migrate to the new process. This migration may involve addition of some transition workflow activities as well as rollback activities. Defining the migration strategy is a complex problem and has been the target of extensive research in this area , , , .
The second dimension of change is adaptability - which is the ability of the workflow processes to react to exceptional circumstances. These exceptional circumstances may or may not be foreseen, and generally would effect one or a few instances. Of course the handling of exceptions, which cannot be anticipated, is more complex. However, a large majority of exceptions can be anticipated , , and by capturing these exceptions, the adaptability of the workflow is promoted. In fact, unless these exceptions are captured within the workflow model, their handling will continue to be done outside of the system, in the form of "system workarounds", the consequences of which may come in conflict with process goals. However the complete set of exceptions for a given process can never be captured, thus dealing with unanticipated (true) exceptions will always be an issue , .
Using the same example as before, we can consider dealing with an admission application for a student with a multi-disciplinary background. For example, a student with a background in microbiology may be applying for a degree in IT. The review of this application may require the services of an academic outside the offering department. This may be rare but, if captured within the process model, could be handled within the workflow system.
Another example, which represents a true (unanticipated) exception, can be found in the employment workflow. An employment instance may have reached a stage where even the letter of intent has been issued. If at that time the organization issues a spending freeze, the active instances of the employment workflow will have to be dealt with, requiring rollback and/or compensation activities, even though the original employment workflow remains unchanged.
The third dimension is flexibility - which is the ability of the workflow process to execute on the basis of a loosely, or partially specified model, where the full specification of the model is made at runtime, and may be unique to each instance.
Processes which depend on the presence of such flexibility for the satisfactory
attainment of process goals can be found in many applications:
− 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 none-the-less 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.
− Web content management is also characterized by flexible processes, where especially in large projects, every development suggests the need for an overall plan to provide the objectives, approvals, and strategy, as well as a flexible means of coordinating the combined efforts of the theme designers, graphic experts, programmers, and project planners.
− 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.
The key issue in flexible workflows is the modeling of the loose or partial workflow. Thus rather than enforcing control through a rigid, or highly prescriptive model that attempts to capture every step and every option within the process, the model is defined in a more relaxed or "flexible" manner, that allows individual instances to determine their own (unique) processes. How to achieve such an approach to modeling is the main focus of this paper.
3 Framework for Flexible Workflows
Several workflow products and research prototypes exist. Most, if not all, provide process modeling tools that follow some variation of the workflow modeling language introduced by the workflow coalition . In Figure 1, we briefly introduce the basic structures of a generic workflow modeling language , also based on the coalition standards to a large extent. This language will be used in later sections to illustrate various examples.
In terms of a prescriptive language as above, one can say that the degree of flexibility is indicated by the number of instance types that can be generated from the process model. Number of instance types have a direct correlation with the number of choice constructs found within the process model . For example in the above figure, a choice-merge construct encapsulates two activities, E and F. In any given execution of this process, only one of E or F will be executed. Thus the process has two instance types. This is a straightforward and well-understood concept.
However, consider a scenario where a process generates a very large number of instance types, that is, demands a high degree of flexibility. Suppose that a large number, say k number of paths are present within a choice-merge construct. Each of these paths potentially represents a complex sub-process. There can be several such constructs within the process model, which may include nesting also. One can see that a typical workflow language may not provide a very elegant means of representing such a process. In order to seek some alternative way of modeling, let us start first with some simple approaches.
− Flexibility by Definition: Flexibility may be built into the model through choice merge constructs. Limitations of this approach have already been discussed. This would result in a highly complex model, which in some cases may still be incomplete.
− Flexibility by Granularity: Flexibility may be achieved by encapsulating activity details within workflow tasks, and keeping sub-activities 'internal' (and flexible), or outside the direct control of the workflow . This approach can be applied to a limited extent, but it cannot be used at a generic level without compromising the purpose of deploying workflow technology, namely to coordinate and control the flow of process activities.
− Flexibility by Templates: Flexibility may be achieved by providing separate templates for a given (set of) instance type. This slightly improves the readability and consequently maintainability of the model. However, choosing an instance type from a set of templates rather than one model with many choices will have advantages only if the number of templates can be restricted to a reasonably small number.