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

1/17/2012 11:38:08 AM
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.

  •  Separating BPM and SOA Processes : The Model Stack & Design Tips on Separating BPM and SOA
  •  BizTalk 2006 : Editing and Resubmitting Suspended Messages (part 2) - Pseudo-Walkthrough to Perform Edits and Resubmits
  •  BizTalk 2006 : Editing and Resubmitting Suspended Messages (part 1)
  •  BizTalk 2006 : Building a Resequencing Aggregator
  •  Windows System Programming : Listing Registry Keys and Contents
  •  Windows System Programming : Registry Management
  •  .NET Debugging : PowerDbg (part 2) - Send-PowerDbgCommand & Extending PowerDbg
  •  .NET Debugging : PowerDbg (part 1) - Installing PowerDbg & Analyze-PowerDbgThreads
  •  Sharepoint 2010 : Business Connectivity Services Deployment Types (part 3) - Configure Indexing & Performing a Search
  •  Sharepoint 2010 : Business Connectivity Services Deployment Types (part 2) - Creating a Profile Page to Display BCS Results
  •  Sharepoint 2010 : Business Connectivity Services Deployment Types (part 1) - Code-Based Solutions
  •  Sharepoint 2010 : BCS Architecture - Presentation & Core Components
  •  Collaborating via Web-Based Communication Tools : Evaluating Instant Messaging Services
  •  Collaborating via Web-Based Communication Tools : Evaluating Web Mail Services
  •  Developing the SAP Data Center : Data Center Physical Requirements
  •  Developing the SAP Data Center : Introducing the SAP Data Center
  •  Inventory of Broadband Phone Services
  •  Parallel Programming : Task Relationships (part 2) - Parent and Child Tasks
  •  Parallel Programming : Task Relationships (part 1) - Continuation Tasks
  •  BizTalk 2006 : Handling Ordered Delivery
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)