Pattern 7 (Retain Familiar)

FLASH animation of Retain Familiar pattern

Description

Where several resources are available to undertake a work item, the ability to allocate a work item within a given case to the same resource that undertook a preceding work item.

Example

Motivation

Distributing a work item to the same resource that undertook a previous work item is a common means of expediting a case. As the resource is already aware of the details of the case, it saves familiarization time at the commencement of the work item. Where the two work items are sequential, it also offers the opportunity for minimizing switching time as the resource can commence the latter work item immediately on completion of the former.

This pattern is a more flexible version of the Case Handling pattern discussed earlier. It only comes into effect when there are multiple resources available to undertake a given work item and where this occurs, it favours the allocation of the work item to the resource that undertook a previous work item in the case. Unlike the Case Handling pattern (which operates at case level), this pattern applies at the work item level and comes into play when a work item is being distributed to a resource.

The Chained Execution pattern is related this pattern and is designed to expedite the completion of a case by automatically starting subsequent work items once the preceding work item is complete.

Overview

The Retain Familiar pattern takes the form of a one-one relationship between a task and a preceding task in the same process. Where it holds for a task, when an instance of the task is created in a given case, it is distributed to one of the nominated resources the completed one of the preceding tasks in the same case. If the preceding task has been executed more than once, it is distributed to one of the resources that completed it previously.

Context

There are no specific context conditions associated with this pattern.

Implementation

Not surprisingly, this pattern enjoys wider support than the Case Handling Pattern. WebSphere MQ allows individual work items to be allocated to the same resource that started another work item in a case or to the resource that started the case itself. FLOWer provides a facility in the design time workflow model to enforce that a task must be executed by the same resource as another specified task in the case. COSA does the same thing using a customised distribution algorithm for a specific work item that requires it to have the same executor as another work item in the case. Similarly iPlanet achieves the same result using the linked user concept which requires two work items to be executed by the same resource. Oracle BPEL supports the pattern via the ora:getPreviousTaskApprover() function.

Issues

None identified.

Solutions

N/A.

Evaluation Criteria

An offering achieves full support if it satisfies the description for the pattern.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.

Summary of Evaluation