Agent-Based Workflow

Smoots Agent Based Workflow Powersoft International User Meeting and Training Conference 1995

This DRAFT document is distributed to attendees of PowerSoft Workflow presentation only June 6, 1995

Smoots: Agent Based Workflow Page 2

SMOOTS: A NEW MEASURE FOR WORKFLOW 3

Introduction 3

What is Workflow? 3

Why implement a Workflow Management System? 4

What is a Workflow Management System? 6

Challenges of a Workflow System 7

Smoots Architecture 8

Enterprise Service Bus 8 Data Management 10 End User Tools 12 User Application Integration 16 Development/Deployment Support 16 Administration 17

Summary 18

References 19

Workflow Glossary 20

Appendix A 22

Demo Scenario - New Hire Workflow 22

June 6, 1995


Smoots: A New Measure for Workflow — SOFTWARE MANAGEMENT OF OBJECT TRANSFER SERVICES

Introduction This paper describes the Smoots (code name) Workflow project currently under development at the PowerSoft West Engineering Center.

This document is written to:

• Introduce the project to potential key customers in order to recruit design partners

• Solicit feedback from partners interested in workflow systems

• Accompany the preliminary demo system prepared by the project team

This document provides the overview of the project and discusses some of the preliminary design and architectural issues.

For the workflow concepts and terms used throughout this paper, please refer to the attached glossary.

What is Workflow? A workflow is a collection of tasks that has to be performed following a predefined or ad-hoc process to accomplish a certain business function. Almost any task one may perform in a job can be associated with a workflow if it requires more than one person to complete the work.

In a typical business organization, there are very complex workflows requiring collaboration of several cross functional areas. Many subworkflows may need to be completed in a certain order for the work to be completed. Sales order processing, inventory control, insurance claims processing, and customer service call processing are examples of commonly understood workflows.

June 6, 1995


Why implement a Workflow Management System?

Evolution in Information Technology

Originally applications were written as large monolithic blocks that were responsible for all aspects of the processing that the application was to perform. The programmer was responsible for every detail all at once and lots of different functionality was mixed together in modules in the application.

Early on in computing history it was found that the application functionality related to data access was an important component of each application, was very detailed and tricky to implement efficiently, and was very similar from application to application: Each application needed a different and specific description of the data it was accessing but all applications accessed and managed data basically in the same ways. Thus, data access and management was removed from applications into common components or systems, and data base management systems were born. Now applications using data base management systems can get basic functionality very easily—perhaps even declaratively, without programming—and yet with modest effort take advantage of the now extremely powerful capabilities present in DBMSs. Organizations using applications built using DBMS systems find it possible to update their applications as their business needs change more easily than before because the data bases now contain the capability to centralize definition and enforcement of business rules related to data content and access which previously were spread throughout the millions of lines of custom application code.

DataAccess

UserInterface

MonolithicApplication

DataAccess

UserInterface

ProcessApp

Algorithms

RDBMS

RDBMS

GUI (MSWindows, X)

GUI (MSWindows, X)

WorkflowAutomation

Data Access +Process + UserInterface + App

Algorithms

ApplicationProcess + Application

Algorithms

June 6, 1995


Later, in the 80’s, as computer power increased and desktop computing became widespread, the same separation of common functionality occurred for the user interface component of applications, and now it is normal to let a GUI handle very complex user presentation and interaction mechanisms instead of programming it all into each and every application. Separating the UI from the application also led to a new style of building an application where the application is driven by a user’s needs rather than controlling a user’s actions, and that has led to productivity gains in the organization as applications have become easier to use at the same time as becoming more powerful.

Emerging workflow systems allow business process management to be separated from the application providing the same level of benefits as the move to data base management systems and GUIs has done:

• Centralized definition and control of business rules related to business processes—leading to higher accuracy and less cost to track changes in the business

• A less expensive “declarative” style of specifying process functions—relieving the programmer from managing all of the details related to process control

• Reuse of major functionality—resulting in smaller applications which are easier to develop

• Reuse of a company’s “data warehouse” or information store

• Greater functionality related to business processes—because specialist companies will be driving development of workflow systems further to meet customer needs

• Higher interoperability between separate applications—the common workflow layer will enable or improve communication between separately developed applications leading to productivity gains as duplicate (frequently manual) work is avoided by the workers in the organization

Business Process Re-engineering

In a global economy, most companies look into improving their processes to be more competitive in the market. Business Process Re-engineering (BPR) refers to evaluating and improving business processes to increase organizational productivity. The end result of BPR projects often recommends implementing a workflow system. By implementing a workflow system, businesses can

• Improve customer satisfaction by furnishing accurate information on products and services in a timely manner

• Improve the productivity of the Information Services function. Since the process logic is stored in the workflow system rather than individual applications, process independent applications can be developed and deployed quickly and reused.

• Implement the new process quickly though the system as business rules change.

• Improve daily operations by keeping the process moving, automating manual procedures and reducing the number of manual hand-offs, encouraging coordination between Workgroup and productivity tools, and reducing errors

• Improve communication and coordination between end users and their activities in the business. The vital business rules are enforced and optimized by automating standard business processes. End Users are empowered with information to improve their individual productivity. They can also control their own work environment using the end user tools that are provided by the workflow system.

• Improve planning, scheduling, and management by tracking results and process cycle times. The system can monitor for bottlenecks and “hotspots” and notify the management for immediate action.

June 6, 1995


What is a Workflow Management System? A workflow management system refers to a software function that allows automation of workflows such that driving and monitoring of the workflows can be done effectively and efficiently. There are several different types of workflow systems:

• client-server applications with workflow functionality: These vertical applications are built to handle very specific types of workflows with mostly structured data. Most customer calltrack/support applications and sales order processing applications are in this category. These applications typically support creation of rules and roles that are specific to the application. Routing and monitoring of the activities are built into each application. These applications can be very expensive to maintain since there is no sharing of data with other workflow applications or systems and each application has to be administrated separately.

• email-based, forms-driven workflow systems : Most low-end workflow systems are built on top of the organization’s email infrastructure, and the email message itself contains all the information needed to process the task. These systems can be easily implemented for any users connected through the mail network, remote or local. Expense reports or purchase orders may be processed over the email system and engineering documents may be reviewed over the email system. Monitoring activities and sharing information is limited by the functionality offered by the email system unless the client application performs extra steps to provide additional information about the case. In most cases it is difficult to locate a case that is in the process.

• Server-based workflow systems: Most workflow products provide a server or an engine that handles key workflow functionality such as routing, management of rules and roles, status monitoring and administration. These systems are built on top of a relational database system that allows for sharing of the information among client applications. For example, the server may monitor the inventory level of all current products and when one falls below the restock point, it may facilitate launching a new workflow to place an order from a distributor. System administration is centralized.

• Agent-based workflow systems: These systems provide all the functionality offered by the server-based system but the work is accomplished by several agents. An agent is a service provider. Each agent provides a specific service and communicate with each other to complete a case. For example, a transition agent moves a case from one activity to another while a directory service agent logs the history information in the database. An agent based architecture provides the flexibility and capability to deploy the workflow over a wide range of computing environments. This architecture allows for a rapid development and deployment of new applications that can use the services already provided by the agents.

June 6, 1995


Challenges of a Workflow System Workflow solutions are currently being provided by more than fifty vendors. However, no workflow system currently meets all of the following challenges:

• Scaleability to Enterprise : The architecture must be able to support implementation from the department level up to the enterprise level. This means it must be able to support administrative, ad-hoc, and production workflows and should be able to handle the volume at the enterprise level. When implemented at the department level, it should be light and flexible to run on a desktop PC without performance problems but when installed for the enterprise, the processing power cannot be limited by the workflow system or the database system in use. Single-server bottlenecks must be avoided if enterprise scaleability is to be achieved.

• Multiple Platform Support: Since we have yet to see a standard on enterprise platforms, the support for multiple key platforms will be essential. Platform choices are necessary on both the workflow server (engine) side and on the client side.

• Integration with Existing Applications: A large percentage of process automation projects fail because they take too long to develop new applications and deploy them. Other projects are not attempted because the costs involved in recoding applications to work with a workflow system are larger than the benefits that could be gained. These projects also face resistance to change by the end users who are used to doing things the “old” way (and who may fear the loss of individual discretion). Workflow that uses current user applications will shorten the implementation cycle while giving the organization most of the benefits expected from implementing a workflow system. New applications can be gradually introduced to fine tune the process. The workflow system should provide end users with the information and tools they need to do their job, but allow them the level of control and freedom of action that is appropriate.

• Interoperability with other Workflow Systems: The workflow industry is emerging but has yet to address the interoperability issue. An organization may have several workflows that cannot communicate with each other without someone reentering data. The Smoots Project is a member of the Workflow Management Coalition (WfMC) whose mission is to promote the use of workflow through the establishment of standards for software terminology and interoperability and connectivity between workflow products. The Smoots Workflow will support the common API once it is defined by the coalition. The Smoots agent based architecture allows for special agents to be built to interoperate with non-WfMC compliant workflow system.

• Ease of Administration : Workflows, and the workflow system, must be easy to monitor, easy to update, and easy to deploy. Monitoring tools must provide an aggregate view of the workflow as well as individual case or worker view. Essential metrics should be provided on an on-going basis in order to insure the health of the production workflows. The administration tool needs to support ad-hoc routing, updates to an existing workflow, and deploying new workflows over a wide range of networked computers. The workflow system should support life-cycle management (configuration management and version control) of all aspects of a workflow: The process map, associated parameters and scripts, and associated tools.

June 6, 1995


Smoots Architecture The Smoots Workflow architecture provides a solid foundation for building solutions for an enterprise. The Smoots Workflow System is an agent-based workflow system that is implemented as a set of agents collaborating to provide workflow functions. It is designed to be open at the top and the bottom:

The Smoots architecture provides an open development environment for business applications. Smoots workflow services are offered via OLE Automation, OLE custom controls, PowerBuilder class libraries, and through a published set of APIs.

Smoots is layered on backend services via open standards. It can support any ODBC data store or replication server for case data and workflow descriptions. Smoots can also use emerging messaging layers such as MAPI, Sybase’s EMS, and Microsoft’s Distributed OLE.

The goal of Smoots architecture is to meet the challenges listed in the previous section.

Enterprise Service Bus The Smoots architecture is largely built on top of the Enterprise ServiceBus1. The Enterprise ServiceBus is a message-based system that supports the communication of agents to accomplish tasks. An agent provides a unit of work called a service. A service can be either software or a person-in-the-loop representing the entity that actually does task processing. The ServiceBus exploits the service-provider and divide-and-conquer aspects of distributed application design.

ServiceBus

Host A

Bus Agent

Host B

Bus Agent

1 Enterprise Service Bus is a trademark of Segue Technologies. Enterprise ServiceBus is solely owned by Segue Technologies.

June 6, 1995


The Enterprise ServiceBus is responsible for locating and starting agents and managing the communication between agents over a wide range of platforms in a distributed environment. The Enterprise ServiceBus also can handle conversations between disconnected agents that provide services for remote users.

The Smoots Workflow System is implemented as a set of agents and services which cooperate together to provide necessary services to process workflow cases through the organization.

Bus Agent

The Bus Agent is a special agent running on a host that controls all agents running on that host. Its job is to route messages to the appropriate agent, either on the same host or on any other host it can communicate with, in addition to monitoring the health of those agents. The Bus Agent is required to be running at all times on a host providing overall coordination of the bus by filtering messages, locating agents, launching agents on the host, etc. The user agent sees all messages received and sent from a service so it can manipulate the flow of messages.

System Agents

The Enterprise ServiceBus supports a number of pre-built agents which are called system agents. The system agents provide services that are necessary to support a distributed environment. Some of the system agents are as follows:

• Queue Manager Agent - provides distributed queues (used for store-and-forward capabilities, and is available for general use).

• Directory Services Agent - provides directory services (name lookup / service location) with advanced service lookup capabilities. Different directory services can be substituted under the agent to provide access to different network global naming facilities.

• Event Agent - provides the ability to create, update, delete, publish, and subscribe to global events.

• Identifier Agent - provides unique object ids for persistent objects in the Enterprise ServiceBus’ distributed environment.

Workflow Agents

A set of agents provide workflow specific services.

• Workflow Queue Agent - manages the workflow queues based on a worker. Each worker gets one queue, and a worker can be assigned to more than one activity.

• Activity Agent - the call activity agent launches a new case and the standard activity agent is called for all other activities.

• Transition Agent - routes a case from one activity to another. Manages the data transfer between two activities and interfaces with the queue agent.

A workflow’s process map is “compiled” by Smoots into a description of a set of related agents. As each case in the workflow is initiated, a set of agents is created from the description. In this way, each case runs independently once created. Ad-hoc routing is performed by directly modifying the agent definitions for the given case.

User Defined Agents

The Enterprise ServiceBus supports a number of computation and communication paradigms for custom agent development. A user may want to write their own agent that provides computation services for a financial application or may need to build a special agent that launches test cases. The ServiceBus Application Programming Interface is published for developers to access and manipulate the Enterprise ServiceBus. The category of available APIs are:

June 6, 1995


• Agent-Based Functions - These are functions that deal with the run-time processing of agents. This includes the locating, launching, suspending, and resuming of agents.

• Messaging Functions - These are functions that deal with the creation, sending, and receiving of messages between agents.

• Event Functions - These are functions that support event processing on the Enterprise ServiceBus.

• Administration Functions - These are functions that deal with the administration of the Enterprise ServiceBus.

• Directory Services Functions - These are functions that deal with the processing of directory information for the ServiceBus.

• Agent-Specific Functions - These are functions that support specific agents provided by the ServiceBus.

Message Processing

Agents can communicate through a messaging facility provided by the ServiceBus or through other messaging facilities such as MAPI, Distributed OLE or Sybase’s new Event Messaging Services.

The messaging facility provided by the Enterprise ServiceBus sends messages through a connectionless, asynchronous interface (UDP) in which the ServiceBus guarantees that a message will arrive at its destination. in the correct order. A connectionless interface is chosen to support dynamic messaging behaviors and to support dynamic migration and execution of agents within a distributed environment.

Both push and pull models of communication are supported by this messaging facility. In the push model, an agent can launch another agent to communicate directly with that agent; i.e. push the message to a recipient. In the pull model, an agent can send messages to a message queue in which a recipient agent can pull work out of the queue at its convenience.

Data Management The workflow system manages the flow of information by providing the right information to the right people at the right time. In order for a new case to be launched on a workflow, the information about the workflow including what it is, what the route is, what the activities that need to be completed are, who the workers are, etc. must be provided. A worker assigned to an activity needs some information about the case to process the task before transitioning the case to the next activity. She/he may need to provide additional information for the next activity. These information needs are addressed through the use of work items and flow stacks discussed in this section.

Work Item

A work item is a collection of data that is flowing through the system or is associated with activities. The data is collected in related groups and put in work items. Fields or attributes in a work item are referenced by their strings and can be added and removed from a work item during the process. The type of the values of a field of a work item can be varied from integer, float, strings, blob, date, Boolean, to a special type called attachment and can be stored by value or by reference.

There are three kinds of work items. A global work item consists of a set of data that flows throughout the workflow process. In most cases, a global work item for a particular workflow is created from the same work item template defined by the workflow author. Each global work item is assigned a unique id and contains fields including attachments and history log. A local work item consists of a set of data that is specific to a particular activity. A workflow work item is a special global work item that contains data that are specific to the workflow.

June 6, 1995


Work Item starts withclones of Template

Attachments

Each Agent can modifydata, attachments, oradd new attachments

One work item flowsfrom agent to agent

through entire process

Activity 1 Activity 3Activity 2

Agent A Agent B Agent C

Service X Service Y Service Z

Work Item Flows Through Processsimplified mechanism

Work ItemIn

Work ItemOut

In the HR-new hire workflow example, a file of information containing employee’s application, resume, employment agreement, the new hire process request form, and a copy of the process checklist may be routed through the process. The process checklist that specifies the tasks that have to be performed for this case is the workflow work item. The rest of the documents in the folder is the global work item. At one point in the legal sub-process, more documentation such as a stock option agreement may be added to the global work item. At another point in the HR subworkflow, it may be necessary to look at a spreadsheet that shows the relationship between a position grade and a salary range. This information is relevant to performing that particular activity but shouldn’t be associated with the case throughout the process. The spreadsheet containing the salary ranges should be attached to the local work item associated with that particular activity.

Flow Stack

Since there can be several work items in a workflow, there is a need to keep track of information that gets collected along the way. There is also a need to allow selected activities to share some information on a local work item without exposing the information to the rest of the activities in the workflow. A flow stack construct is introduced to solve the problems of field lookup in multiple work items while permitting overrides and defaults of fields.

A flow stack is an ordered list of work items. Work items are pushed on to or popped off of the flow stack or can be inserted at any point on the flow stack. The principal property of a flow stack is that it can be treated as a single work item for looking up fields by name, and the look up goes to each work item in the stack in order. In this way, work items can be combined to provide a larger set of named fields for the activities in the process. Flow stacks hold work items by reference with the actual work item stored separately from the flow stack. Multiple flow stacks may refer to one work item.

June 6, 1995


Activity 1 Activity 3Activity 2

Agent A Agent B Agent C

Service X Service Y Service Z

Flow Stack Flows Through Processactual mechanism

Start Activity End Activity

WorkflowWork Item

Global Work Item

WorkflowWork Item

Global Work Item

Global WorkItem is archived

when done

Copy Start ActivityWork Item to MakeNew Global Work

Item

Workflow Work Itempushed first; containsprocess map (among

other things)

WorkflowWork Item

Activity 1 LocalWork Item

Global Work Item

WorkflowWork Item


Shared 2-3 WorkItem

Global Work Item

WorkflowWork Item


Global Work Item

Shared 2-3 WorkItem

Push Activity 1Work Item onStack, Pop it

on way out

Pop both SharedWork Item andActivity 3 WorkItem on way out

Push SharedWork Item onStack, don't popit on way out

When a new case is created in a workflow, a new flow stack and a new global work item is created. The workflow work item is pushed on the flow stack first followed by the global work item. The local work item is pushed on the flowstack at the first activity. The sharing of the data between two activities is done by leaving the shared information on the flowstack until they are no longer needed. For parallel routing, a copy of the flow stack is made for each route.

End User Tools One of the benefits of the workflow system is to empower workers to organize and manage their environment. Several end user tools will be developed to allow workers to:

• organize his/her cases into meaningful groups • launch new cases • manage data associated with the case including attachments • transition the case to the next activity • route the case to ad-hoc activities

Three end user tools, Case List Viewer, Folder Browser, and History Browser developed for the demo system are presented in this paper.

June 6, 1995


Case List Viewer

The Case List Viewer provides a view of a worker’s cases. A worker may perform several different tasks for several different workflows. The Case List Viewer shows all cases belonging to the worker in the order specified by the worker. From this viewer, a worker can:

• View case information containing common workflow fields.

• Sort cases according to various displayed criteria.

• Launch a case by selecting and double clicking on a case.

• Mark the case as done or finished for the current activity, initiating its transition to the next activity in the process map.

• Perform ad-hoc routing on the case. Examples include: review and return, delegate and return, and delegate passing responsibility

• View annotations on the case entered by users. These annotations contain discussions or conversation about the case.

• View the list of attachments. Select and display an attachment (launch the attachment’s viewer).

Icons Bar- SpeedKeys for menu

items

A list of cases within aparticular folder. User can

double-click on a case tolaunch. User can drag caseinto other tools/views which

accept cases in order tomove cases. Right mouse-button on case will bring upcontext-specific popup case

menu.

Case-Specific Commands. Applicable for currently selectedcase. Options include: Launch case, view history, mark case

as done.

Shows attributes for currenltyselected case. Used to show

detailed information whichdoesn't make sense to put as

column heading in case list.

Attachment list for currentlyselected case. Double-

clicking on attachment willlaunch that attachment.

June 6, 1995


Folder Browser

The folder browser is a version of the case list viewer that also allows a worker to organize his work into a hierarchy of folders containing cases. The worker can create folders as he chooses, and either populate them manually, or through simple filtering rules. One of the folders is the In Basket, where tasks the worker hasn’t otherwise classified are displayed.

There are several ways to assign tasks to folders:

• A worker can manually move (drag-and-drop) a task into a folder, where it will remain.

• A folder can have a filter associated with it (similar to many email systems) such that new tasks assigned to the user can be selected into the folder based on the contents of the fields in its flow stack.

• A folder can hold tasks that have had various events raised. Such a folder could be used to hold tasks that have passed their delay limit in a queue or deadline at an activity.

• Finally, a folder can be associated with a query against the workflow system that is executed when the folder is selected. This kind of folder can be used to quickly refer to a highly dynamic set of cases in the system. For example, in a bug tracking workflow you might want to have a folder that can open on the set of “open level 1 bugs”. In an expense report workflow you might want a folder on “my expense reports which haven’t been paid yet” (i.e., “my expense reports which haven’t yet be processed at the “cut a check” activity).

Hierarchical Listof Folders defined

by the user.

Context popup menu for foldermanagement

List of cases for highlightedfolder, In Basket

Attachments for Highlightedcase in In Basket

Information for Highlightedcase in In Basket

June 6, 1995


Case History Browser

The Case History Browser provides a view into the history/event log that is attached to a particular case. The worker or the administrator can use this tool to view the status of a case. The top pane shows which activities have been completed in this case (or any other query that can associate an interesting state with an activity). The bottom pane shows history log entries since the case’s inception. The two panes are linked: licking on an activity symbol in the top pane will highlight the history log entries associated with that activity. Also, double clicking on an activity which represents a subworkflow will “drill-down” into a history browser on the dependent case in that subworkflow. In this way all user questions about the progress of a specific case (when, where, how, ...) can be quickly answered.

Process Map of Activities

List of activities completed on specificcase

Sub-workflow. Double-clicking drillsto new process map.

Workflow Status Browser

In the same way that the case history browser provides a user with a view into a specific case, the workflow status browser provides a view of a specific workflow. The top pane in a workflow status browser shows summary status on each activity in the process map, computed based on the results of a query. Then clicking on any activity causes the bottom pane to display cases that are being enqueued or are in process at that activity.

June 6, 1995


User Application Integration

Application Programming Interface

A comprehensive set of APIs, including those defined by the WfMC, allows a user application to access and manipulate the workflow data as well as case data and case history. An application should be able to create a new case, access information about the case, update necessary information, and transition to the next activity. This same set of APIs should also allow end users to write their own status monitoring tools or administration tools if the standard set of tools provided by the system do not meet their needs.

OLE Custom Controls (OCXes)

The same set of APIs will be provided in the form of visual and non-visual OLE custom controls (OCXes) on MS Windows and MS NT. The OLE controls are the next step in achieving Microsoft’s component based software development strategy and will be adapted by most application development tools including PowerBuilder and Visual Basic. They may also be accepted by other operating systems such as Macintosh and UNIX. The OLE custom controls are embeddable objects with in-place activation capabilities. These controls have properties and support events and methods. For example, a custom control called “attachment” can be embedded into an application and when invoked, it brings up a list of attachments that can be viewed. OLE custom controls are able to return events to the containing application, which would then be able to track cases through workflows or exceptional conditions on a case, workflow, or the workflow system itself, that need special handling.

OLE Automation Controller

Another way to enable applications for workflow is through the use of OLE automation controller. The application defines and exposes the OLE automation objects and the OLE automation controller acts on them by getting or setting properties or invoking methods. This will allow desktop applications such as Excel and Word for Windows to access workflow functionality.

Development/Deployment Support

Process Modeling

The first step in improving a business process is to understand the current process. A tool that allows an organization to represent the activities graphically, capture all possible routing paths, represent rules that determine routing, document integration, and application integration is essential in evaluating and re-engineering current processes. This tool is sometimes referred as a workflow definition tool. Most process modeling tools are based on flow-charting paradigms and can represent sequence of activities, points where rules are enforced, alternate and parallel path, and synchronization points. This tool should be tightly integrated with the workflow system to provide a consistent and most up to date view of the process.

Smoots will integrate with an existing tool that provides capabilities to represent the workflow graphically and to define all the data associated with the workflow. At each activity, the workflow author should be able to define the following attributes:

• role of the worker - e.g. HR administrator, Lawyer, etc.

• data access - e.g. local work item, information added to the global work item, attachments, etc.

• processing rules - e.g. FIFO, if the purchase amount greater than $50,000, route it to a Vice President for approval

June 6, 1995


• external event handling - e.g. if the number of cases in the queue greater than 100, reroute the case to another activity

A simple scripting language will be needed to support defining more complex pre- and post-processing rules and external event handling. The syntax of the scripting language will be PowerScript or Visual Basic. A rule-based decision engine will support generalized condition/rule/event processing.

Once the design process is complete, the workflow information should be generated from the process map and stored in the database.

Administration

Versioning/Change Control of the Workflow

The workflow administrator needs to be able to deploy workflows, enable and withdraw their use, and update a workflow with a new version. These operations may include changing the workflow route and rules as well as new data requirements, forms, and attachments. Versioning of the workflows can be done utilizing the new Enterprise Object Life Cycle currently under development. Deployment of new workflows can be handled by a special agent. The agent based technology allows for automatic distribution of agents that can manage deploying workflows over a wide range of servers.

Monitoring Tools

A set of monitoring tools that meets the needs of various roles in the organization will be provided.

The workflow administrator may want to monitor the workflow process to identify problem areas and make adjustments either instantaneously or over time. A monitoring tool should highlight “hot spots” where attention is needed based on the attributes that can be set on activities. For example, if total calls in the front-line queue of a customer service line is greater than 100 with three customer support engineers taking the calls and the backline queue only has five calls when there are six engineers taking the calls, an adjustment needs to be made to the process to balance the call load.

The supervisor of a certain activity may want to monitor the queue for the activity for the number of pending cases and number of cases in process. Based on the data he/she monitors, he/she may decide to implement ad-hoc routing of some cases.

The monitoring tool itself can be run as an agent, generating events corresponding to the current or average state of the system. The user agents can handle these events to dynamically perform load balancing or load other workflow system configurations.

Simulation Tools

Complex workflows cannot be easily changed and deployed. A simulation tool can assist greatly in designing the most optimum workflow based on the current data on average processing time, incoming case rate, number of servers, etc. Once the workflow is implemented, the simulation tool can help to tune the process with updated data from the process before a new version of the workflow is deployed.

June 6, 1995


Summary The Smoots Workflow project will provide a flexible and intelligent workflow system that is scaleable from department to enterprise. It is built on top of the Enterprise ServiceBus, an agent based service oriented technology that provides the flexibility for workflow development, deployment and life cycle management as well as security administration, process simulation and interoperability with other workflow systems. The Smoots Workflow encourages application reuse by integrating existing applications through a comprehensive set of APIs or emerging OLE component technology and OLE automation. Workflow administration challenges will be carefully evaluated and addressed. Several monitoring and reporting tools will be built into the system to assist in the evolution of the workflow implementation.

June 6, 1995


References 1. Ronni T. Marshak, “Workflow White Paper, an Overview of Workflow Software”, Workgroup

Computing Report, Vol. 16, No. x

2. Peter Spellman, “Flexible Workflow System - extended abstract”, Workflow ‘95, Mitre Corporation, Boston

3. Dave Dyda, “Choosing the Right Solutions for Enterprise Process Management”, Technical Paper Series, Sybase, 1995

4. Dave Dyda, “Workflow Management Systems - Collaborative Solutions for Managing Business Change”, Sybase, 1995

5. Larry Suarez, Enterprise ServiceBusTM - White Paper, Segue Technologies, 1994

6. Larry Suarez, Enterprise ServiceBusTM - Developers Manual, Segue Technologies, 1995

7. Ronni T. Marshak, The Power of Business Process Representation - Workflow-BPR from Holosofx, the Patricia Seybold Group, 1995

8. Keith D. Swenson, Robin J. Maxwell, Toshikazu Matsumoto, Bahram Saghari and Kent Irwin, “A business process environment supporting collaborative planning”, Collaborative Computing, 1994

9. Dave Bakin, “Workflow System Glossary”, internal PowerSoft document, 1995

10. Dave Bakin, “Work Items and Flow Stacks”, internal PowerSoft document, 1995

11. Derek Miers, “Work Management Technologies”, Process Product Watch, volume 2, Enix Limited, 1994.

June 6, 1995


Workflow Glossary This section defines and describes common workflow concepts and terms used throughout this paper.

• A workflow is an automated business process to be accomplished by a set of activities performed by cooperating workers.

• A case is an instance of a workflow and a unit of work that is to be done in steps by following the process of the workflow.

• An activity is some task that has to be performed on a case by a person or a program at a given point in the process.

• A worker is a person or a program that is doing work for/on a particular activity.

• A role is a kind of worker or an identifier for a class of workers that can be interchangeably assigned to perform some activity.

• Assignment refers to determining a specific worker for an activity at design time or at run time

• An application is a program that is used to complete an activity.

• The fundamental function of the workflow system is routing. Most workflow systems support serial, parallel, conditional, and ad-hoc routing. Parallel routing supports multiple subworkflows to be completed in parallel with a specified meeting point. Conditional routing supports changing the content and the direction of the work based on the pre-defined business rule. Ad-hoc routing is a process described by the user at the time of processing.

• Transition refers to a path from one activity to another.

• Junctions are used for represent complex routing of work items and are used for splitting and for merging. For example, an OR-Split junction is used for conditional routing and an OR-Join junction requires one of many input transitions to happen. An AND-Split causes the case to be “split” for simultaneous work in several parallel routes of activities, and an AND-Join merges all work items before passing on to the next activity.

• An administrator administers the workflow system including deploying servers, versioning, deploying and activating workflows and monitors workflow performance.

• The author designs the workflow process, the work item being routed, and all other aspects of a workflow.

June 6, 1995


June 6, 1995


Appendix A

Demo Scenario - New Hire Workflow An example workflow is described in this section to introduce common workflow concepts. A simplified version of the new hire scenario illustrates a cross organizational workflow that spans two platforms. This workflow needs to be completed for a company to officially employ a new person. In this scenario, three different departments are involved in processing a new employee; Human Resources department, MIS department, and Legal department.

HR workflow

A

Start

AllocateEmployee ID

HR Recruiter

Specify job description,department, manager,salary, salary grade, etc.Establish physical paperfolder for employee.

Update PayrollRecords

Accounting -Payroll

Update TelephoneBook

TelephoneAdmin

New-Hire MISWorkflow

MISDepartment

New-HireLegal

Workflow

LegalDepartment

Followup

HR Recruiter

Done

B

A B

DetermineAccess

Requirements

DepartmentManager

The workflow is started from the HR department which handles all new hire processing. The HR department, in this case, is also responsible for tracking all subworkflows.

June 6, 1995


• The first activity is performed by a HR recruiter who enters the new employee into the employee database using an HR application. A new employee id number is assigned at this point and other data required by the application are entered.

• After the first activity has been completed, the case has been routed to three different routes to be processed in parallel by the HR department, the MIS department, and the Legal department. The HR workflow continues on each of the subworkflows simultaneously. One track remains in the HR department.

• On the HR track, the first activity is for a payroll record for the new-hire to be generated by payroll clerk in the accounting department.

• Then, the company’s phone directory, an Excel spreadsheet, also gets updated by the company’s receptionist.

• Now, the case waits at the AND-Join until the other departments are done with their processing of this new-hire.

• Meanwhile, on the MIS track, the case is first processed by the new employee’s manager. The manager will specify the machine configuration and needed network server access for his new employee. After that is done the next activity is for the MIS department to process the request. This is done by a workflow owned by the MIS department: it is a workflow in its own right and is used as a subworkflow for the new hire workflow.

• Meanwhile, on the Legal track, the case is sent immediately to the Legal department which will process it in a workflow of their own.

• When all three parallel tracks are done, the case is assigned to the HR recruiter to perform the last step of the workflow. Now the HR recruiter can perform any follow-up that is necessary, generate a nice form letter to the new employee and his manager, and mark the case as finished. When finished it will still be in the system but not in any worker’s queue of tasks. At some later time, according to the company’s HR policy, the case will be archived and deleted from the system.

Delay or deadline scheduling would be used effectively in this workflow to make sure that some processing steps are completed before the employee’s start date, and make sure that other activities are completed no later than 1 week after the employee starts.

The HR department is responsible for owning this workflow, since it has the ultimate responsibility for making sure that new hires are properly processed and that it their “coming on board” is as smooth as possible. Some of the activities are performed by workers outside the HR department but are still a part of this workflow, e.g., updating the telephone book. Other activities are really entire subworkflows which are owned by a different department, e.g., performing all the tasks related to computer accounts and network security.

June 6, 1995


MIS network setup

Start

ChooseNetwork

Parameters

MIS Technician

Pick unique email name,subnetwork, IP address

Create UserAccount

Script

Create a user account,home directory, initialpassword, etc.

Establish UserPrivileges

Script

Establish security tospecified file servers,SQL servers, etc.

Done

The MIS department is responsible for computer and network accounting and security, as well as machine installation and setup. In this workflow the new employee will be assigned a machine, a login account, and network access and security.

• Before reaching this workflow the case data includes the requested machine configuration and network access. This information was entered by the new employee’s manager as part of the HR (parent) workflow, and copied to the new MIS case when it is created.

• An MIS technician will assign a unique email name to the new employee, determine network parameters such as IP address and submit address, and approve the network server access requested.

• The next activity is to create the user account with a home directory, initial password, and initial configuration. This activity has been automated with a batch file. The executable batch file is assigned to be the worker for this activity and when the case reaches this activity the batch file will be automatically started, fetching the data it needs out of the case that is flowing through this workflow. When the batch file is done the case will automatically transition to the next activity.

• Similarly, another batch file will be automatically invoked at the next activity to assign the new login account access privileges on various servers in the organization.

In the HR scenario this MIS workflow is used as a subworkflow. The HR workflow will generate a new case in the MIS workflow. The new case is considered a dependent of the case in the HR workflow, its parent. When the case is done in this workflow, the parent case is notified by the system, and will transition to its next activity.

June 6, 1995


Legal Subworkflow

DoneStart

ChooseDocuments

Get EmployeeSignatures

Verify Contracts,Handle

Exceptions

Get EmployeeSignatures

Further CandidateProcessingRequired?

Lawyer -Employment

HR Recruiter Lawyer -Employment

Admin Asst -Legal

No

Yes

The legal department is responsible for distributing, collecting, and reviewing proper forms for the new hire.

• Verify signed employee contract, confidentiality agreement, and citizenship information collected by HR

• If “custom” processing required for immigration, prior invention, etc., mail document to employee for more signatures and information.

June 6, 1995