24.3 Description The workflow implementation is based on the development of a logical model and a physical model that incorporate the characteristics of the business process, workflow enactment products, the computing infrastructure, and the workforce that will perform the tasks. The design of the models forms most of the activities in step 6. Once the models have been completed, the remainder of the step is concerned with programming the workflow engine and testing the configuration using the scenarios. 24.3.1 Task definition The first step in the development of the workflow models is the determination of the tasks that provide the fundamental unit of functionality for the workflow. The workflow is concerned only with the movement of information and control between tasks. It has knowledge of only the intertask environment and is not involved in the workings of the tasks themselves. For completeness, it should be noted that it is possible for the tasks also to utilize a workflow approach for their internal implementation and for the two workflow services (external and internal to the tasks) to communicate with each other. That complexity does not change the basic approach and is considered to be beyond the scope of this discussion. Because the workflow is not concerned with the internals of the tasks, initially each dialog can be considered to be a task. The issue then is to determine which tasks can be combined for the purpose of the workflow implementation. In making that determination, it is useful to note two differences between tasks and dialogs: § Tasks can have more than one entry point. The particular entry point is selected by the workflow instance information available at task start time. § Tasks can have more than one role performer. That means the transition between roles does not necessarily imply a timebreak and a given member of the workforce can perform multiple roles as required. Other characteristics generally are the same for both tasks and dialogs. If dialogs are to be combined into a larger task, there must be no need to track the transition from one dialog in the task to another. If such a need exists, the dialogs cannot be combined. An example of a task being defined from multiple dialogs is illustrated in Figure 24.1, which shows a portion of a dialog map. In that example, D2 is defined as a separate dialog from D1 because it has an input from other than D1. D3 is an independent dialog because it is in a role different from that of D1. D4 is an independent dialog because it already exists, having been defined during another process implementation. Figure 24.1: Task definition. It is possible to combine all four dialogs into one workflow task. That assumes that the given role conditions have been met: § No inherent timebreak exists between D1 and D2 (e.g., D1 is used to take a telephone order, and D2 is used to determine the credit status and associated discount of the customer). § The human user is capable of performing both roles. In addition, there must be no need for the workflow service to track the ending of D1 and the start of D2. If tasks consisting of multiple dialogs are to be used, there must be some mechanism for transferring information and control between dialogs independent of the workflow system. That is accomplished by defining and implementing an infrastructure service on the task computing platform that can communicate with the termination actions of the dialog instead of using those actions to communicate with the workflow service. If the platform service is designed properly and can be programmed with the identification of the dialogs the task comprises, none of the actions of a dialog has to change, regardless of whether or not it is communicating with the task platform service or the workflow service. For reuse considerations, if multiple dialogs are combined into a task, they should not be implemented as a single dialog. That may be tempting because it could eliminate the task platform service, but in the long run it is not an efficient practice. Once the tasks have been defined, a workflow map can be constructed. This map is essentially the same as the dialog map except for the following: § Instead of dialog interconnections, task interconnections are shown. § Instead of roles, appropriate workforce units are shown. These units still can be characterized as roles if desired, but because of the possible combination of process roles, these task roles must be considered to be a different type of entity. An example of a workflow map is shown in Figure 24.2. A workflow map is used in the development of the logical and physical models. Although similar in form to the process and dialog maps, the workflow map has some important differences. Figure 24.2: A workflow map. § The roles (organizational work groups) are not presented in bands but are provided by annotations to each task. That format is needed because multiple work groups may be used to perform a given task, such as is the case with T0. In addition, the physical location of each work group should be included and the same work group may be in multiple locations, such as Organization B, which performs T2. That organization and location information is necessary for the development of the logical model. § The emphasis is on the task transitions, not on the performers. Even though tasks T0, T6, T7, and T8 are all performed by work group C in Chicago, no attempt is made to show that by the position of the tasks in the map, as is the case for the process and dialog maps. § The task map also should contain the data elements and values used to determine the transitions between tasks when there is a choice. The transition from T1 is to T2 if element W has a value greater than or equal to 5, and it is to T5 if W has a value less than 5. That also holds true for the transition from T4 using element F. § The task map may contain artifact tasks that are not reflected in either the process maps or the dialog maps. For example, what occurs if element F has a value other than 0 or 1 when T4 completes? That is an obvious error condition and should be accommodated in the task map. For a value other than 0 or 1, the next task is an exception-handling one on a supervisor’s desk. That requires an update of the task map but should not require a change in the process or dialog maps, because the operating assumption is that the implementation is error free. § Other information should be made available in the task map as available. That would include such items as the task load (number of invocations per unit time) and the QoS agreements between organizations responsible for different tasks. The workflow map is used in the development of an example logical model in Section 24.3.4.3. 24.3.2 Task environment Figure 24.3 illustrates the position of a task in a workflow environment. The interfaces between the task (dialogs) and the role performer were discussed in Chapter 23, which dealt with the human interface, and in Chapter 21, which discussed action mapping. The other interfaces are specific to the workflow environment and need further explanation. Figure 24.3: Task workflow environment. In general, all information exchanged between the workflow service and the task goes through the workflow client. The client represents the workflow service on the platform where the task is resident. For improved clarity of discussion and to avoid an unduly complex figure, direct interfaces are shown for status information and instance data exchanges. Status information is exchanged between the task and the workflow engine that is responsible for tracking the state of each workflow instance. The information consists of at least the following: § The ID of the user assuming responsibility for the task; § Time responsibility is assumed; § Time of completion; § Completion status (normal or error). The workflow client selects an available workflow instance task from the task list either automatically according to some predetermined criteria or under guidance of the user as indicated by the client-user interface. In the latter case, the client must contain a human interface that facilitates the manual task selection. The software needed to execute the task is launched automatically by the client through the use of the facilities available from the platform infrastructure (e.g., operating system calls). The initiation is indicated by the client-task interface and is specified during the development of the physical model (described in Section 24.3.4.4). In many cases, the client must also be aware of the termination of the task. For example, it may need to add the task back to the user task list for later processing when additional information becomes known to the user (probably through a paper mechanism). This type of task termination (suspension) is quite common. It also might be necessary to assign the task to another performer if, for some reason, the original performer is unable to complete it. When a task is selected from the task list (tasks that are available to and addressable by the user), the instance data automatically become available for use during the execution of the selected task, again through action of the platform infrastructure. The task can utilize the information in any way that is needed. The task can store the information in persistent store and/or update the instance information from persistent store, changing names as needed. The updated instance data are then available to the remaining tasks. Defining this type of data mapping is also part of the development of the physical model. 24.3.3 Engineering guidelines The initial guidelines for the design and development of a workflow implementation are presented in this and the following sections. The specific recommendations are based on current practice and projections as to the probable evolution of the technology. Their real value, however, is an indication of the types of considerations and analysis that must be performed to realize an effective workflow implementation. § Use a single workflow system, if possible. § Do not assign more than 100 users to a workflow engine. § Do not assign more than 10 distinct processes to a workflow engine. § Avoid partitioning a process across workflow engines, if possible. § If the load requires more than one workflow engine, run the entire process in each engine and split the users between them. § Some code may have to be written to utilize product APIs for incorporating legacy systems, worklist management, and desired human interfaces. Do not be intimidated by this need. In many ways, it can be a strength, not a weakness. § Before beginning the workflow design, make sure the process to be implemented has been defined in sufficient detail, including activities, data, roles, organizations, and measurement metrics. If not, a return to step 1 and the process spiral is indicated. It may not always be possible to conform to all those guidelines in developing a specific design. If that is the case, careful attention must be paid to the testing of the workflow to ensure that it will operate as designed. 24.3.4 Design considerations There are five major considerations in the specification and implementation of a workflow service: load analysis, topology analysis, the logical model, the physical model, and the deployment procedure. Except for the deployment procedure, each aspect is examined in detail in the following sections, along with examples that illustrate the concepts. The deployment aspect is addressed in Chapter 26, which considers the deployment of the entire process implementation, including the workflow portion. 24.3.4.1 Load factors The purpose of the load analysis is to determine the major load factors for use in the logical model design step. Three load factors must be estimated for each complete workflow. If different portions of the workflow have significantly different values in any of the factors, they should be documented independently. The reason for this will become clearer during the topology analysis. Table 24.1 lists some examples of load rules. Table 24.1: Examples of Load Rules Load Factors Low Medium High Number of simultaneous workflow instances <50 50 to 100 >100 Number of tasks in the workflow <20 20 to 40 >40 Percentage of tasks needing human involvement <30% 30% to 70% >70% The load factors eventually help determine the number of individual workflow engines required and their interconnection topology. Some commercial workflow management systems have capacity planning tools that estimate the number of workflow engines based on the factors shown. 24.3.4.2 Topology analysis Activities of the workflow are partitioned according to geographical location or organizational unit. The sequencing of activities between them is also determined in this analysis. For purposes of this discussion, the following assumptions are made. § Different organizational units and geographical locations are relatively independent of one another for the purposes of workflow design and implementation. § Individual workflow activities are always performed in one organizational unit. Independence in this context implies that each organizational unit or location requires its own workflow engine because of administration and other needs that must be met on an individualized basis. If this need for independence is not necessary in a particular circumstance, the locations or organizational units should be combined for the purpose of the following analysis. Figure 24.4 illustrates three different types of topology constructs. The circles represent all tasks assigned to a location or business unit for a given workflow. The entire workflow map should be analyzed for each occurrence of those constructs. In most cases, the map is easily partitioned into a small set of the topological constructs. Figure 24.4: Types of topology constructs. If all the tasks for a workflow map can be assigned to a single location, organizational unit, or task role, the map is said to be a simple linear construct, as is the case for the first diagram in the figure. Other linear constructs can be formed from either a sequence or a parallel flow, as illustrated in the other diagrams of the linear flow section of Figure 24.4. If there is a feedback path somewhere in the workflow map, the construct is called a feedback flow. The flow constructs can be combined to define a workflow that is sometimes referred to as a combination flow. 24.3.4.3 Logical model The results of the load analysis and topological analysis can now be used to determine the configuration of the logical model. That is accomplished by first defining a series of simple configurations, as shown in Figures 24.5 through 24.8. Each configuration has an associated series of rules whose applicability can be obtained from the results of the two analysis steps given in Section 24.3.4.2. The rules determine under what circumstances that configuration is applicable. As necessitated by the workflow map, the simple configuration diagrams can be combined to form a more complex one. Figure 24.5: Single-engine configuration. Figure 24.6: Two or more load-sharing engines. Figure 24.7: Two or more chained engines. Figure 24.8: Hierarchical engine configuration. After those rules have been applied to a workflow map, the basic topological constructs of the workflow are obtained. The results of the topological analysis for the workflow map in Figure 24.2 are shown in Figure 24.9. The only concern of this analysis is the transition from organizational unit to organizational unit or from geographical location to geographical location. Note that each transition in the figure is to a different organization or location. Along with the load data, that provides the information needed to define the logical model. Figure 24.9: Topology analysis example. The logical model obtained from the workflow map in Figure 24.2 and the topological analysis shown in Figure 24.9 is presented in Figure 24.10. For the purpose of this figure, because only a small number of tasks are shown, it is assumed that the load can justify the number of individual engines indicated. The major design feature indicated by this design is the use of a workflow engine that serves as a manager of several other engines. That was indicated because of the complexity of the interactions, as shown in the topology analysis. Other designs also could have been utilized, depending on the exact load data, the capabilities of the products that will be used in the physical model, and the experience and knowledge of the designer. Figure 24.10: Example of a logical model. As indicated in Section 24.3.3, the simplest logical model configuration possible should be used. However, for large, complex processes with heavy utilization and participation by many organizational units, that is not always possible. The approach presented here is applicable whether a simple result or a complex one is needed. For simplicity, the load-sharing engines can be combined into a single box and labeled a workflow enactment service. That makes the diagrams easier to follow when a large number of instances are required. Thus, in all logical model diagrams, boxes can be labeled as workflow enactment services which consist of one or more load-sharing managers, depending on the number of simultaneous instances required. 24.3.4.4 Physical model The physical model is produced by programming the selected workflow engine with the process, dialog, and workforce information in accordance with the configuration of the logical model. Some of the information needed for the physical model, such as the names and locations of the dialog functionality, are not known until step 7, when all the parts of the development are assembled. During the initial invocation of step 6, unknown functionality can be “stubbed” until it has been specified in later steps. Subsequent invocations of this step receive most, if not all, of the functionality information. Because the physical model can be implemented in a test environment prior to actual deployment, it is not necessary at this time to integrate the workflow products with the production computing infrastructure. That will be accomplished during the deployment phase in step 8. However, the physical design should always be performed with the eventual deployment environment in mind. 24.4 Prototype The prototype in step 6 is the workflow prototype, which is the implementation of the workflow physical model into the selected workflow product set with the task functionality stubbed in an appropriate fashion. The purpose of the prototype is to animate the workflow using the scenarios to determine if the workflow definition meets the intent of the original business process. The operation of the prototype would be of interest to the business and technical stakeholders as an overall indication of how the business process implementation will operate. 24.5 Activities The 11 activities in step 6 are listed according to the sequence diagram in Figure 24.11. All the activities in this step are oriented toward the implementation of a workflow that will meet the intent of the original business process. This step will be revisited whenever it is determined in a succeeding step that some change needs to be made in some aspect of the workflow definitions. Figure 24.11: Activity sequence diagram. The following are brief descriptions of each of the individual activities needed to produce the results expected from this methodology step. All these activities must be considered whether step 6 is being invoked for the first time or as a result of a change in another step. If it is being revisited, many of the activities will be very simple and fast. They cannot, however, be skipped because there is always the chance that they will be needed to respond to the change. 1. Define tasks using the dialog map. Use the dialog map as a base to determine which, if any, dialogs can be combined into workflow tasks. If dialogs from different process roles are combined, new workflow roles have to be defined to accommodate the merged responsibilities. 2. Create a workflow map. After the tasks have been defined, a workflow map can be defined. The workflow map serves as the vehicle for defining the operational characteristics of the tasks and the workforce that will perform them. It is also used to program the workflow engine with the sequence information. 3. Perform a load analysis. Determine the amount of activity that each task must support. The load analysis is used to help determine the logical model of the workflow implementation. 4. Perform a topology analysis. Examine the workflow map for topological structures that will help determine the logical model of the workflow implementation. 5. Define a logical model. The logical model contains the structure of the workflow engines used in implementing the process. The logical model also indicates the tasks supported by each workflow engine, their geographical location, and the organizations supported. 6. Define task list processing for each workflow role. There are many ways that the next task to be addressed can be selected from those available for a given role. The most common way is to allow the role performer to select the task from a list displayed by the workflow client. Another possibility is to automatically select the next task using the task characteristics and predefined business rules that contain the selection criteria. Some workflow clients allow a great deal of flexibility in selection, while others require a significant amount of custom programming. 7. Develop a physical model. Program the selected workflow products using the logical model and the workflow map as the main inputs. If multiple workflow engines are required, they need to be connected using the same protocols that would be used in the deployed configuration. The same network configuration does not have to be used, however. As part of the engine programming, access to the required task and external functionality needs to be defined. The functionality does not need to be integrated if it is unavailable or if immediate access is cost prohibitive. However, a configuration as close to the one that will be deployed is desired. 8. Animate the workflow prototype using the scenarios. Once the physical model has been implemented, it becomes the workflow prototype. The scenarios are used to animate the prototype and ensure that the workflow reflects the intent of the original business process. This type of testing can also find problems with either the logical or the physical model so they can be corrected before the integration phase. 9. Demonstrate the workflow prototype to stakeholders. Arrange a facilitated session with the stakeholders to observe the operation of the initial or revised prototype and determine the conformity of the prototype operation to the needs of the business and the individual stakeholders. At the end of step 6, the stakeholders must determine if the workflow definitions, functionality, and relative sequences meet the needs of the business process being implemented. 10. Obtain necessary approvals. If approvals are needed to continue beyond step 6, they need to be obtained before proceeding. The workflow prototype, the opinions of the stakeholders, and the hard deliverables from this step (task specifications, workflow map, logical model, physical model) should be sufficient to demonstrate the suitability of the action definitions and the ability to proceed. 11. Enter new or updated workflow specifications into repository. All information obtained as a result of step 6 should be entered into a repository where it is available for future needs. Because maintenance is considered an integral part of the methodology, this information may be needed for a considerable length of time and may be useful to individuals other than those involved in the initial development. 24.6 Linkages to other steps Step 6 must be invoked whenever there is a needed change to any aspect of the workflow specification. Changes could result from the activities in any step of any spiral and consequently cause a direct transition to step 6 or to other steps that may be affected (e.g., step 1) before this step is reentered. The exact transition sequence depends on the circumstances. If the changes are relatively small, the time required for a reinvocation of this step or previous ones should be relatively quick. The usual transition to step 6 is directly from step 2, where the dialogs are identified and specified. The initial specification or changes to the specification of the dialogs always require an analysis of the workflow definition. The definition of the actions also can have a significant effect on the design of the workflow. Therefore, step 6 should be reinvoked after step 3 has completed, to consider any possible effect on workflow definition. Changes in actions concerned with error recovery, for example, could affect the design of the workflow even if the definitions of the process dialogs remain unchanged. If the results of step 6 do not require the business processes or dialog definitions to be reexamined, the normal transition from this step is to step 7, where all the individual parts of the development are integrated and assembled into a working implementation. If step 6 raises questions concerning the process map or dialog definitions, then a transition to step 1 must be made and the process spiral reiterated until those questions are resolved. 24.7 Postconditions Step 6 is completed and may be terminated for a given development when the following information and conditions are present as a result of the current step invocation: § All step activities have been considered at least once. § The logical and physical models (prototype) of the workflow have been implemented and are available for demonstration. § Appropriate animation of the workflow prototype using the scenarios has been performed and the results verified. § The business and technical stakeholders have been involved as needed. § All relevant workflow information has been entered into the appropriate repository and updates verified. § All necessary approvals have been obtained. At the normal conclusion of step 6, all affected business and technical stakeholders must agree that the workflow, as it is currently defined and represented, is the best that can be accomplished prior to actual use. As necessary, changes may be made after the implementation and improvement spirals have been invoked as additional information is obtained. Selected bibliography Basu, A., “Metagraph Transformations and Workflow Analysis,” Proc. 30th Hawaii Internatl. Conf. System Sciences, Wailea, HI, Jan. 7–10, 1997, Vol. 4, pp. 359–366. Gokkoca, E., et al., “Design and Implementation of a Distributed Workflow Enactment Service,” Proc. 2nd IFCIS International Conference on Cooperative Information Systems, Kiawah Island, SC, June 24–27, 1997, pp. 89–98. Karnath, M., and K. Ramamritham, “Failure Handling and Coordinated Execution of Concurrent Workflows,” Proc. 14th Internatl. Conf. Data Engineering, Orlando, FL, Feb. 23– 27, 1998, pp. 334–341. Kwan, M. M., “Dynamic Workflow Management: A Framework for Modeling Workflows,” Proc. 30th Hawaii Internatl. Conf. System Sciences, Wailea, HI, Jan. 7–10, 1997, Vol. 4, pp. 367– 376. Orwig, R., D. Dean, and L. Mikulich, “A Method for Evaluating Information Systems from Workflow Models: Results from a Case Study,” Proc. 31st Hawaii Internatl. Conf. System Sciences, Wailea, HI, Jan. 6–9, 1998, Vol. 4, pp. 322–331. Schuster, H., S. Jablonski, and C. Bussler, “Client/Server Qualities: A Basis for Reliable Distributed Workflow Management Systems,” Proc. 17th Internatl. Conf. Distributed Computing Systems, Baltimore, May 27–30, 1997, pp. 186–193. Van Der Aalst, M. P., “Modeling and Analyzing Interorganizational Workflows,” Proc. 1998 Internatl. Conf. Application of Concurrency to System Design, Fukushima, Japan, Mar. 23–26, 1998, pp. 262–272. Chapter 25: Step 7: Assemble and test [...]... life cycle of the process That enables the same approach to the maintenance of the process as was used in its initial development By combining the development and maintenance aspects, the inevitable changes to the process are facilitated Changes to the process use the same activities and approach as the initial development Step 8 also contains the activities necessary to deploy the process to achieve... make it conform better to changing business conditions 26.7 Postconditions Step 8 is completed and may be terminated for a given development when the following information and conditions are present as a result of the current step invocation: § The process implementation has been deployed and has obtained operational status § All step activities have been considered at least once § A need for a process. .. activity must be involved § Demonstration to the stakeholders that the resultant implementation operates in a manner that conforms to the intent of the defined business process (original or as currently exists) This demonstration usually concludes with the acceptance test that is a formal mechanism for obtaining the necessary approvals § Determination of the method for involving the users with the new process. .. of the process implementation At the conclusion of the first phase, the process implementation is used in the day-to-day operations of the enterprise Figure 26.2: Activity sequence diagram The second phase deals with the identification of needed changes to the implemented process Until a change is needed, step 8 does not exit When the need for a change does occur, the step is exited and transition... well-constructed implementation The training should indicate why the implementation works as it does in addition to presenting the usual how-to information Comments from the users should be noted and considered as a basis for changing the process during the first operations analysis activity At this point in the development, it probably is unwise to change the implementation The instability introduced... specification Test the implementation using the scenarios Animate the test environment process implementation using the scenarios Verify that the implementation conforms to the intent of the original (or as modified during development) process description If this agreement is not adequate, then either the process description or the implementation must be altered in some way to achieve conformity Depending on... 10: Role modeling Figure Figure Figure Figure Figure Figure 10. 1: 10. 2: 10. 3: 10. 4: 10. 5: 10. 6: Structure of role relationships An enterprise organization chart An organization-oriented role class structure Enterprise process definitions A process- oriented role class structure Addition of general roles to the class hierarchy Chapter 11: Information modeling Figure 11.1: An example of an E-R diagram... which consists of the means for activating its set of actions, to the cluster store and control forming the dialog execution environment They also must be linked to the human interface implementation through the client platform environment functionality If an automated dialog is involved, it can be implemented on a server platform instead of a client platform In that case, except for the human interface,... the process needs as they evolve over time Management by process will have effectively broken down! By maintaining the integrity of all the process representations, the business and technical views of the process will be compatible and the effect of changes can be seen and understood by all concerned That is the fundamental need for an enterprise that is managing by process It is well worth the additional... Provides an effective implementation of the original business process; § Can be managed so it continues to meet the needs of the business as changes are encountered; § Has a form that can be efficiently deployed into the enterprise computing environment An effective assembly procedure should resemble the construction of a jigsaw puzzle All the pieces should have a form that fits with the form of the connecting . selected workflow engine with the process, dialog, and workforce information in accordance with the configuration of the logical model. Some of the information needed for the physical model,. vehicle for defining the operational characteristics of the tasks and the workforce that will perform them. It is also used to program the workflow engine with the sequence information. 3. Perform. produces an implemented process. 25.2 Preconditions The following items are required to be available before work on the activities in step 7 can be initiated. It is assumed that any result