Human Workflow and SOA

As I have previously stated, many services include both IT systems and people. Business processes within a service are comprised of individual activities that are performed either by an IT system or a person. Activities performed by people are either completely manual (meaning they are performed outside the context of any IT system - for example mailing a document to a customer), or partially manual (meaning they involve a person interacting with a computer system to complete the activity). Activities performed by IT systems are fully automated.

We need a mechanism for coordinating manual activities with automated activities in support of any given business process. One way this can be achieved is to leverage a human workflow system (HWS). In this case, any service involving manual activities would have an HWS behind its service boundary to coordinate the manual and automated activities contained within business processes supported by that service. An HWS allows us to establish worker roles and assign tasks to these roles to be later accepted by workers within each role for completion.

Usually what we see however is the HWS becomes the centrepiece of the service. All service logic executes within the HWS. You become bound to the HWS as your technology platform, which limits your overall flexibility and leaves you somewhat at the mercy of your HWS vendor.

Ideally what we would like to do is rely on the HWS only for assigning tasks to worker roles, managing work queues, notifying workers when new tasks have arrived or been accepted and closing tasks off. This then gives us the freedom to implement the remainder of the service logic however we like and on whatever platform we deem appropriate.

Consider a Policy Administration service which amongst other processes supports the process of writing a new insurance policy. Let us assume that this service includes a Web application for managing policies. A user enters the policy information into the Web interface.

The application logic then assesses the risk and decides that the policy must be referred to a risk assessor. The application then allocates a unique task ID (a GUID is good for this purpose) and sends a message to the HWS (containing the task ID), instructing it to open a new workflow task for a risk assessor, then storing the task ID against the policy in its database.

The HWS places the new task on the shared risk assessor work queue and notifies all risk assessors that a new task has arrived. One of the risk assessors accepts the task via the HWS interface and then actions that task. The HWS client application then spins up a Web browser pointing at the referred policy ready for assessment.

The risk assessor then reviews the risk profile and either approves or declines the policy via the policy administration application. The application then grabs the previously stored task ID for the referral and sends a message to the HWS to close the outstanding task.

One nice thing about this approach is that we remove our dependency on the HWS. If the HWS is unavailable, a risk assessor can still manually look up the policy and approve or decline it and the human workflow task would eventually be closed when it processes the message to do so (sent asynchronously by the policy administration application).

Furthermore, once we have removed all business logic from the responsibilities held by the HWS, we are in a better position to share the HWS between all services.

One key benefit of leveraging a single HWS enterprise wide is where we have the same worker being assigned tasks from multiple services. If there are multiple human workflow systems in operation, then a single worker may need to have multiple HWS clients operating on his or her desktop simultaneously.

In the end, the decision lies with the architect to determine the most appropriate approach for any given service. It may be that hosting an entire service inside an HWS is the most appropriate option based on features offered by the HWS. As usual, there is no one right approach.