EDA and SOA Myth #5: Do BPM Before BAM

In a recent tour of Asia Pacific, I met with the lead Gartner Analyst in Japan, Kimihiko Iijima, who told me that, in Japan, companies were "bypassing BPM and moving directly to BAM" as a way to demonstrate the business value of their investment in service oriented architecture (SOA).  Rather than unify their business process management in a traditional BPM tool, in Japan, companies are directly implementing event processing (CEP) tools that are integrated with BAM dashboards to process events from a variety of sources, including processes that represent a structured business process. 

Why skip the BPM?  Because BAM tools process events from a variety of sources, not just a business process flow.  Business process flow is one thing, but the integration and analysis of events from applications, technical infrastructure, databases, and even automation devices like kiosks or RFID readers is intrinsic to pure BAM tools, and is not common with BPM.

One example of such an application is shown here, where a traditional business process flow that manages mortgages is shown.  CEP allows this application to monitor, analyze, and act on this flow and ask questions like: "when the time between the "assign coordinator" and "acknowledge" phase of the business process is greater than 10 minutes, then alert the coordination manager with an alert."  CEP provides a flexible model to express these rules on top of a business process flow.

Some argue that BAM is simply an extension of BPM, or, worse, that BAM and BPM are converging (Myth #3).  In Japan, Gartner's seeing this another way, and we see it differently as well - that CEP and BAM, when combined, can provide a higher level of intelligence, more rich and complete than a unified BPM environment where input comes from a variety of sources, not just a BPM tool.

Comments

[Jack van Hoof]

Nice Posting, Mark. I know it depends on definition, but perhaps it's valid to think of BAM relating to CEP as BPM relating to SOA. BAM and CEP are more about state, while BPM and SOA are more about transition.

[Rob Eamon]

I agree with Jack that BAM is about state. To further refine, I'd offer that BAM is about, at least in part, understanding past states (e.g. today's transaction counts are 2 standard deviations below normal for this time of day) and using them to possibly predict the future (e.g. critical alert--nominal transaction threshold exceeded, possible system degradation in x minutes at current levels).

[Ismail Ari]

If you don't need complex application logic to handle events and integration into multiple channels (email, web, mobile), then you can surely skip BPM and layer BAM on CEP as some Japanese companies were doing. BPM ultimately creates another tier in the path, which can affect performance and scalability. However, some applications will need the flexibility and extensiblity that workflows+rules (e.g. Microsoft Biztalk BPM and Rule Engine) provide for event handling and rich channel integration. We made some research about this topic in 2007 and posted an HP Labs tech report at:
http://www.hpl.hp.com/techreports/2007/HPL-2007-176.pdf