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.
OOPSLA'98
Business Object Workshop IV