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 {shazia,maria}@csee.uq.edu.au;
[email protected]
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 [11], 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 [8] 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 [2], [3], [4], [15]. 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. 2.1
Dynamism
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 pre-
defined 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 [18]. 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 [7]. 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 [5], [9], [10], [13]. 2.2
Adaptability
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 [6], [17], 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 [12], [14]. 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. 2.3
Flexibility
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 [21]. In Figure 1, we briefly introduce the basic structures of a generic workflow modeling language [19], also based on the coalition
standards to a large extent. This language will be used in later sections to illustrate various examples. B
Begin
A
C
D
Fork
Synchronizer
G
End
E Choice
Merge F
Fig 1. Workflow Modeling Language
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 [20]. 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 [16]. 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.
A common disadvantage of the above approaches is that they still rely on a prescriptive model. Thus, not only is it cumbersome to model all choices in flexible processes, there may be choices which cannot be anticipated. Flexibility as we defined it earlier, is the ability of the workflow process to execute on the basis of a partial model, where the full specification is made at runtime. 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. In the following section, we present our approach to defining the flexible workflow, which aims at achieving the above. 3.1
Defining the Flexible Workflow
Almost all workflow enactment systems differentiate between the two aspects of workflow specification, namely, the workflow process and the workflow execution (control) data. Traditionally, the process model defines the process logic that provides the schema for particular instances. Workflow execution data on the other hand, consists of work items, where each work item relates to a particular execution of an activity. The work item thus stores all execution parameters of a particular activity such as client assigned, relevant data, and temporal values. In view of the specific requirements for modeling and enacting flexible workflows, we present a variant of the typical specification framework. Since flexible workflows need to consider the factors that dictate the individual instance paths, our approach aims at bridging these two aspects. The fundamental feature of our approach is: − To introduce a layer between the definition and execution data. This represents an open copy of the workflow model, for a particular instance, and − To have a workflow model which in itself constitutes only the partial definition. Model Specification The specification of the partial, which we now call the flexible workflow consists of: − A defined core process containing − Identifiable (pre-defined) workflow activities − Pockets of flexibility within the process with an associated − Set of workflow fragments, where a workflow fragment may consist of a single activity, or a sub-process − Special workflow activity called the build activity that provides the rules for concretizing the pocket with a valid composition of workflow fragments. The assumption is that the control flow between the fragments is not completely defined in the core process. The concept of pockets of flexibility aims at compensating for this inability to completely specify the process. The concept as such, is thus not limited to the workflow modeling language used to demonstrate the examples in this paper. As shown in figure 2, the pocket can simply be seen as a special BUILD activity within the workflow model, together with the set of workflow fragments from which the build activity will form a valid composition.
Current workflow products and projects have introduced an assortment of workflow modeling languages that support several variants of the typical (Sequence, Choice, Fork and Iteration) modeling constructs [1]. Introducing flexibility of specification by introducing more constructs within the modeling language has many drawbacks. There is often a semantic overlap in many of these constructs, making it difficult to define and verify. Furthermore, their enactment introduces unnecessary complexity in the workflow engine, limiting its scope and interoperability. However, the pocket concept provides the means for flexible definition without compromising the genericity or simplicity of the modeling language. We shall demonstrate this further in subsequent sections. Create File Begin
Recieve Patient
Examine Patient
Merge
Choice Retrieve File
BUILD
Make Diagnosis
Recieve Payment
End
Mamogram Ultra Sound
Second Opinion
Fig 2. Specifying the Flexible Workflow
In figure 2, we give an example of a flexible workflow representing a typical diagnostic process for investigation of breast cancer. A new patient coming into the center will first be entered into the system, or the file of an old patient will be retrieved. All patients then consult with an attending physician, who will determine what tests need to be performed, on a case-by-case basis. This forms the pocket of flexibility for the process. After the tests, the patient is called again by the attending physician who explains the results of the tests and makes a diagnosis. The patient is then required to report to accounts to make the required payments before leaving the center. Instance Specification The instance specification initially consists of a copy of the core process. As a particular instance proceeds with execution, the build activities provide the means of customizing the core process for that particular instance. The instance specification prior to building, we call an open instance. The instance specification after building we call an instance template. Thus the instance template is a particular composition of the fragments within the flexible workflow. The instance templates in turn have a schema-instance relationship with the underlying execution data. In traditional terms, the instance template acts as the process model for a particular instance. Execution takes place with full enforcement of all coordination and temporal constraints, as in a typical production workflow. However, template building is progressive. The core process may contain several pockets of flexibility which will be concretized through
the associated build activities as they are encountered. As such, the template remains open until the last built activity has completed. Retrieve File Begin
Recieve Patient
Merge
Choice Create File
Examine Patient Mamogram Ultra Sound
Second Opinion
Retrieve File Begin
Recieve Patient
Merge
Choice
Make Diagnosis
Recieve Payment
End
Examine Patient
Create File Ultra Sound
Make Diagnosis
Recieve Payment
End
Fig 3. Instance Templates
In figure 3, we give example instance templates for the flexible workflow given in figure 4. Execution will commence with the initial activity of the core process, which establishes the creation of the instance and necessary data. After successful completion3 of the initial activity and subsequent activities, a pocket of flexibility is encountered, and the associated build activity is activated. The execution of the build activity replaces the open instance with the instance template, which in turn serves as a process model for that instance. A critical question however is, why is the instance template in figure 4 a valid composition. Where, validity relates to the semantic correctness of the composition in relation to the process under consideration. Valid instance templates must be ensured through the build rules captured within the build activities. Building may be constrained by several factors, including at least the data relating to that instance, the stage of execution of the instance, temporal constraints, and the business rules of the particular application for which the template is being defined. For example, in education, it will be constrained by the progress of the student, such that at any given stage of the study process, the student can build the template from a specified set of study activities. A student, for example, cannot take up a study activity whose prerequisites have not been met.
3
We ignore failure of workflow activities at this time
3.2
Building Instance Templates
The functionality of the build activity is fundamental to this approach. In this section we will discuss and identify the set of parameters that are essential to define a build activity at a generic level. First of all there is no reason why the build activity should allow building from existing fragments only. There are several examples of processes, where entirely new (unprecedented and hence not pre-defined) activities have to be performed for a given instance, and perhaps subsequently used for other instances. By extending the functionality of the build activity, processes with such a high level of flexibility can also be catered for. We see the build activity providing one of the following: − Fully Automated Support: The Build activity automatically builds the instance template from the given set of workflow fragments based on the instance data and given constraints. − Partially Automated Support: The Build activity invokes an application program that allows a workflow client, to build the instance template from the given set of workflow fragments, but within given constraints. − Manual Control: The Build activity allows a workflow client to define new fragments, and then build the instance template from the new as well as existing fragments. Secondly, there will be constraints on the extent of building. For example, a student may be allowed to take not more than 4 subjects consecutively. Extents may also be defined on the basis of other factors such as temporal properties. For example, a doctor may prescribe tests to be performed in the next 3 days. Thus building will be restricted by both the pool of workflow activities (fragments) that are available for selection, as well as the extent of selection. Lastly, there is the question of composing the selected fragments. From an engineering point of view, the workflow client may not (rather should not) be given an interface to compose the fragments using a complex workflow modeling language. Instead, we see the build activity as another application within the process, since making an assumption about the user’s knowledge of process models and workflow languages is unrealistic. This is a strong justification of the argument that our approach integrates the process of change within the workflow process. Behind the build application, an instance template will be composed, and made available to the workflow engine. In the following sections, we will discuss the ways of composing selected workflow fragments, explaining how each of these compositions provide a means of capturing flexible specifications without compromising the simplicity of the modeling language. Sequence The build activity allows workflow fragments to be arranged in sequence. However, the choice of order remains flexible and is determined by the user during the build activity. Figure 4 gives an example composition using the sequence construct.
A B
A
B
B
B
A
C
C
C
A
…
C
Workflow Fragments
Fig 4. Building Sequential Constructs
It is interesting to note that this flexibility of composition contradicts conventional sequential constraints, where “A is followed by B” indicates a control flow dependency between A and B. This dependency cannot be established in the above scenario. However, such a flexible sequential composition is required to fulfill constraints such as “Do all of A, B and C, but one at a time”. Fork The build activity introduces a fork coordinator and arranges selected workflow fragments in a fork structure. Flexibility of definition is especially required when the fork can be built from any number of fragments. A typical constraint for the above can be “Do any 3 of A, B, C or D”. Figure 5 shows the various templates that the build activity can compose using a fork construct. A
Fork
Fork
B
C
A
D
C
C
B
B
D
Fork
Fork
Workflow Fragments
D
A
D
A
C
B
Fig 5. Building Fork Constructs
Synchronize Instance templates that contain the fork construct, will require the fragments constituting the fork to be synchronized at some point. Synchronization can be achieved in one of two ways: 1. Immediate Synchronization: A synchronizer is added as part of the build activity that introduces the fork. This is a simple option as illustrated in Figure 6 (a).
Providing synchronization within the pocket preserves its boundary, and provides a clean connection to the core process. 2. Deferred Synchronization: Synchronizing may be premature at this stage for some applications, and may unnecessarily hold up the progress of the instance. For example Figure 6(b) shows a template built against the constraint, “Do all of A, B and C, but do not wait for A to complete. In this case it has to be ensured that eventually all multiple branches will be synchronized, or at least completed before the core process completes.
Fork
A
Fork
B
C
Synchronizer
a. Immediate Synchronization
A
B
C
Synchronizer
b. Deferred Synchronization
Fig 6. Building Synchronizing Constructs
Choice and Merge While choice and merge constructs may be present within workflow fragments, we propose that these constructs not be used to build the instance template. Since an instance template represents a particular occurrence of the workflow process, the choices should be made during the execution of the build activity. For example, the constraint “Do any one of A, B or C” will be built as either A or B or C, and not all within a choice-merge construct. The elimination of the choice-merge construct from the instance template, further has the advantage of simplifying the model, and removing the chance of deadlocks or lack of synchronization [19]. Iteration Iteration and/or multiple executions may take many forms [1]. The build activity can provide these constructs with significant convenience as compared to pre-defined models. 1. Arbitrary Cycles: A fragment may be encapsulated in a typical do-while/repeatuntil construct, with a given condition for iteration. 2. Multiple Executions: The case of multiple executions is more interesting. A fragment may be required to be executed any k number of times, for example to fulfill the constraint “ Do A k number of times” where k is instance dependent. Figure 7 illustrates the possibilities for multiple execution of A, which can be (a) multiple executions in sequence, or (b) multiple executions in a fork.
A
A
Workflow Fragments
A
Fork
A
A
A
A
a. Multiple Executions in Sequence
b. Multiple Executions in a Fork
Fig 7. Building Multiple Executions
The above discussion reveals the fact that the build activity is a fundamental object of constraint specification in this framework. These constraints represent the process logic of the application under consideration. The challenge is to identify a generic set of parameters, which would allow the customization of the build activity. We identify the following three factors, which at least need to be specified, in order to customize a build activity for a given application: − Type: Whether the selection of the workflow fragments will be (fully/ partially) automated or manually controlled. This determines the available pool of workflow fragments. − Extent: How many fragments can be selected from the available pool. − Structure: What modeling construct will be used to compose the selected fragments. The design of an appropriate language which facilitates the specification of build rules and constraints is a whole new, interesting and challenging research issue. The functionality of the process definition tool must be extended with the ability to define the pockets of flexibility. Also, the build activities must have the ability to access and change open instances as they execute. There are several interesting architectural implications of this framework. Currently, we are working on extending the functionality of a process modeling and verification tool FlowMake [http://www.dstc.edu.au/praxis], to incorporate the concept of pockets of flexibility.
4
Conclusions
Difficulties in dealing with change in workflow systems has been one of the major factors limiting the deployment of workflow technology. At the same time, it is apparent that change is an inherent characteristic of today’s business processes. This paper provides a comprehensive categorization of change characteristics in workflow processes, based on which 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 provide a powerful means of capturing the logic of highly flexible processes without compromising the simplicity and genericity of the workflow specification language. This we accomplish through pockets of flexibility in workflow specifications, which allow workflow processes to be tailored to individual instances at runtime.
Acknowledgements The authors would like to acknowledge the comments and feedback provided by Karsten Schulz at the Distributed Systems Technology Center, Brisbane, Australia.
References 1.
W.M.P. van der Aalst, A.P. Barros, A.H.M. ter Hofstede, and B. Kiepuszewski. Advanced Workflow Patterns. O. Etzion and P. Scheuremann, editors, Proceedings Seventh IFCIS International Conference on Cooperative Information Systems, CoopIS 2000, Volume 1901 of Lecture Notes in Computer Science, pages 18-29, Eilat, Israel. Springer-Verlag. September (2000). 2. W.M.P. van der Aalst and S. Jablonski. Dealing with Workflow Change: Identification of issues and solutions International Journal of Computer Systems, Science, and Engineering, 15(5):267-276, (2000). 3. S. Ellis, K. Keddara , G. Rozenberg. Dynamic Changes within Workflow Systems. Proceedings of ACM Conference on Organizational Computing Systems COOCS 95 (1995). 4. J Eder, W. Liebhart. The workflow activity model WAMO. Proceedings of the 3rd international conference on Cooperative Information Systems (CoopIs), Vienna, Austria, May (1995). 5. Fabio Casati, S. Ceri, B. Pernici, G. Pozzi. Workflow Evolution. In Proceedings of the 15th International Conference on Conceptual Modeling, ER’96, Cottbus, Germany. Springer Verlag, Lecture Notes in Computer Science (1996). 6. Fabio Casati, Giuseppe Pozzi. Modeling Exception Behaviors in Commercial Workflow Management Systems. Proceedings of the Fourth IFCIS International Conference on Cooperative Information Systems (CoopIS99). Edinburgh, Scotland. Sep 2-4, (1999). 7. Gregor Joeris, Otthein Herzog. Managing Evolving Workflow Specifications. Proceedings of the third IFCIS International Conference on Cooperative Information Systems (CoopIS 98). NewYork, USA. Aug (1998). 8. Mark Klein, Chrysanthos Dellarocas, Abraham Bernstein (eds.) Workshop on Adaptive Workflow Systems. Conference on Computer Supported Cooperative Work (CSCW), Seattle, USA. November (1998). 9. Markus Kradolfer, Andreas Geppert. Dynamic Workflow Schema Evolution based on Workflow Type Versioning and Workflow Migration. Proccedings of the Fourth IFCIS International Conference on Cooperative Information Systems (CoopIS99). Edinburgh, Scotland. Sep 2-4, (1999). 10. Chengfei Liu, Maria Orlowska, Hui Li. Automating Handover in Dynamic Workflow Environments. Proceedings of 10th International Conference on Advances in Information System Engineering (CAiSE 98), Pisa, Italy, June (1998).
11. Mohan C. Tutorial: State of the Art in Workflow Management System Research and Products, 5th International Conference on Extending Database Technology, Avignon, France, March (1996). 12. Manfred Reichert, Peter Dadam. ADEPTflex - Supporting Dynamic Changes of Workflow without loosing control. Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow and Process Management (1998). 13. Shazia Sadiq. Handling Dynamic Schema Change in Process Models. Australian Database Conference, Canberra, Australia. Jan 27 - Feb 02, (2000). 14. Shazia Sadiq. On Capturing Exceptions in Workflow Process Models. Proceedings of the 4th International Conference on Business Information Systems. Poznan, Poland. April 12 13 (2000). 15. Amit Sheth. From Contemporary Workflow Process Automation to Adaptive and Dynamic Work Activity Coordination and Collaboration. Siggroup Bulletin, 18(3):17-20, (1997). 16. Keith D. Swensen, Kent Irwin. Workflow Technology: Tradeoffs for Business Process Reengineering. Proceedings of ACM Conference on Organizational Computing Systems (COOCS 95), Milpitas, CA. USA, Nov (1995). 17. Diane M. Strong, Steven M. Miller. Exceptions and Exception Handling in Computerized Information Processes, ACM Transactions on Information Systems, Vol. 13, No 2, Pages 206-233, April (1995). 18. Shazia Sadiq, Olivera Marjanovic, Maria E. Orlowska. Managing Change and Time in Dynamic Workflow Processes. International Journal of Cooperative Information Systems. Vol. 9, Nos. 1 & 2. March -June (2000). 19. Wasim Sadiq, Maria E. Orlowska. On Correctness Issues in Conceptual Modeling of Workflows. In Proceedings of the 5th European Conference on Information Systems (ECIS ‘97), Cork, Ireland, June 19-21, (1997). 20. Wasim Sadiq, Maria E. Orlowska. Analyzing Process Models using Graph Reduction Techniques. Information Systems, Vol. 25, No. 2, pp. 117-134, 2000. Elsevier Science. June (2000). 21. Workflow Management Coalition. Interface 1: Process Definition Interchange, Process Model, Document Number WfMC TC-1016-p. (1998).
