On Capturing Process Requirements of Workflow ... - Suraj @ LUMS

On Capturing Process Requirements of Workflow Based Business Information Systems* Wasim Sadiq and Maria E. Orlowska Distributed Systems Technology Centre Department of Computer Science & Electrical Engineering The University of Queensland Australia email: {wasim, maria}@dstc.edu.au Abstract The workflow technology manages the execution of business activities and coordinates the flow of information throughout the enterprise. It is emerging as one of the fastest growing disciplines in information technology. It is essential to correctly and effectively capture the workflow specific requirements of business information systems before their deployment through workflow management systems. In this paper, we look at different issues in capturing such requirements and propose a systematic layered modeling approach. We split the workflow specification requirements into five basic dimensions: structure, data, execution, temporal, and transactional. The concepts introduced in this paper have been applied as a foundation to the development of a workflows modeling and verification tool, FlowMake.

1. Introduction The past few decades have witnessed a tremendous growth in business process automation. It is essential to understand the operations of business processes before any information systems are developed and implemented. For this purpose, business data and process modeling methodologies are used. Data requirements are modelled through conceptual data modeling methodologies like entity-relationship, and process modeling methodologies like data flow diagrams, are used to identify business processes and capture the flow of information between them. Organizations are partitioned into several functional areas and information systems are deployed for each of the divided areas. Activities within a functional

————— * 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.

business area are either manual, automated, or a combination of both. For large organizations, the systems supporting the functional areas run in heterogeneous and distributed hardware and software environments. Generally, each system itself is also developed following a modular approach. The related modules and systems must communicate and coordinate with each other to effectively achieve their functional objectives. The coordination of these automated or manual activities has historically been performed manually. In recent years, the possibility of automating such coordination is being explored through workflow technology. The Workflow Management Coalition [14] defines workflows as “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules.” Workflows represent the organizational flow of information from one processing entity, either manual or automated, to another. The processing entities use this information to accomplish assigned tasks. These tasks take some information from the preceding tasks, perform some work based on the information received using the services of the assigned processing entities, and proceed to the next task(s) in the workflow. The on-line information management systems accomplish much more automation than their batch-oriented counterparts. Sophisticated computerization provides further possibilities for automating the execution coordination. Workflow management systems provide capabilities to partially or fully take over the responsibility for coordinated execution of workflow tasks from human coordinators. The execution coordination involving tasks and processing entities is accomplished by enforcing associated business process rules and constraints. Before a workflow management system can be deployed to manage workflows, process definition tools are required to model workflow processes. Information about the process rules and constraints is stored in the workflow repository. The workflow management systems make extensive use of this repository in their operation. On the basis of the process definitions, workflow management systems create and execute workflow instances and coordinate the interactions between its tasks. The workflow management systems promote a component oriented information systems development approach. The workflow based information systems separate the process logic from application logic. The process logic is implemented through a workflow management system and the application logic through underlying application components. Whereas, in conventional information system both process logic and application logic are embedded into the same system. This separation requires that at the time of capturing the requirements of information systems a clear distinction be made between these two types of requirements. This paper is an attempt to provide a framework that helps in capturing the process logic requirements of workflow based information systems. There are several workflow management systems in the market. Most of these products also provide graphical tools and a variety of modeling languages to define workflows. We believe, however, that there is a need to identify and systematically classify the issues that should be targeted during the workflow modeling process. The major contribution of this paper is to provide a breakup of the modeling effort

into five intuitive phases. Furthermore, we identify a means of capturing different requirements of workflow applications. A CASE tool, FlowMake, for workflow modeling and verification has also been developed as an outcome of this work. The FlowMake provides workflow analysts and designers a well-defined framework to model and reason about various aspects of workflows.

2. Partitioning the Workflow Model The primary objective of a workflow management system is to coordinate the execution of activities or tasks in an organization. Correspondingly, a workflow modeling framework should cover the techniques and tools to capture, analyze, and specify different aspects of tasks and their coordination. Objects Manipulate Tasks

Performers Perform Control

Control Constraints

Figure 1. Workflows building blocks

We divide a workflow application into four building blocks: objects, tasks, performers, and constraints. The overall characteristics of these four components identify the nature of the application. We use the keyword work to define these four building blocks: – Work is performed on Objects. An object is any entity of interest. – Tasks specify the work to be done. The work specified by tasks is generally performed on objects or on the basis of information contained in objects. – Performers carry out the work. Tasks cannot perform the work themselves. They need the services of performers. – Constraints control correct execution of the work. Tasks specify what to do and performers carry out that work. The constraints ensure that the work is performed correctly. The motivation of the work presented in this paper is to specify a framework for capturing the workflow specific requirements of a business information system. In other words, capturing the essential information pertaining to the above mentioned four building blocks. A workflow management system coordinates the execution of tasks. Looking at Figure 1, we realize that this coordination is dependent on the constraints block. The performers execute tasks conforming to the specified constraints. As such, a primary objective of workflow modeling is to capture and ensure the correctness of these constraints.

One way to enhance the understanding of workflow models and to reduce the complexity is to divide the modeling activity into phases. By adopting a layered modeling approach, we can capture and analyze the modeling information for each of the phases. Eventually requirements captured in all phases could be combined into an integrated workflow model.

Workflows Structure

Transactional Data Execution

Temporal

Figure 2. Partitioning the workflow model

We propose to divide the modeling effort into five phases: structure, data, execution, temporal, and transactional. In the following sections, we briefly explain the process information captured under each phase.

2.1. Structure A workflow is a set of tasks that are performed to achieve some business objectives. Generally, the tasks in a workflow are inter-related in such a way that the initiation of one task is dependent on the successful completion of a set of other tasks. Therefore, the order in which tasks are executed is very important. The first phase of this modeling framework captures the flow of execution from one task to another. The structural modeling of a workflow defines the way a workflow management system would order and schedule workflow tasks. This is the primary and perhaps the most important aspect of a workflow model and builds a foundation to capture other aspects of workflow requirements. Generally, information modeling techniques include graphical representation that enhances the understanding of the model. A workflow specification could also be represented using graphical objects. In this section, we briefly describe the structural aspect of our workflow modeling language and its graphical representation. This language is based on generic workflow modeling concepts as described in Workflow Management Coalition [15]. For a more detailed description, the reader is referred to [13]. The workflow models in this graphical language are modeled using two types of objects: node and control flow. Node is classified into two subclasses: task and condition. A task, graphically represented by a rectangle, represents the work to be done to achieve some objectives. It is also used to build sequential, concurrency, and synchronization structures. It is the primary object in workflow specifications

and could represent both automated and manual activities. Tasks are executed by assigned performers. A condition, graphically represented by a circle, is used to construct or-split and or-join structures. A control flow links two nodes in the graph and is graphically represented by a directed edge. By connecting nodes with control flows through five modeling structures, as shown in Figure 3, we build directed acyclic graphs (DAG) called workflow graphs where nodes represent vertices and control flows represent directed edges. From now on, we will refer to vertices as nodes and edges as flows.

Sequence

Initial

Concurrency

Synchronization

Choice

Final

Merge Nesting

Figure 3. Workflow modeling structures

Sequence is the most basic modeling structure and defines the ordering of task execution. It is constructed by connecting at the most one incoming and one outgoing flow to a task. A concurrency structure is used to represent concurrent paths within a workflow graph and is modeled by connecting two or more outgoing flows to a task. At certain points in workflows, it is essential to wait for the completion of more than one execution path to proceed further. A synchronization structure, represented by more than one incoming flow to a task, is applied to synchronize such concurrent paths. A synchronization task waits until all the incoming flows have been triggered. A choice structure is used to model mutually exclusive alternative paths and is constructed by attaching two or more outgoing flows to a condition object. At runtime, the workflow selects one of the alternative execution paths for a given instance of the business process by activating one of the outgoing flows originating from the choice condition object. The choice structure is exclusive and complete. The exclusive characteristic ensures that only one of the alternative paths is selected. The completeness characteristic guarantees that, if a condition object is activated, one of its outgoing flows will always be triggered. A merge structure is “opposite” to the choice structure. It is applied to join mutually exclusive alternative paths into one path by attaching two or more incoming flows to a condition object. Since a workflow model is represented by a directed acyclic graph (DAG), it has at least one node that has no incoming flows (source) and at least one node that has no outgoing flows (sink). We call these initial and final nodes respectively. To uniquely identify a final node for a workflow graph, we join all split structures. Therefore, a workflow graph contains only one initial and one final node.

A workflow instance completes its execution after its final node has completed its execution. We need the iteration structure to model the repetition of a group of tasks within a workflow. The iteration is modeled through block structures. As long as a certain condition is met, a sub graph of the workflow is repeated. The nesting structure simplifies the workflow specifications through abstraction. Using this construct, we can encapsulate a workflow specification into a task and then use that nested task in other workflow specifications. For each execution of a nested task, the underlying workflow is executed. The Workflow Management Coalition [15] identifies four primary workflow control structures: or-split, or-join, and-split, and and-join. These are represented in our model through choice, merge, concurrency, and synchronization structures respectively. We have the condition object to model the choice and merge structures. However, the concurrency and synchronization structures are represented simply by directly connecting flows to tasks. This approach reduces the number of modeling objects but at the same time allows explicit notation for workflow structural models. Nevertheless, in certain cases, it requires the use of null tasks whose only purpose is the coordination of flow and compliance to the syntactical correctness criteria of workflow structures.

2.2. Data The workflow tasks are generally defined and executed outside the workflow management system. The coordination relationship among these tasks is modeled through control flow specifications. A data dependency may also exist between tasks that is not identified in control flow specifications. A task T1 is called data dependent on another task T2 if, for its successful execution, it requires the data produced or provided by T2. Such a relationship is modeled by using a data flow that specifies the mapping between data provided by the T1 and received by T2. As shown in Figure 1, performers are responsible for task execution. During task execution some objects are manipulated by tasks. While the performers execute tasks they make use of or generate some data regarding the objects they work on.

Performer

Performer Data Common Data

Task

Workflow Data

Figure 4. Task and performer data relationship

We classify such data in three categories: performer data, workflow data, and workflow specific performer data. The performer data is generally invisible to the workflow application unless the performer makes it available to the workflow management system. The workflow data is local to the workflow management system and is used for coordinating the task scheduling and execution. A subset of workflow and performer data is common and called workflow specific performer data. The workflow management system and the performers communicate with each other using this set of common data parameters. This relationship is shown in Figure 4. The structural and data aspects of a workflow model are significantly dependent on each other. For example, the condition object needs the data parameters provided by a data flow to select the alternative path. Similarly, a control flow path must also exist to satisfy a data flow constraint between two tasks. We support the modeling of data flows through global workflow variables. Each task has associated input and output containers. The underlying application component of a task can read the variables in its input container and write into the variables in its output container. The variables in these containers of a task are mapped to a subset of the global workflow variables, which are used to indirectly map the variables of one task to another.

2.3. Execution Using the structure and data aspects of a workflow model, the workflow engine schedules appropriate tasks at different stages of workflow execution. This scheduling activity is accomplished through the task scheduler that is a fundamental part of a workflow engine. The task scheduler allocates the tasks to respective performers. For task allocation, the workflow management system needs certain modeling information for individual tasks that is captured by the execution aspect of the framework. As shown in Figure 1, tasks are allocated to performers who in turn are responsible for carrying out the tasks. We classify tasks into two categories: automated and human-oriented. An automated task is performed completely and independently by a computer. To execute such a task, the workflow management system would need information about the protocol to communicate with the underlying computer application. A human-oriented is performed by humans and may also have an associated computing resource for accomplishing the task objectives. For such a task, the workflow management system would also need information about role and responsibilities of the person who would be executing the task. As described earlier, we use the nesting structure to encapsulate a workflow into a task and then use that nested task in some other workflows. The atomicity characteristic distinguishes between the tasks that could be decomposed into workflows and the tasks that could not be decomposed. An atomic task is a single task from the point of view of a workflow management system. A nested task encapsulates a workflow and the tasks in the encapsulated workflow have to be executed for the successful completion of the nested task. It is possible to have an atomic task that

is more complex than a nested task. It all depends on the workflow specifications. However, as long as it does not decompose into a workflow, we call it an atomic task. Under the scope classification, we have two types of tasks: external and internal. Most of the tasks in a workflow specification belong to the first category. An external task is any automated or manual activity that is performed to accomplish some business objective. An internal task is a workflow management system activity that is performed to coordinate other external or internal tasks. In some workflows, certain authorization may be required for task allocation. The workflow application for such a process must have the ability to ensure that only the authorized performers execute the task. Such authorization levels are also captured during the modeling of execution aspects. Another important feature of workflows is distributed allocation of tasks to a group of performers. Tasks use services of performers for carrying out their operations. In a workflow application that involves a large number of humans as performers, effective task allocation policies are even more important. For example, for a particular task there could be a group of performers who could perform the task. There could be several considerations for allocating the task to a particular performer. For example, we may want to maintain a balanced workload among performers. These task allocation policies could be very complex and may involve many constraints. It is important to capture and analyze the task allocation policies during the modeling process.

2.4. Temporal The temporal aspects add another dimension to the scheduling of workflow tasks. Without temporal constraints, a workflow task is initiated when its preceding tasks in structural specification have finished execution. However, if any temporal constraints are specified, they must also be satisfied, besides other constraints, to successfully execute the task. One may argue to include temporal constraints in execution partition. However, in our opinion, these constraints are complex enough to be captured in an independent phase of workflow modeling. In this section, we identify the types of temporal constraints that could be applied to workflow specifications. At certain points in workflows, we may require a task to finish by a specific deadline. There is more than one way to specify such deadlines. A task specific deadline does not depend on other tasks in the workflow. We may specify that a task T1 must finish at a given time. At the time of execution, if that deadline was reached and task T1 had not finished its execution, the workflow engine would take appropriate actions. The task specific deadline could be specified as a task property. There could be two possibilities of specifying a task specific deadline. The first type is specified at the initiation of the workflow that contains the task with deadline. Such a deadline specification model the maximum time allowed for the workflow to finish all the preceding tasks and the task with deadline specification. The second type is specified at the time of the task initiation

and models the maximum time allowed for the execution of the task. The task specific deadlines could be relative or absolute. We can specify an absolute deadline irrespective of the current time. For such a workflow, each instance would have the same task deadline as long as it is not changed at the workflow definition level. Such deadlines are defined as workflow constants. The relative deadlines are specified in relation to the current time. An inter-dependent deadline introduces temporal dependencies between tasks. For example, we may specify that task T2 must finish within a specified time after initiating or completing task T1. The workflow engine may have to finish several other tasks between T1 and T2. The temporal dependency is represented with the help of a temporal flow where the deadline constraint is attached to the flow. Another type of temporal constraint is the wait constraint. At particular stages of workflow execution, we may want to wait for a given time before proceeding. Just like deadlines, this wait specification could either be task specific or inter-dependent. A task specific wait specifies the time a task should wait for before starting its execution. Just like deadline, this wait could be specified at the time of workflow initiation or task initiation. The workflow initiation based wait models the minimum time allowed for the workflow to finish all the preceding tasks before starting or completing the execution of the task with wait specification. The task initiation based wait models the minimum time allowed for execution of the task. If the task finishes its execution before the wait time, it would wait before proceeding. The inter-dependent wait introduces temporal dependency between tasks. For example, we may specify that task T2 must not start or finish before a specified time after starting or completing task T1. The temporal dependency is represented with the help of temporal flow where the wait constraint is attached to the flow. The workflows with obligatory constraints must be able to handle any number of instances at a given time. For example, the workflow to process the admission applications for a university has an obligatory constraint to process all the applications received. These constraints, along with other temporal constraints, add to the complexity of workflow applications. Other important temporal properties are the minimum, maximum, and average execution times for each task. Such specification, along with deadlines, waits, and obligatory constraints are required to reason the feasibility and effectiveness of a workflow application. In structural specification, we introduced the iteration concept that is based on some conditional value. There is another possibility of iteration, called temporal iteration, that is modeled to repeat a task for a given time period. Such a concept is very useful for transactional workflows, where we may want to model a task with time dependent redo properties in case of failures. There are several other constraints like workload, availability and efficiency of staff, holidays, etc. that may affect the timely completion of workflow tasks. The identification of temporal constraints and associated bottlenecks during the modeling process is very important for workflows involving a large number of performers and expected instances.

2.5. Transactional The concept of transactional workflows has been an active area of workflow research [2, 9, 10]. The difference between workflows and transactional workflows is similar to the difference between legacy applications based on flat sequential files and the applications developed using relational database management systems like Oracle. The modern relational database management systems provide extensive transaction management features to ensure the consistent updating of databases and handling of system failures. Similarly, transactional workflows extend the basic workflow model by introducing well-tested transactional features of the transaction management systems. The concept of transactions is used in transaction processing systems to maintain the consistency of information systems in case of system and transaction failures and concurrent updates to the underlying database. A Transaction conforms to the wellknown ACID (Atomicity, Consistency, Isolation, and Durability) properties. Correspondingly, a transactional workflow management system should have facilities to define these transactional properties. The concept of transactions fits beautifully within the database-oriented transaction management paradigm. However, the transactional workflows for large enterprises involving heterogeneous and distributed environments may not meet the strict requirements of ACID properties [2]. A database management system has to deal with computer programs and data only, whereas, a workflow management system deals with humans and manual activities as well. Furthermore, not all the workflow processing entities may be based on database management systems supporting transaction management. Therefore, a flexible transactional model is generally required for defining and managing transactional workflows. The motivation behind modeling the transactional features of a workflow is to add the capability in the workflow to handle exceptional circumstances that would otherwise leave the workflow in an unacceptable state. The transactional features of a workflow are handled by a workflow management system. However, the workflow management system needs some information about transactional properties of the workflow tasks to control these features. Two important transactional workflow concepts are abort and recovery. A workflow starts its execution from a unique initial task and completes its execution after executing a final task. During these two tasks, it may run several other tasks depending on the control flow specification. Abort introduces an exceptional termination of the process during its execution. There could be several reasons for abort. For example, a system or application error could result into abnormal workflow termination. It is also possible for the user to abort the workflow during its execution. Recovery is the process of taking an aborted workflow from an unacceptable state to an acceptable state. The way a system handles recovery depends on the underlying recovery mechanisms in the workflow management system. In some cases of recovery, the system would need to undo the activities performed by some tasks. For this purpose, during the modeling activity, we identify compensating tasks that are executed during recovery process to accomplish the task undo operations.

3. Putting it all Together We have applied the framework for workflow modeling presented in previous section as a foundation for developing a CASE tool for workflow modeling and verification, FlowMake. The layered approach of the proposed framework has been effectively applied in FlowMake. Rather than modeling all the workflow constraints on a single graph, a workflow is partitioned into several graph layers, where the same tasks are presented with different partition related properties and constraints. It is also important to note that although the workflow constraints could be partitioned into logical groups, inter-dependencies do exist between them. For example, the transactional specifications depend on the structural specifications. An important and challenging aspect of the workflow modeling methodology and associated CASE tool is to ensure the consistency and reliability of the integrated workflow conceptual model.

Figure 5. FlowMake: Workflow Modeling and Verification Tool

It is possible to easily get into error situations while building complex workflow specifications. The identification of these errors is obvious and trivial for workflows that consist of only a few objects. However, the verification of workflow conceptual specifications containing a large number of objects is known to be complex [8].

The extensive use of choice and concurrency structures in workflows and the overlapping data, execution, temporal, and transactional aspects further increase the complexity of some verification problems. This inherent difficulty of manually verifying the correctness of workflows makes a strong case for the development of an automated verification engine. Such an engine would become an essential component of a process definition tool for workflows. The early detection of errors in workflow specifications during the modeling stage is of vital importance and facilitates the development of reliable and correct workflow applications. The identification of a set of constraints for avoiding errors in workflow specifications is the first step towards developing a verification engine. Some of these constraints have been identified in [13]. The implemented tool based on the framework presented in this paper, called FlowMake, provides workflow analysts and designers a well-defined framework to model and reason about various aspects of workflows. It has been designed to augment production workflow products with enhanced modeling capabilities and to provide a basis for expanding the scope of the verification. It attempts to identify inconsistencies in the model that could arise due to conflicting use of modeling constructs. For example, it is possible that a particular instance of a syntactically correct workflow model stops executing before reaching and completing an acceptable final task because of a modeling inconsistency and thus terminating the workflow instance in an undesirable state. FlowMake provides means to identify such problems in workflow models. FlowMake is composed of four major components: the repository, the workflow editor, the verification engine, and the interface. Repository maintains workflow models and has been implemented using relational technology. Workflow Editor provides a user-friendly graphical environment to maintain large workflow graphs. It is also used to visualize inconsistencies in design. Verification Engine implements the algorithms to check the consistency of workflow models. Interface component provides linkage to workflow products through import and export of workflow models. Presently, the tool allows importing of process models from IBM workflow product MQ Workflow (previously known as FlowMark), analyzing them for structural conflicts, and exporting them back to the product. More information about FlowMake is available at http://www.dstc.edu.au/DDU/projects/FlowMake/.

4. Conclusion The contribution of the work presented in this paper is to identify a layered framework for capturing the requirements for a workflow based business information systems. We divide the workflow modeling effort into five partitions: structure, data, execution, temporal, and transactional. We introduced a graphical language for workflow modeling and discussed the issues in capturing and specifying the workflow constraints. The presented framework is applied as a foundation to develop a methodology and automated tool for the modeling and verification of workflows.

There are several workflow products available in the market. The framework presented in this paper is based on generic requirements of workflow applications and is not influenced by any of the products. However, the framework could be used to model and analyze workflow requirements before mapping to workflow products. The framework may also be used to evaluate the functionality supported in workflow products for each of the partition. We believe that the presented framework represents a logical, intuitive, and effective breakup of workflow constraints.

References 1. Aalst. WMP van der (1998). The Application of Petri Nets to Workflow Management. The Journal of Circuits, Systems and Computers 1998, 8(1):21–66 2. Alonso G., Agrawal D., El Abbadi A., Kamath M., Guenthoer R., Mohan C. Advanced Transaction Models in Workflow Contexts. In Proceedings of the 12th International Conference on Data Engineering, New Orleans, 1996 3. Butler Report. Workflow: Integrating the Enterprise. The Butler Group, 1996 4. Carlsen S. Conceptual Modeling and Composition of Flexible Workflow Models. PhD Thesis. Department of Computer Science and Information Science, Norwegian University of Science and Technology, Norway, 1997 5. Casati F., Ceri S., Pernici B., Pozzi G. Conceptual Modeling of Workflows. In: Papazoglou M.P. (ed) Proceedings of the 14th International Object-Oriented and EntityRelationship Modeling Conference, Springer-Verlag, pp 341–354 (Lecture Notes in Computer Science no. 1021) 6. Ellis C.A., Nutt G.J. Modelling and Enactment of Workflow Systems. In: M. Ajmone Marasan (ed) Application and Theory of Petri Nets, Springer-Verleg, Berlin, 1993, pp 1–16 (Lecture Notes in Computer Science no. 691) 7. Georgakopoulos D., Hornick M., Sheth A. An Overview of Workflow Management: From Process Modeling to Workflow Automation Infrastructure. Journal on Distributed and Parallel Databases 1995; 3(2):119–153 8. Hofstede A.H.M. ter, Orlowska M.E., Rajapakse J. Verification Problems in Conceptual Workflow Specifications. Data & Knowledge Engineering, January 1998; 24(3):239–256 9. Kuo D., Lawley M., Liu C., Orlowska M.E. A General Model for Nested Transactional Workflow. In: Proceedings of the International Workshop on Advanced Transaction Models and Architecture (ATMA'96), Bombay India, 1996, pp 18–35 10. Kamath M., Ramamritham M. Bridging the gap between Transaction Management and Workflow Management. Proceedings of the NSF Workshop on Workflow and Process Automation in Information Systems: State of the Art and Future Directions. Athens, Georgia, May 1996 11. Rajapakse J. On Conceptual Workflow Specification and Verification. MSc Thesis. Department of Computer Science, The University of Queensland, Australia, 1996 12. Reichert M., Dadam P. ADEPTflex – Supporting Dynamic Changes of Workflow without loosing control. Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow and Process Management, 1997 13. Sadiq W., Orlowska M.E. 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

14. Workflow Management Coalition. The Workflow Management Coalition Specifications – Terminology and Glossary. Issue 2.0, 1996, Document Number WFMC-TC-1011 15. Workflow Management Coalition. Interface 1: Process Definition Interchange, Process Model, 1998, Document Number WfMC TC-1016-P