Rule and event-driven business process M&A

On the heels of IBM’s acquisition of Lombardi comes Progress Software’s acquisition of Savvion.  The salient similarities are that IBM is adding BPM applications to its middleware stack as is Progress, at least with regard to its enterprise service bus offerings.  More interesting is the relationship between Progress’ complex event processing software and Savvion’s BPM.  Also of note is the vendor-provided integration of JBOSS Rules within Savvion versus the unrealized potential of IBM’s Ilog with respect to Lombardi.

We’ve written several times about the artificial distinction between CEP and BPM, their inevitable convergence, and the immature integration of business rules with business process management and event processing that inhibits knowledge-driven governance and decisioning. Continue reading “Rule and event-driven business process M&A”

In the names of CEP and BPM

Have you heard the one about how to drive BPM people crazy? 

Ask them the question that drives CEP people crazy!

Last fall, at the RuleML conference in Orlando, was the first time I heard a consensus that a standard ontology of events and processes was sorely needed.  I’ve had a number of discussions with others on this over the interim until today’s posts by Paul Vincent, summing up an OMG meeting in Washington, DC, and Sandy Kelmsley’s comments on a survey of 590 business process modeling notation users.   Continue reading “In the names of CEP and BPM”

Behind the CEP curtain – it’s about time, not the cache

TIBCO is the CEP vendor most focused on the market for business rules, as reflected in Paul Vincent’s post here.  Although I agree with Paul that rule vendors are not currently offering enough in terms of support for long-running processes, the conclusions that he draws in favor of considering a CEP alternative to a BRMS are not compelling yet.

Paul said that rules don’t address the following that are addressed by CEP:

  1. BAM (business activity monitoring) and the other BPM (business performance management)
  2. Complex-rule processing
  3. Customer-centric (portfolio-based) decisions / policies

I am sure Paul was just being flippant, but you may notice that there is a bit of a war going on between CEP, BPM and rules right now.  Continue reading “Behind the CEP curtain – it’s about time, not the cache”

CEP crossing the chasm into BPM by way of BRMS

Complex event processing (CEP) software handles many low-level events to recognize a high-level event that triggers a business process.  Since many business processes do not consider low-level data events, BPM may not seem to need event processing.  On the other hand, event processing would not be relevant at all if it did not occasionally trigger a business process or decision.  In other words, it appears that:

  • CEP requires BPM but
  • BPM does not require CEP

The first point is market limiting for CEP vendors.  Fortunately for CEP vendors, however, most BPM does require event-processing, however complex.  In fact, event processing is perhaps the greatest weakness of current BPM systems (BPMS) and business rules management systems (BRMS), as discussed further below. Continue reading “CEP crossing the chasm into BPM by way of BRMS”

Process vs. Decisions

In comments to a recent post concerning the acquisition of Haley Systems by Ruleburst, James Taylor suggested that a “decision-centric” perspective is necessary for business rules to become mainstream.  In subsequent correspondence, I questioned whether fixating on decisions would achieve his objectives for enterprise decision management.   EDM hopes to integrate business intelligence (e.g., predictive analytics) with point decision making so as to improve decision making over time.  This is a natural step beyond the typical point decision making application of business rules, such as in a stateless web service that returns a simple decision, such as a score, price or simple yes/no.  But it is a narrow perspective on the broader confusion between business rules and business process that has been holding back the mainstream.

For years, smart people have been searching for a razor to determine what logic they should “code” in process versus as rules (e.g., using a BRMS versus their BPM platform).  At first glance, the decision-centric approach seems to have the answer.  Simply put a decision node in your business process diagram and let the BPM tool orchestrate the decision implemented as a stateless web service! 

Unfortunately, this alluring answer is all too often inadequate or impractical.  The business rule vendor has effectively transfered responsibility for managing state (i.e., information collection and provisioning) into the business process diagram and orchestration tools – or code.  The result is implementation complexity, limited user communities, cost overruns and failures.  That will certainly hold back mainstreaming a bit!

A better answer is coming.  Complex event processing anticipates that business processes and decision making can be stateful, as Paul Vincent explains briefly but well here.  When CEP is supported by knowledge capture, management and automation tools such as the better BRMSystems provide, the lines between process specification and decision specification will further blur beyond the adequacy of the decision-centric advisory.   Expect this to happen in 2008.