Exploring Human Workflow Architectures
by Jesús Rodríguez and Javier Mariscal
Summary: Human workflow systems and some of the most representative patterns of human-to-business processes interactions break down into two major components. The first is human workflow systems and the interactions among them as they are implemented in integration platforms. The second component is human workflow interaction design patterns and how they are implemented using interactions among the human workflow systems. This discussion will take a close look at these processes.
Contents
Task States
Workflow Services
Task-Assignment Patterns
Task Assignment Using Policies
Business-Process Integration
About the Authors
Resources
Total automation of business processes is practically unachievable without considering human interaction, a factor that is tied semantically to many aspects of process automation and integration. Human interaction is present in some of the most common business processes like order approvals and human-resources management. Those human interactions can vary from a simple task-assignment process to a very complex business-process notification and task reassignments.
Frameworks for human workflow are present in a variety of popular integration servers from different vendors. We'll explore conceptually some of the main components that are present in those human workflow platforms and the interactions among them. We'll also cover some of the most common human workflow design patterns and how they can be implemented using those components.
Human workflow systems have to support the communication between people and systems. To accomplish this support every human workflow system has to provide basic functions like task assignment, identity management, notifications, tracking, and interoperation with business-process management (BPM) systems (see Figure 1).
Four main components of a human workflow architecture are a task management service, a tracking service, a notification service, and an identity service. Before we explore these services in depth, it's important to understand the role of tasks in human workflow systems.
Tasks are the main communication unit between business processes and people. Typically, a task is assigned to a user who needs to perform some related action. For example, a supervisor might need to approve the request to purchase some items. Normally, a user has to perform a series of tasks that are grouped semantically. That is, our supervisor might group all items to perform each day into a group called "today's approvals." These groups are called task lists.
Task States
During the lifetime of a human workflow system, tasks in task lists are constantly switching from one state to another. For example, the task for our supervisor first enters a state of pending; when the supervisor accepts the task, the state changes to claimed. Finally, when the supervisor approves the request, the task enters its final state of completed. States are used conceptually to describe the task life cycle. Some of the most common states are pending, where the task has been created; claimed, where a user has claimed the task and has received its input data; completed, where a user has finished the task and provided its output data; and failed, where a user has finished the task and provided a fault message.
Tasks are normally associated with time frames: expiration, escalation, delegation, and renewal. In our example, the approval task can expire if the supervisor does not act on it in a specified period of time. This expired task can be subsequently escalated to another course of action or assignment. Also, the supervisor can decide to delegate the task to another person (a manager, for example) to act in his or her place. The manager can also decide to necessitate another manager to gather additional insight. If this second manager does not act on the task in a given time frame, the task will be renewed for another period of time.
In other scenarios, tasks are related semantically to each other. The question "What's the next task?" will not always have a trivial answer. In some cases, this answer has to be determined at runtime. Tasks can be grouped sequentially within a business-process instance so the user knows the next task(s) to perform after completing the current task.
In our example, 20 requests should be approved for the supervisor in sequence to complete the business process. Each time the supervisor completes an approval, the engine should be able to identify the next task. Task chains represent a metadata-driven approach to describe the relationship between a set of tasks within the scope of a business process. Task chains can group tasks semantically to help users achieve functionalities like sequence execution and failure management.
Tasks that have a dependency on a specific business process are known as inline tasks. Tasks that are totally independent of a particular business process are stand-alone tasks. Inline tasks typically have access to data related with a business process and are stored in native, business-process artifacts like variables or messages. By contrast, stand-alone tasks interact with business processes through a well-defined interface without any dependency on the process data itself.
Workflow Services
The architectural component that handles sectional tasks is the task management service. In a typical scenario, the task management service receives a request to create a task, interacts with the identity service to select all people that are eligible for the task, adds the task to the work lists (to do's) associated with the selected users, and assigns the specific timelines and policies. Eventually, one user decides to work with the task by claiming it. The user can then work with the task or request more data.
.gif "Click here for larger image")
Figure 1. The main components of a human workflow architecture (Click on the picture for a larger image)
A key aspect of human workflow systems is the ability to resolve the set of users allowed to execute a task. This user-resolution process can be based on interactions with identity management platforms. In our example, the human workflow services need to identify which users are able to approve the request—in this case the supervisors. To accomplish this identification a human workflow platform has to resolve the concept supervisor against a set of users and roles traditionally stored in a user directory.
Multiple types of relationships can be established between people and processes. One of the most common is how people interact with processes (human roles). People in an organization can be grouped in roles that are related semantically to some business activity, such as a process administrator or task owner. Another common relationship is how processes identify which people to interact with (people links and queries). Within a business process, certain groups of users are relevant from the business standpoint. People links are used to represent the different groups of people who participate in the execution of the process. A query against an organizational directory is used to determine the individuals associated with a people link and is bound to the people link. In our example, the generic human role, finance manager, could be qualified by the people link supervisor, which is bound to the query "select head of department, where department name is finance."
The identity service is in charge of the user-related features like authentication, authorization, or people resolution. User information is frequently stored in organizational directories (for example, Active Directory directory services, an LDAP directory, or a relational database). The identity service can work independently of the organizational directory. Based on the adapter pattern, it is possible to extract the directory access through the provider, which is able to execute the queries to obtain the information from the directory. This approach extracts the human workflow functionalities from the user's store.
In our example, let's assume a manager would like to reconstruct the execution of the request-approval workflow to check for deficiencies. The tracking service keeps track of the state changes related with tasks and task chains. This service should provide the basics of the required functionality to reconstruct the task history changes and perform task analysis.
We also need a service that will notify the supervisor by e-mail when the request-approval task is created. The notification service handles the notification mechanisms to the user related with the task's state changes.
The four run-time services discussed here provide a good overview of some of the most common functionalities required for human workflow systems. Combining these services addresses some of the most common human workflow scenarios. Now let's explore some of the common human workflow patterns.
Task-Assignment Patterns
Workflow-oriented processes have been present in the industry for years. The knowledge acquired serves as the base for improvements to build workflow systems. Patterns abstract workflow systems at different levels such as task approval, task creation, and task state management. We don't intend to define a catalog of human workflow patterns here. Instead, we'll cover some common patterns in human workflow systems from the angle of the architecture defined previously.
We'll begin by looking at a single-user workflow example. A task can be assigned to one user, and only one user can act on it. For example, an employee, through the employee portal, submits a vacation request. The portal initiates a business process that includes a user task modeled using a simple workflow. The task is assigned to the employee's manager. When the manager approves or rejects the vacation request, the employee is notified by e-mail of the manager's decision.
For this solution combine the human workflow components through four interactions. The task is configured using the client applications that interact with the task management service; the task's life cycle or task states are configured. As part of the business process, the task is assigned to a group of users using the task management service. One of the users claims the task, and the task management service applies the correct policy to prevent other users from acting on the same task. The business process uses the task management service to get the status update of the task.
Now let's consider a sequential workflow example. The sequential workflow represents a scenario in which a task must be approved sequentially by a set of users. For example, when a purchase order approval system processes a purchase order using a business process, an employee belonging to the group "Supervisor" initially evaluates the purchase order. After the initial user approves the purchase order, that user's manager approves it. After the manager approves the purchase order, it is forwarded to the billing and shipping departments. This solution has for interactions. Interact with the task management service to configure tasks and set appropriate policies. Define the sequence of users that should act on the task. Start the task interacting with the task management service. The first user will claim the task to start working on it, and upon completion the task management service will route the task to the next user in the group.
A parallel workflow pattern represents the scenario in which a task must be approved by different users at the same time. Each approver can add comments and attachments that are independent of the others. For example, a hiring process is used to hire new employees. Each interviewer votes in favor of or against a candidate. If 75 percent of the votes are favorable, the candidate is hired; otherwise, the candidate is rejected. The process is modeled using the parallel workflow, where each interviewer can vote independently from the other interviewers. For implementation this solution has five interactions. Interact with the task management service to configure tasks and set appropriate policies. Define the sequence of users that should act on the task. Start the task interacting with task management service. The task management service routes the task to all users. The task management service will complete the task only when all users are finished acting on it.
Task Assignment Using Policies
Now let's take a look at using policies for task assignment in which the tasks need to be assigned to the user by following specific rules. For example, the heart-bypass procedure is allocated to the surgeon who has the least number of operations allocated to him or her. This solution's implementation combines the human workflow components through five interactions. Interact with the task management service to configure tasks and set appropriate policies. Configure the assignment policy as part of the task definition—for example, select from the available users the one that has the least number of tasks assigned. As part of the business process, the task is assigned to a group of users using the task management service. Start the task interacting with the task management service. The task management service will execute the task policies against the potential users that can act on the task and, in turn, select a user matching the policy criteria and assign the task to that user.
In a single-user workflow with escalation example, a task can be assigned to multiple users, but only one user can act on it. If the task expires, the user's manager has to act on the task. For example, the help desk service request process allows users to file help desk service request tickets. If the person who receives the ticket does not act on it within a specified time period, the ticket is escalated automatically to that person's manager. The ticket is escalated automatically three times if no one has acted on it within a predefined time period, until it gets to the CEO of the company. If the CEO also doesn't act on it, it expires.
For this solution's implementation combine the human workflow components through five interactions. The task is configured using client applications that interact with the task management service; properties such as the task's life cycle, escalation policy, or task states are configured in this step. As part of the business process, the task is assigned to a group of users using the task management service. One user claims the task, and the task management service applies the correct policy to prevent other users from acting on the same task. If the task expires, the task management service applies the escalation policies to escalate the task to the correct user. If the task expires again, the task management service cancels it.
In a single-user workflow with delegation example, a user who claimed to act on a task can reassign it to another user. For example, before going on leave, the chief accountant passed all of his or her outstanding tasks on to the assistant accountant. For this solution's implementation combine the human workflow components through four interactions. The task is configured using client applications that interact with the task management service; properties such as the task's life cycle, escalation policy, or task states are configured. As part of the business process, the task is assigned to a group of users using the task management service. One user claims the task and the task management service applies the correct policy to prevent other users from acting on the same task. Using the appropriate client applications the user inspects the list of possible people that are able to act on the task. The user reassigns the task to one of those people and readjusts the task's properties.
For the task chained pattern example a task needs to start based on the completion status of another task. For example, immediately commence the next work item(s) in the emergency rescue coordination process when the preceding one has completed. To implement this solution combine the human workflow components through four interactions. The task is configured using client applications that interact with the task management service; properties such as the task's life cycle or states are configured. The task chain metadata is configured, indicating the second task will be triggered by the completion of the first task. The task chain is started through the task management service, causing the start of the first task. When the first task completes, the task management service will use the metadata in the task chain to start the second task.
Business-Process Integration
Human workflow solutions can be designed using a combination of services like task management, identity management, tracking, notification, and client applications. We've explored some of the most common components present in human workflow architectures and their implementation in a series of interactions. Some of the most complex human-systems interactions can be modeled using a set of human interaction patterns that are in turn implemented using the human workflow components. These basic components and patterns of human workflow architecture represent key aspects in the business-process integration space, and when implemented they create a powerful human workflow solution.
The concepts and scenarios presented here are intended to assist you in better understanding the components found in typical human workflow platforms. For more information on human workflow concepts consult the listed resources. In addition consult the workflow engine architectures from some of the major integration server vendors.
We would like to thank Kirsti Elliot, Ben Elliott, and the architecture strategy team at Microsoft for all their feedback and corrections made to this article.
About the Authors
Jesús Rodríguez is chief software architect at Two Connect Inc, a Microsoft Gold Certified Partner based in Miami, FL. He is also a Microsoft BizTalk Server MVP. Jesús's extensive experience with business-process integration and human workflow has been derived through multiple implementations of loosely coupled systems founded on the principles of SOA. He is an active contributor to the .NET and J2EE communities, focusing on the interoperability aspects between those two platforms. His contributions include several articles for different publications such as MSDN, sessions in Microsoft conferences such as Teched, and Web casts about different Microsoft technologies. He is a prolific blogger on all subjects related to integration and has a true passion for the technology. Contact Jesús at jrodriguez@twoconnect.com or through his blog.
Javier Mariscal is president of Two Connect Inc. Javier has dedicated a good part of his 16-year professional career to designing and deploying data and application integration solutions, particularly those involving the merger of mainframe and AS/400 environments with the WinTel platform. He has a true passion for business-process automation and workflow solutions that implement the service-oriented development of applications (SODA) approach to globally distributed application development and maintenance. He keeps quite busy working on just such solutions for Fortune 1000 and upper midmarket organizations worldwide. Contact Javier at Javier@twoconnect.com.
Resources
The Workflow Management Coalition
OMG Business Process Management Initiative
This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal website.