../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV

Using Intentional Information to Coordinate Inter-operating Workflows

Position Paper for the Business Object Design and Implementation Workshop; OOPSLA '98

Bill Kuechler Bill Burg

University of Texas at San Antonio

Department of Accounting and Information Systems

E-mail: bkuechler@utsa.edu E-mail: wburg@utsa.edu

Abstract

Automated workflow management systems (WFMS) between cooperating but autonomous groups can fail because autonomous workgroups are free to change the activities that constitute their task, disrupting coordination between systems. We have spent several years constructing and validating a model of trigger-based (process state based) coordination that is more robust than current WFMS implementations under conditions of unilateral process change. We believe the research has implications for the design of inter-operating software systems outside the restricted domain of WFMS, specifically for the development of enterprise business object component systems. In this paper we briefly describe an intentional definition of workflow and the interpretation of that definition for maintaining coordination of a composite system in which components autonomously evolve.

1. Introduction

Most existing WFMS are based on 'manufacturing models' of work where precise specification of activities and their execution times are (presumed) critical. Yet many work processes, especially knowledge (office) work, necessarily incorporate slack time to handle indeterminacy and frequently specify desired results intentionally, that is the process goal(s) are significant, but the details of execution are not [1]. This delegation of responsibility is well represented in the object-oriented paradigm by messaging and information hiding. However a problem arises when two conditions occur: (1) the delegating process requires intermediate state information from the delegated process to coordinate other activities, yet (2) the autonomous subprocess is free to change its enactment definition rendering pre-defined process state checkpoints undefined. This situation is likely to occur in inter-organizational systems when multiple, autonomous business entities control the software systems that must coordinate, as in virtual manufacturing organizations.

2. Conventional Trigger Modeling

Trigger modeling for workflows [2] is a formal procedure for identifying which activities, performed by which actors (or more generally, roles) are the logically necessary predecessors of other activities. Trigger modeling is a rigorous analysis of manual processes, typically performed in order to obtain a formal definition of work being performed prior to entry into a WFMS. A portion of a conventional trigger model for the manufacturing case described later in this chapter is shown in Figure 1.
In Figure 1 the work activities such as Cut Vest Batch are constrained not to begin until triggered by semaphores from prior processes (t1 through t5) that indicate preconditions have been satisfied. The semaphores themselves are called triggers. Trigger models are isomorphic to Petri nets, and following work analysis the trigger model can be directly translated to a Petri net for formal analyses of correctness and completeness.

3. Abstract Context of the Coordination Model

Trigger modeling has traditionally been used in the context of a single work site. Additional complexities arise when triggers are required between WFMS at different sites with potentially different views of how a given process should be performed.
With reference to Figure 2, process A is dependent on multiple autonomous subprocesses. The dependency is both for the final product of the subprocesses, and for coordinating communications at intermediate points within the subprocesses, which enable various efficiencies, principally scheduling efficiencies. The timing of the coordinating communications are specified in terms of a process state (trigger state), as A understands the production process. However B may change process definition dynamically. This will result in mis-timing or disappearance of the coordinating communications with process A. The processes will become uncoordinated unless the trigger state can be reinterpreted in terms of the new process definition. The problem is to place the coordinating trigger in the altered definitions at positions that would be considered equivalent by both A and B to the position occupied by the trigger in the original definition. An exact match to the original position cannot be found and so a semantically similar positioning must be inferred from an interpretation of the incomplete information contained in the process models.

4. Goal Based Coordination Model

The basis of our coordination model is a work definition (WD) that specifies a hierarchy of intentions (goals) for the activities of a work process. Figure 3 illustrates the WD used by the model. The root goal is the overall purpose of the work process, and the name by which the work is commonly known in the organization. The layer of subgoals is generated during process design or specification, and represents a process of stepwise decomposition of the root goal into its components [5]. When the subgoals are well enough defined to be implemented, they are linked to the generalized functionality by which they will be enacted. Incorporating the concept of functions into the WD more closely models the manner in which workers conceive their activities than use of goals alone [4]. The terminal (leaf) nodes of the WD are the actual work activities containing predecessor / successor information.

5. Interpretation of the Work Definition

Our model of coordination is able to interpret changes in an intentionally defined workflow and locate placement points for coordinating triggers that are semantically similar to the placement points in the original work definition. Interpretation involves determining the most common set of intentions and the most common set of predecessor and successor activities for activities in two different workflows. While not conceptually difficult, the process too lengthy to address in detail in a short paper, and is fully described elsewhere [3]. Some common understanding (definitions; semantics) across inter-operating systems is required even with interpretation, but that understanding is at a business level; this information has been shown repeatedly to be far more stable and more widely shared than low level implementation information.

6. Conclusion

Dynamic change of process enactment seems as inevitable for autonomous inter-operating software systems of all types. Capture of intentional information concerning the higher level business objectives of processes and the mapping of specific activities to those objectives allows dynamically changing systems to maintain coordination across a useful range of situations. Interpretation of intention or purpose relieves the developer of the impossible task of specifying a-priori the evolution of a complex, open system [6].

References:

[1] T. Davenport, S. Jarvenpaa, and M. Beers, "Improving Knowledge Work Processes", Sloan Management Review, Summer, 1996.

[2] Joosten, S., "Trigger Modelling for Workflow Analysis", in Proceedings of CON 94: Workflow Management, (pp. 236 247). R. Oldenbourg.

[3] W. Kuechler and V. Vaishnavi, " A Goal-based Model of Coordination in Interoperating Workflows", submitted to WITS'98.

[4] R. Schanck, and R. P. Abelson, Scripts, Plans, Goals and Understanding: An Inquiry into Human Knowledge, Hillsdale, NJ: Lawrence Erlbaum, 1977.

[5] H. Simon, The New Science of Management Decision - Revised Edition, Prentice Hall, 1977.

[6] Wegner, P., "Why Interaction is More Powerful than Algorithms", Communications of the ACM. 40(5), 1997, pp. 80 91.

../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV