Business Process Implementation for IT Professionals phần 7 pps

Glass, R. L., “Reuse: What’s Wrong With This Picture,” IEEE Software, Vol. 15,No. 2, 1998, pp. 57–59. Gustavsson, A., “Software Component Management and Reuse Component Repositories,” Proc. 4th Internatl. Workshop Software Configuration Management, Baltimore, May 1993, pp. 123–126 Heinninger, S., K. Lappala, and A. Raghavendran, “An Organizational Learning Approach to Domain Analysis,” Proc. 17th Internatl. Conf. Software Engineering, Seattle, Apr. 23–30, 1995, pp. 95–104. Jacobson, I., G. Martin, and P. Jonsson, Software Reuse: Architecture, Process and Organization for Business Success, Reading, MA: Addison-Wesley, 1997. Kotula, J., “Using Patterns to Create Component Documentation,” IEEE Software, Vol. 15, No. 2, 1998, pp. 84–92. McClure, C., Software Reuse Techniques: Adding Reuse to the System Development Process, Englewood Cliffs, NJ: Prentice-Hall, 1997. Rada, R., and J. Moore, “Sharing Standards: Standardizing Reuse,” Communications of the ACM, Vol. 40, No. 3, 1997, pp. 19–23. Radding, D., “Benefits of Reuse” Information Week, Mar. 31, 1997, pp. 1A–6A. Rosenbaum, S., and B. du Castel, “Managing Software Reuse—An Experience Report,” Proc. 17th Internatl. Conf. Software Engineering, Seattle, Apr. 23–30, 1995, pp. 105–111. Sen, A., “The Role of Opportunism in the Software Design Reuse Process,” IEEE Trans. Software Engineering, Vol. 23, Issue 7, 1997, pp. 418–436. Voas, J. M., “Certifying Off-the-Shelf Software Components,” Computer, Vol. 31, No. 6, 1998, pp. 53–59. Chapter 15: Workflow modeling Workflows are the last automation assets that need to be examined as background for the specification of a process implementation methodology. Essentially, a workflow is another representation of a business process. The workflow representation or model is different from the business process models discussed in Chapter 5 because workflows must incorporate the technical and workforce information needed for implementation and deployment. To differentiate the different process representations, the original representation is referred to here as the business process, while the workflow representation is called a workflow. 15.1 Evolution Although workflow-like techniques have been in use for many years, the designation of workflow as a distinct technology is relatively recent. As such, it is useful to (1) investigate how and why the technology started; (2) develop an understanding of the current state of the art (including the availability of products that incorporate the technology); and (3) determine the specification of any standards that have general industry acceptance. 15.1.1 Genesis Workflow technology had its start in the image processing and document management technologies. Many business procedures involve interaction with paper-based information, which can be captured as image data and used as part of an automation process. Once paper-based information has been captured electronically as image data, it often is required to be passed between a number of different participants, thereby creating a requirement for workflow functionality. The emphasis on business process reengineering (BPR) in the early 1990s provided a need for utilization of the general workflow techniques and contributed to their development as a separate technology. Because the initial emphasis of BPR was on process definition and not implementation, the pace of development for workflow technology has been relatively slow. That situation is beginning to change as the emphasis shifts from process development to process implementation. Defining a process is not very useful unless some means exists to monitor and track the operation of the process and determine how well it is working. That is true for mostly manual processes as well as highly automated ones. Although manual monitoring and tracking can be utilized, they are not very efficient and the tendency is always to eliminate that function when time gets short. Utilizing the automated means for monitoring and tracking that workflow provides can greatly assist in evolving to an efficient and effective process. 15.1.2 Standards The Workflow Management Coalition (WfMC) was formed in 1993 by a number of vendors who produced products addressing various aspects of workflow technology. The purpose was to promote interoperability among heterogeneous workflow management systems. A workflow management system consists of workflow products configured in a manner that enables implementation of one or more specified business processes. Currently, the WfMC remains the only standards body involved with workflow products and services. It currently produces standards that address the following areas: § Application program interfaces (APIs) for consistent access to workflow management system services and functions; § Specifications for formats and protocols between workflow management systems themselves and between workflow management systems and applications; § Workflow definition interchange specifications to allow the interchange of workflow specification among multiple workflow management systems. The standards activities are still in an early stage, with only a small portion of the needed standards addressed in a manner that can provide needed guidance to product vendors and workflow implementers. Nevertheless, the existence of a standards body is an important indication of the viability and strength of the technology. Because the WfMC standards generally are concerned with the partitioning of workflow functionality and the interfaces between different functions, further discussion of that aspect of the standards is deferred until Section 15.5 when configuration models are discussed. 15.2 Model views To facilitate the discussion and present the diversity of information required to understand the use of workflow technology in the implementation of business processes, this chapter utilizes several different models. Each model is oriented toward a specific aspect of workflow design and operation. The following basic models are considered: § The dynamic model illustrates the basic operation of a workflow in performing a business process. § The design model represents a business process suitable for implementation and deployment. The parts of the design model are the workflow map, data access, and control. § The configuration model defines the interaction of the different components of a workflow management system. Each component eventually is realized by one or more products. The parts of the configuration model are the reference model, the logical model, and the physical model. Although the three models are discussed separately to avoid unnecessary complexity, they are closely related and the definitions of all the models must be compatible for the resultant implementation to function properly. The interrelationships are not discussed explicitly because of the complexity involved. However, it should be evident from the discussion how the models interact. As will be seen, some of the models use concepts and models from previous chapters as an integral part of their definition. That also illustrates the close relationships among all the models that have been presented. 15.3 Dynamic model The basic dynamics of a workflow implementation are shown in Figure 15.1. The four major components of this model are: Figure 15.1: Workflow dynamics. § A workflow instance that contains the data relevant to a given invocation of the workflow; § Tasks, each of which performs some specific aspect of process functionality; § Business rules that determine when and where the next task is performed; § A monitor that determines if the workflow is progressing according to the specified parameters. When a business event occurs, a workflow instance is created. The purpose of the instance is to contain the status and instance-specific data that will be associated with the handling of the business event. Initially, the workflow instance contains very little information. As the solution to the business event progresses, additional information is added. A workflow instance exists until the final response to the defining business event is provided. At that time, the characterization of the workflow is complete and can be used for statistical purposes in the management of the process. The workflow instance is known by a number of different names, including folder, container, courier, and token. In addition, the implementations may vary considerably, ranging from a single structure to a complex set of structures. To avoid confusion, the generic term of workflow instance is used throughout this discussion. During a review of the characteristics of different products, it is necessary to understand that a diversity in naming conventions and implementation methods exists. The information in the workflow instance is examined by the business rules defined for the workflow. Depending on the instructions contained in the rules and the data elements and values contained in the workflow instance, a specific task is scheduled and routed to a role performer assigned to that task. After the task is performed, the workflow instance information is updated and the procedure continues until the business event is satisfied. When a workflow instance requests a specific task to perform a function, an instance of that task is formed that is then associated with the workflow instance. In that way, all the work necessary to respond to a given business event can be connected with that particular business event, even if the same task is needed for many different workflows or multiple instances of the same workflow. The operation of the workflow is continuously monitored to ensure that it is performing satisfactorily. If a problem is encountered, the instance data are updated appropriately. For example, if the monitor discovers that an assigned task has not been completed within the time period indicated by the business rules, the instance information is updated to reflect that fact. When the business rules are next used to examine the instance information, they then may cause a task to be executed that notifies a supervisor of the problem. If allowed by the business rules, it is possible to have multiple tasks simultaneously executing in the same workflow. As part of its function, the monitor also collects statistics on the defined metrics of all the instances of the given workflow process, including the associated task instances. Those statistics are used to determine how effectively the process implementation (workflow) is functioning and what, if any, changes should be considered. That statistical function operates across all instances of the workflow, as contrasted with the monitoring function, which operates within a single instance. The dynamics of the workflow are incorporated in a workflow engine that is part of the overall workflow management system. The engine provides the means for creating the workflow instance, interpreting the business rules, executing the tasks, and monitoring the overall operation of the workflow. Because of the differences in commercial products, the specifics of individual workflow engines are not discussed here. Instead, the discussion of workflow engines emphasizes the modeling efforts needed to utilize any workflow engine. 15.4 Design model The workflow design model is an operational representation of the business process being implemented. It consists of three parts. The workflow map shows the relative sequences of the tasks that will be utilized by the workflow. Other information is considered as part of the map and must be keyed to the diagram, including: § The rules that determine which tasks will be selected for execution; § The transactions called by each task and the location of the functionality needed by each transaction; § The workforce units that will perform the roles used to perform the tasks. The characteristics of the workforce units are not considered part of the map information. The data access model part of the design model indicates what data are contained in the workflow instance and what data are contained in databases external to the workflow system. Both types of data are accessible by the tasks. Finally, the control model determines how the workflow progresses. 15.4.1 Workflow map As a part of the workflow process model, a workflow map is produced. An example of such a map is shown in Figure 15.2. Although the business process map and the resultant workflow map may look similar, there are important differences. The workflow map is the result of the design phase and is not an exact duplicate of the business process map. To help impress that point, the terminology employed is different. Instead of a sequence of process steps, a sequence of tasks is utilized. Figure 15.2: Workflow map structure. As defined in Chapter 13, a task usually consists of one or more dialogs assigned to the same role. A task can be implemented via a custom development, a purchased product, a legacy system, or a combination of those methods. Instead of the information flows used in the business process representation, the need to interact with databases and processing functionality is indicated by the use of transactions. The location of the functionality accessed by each transaction also must be indicated. Without that information, the workflow cannot be implemented. Transactions result from the specification of the actions for each of the dialogs in a task. 15.4.2 Data access model The data access model defines how data are stored and accessed. It is illustrated in Figure 15.3 and shows how tasks can utilize data from either the workflow instance or databases external to the workflow management system. As will be discussed, not all the data in a workflow instance can be accessed by the tasks. Some data are available only to the workflow control mechanism. In general, that is not a problem because the tasks performing process functionality do not usually require data of that type. Figure 15.3: Data access structure. As shown in Figure 15.3, a task can obtain data from either the workflow instance or an external database. Data also can be transferred between tasks using either construct. In general, it is better to keep the information in a workflow instance relatively small. That avoids the need for routing the same information to a number of potential role performers. Depending on the number of potential role performers, a large amount of data in a workflow instance can require considerable network and processing resources. The use of pointers in the workflow instance to locate required data in an external database usually is the best method of transferring large amounts of data between tasks. The first task stores the data on a database outside the workflow management system but stores key pointers to those data in the workflow instance. The second task uses the key pointers passed to it in the workflow instance to retrieve the application data it needs from the external application database. As will be shown, any data needed by the workflow management system business rules to make decisions must be placed in the workflow instance. If desired, task functionality can be defined that transfers data between external databases and the workflow instance. To help in the determination as to where to place needed data, the classification of workflow instance data is presented along with a brief explanation of the data involved. 15.4.2.1 Internal control data The internal control data identify the state of individual workflow processes or task instances and may support other internal status information. The data may not be accessible to the tasks, but some of the information content may be provided in response to specific commands (e.g., query process status, give performance metrics). Multiple workflow engines used to implement a given process also can exchange this type of information between them. 15.4.2.2 Workflow-relevant data Workflow-relevant data are used by a workflow management system to determine particular transition conditions and may affect the choice of the next task to be executed. Such data potentially are accessible to workflow tasks for operations on the data and thus may need to be transferred between tasks. Multiple workflow engines used to implement a given process may also exchange this type of information between them. The transfer may (potentially) require name mapping or data conversion. 15.4.2.3 Workflow application data Workflow application data are not used by the workflow management system and are relevant only to the tasks executed during the workflow. They may convey data utilized in task processing, instructions to the task as to how to proceed, or instance priority. As with workflow-relevant data, they may need to be transferred (or transformed) between workflow engines in a multiple-engine environment. 15.4.3 Control model The workflow control model consists of the business rules responsible for determining the sequencing, scheduling, routing, queuing, and monitoring of the tasks in the workflow process. Each area is briefly described, and examples of rules for the continuing example are provided at the end of this section. 15.4.3.1 Sequencing Sequencing is the determination of the next task or tasks that must be performed to respond to the business event. Multiple tasks can be scheduled concurrently if determined by the appropriate rules. Although much of the sequencing information is shown on the workflow map, additional information may be needed to determine when the conditions for task execution have been met. For example, assume two tasks are executing in parallel and the map shows that both tasks require a common task as the next in sequence. The rules must determine if execution of the common task must wait until both parallel tasks are completed or if it can be started when one or the other predecessor task completes. Such rules can get somewhat complex for large maps. One of the more interesting differences between the business process map and the associated workflow process map is the amount of parallelism that can be obtained. The business process map is very sequential, while the workflow map can have many tasks that are able to execute in parallel. Whether it is desirable to take advantage of that situation is up to the workflow designer and depends on a number of factors, including the size and sophistication of the workforce. 15.4.3.2 Scheduling Scheduling is the determination as to when the next task in the sequence should be executed. That can vary from immediately to weeks or even months in the future. The schedule can be static or dynamically determined from the workflow instance data or an external event calendar. Although most of the time, subsequent tasks can be executed immediately, there are a number of situations in which the execution must wait until a predetermined time. Such situations would include the availability of equipment or other resources, a time negotiated between the service provider and the customer, and the desirability of performing certain tasks, such as switching electric lines when electric usage is light (e.g., at 2 A.M.). 15.4.3.3 Routing Once a task has been selected and scheduled, the next need is to determine the work stations or the task performers that are to be used to process the task for a given business event (workflow instance). There are many methods that can be used to determine the routing, and the routing business rules specify which ones are to be used in a specific situation. When the task is routed to more than one individual, the first individual to select that task is assigned the task and it is unavailable to any others in the identified group. The most popular routing methods are as follows: § Route to the same individual who performed the previous task in the given workflow instance; § Route to a specific named individual; § Route to a list of named individuals; § Route to any individual in a given geographical location; § Route to any individual who can perform the specified role; § Route to an individual who can perform the specified role and who has the shortest queue or who is next in line for a new task (round- robin); § Any combination of those. Although most products allow an individual who is assigned a task to reroute it to another permissible performer, the workflow designer may restrict that ability to prevent misuse. 15.4.3.4 Queuing The queue of tasks available to a given individual can have several characteristics, depending on the capabilities of the products utilized and the rules established by the workflow designer. Queues may be defined to be first in/first out (FIFO) or last in/first out (LIFO) for all tasks arranged by priority in one of those categories. In this type of queue, the task performer would not be able to select the next task. The task would be presented automatically when the performer is available using the defined rules. This type of queue is known as a push queue, because it pushes work to the performer. In another case, the queue might be able to be viewed by a prospective performer, who could select any task deemed appropriate. For knowledge workers, this is probably the most used method. This type of queue is a pull queue, because the performer pulls work from the queue as needed. Any form of queue could be used with an automated task performer, although the push queue probably is utilized most often, because it eliminates the need for the task logic to determine which task is to be selected. 15.4.3.5 Calendaring Calendaring is the definition of events based on calendar units (days, weeks, months, years). Examples of calendar events are employee work schedules, server availability, due dates, deadlines, holidays, and special sale periods. Sequencing, scheduling, and routing operations are able to use calendar events in making the necessary decisions. A monitor function, discussed in Section 15.4.3.6, also can utilize those events to determine if problems exist with the operation of the workflow instance. 15.4.3.6 Monitoring Using the specified rules, the monitoring function examines the values of the metrics defined for the workflow. Depending on the conditions established in the rules, tasks that indicate that some condition has occurred may be initiated or a database may be updated with appropriate information that can be utilized later for reports or queries. Metrics Some common metrics are as follows: § Total time expended for the instance to present; § Elapsed real time total for the instance; § Elapsed real time in each task in the instance; § Elapsed real time in each queue; § Elapsed active time in each task; § Elapsed active time in each queue; § Task throughput per unit time; § Resource utilization per unit time; § Queue length for each work station; § Number of each priority item in each queue. Active time is time that counts against the workflow instance. For example, some workflows do not count traveling time assessed against the workflow instance. This type of metric is important when contractual obligations (service-level agreements) differentiate between real and assessed time. Alerts and alarms Based on the values of the metrics and the threshold defined for them, alerts and alarms determine if an alert task (no action required), an alarm task (action required), or a recovery task should be scheduled and routed to locations specified by the routing rules. Statistical information Statistics are developed for each metric, including those for each instance, all workflows of a given type, all tasks, and all task performers. Queries and reports Queries and reports request and receive information related to any of the measured values given previously for an individual workflow instance, including: § Total time expended to present; § Time until defined calendar or schedule event; § Total cost expended to present; § Any of the available statistics. The time period over which the information is needed must be specified. 15.5 Configuration model The configuration of a workflow management system refers to the way in which the components of the system are defined and interconnected. The three parts of this model are: § The reference model, which defines the system components and their interfaces; § The logical model, which indicates how the components will be utilized to accommodate a given workflow specification; § The physical model, which indicates how the components given by the logical model will be implemented using selected products in the environment in which they must function. The structure of each model is defined in later sections. Additional information as to how the models are developed in response to a given workflow process specification is provided in Chapter 24, which deals with the workflow aspects of the process implementation methodology. 15.5.1 Reference model As a part of its standards activities, the WfMC has developed a workflow reference model that defines the elements of a workflow management system and the interfaces between them. Figure 15.4 is a pictorial description of the WfMC workflow reference model, which consists of five components: § Process definition; § Workflow enactment service; § Administration and monitoring; § Workflow client applications; § Invoked applications. Figure 15.4: Workflow reference model. (Source: WfMC.) 15.5.1.1 Process definition The process definition component of the workflow reference model allows workflow definition information (as defined by the process models) to be entered into the workflow system and some amount of testing of the resultant workflow definition to be performed. Simulation and other test procedures also are defined as a part of this component. The process definition tool translates the process model information into a standard format for input to the workflow enactment service. 15.5.1.2 Workflow enactment service The workflow enactment service provides the run-time environment in which one or more workflow processes are executed. It consists of one or more workflow engines that cooperate in the implementation of a given process. The model assumes that the engines of an enactment service are all from the same vendor and are allowed to communicate using proprietary protocols. If engines (and hence enactment services) from multiple vendors are used to implement a process, the reference model requires them to communicate via a standard protocol. The characteristics of a workflow engine are described in Section 15.5.3. The enactment service is distinct from the application and end-user tools used to process items of work. As such, it must provide interfaces to those components to provide a complete workflow management system. As can be seen from Figure 15.4, the workflow enactment service is the main component of the model. All the defined interfaces are between it and the other components. There are no direct interfaces between components of the model other than the ones shown. 15.5.1.3 Administration and monitoring The administration and monitoring component contains the logic for administering and monitoring the status and operation of the workflow. Queries and online status information (dashboard display) would be a part of this component. Process and workforce changes would not be functions of this component but would be contained in the process modeling component. 15.5.1.4 Workflow client application The workflow client application is the component that presents end users with their assigned tasks according to the business rules (push, pull, and other custom rules). It may automatically invoke functions that present the tasks to the user along with related data. It allows the user to take appropriate actions before passing the case back to the workflow enactment service and indicating its current state (e.g., completed, error condition, reassigned to another performer). The workflow client application may be supplied as part of a workflow management system, or it may be a custom product written specially for a given application. 15.5.1.5 Invoked applications There is a requirement for workflow systems to deal with a range of invoked applications. In may be necessary, for example, to invoke an e-mail or other communications service, image and document management services, scheduler, calendar, or process-specific legacy applications. Those applications would be executed directly by the workflow engine without having to utilize a workflow client. 15.5.2 Logical model There are many ways that a business process can be implemented and deployed using workflow techniques and products. The purpose of the logical model is to depict the specific components that are used to implement the process of interest. The issues and procedures involved in producing a design for a specific logical model are not considered in this section, only the need for the model and its structure. To develop a suitable workflow design for a given business process, it is necessary to understand and incorporate the characteristics of the process as well as the capabilities and characteristics of the workflow management system products being utilized. If, for example, there is a need to utilize multiple workflow engines, any product considered for the function must be able to provide that ability. Figure 15.5 illustrates the example of using a help-desk process. One enactment service consists of four cooperating workflow engines (all assumed to be from the same vendor so multiple enactment services are not needed). The engines are used to support the user roles as follows: § One engine is assigned to the east help desk; § One engine is assigned to the west help desk; § One engine is assigned to the clerks regardless of location; § One engine is assigned to all of the other users (service technicians, marketing representatives, and experts). [...]... useful in developing the process map as well as for testing the process prototype, the prototypes of the other spirals, and the final implementation before it is turned over to the users The initial requirements are considered to be suitable when the SMEs agree on the process map and its associated information, including the scenario definitions In addition to determining an initial set of requirements,... different forms and structures Although a process implementation architecture can be specified separately from the implementation methodology and vary with different functionality, that approach is inefficient and may not allow the implementation methodology to meet the specified requirements For those reasons, only one process implementation architecture is utilized in the automation environment It is... (months, years), the inability to perform an included activity, and the inability to obtain a role performer (automated or human) with the necessary characteristics 17. 1.2 Prototype The prototype (called the process prototype, after the spiral name) defined for this spiral is simply the process map along with the associated scenarios It is designed to allow the user to obtain a feel for the operational characteristics... done, it is difficult, if not impossible, to determine the suitability of the product for the process implementation It may be that only parts of the product should be used or that the products should not be used at all because they do not adequately provide for process needs Specification of the actions is the only way to determine the suitability of existing functionality, and the time to perform... is suited for the type of devel- opment needed to provide enterprise automation in the current environment Spiral methodology The spiral methodology is a type of build-and-test methodology in that it formalizes that approach by defining a standard set of activities that are performed in a repetitive fashion to construct both the initial and additional functionality The use of those standard activities... Coalition, Workflow Handbook 19 97, ed by P Lawrence, New York: John Wiley & Sons, 19 97 Part III: Automation methodology With the conclusion of Parts I and II of this book, the fundamental concepts and models needed to permit the specification of a comprehensive methodology for the implementation of business processes are now in place Part III develops and details the specification of a process implementation. .. 16.1.2 Process implementation architecture The process implementation architecture is the aggregation of several of the concepts and models presented in previous chapters It is illustrated in schematic form in Figure 16.2 The architecture is based on a C/S structure with four explicit types of servers: automation control, workflow, infrastructure, and business functionality/data There is also a client... advantages § A large number of individuals are experienced in its use § Organizations have used this methodology for a long time and are comfortable with it § It lends itself to very large projects The disadvantages are: § § § § The customer does not see the implementation until it is finished, which can be a significant number of years for a large project It is assumed that all the requirements can be determined... mixed with software developed in a more traditional fashion That is required when legacy systems and COTS products are combined in a given process implementation The ability to combine the different software architectures is one of the strengths of PRIME Those requirements, along with the selected spiral approach, form the basis of the PRIME design 16.2.2 Methodology design PRIME is a nontraditional, process- driven,... accomplished by using the explicit transitions between spirals That makes it easy to determine what must be done for a given change and in what order the activities need to be performed The real value of the spiral approach is in that explicit mechanism for keeping track of the progress of the development and in determining how changes will be accommodated 17. 1 Spiral 1: Process (requirements) The purpose . illustrates the basic operation of a workflow in performing a business process. § The design model represents a business process suitable for implementation and deployment. The parts of the design. with the deployed process. The output is the implemented and deployed business process the users employ in performing their work. The deployed processes consist of the business functionality. location of the functionality needed by each transaction; § The workforce units that will perform the roles used to perform the tasks. The characteristics of the workforce units are not considered