Over the years business processes have become automated to the point that the BPM community now considers the SOA language BPEL, designed for the orchestration of Web Services, as the best platform for building contemporary processes. But many processes retain some level of human activity, and BPEL's support for human interaction is problematic. Most attempts to integrate human workflow with BPEL, such as BPEL4People (as well as proprietary task subsystems offered by the major BPM vendors), try to fit human activities into BPEL's execution model. Human tasks are simply special steps in the larger process.

But people don't work that way, argues Keith Harrison-Broninski in his book Human Interactions: The Heart and Soul of Business Process Management. Their work is complex and ad hoc; they interleave their tasks and adapt how they work as business rules change. Harrison-Broninski proposes Role Activity Diagrams (RAD) as the best way to model human workflow, and dismisses BPEL as an impossible fit.

Harrison-Broninski intentionally poses examples (design, sales, marketing, strategy) that are almost exclusively manual, involving little or no system integration, for which the RAD modeling technique is ideal. But what about processes that involve a mixture of human and automated activity, processes whose automation requirements are well served by BPEL? This article makes the bold claim (an anathema for Harrison-Broninski) that BPEL can model these hybrid processes, that it can accommodate complex RAD-style human workflow in a larger orchestration! Our example is the credit card disputes process of fictional ACMEBank. ACME has been sold on BPEL, Web Services, and business rules technology, but needs a RAD-style of human interaction to support its disputes specialists, who, as we'll see below, use the occasion to employ curious upsell techniques.

A Radically Different Example
To understand the style of human workflow that RAD offers, consider the design-engineering example shown in Figure 1. In this process, a product manager (for a car maker, let's say) collaborates with designers. The manager documents the basic product design concept (e.g., "I want a car that can transform into a helicopter to escape traffic"), assigns to one or more designers the task of writing a detailed design, and reviews each design, deciding for each whether to accept or reject (e.g., reject the design for the car whose fuel task might explode). The notation is intuitive, even for newcomers to RAD. Manager and Designer, shown as large outer boxes, are roles. There is one manager but there can be multiple designers, shown as a stack of outer boxes. A role can instantiate, or allocate work to, another role; the manager role instantiates a designer in the small box labeled Start Designer Role. Interactions between manager and designer are shown as lines that connect small white boxes in each role. Individual tasks are small shaded boxes within a role (Prepare Design Concept in Manager and Do Design in Designer, for example). Ovals represent state; Have Design Brief, for example, means the manager has now reached the state of having completed the design brief. Iteration is shown with a windmill symbol; the logic coming below Design Received is the manager's review of the designs from each designer. Refinement (a form or conditional or parallel branching) is shown as an inverted triangle; there are acceptance and rejection paths to deal with a design that has been accepted or rejected. (The notation is Harrison-Broninski's enhancement of Martyn Ould's classic RAD notation.)

An impatient BPEL developer who saw the diagram but did not understand its nuances might quickly whip up the process shown in Figure 2, a screen capture from the Oracle JDeveloper graphical BPEL editor for Oracle's BPEL Process Manager engine. The process uses a while activity to model iteration (the cycle symbol just below designComplete), switch for refinement (the question mark symbol below the cycle symbol), sequence for activities that in RAD appear to follow each other in succession (e.g., prepareDesignConcept is followed in sequence by enterDesignBrief), and partner links to show interactions between roles (this process has the perspective of the manager role, and DesignerRole is its partner).

If RAD were really that simple, there wouldn't be much point in talking about it. As it turns out, the naive BPEL process from Figure 2 is completely wrong! Recognizing this is the first step in understanding RAD.

Although the RAD diagram appears to have rigid control structures like loops, branches, and sequences, it's fundamentally adaptive. The person performing a role isn't bound to execute tasks in order, to stay on a particular branch, or to perform iterations of a loop in succession. The control flow implied by the diagram is merely a guide, an archetype. The manager might, for example, approve a design, then change his mind and add it to the rejection list, or prepare the design concept and enter the design brief simultaneously. Furthermore, the manager isn't bound to assess the designs one at a time, but may, for example, examine two similar designs at once, or defer the more complex designs and work on the easier ones first. The initial BPEL process has none of this flexibility.

As a contrast to the rigidity of the BPEL example, consider the ineffectual approach of Business Process Modeling Notation (BPMN), the leading standard process modeling notation, which advertises support for the modeling of ad hoc processes and, moreover, defines an overall mapping to BPEL. Figure 3 depicts how we might model in BPMN the manager role of the design process. The process (whose outer box is marked with a tilde, designating Ad Hoc) has six tasks, but there's no flow connecting them. Execution is up to the manager. The diagram has two shortcomings. First, unlike RAD, it provides no archetypal control flow. There's no explicit notion of iteration or refinement; it doesn't make explicit that there are multiple designs to assess, and that approved designs are treated differently than rejected designs. The second shortcoming is a showstopper: the diagram has no obvious mapping to BPEL; the BPMN specification admits that there can be no general mapping of ad hoc processes. In other words, we can't model the process very effectively, and we can't map it to BPEL anyway.

The BPMN diagram in Error! Reference source not found (see Figure 4) is much more expressive: it conveys archetypal control flow, but, being designated as ad hoc, allows the manager the flexibility to stray from the archetype. Unfortunately, this diagram is not valid BPMN (an ad hoc process may not have explicit sequence flow), and even if it were, the BPMN specification wouldn't provide a BPEL mapping for it. But let's do something audacious and adventurous: let's cheat and allow this enhanced BPMN notation; and let's demonstrate that this sort of notation REALLY CAN be mapped to BPEL!

Radish BPEL
Actually, our goal isn't to build pure conformant RAD in BPEL, but to embrace the spirit of RAD and build a RAD-ish BPEL, as if BPEL were a salad and we decided to toss in a pungent ingredient. There's nothing preposterous about this mixture. Every bank has jumped on the SOA bandwagon; BPEL or some similar BPM technology is in every bank's technology stack. But you'll find many other kinds of components too. Don't assume the architecture is accidental. Complex requirements necessitate curious technology choices. If you see RAD on BPEL, take the architect at face value when she explains: We're an SOA shop, but we need RAD for our most complex human work.

ACMEBank is no exception. Recently ACME built a straightforward disputes process on BPEL similar to the disputes processes of its competitors. But they're not done! ACME has discovered through analysis of past disputes cases that when "high-value" customers call in to report a dispute and are treated favorably, they are much more likely to accept sales offers. The psychological explanation is that disputable charges make customers feel anxious, and they see their bank as an ally in the battle against the merchant. If the customer has deep pockets, why not seize the opportunity to sell products? But the manner in which the disputes specialist should present offers is extremely subtle, and is difficult to model in vanilla BPEL. ACME gets enough disputes from high-value customers to think there's a business case to build complex RAD-style sales decision logic in BPEL.