Pattern 8 (Capability-Based Distribution)
The ability to distribute work items to resources based on specific capabilities that they possess. Capabilities (and their associated values) are recorded for individual resources as part of the organizational model.
Instances of the Airframe Examination task should be allocated to an Engineer with an aeronautics degree, an Airbus in-service accreditation and more than 10 years experience in Airbus servicing.
Capability-based Distribution provides a mechanism for offering or allocating work items to resources through the matching of specific requirements of work items with the capabilities of the potential range of resources that are available to undertake them. This allows for a much more fine-grained approach to selecting the resources suitable for completing a given task.
Within a given organizational model, each resource is assumed to be able to have capabilities recorded for them that specify their individual characteristics (e.g. qualifications, previous jobs) and their ability to undertake certain tasks (e.g. licences held, trade certifications). Similarly it is assumed that capability functions can be specified that take a set of resources and their associated capabilities and return the subset of those resources that conform to a required range of capability values. Each task in a process model can have a capability function associated with it. Figure 8 illustrates the manner in which the Capability-based Distribution pattern operates with a capability function matching a work item to a resource on the basis of both resource capabilities and work item attributes.
Figure 8. Capability Based Allocation
Capability-based Distribution can be either push or pull-based, i.e. the actual distribution process can be initiated by the system or the resource. In the former situation, the system determines the most appropriate resource(s) to which a work item should be routed. In the latter, a resource initiates a search for an unallocated work item(s) which it is capable of undertaking.
There are no specific context conditions associated with this pattern.
Capability-based Distribution is based on the specification of capabilities for individual resources. Capabilities generally take the form of attribute-value pairs (e.g. "signing authority", "$10M"). A dictionary of capabilities can be defined in which individual capabilities have a distinct name and the type and potential range of values that each capability may take can also be specified. Similarly, tasks can also have capabilities recorded for them.
The actual distribution process is generally based on the specification of functions (in some form of procedural or declarative language) which are evaluated at runtime and determine how individual work items can be matched with suitable resources. These may be arbitrarily complex in nature depending on the range of capabilities that require matching between resources and work items and the approach that is taken to ranking the matches that are achieved in order to select the most appropriate resource to undertake a given work item. Both COSA and iPlanet implement Capability-based Distribution through the use of user-specified capability functions that form part of the process model. In both cases, the strategy is push-based. Similarly Oracle BPEL supports the definition of user properties and the ora:getUserProperty() function can be used when specifying task distributions based on user capabilities. FLOWer uses case queries to determine which cases can be allocated to a specific resource. These can include data elements relating to both the case and the individual resource.
One issue associated with push-oriented Capability-based Distribution is that it is possible for capability functions to identify more than one possible resource to which a work item may be assigned. Where this occurs, the work item may either be offered to multiple resources or assigned to one of the identified resources on a random basis. It is also possible for the capability function to return an empty set of possible resources.
A second issue relates to pull-oriented Capability-based Distribution, in that it is possible for a resource to identify more than one work item that it is capable of undertaking.
The first of these issues is not necessarily a problem although it may result in sub-optimal resource allocations. It can be avoided through more precise definition of capability functions. As an example, if the intention of the competence function in Figure 7 was to allocate the task to a single auditor, then a ranking function (e.g. minimum) should be included in the competence function to ensure only a single resource is returned. The problems associated with an empty return value can be avoided by testing whether the capability function returns an empty set and if so, assigning a default value for the resource. COSA provides the ifnull operator for this purpose. iPlanet allows its evaluate methods to be arbitrarily complex to cater for situations such as this and may include default values or other schemes for identifying a suitable resource.
The second issue should not generally result in difficulties. Under a pull-based distribution strategy, resources should anticipate the possible return of multiple work items. In some systems, it is possible for a resource to query matching work items without committing to executing them.
An offering achieves full support if it satisfies the description of the pattern.
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.
|Websphere MQ Workflow||3.4||-||Not supported|
|FLOWer||3.0||+||Cases can be assigned based on data or process elements|
|COSA||4||+||Supported via competency definitions for users, groups and activity definitions|
|iPlanet||3.1||+||Directly supported through customised distribution algorithms|
|Oracle BPEL||10.1.2||+||Oracle BPEL PM supports this pattern directly. It allows defining user properties and store them in user-properties.xml file, which become accessible via the function ora:getUserProperty(). This function can be used in the condition associated with the dynamic assignment feature.|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||-||OpenWFE does not support this pattern.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern. Enhydra has the capability to import organizational structure information from an LDAP server. However, it is not clear how these facilities can be used for capability-based allocation.|
Summary of Evaluation