Separating BPM and SOA Processes : Example-Process for Handling Credit Card Disputes

The running example in this article is the disputes process for fictional ACMEBank. The process controls how ACMEBank handles complaints over charges raised by its VISA card holders. The process has three stages:

1. The Capture Stage: The customer submits a dispute over one of various channels (call center, web, email, mail, or fax) to ACMEBank. The bank makes a quick determination of whether to reject the dispute outright (for example, because it was not submitted within 60 days of its posted date), write it off (for example, because the dollar amount of the transaction is below a certain threshold), request supporting documentation (for example, receipts) from the customer, or pass it to one of the bank's disputes specialists for further investigation. At any time during this stage the customer may cancel the dispute. The goal of this stage is either to capture the dispute completely or to dispense with it.

2. The Investigation Stage: The dispute specialist examines the fully-captured dispute, and may reject it, write it off, proceed with a chargeback (that is, take the disputed amount back from the merchant), or request a sales draft from the merchant to investigate its validity (and ask the customer for clarification if the draft appears valid). The happy path culminates in a chargeback decision.

3. The Chargeback Stage: ACMEBank charges back the transaction and credits the customer's account. The merchant bank may, in turn, accept the chargeback or represent the transaction (that is, present the charge again), at which point an ACMEBank disputes specialist determines whether to charge back a second time, write off, or reject. In rare cases, the dispute is brought to arbitration before the VISA association.

The next figure shows this process in flowchart form.

Assuredly, it's not a trivial flow, but the logic is not difficult. The numbers in the figure trace through a typical scenario, in which customer submits the dispute, ACME's operations requests further documentation, the customer provides it, ACME charges back the transaction, and the merchant agrees to the chargeback. The steps are as follows:

1. The customer submits the dispute.

2. The Capturing stage begins. ACME's operations staff picks up the dispute for review.

3. Operations decides that it requires documentation from the customer.

4. The disputes process forwards this documentation request to the customer.

5. The customer responds with documentation.

6. Operations picks up the dispute for a second review.

7. Operations indicates that the dispute is now fully captured.

8. Operations picks up the dispute to begin the Investigation stage.

9. Operations decides to go ahead with chargeback.

10. The disputes process, commencing the Charging Back stage, credits the customer's account and sends a chargeback notification to the merchant.

11. The merchant accepts the credit request.

12. The disputes process notifies the customer that the dispute is complete and the customer has won.

The following table describes the purpose of each activity, identifies the role that performs it, and indicates whether it is a call or an inbound event.

Name	Type	Role	Description
Cust Submits	Event	Customer	The customer submits a dispute to ACMEBank.
Cust Cancels	Event	Customer	The customer cancels the dispute.
Cust Updates	Event	Customer	The customer attaches new information to the dispute (for example, receipts).
Send Cust Update Req	Call	Customer	The dispute process prompts the customer to provide additional information for the dispute.
Send Cust Final Outcome	Call	Customer	The disputes process informs the customer that the dispute processing has completed.
Send Conditional Credit	Call	Customer	The disputes process informs the customer that it has conditionally credited the customer's account for the amount disputed. If the dispute is ultimately decided in the merchant's favor, the credit is removed.
Ops Rejects	Event	Operations	Operations rejects the dispute
Ops Writes Off	Event	Operations	Operations writes off the dispute (that is, it credits the customer without attempting to recover funds from the merchant).
Ops Requests More Docs, Ops Requests Draft	Event	Operations	Operations, after reviewing the dispute, requires more documentation from either the customer or the merchant.
Ops Declares Captured	Event	Operations	Operations decides that enough information has been collected for the dispute to enter the investigation stage.
Ops OK to Chargeback	Event	Operations	Operations decides enough investigation has been done to warrant proceeding with a chargeback.
Assign Ops Review	Call	Operations	The disputes process assigns operations to review the dispute in its current state.
Assign Ops Cancel	Call	Operations	The disputes process notifies operations that the customer has cancelled the dispute.
Assign Ops Close	Call	Operations	The disputes process prompts operations to close off the dispute. The dispute has completed for a reason that was not caused by operations itself. Possible causes are timeouts or an arbitration ruling.
Merchant Credits	Event	Net Merchant Bank	The merchant accepts the chargeback.
Merchant Represents	Event	Net Merchant Bank	The merchant rejects the chargeback and represents the disputed transaction.
Send Merchant Chargeback	Call	Net Merchant Bank	The disputes process charges back the disputed transaction from the merchant bank.
Timeout	Event	None	The disputes process did not receive the event it expected within a certain time interval.

There are three roles in this process: the customer, operations, and the dispute network, which serves as an interface to merchants, merchant banks, and the VISA card association. Communications are bi-directional: the process can call (or send a message to) a role and can receive events from a role. The process uses a naming convention of send X (for example, Send Cust Update Req) for calls to the customer and dispute network roles, but assign X (for example, Assign Ops Review) for operations calls. Operations is a human role (its activities are performed by a group of back-office users), so it makes sense that the process assigns work to it. The customer and dispute network roles are automated systems from the perspective of the disputes process; calling them means sending messages, not assigning work.

The disputes process thus has a mixture of BPM and SOA responsibilities. The operations' interface requires a BPM platform, but the customer and dispute network interfaces are best managed by an SOA platform. We need to split the process, then, into SOA and BPM pieces. There are two approaches to this:

1. Model the overall flow as a BPM process, but have it use small SOA processes to manage interactions with the customer and network. The next figure shows the BPM process, with SOA pieces indicated in thick-bordered circles. The strategy, is for the BPM process to use smaller SOA processes to call the customer and dispute network roles, and let SOA processes listen for events from the roles and trigger the BPM process when they arrive. This approach requires a BPM tool that supports calling and receiving events from SOA processes.
   

   

2. Model the overall flow as an SOA orchestration process, but have it use small BPM processes to handle the operations' tasks, as shown in the next figure. The strategy is for the SOA process to treat the operations interface as an automated interface, treating work assignment as a call to a workflow system, and the completion of work as an event back from the workflow system. The SOA process leaves BPM-specific details, such as the logic of task assignment and escalation, to the workflow system. We assume that the SOA tool has an interface to invoke and receive events from the BPM platform. BEA's Weblogic Integration is such a platform, as we demonstrate next.

Both approaches are valid in this case. The SOA process has about as many circles as the BPM process, which suggests that the SOA process has about as many BPM dependencies as the BPM process has SOA dependencies. Counting circles is a useful rule of thumb. As we discussed in the ‘Tips' section earlier, there are additional factors that influence the design choices concerning SOA and BPM.