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.
Data
Access
User
Interface
Monolithic
Application
Data
Access
User
Interface
Process
App
Algorithms
RDBMS
RDBMS
GUI (MS
Windows, X)
GUI (MS
Windows, X)
Workflow
Automation
Data Access +
Process + User
Interface + App
Algorithms
Application
Process + 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 with
clones of Template
Attachments
Each Agent can modify
data, attachments, or
add new attachments
One work item flows
from 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 Process
simplified mechanism
Work Item
In
Work Item
Out
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 Process
actual mechanism
Start Activity End Activity
Workflow
Work Item
Global Work Item
Workflow
Work Item
Global Work Item
Global Work
Item is archived
when done
Copy Start Activity
Work Item to Make
New Global Work
Item
Workflow Work Item
pushed first; contains
process map (among
other things)
Workflow
Work Item
Activity 1 Local
Work Item
Global Work Item
Workflow
Work Item
Activity 3 Local
Work Item
Shared 2-3 Work
Item
Global Work Item
Workflow
Work Item
Activity 2 Local
Work Item
Global Work Item
Shared 2-3 Work
Item
Push Activity 1
Work Item on
Stack, Pop it
on way out
Pop both Shared
Work Item and
Activity 3 Work
Item on way out
Push Shared
Work Item on
Stack, don't pop
it 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- Speed
Keys for menu
items
A list of cases within a
particular folder. User can
double-click on a case to
launch. User can drag case
into other tools/views which
accept cases in order to
move cases. Right mouse-
button on case will bring up
context-specific popup case
menu.
Case-Specific Commands. Applicable for currently selected
case. Options include: Launch case, view history, mark case
as done.
Shows attributes for currenlty
selected case. Used to show
detailed information which
doesn't make sense to put as
column heading in case list.
Attachment list for currently
selected case. Double-
clicking on attachment will
launch 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 List
of Folders defined
by the user.
Context popup menu for folder
management
List of cases for highlighted
folder, In Basket
Attachments for Highlighted
case in In Basket
Information for Highlighted
case 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 specific
case
Sub-workflow. Double-clicking drills
to 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
Allocate
Employee ID
HR Recruiter
Specify job description,
department, manager,
salary, salary grade, etc.
Establish physical paper
folder for employee.
Update Payroll
Records
Accounting -
Payroll
Update Telephone
Book
Telephone
Admin
New-Hire MIS
Workflow
MIS
Department
New-Hire
Legal
Workflow
Legal
Department
Followup
HR Recruiter
Done
B
A B
Determine
Access
Requirements
Department
Manager
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
Choose
Network
Parameters
MIS Technician
Pick unique email name,
subnetwork, IP address
Create User
Account
Script
Create a user account,
home directory, initial
password, etc.
Establish User
Privileges
Script
Establish security to
specified 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
Choose
Documents
Get Employee
Signatures
Verify Contracts,
Handle
Exceptions
Get Employee
Signatures
Further Candidate
Processing
Required?
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

Agent-Based Workflow

Recommended

More Related Content

What's hot (18)

Viewers also liked (7)

Similar to Agent-Based Workflow (20)

Recently uploaded (20)

Agent-Based Workflow