My colleague, Paul, got lots of… let’s call it, “feedback” regarding his post on the impending demise of the standalone Business Rule Engine (BRE) Market. It seems there are lots of folks out there who feel quite passionate about the subject, so I thought I would continue, albeit from a different angle and relate it back to the CEP and BusinessEvents for comparison.

So… taking my cue from David Letterman and with a tip o’ the hat to Paul, here are the:

Top 10 reasons why TIBCO BusinessEvents (BE) beats a simple Business Rule Engine + JMS layer (remember, no wagering please)

10. BE is Standards-based (for concept/class models, state models, rule models etc)

9. BE requires no app server or RDBMS (for lower cost, and quicker deployment)

8. BE provides multiple options to extend to other event channel types (for flexible complex event processing)

7. BE has Rule / decision management (for business control of software services)

6. BE takes a co-operative agent approach (for co-operating components and event processing services)

5. BE supports high scalability (for parallelizing applications and eXtreme Transaction Processing)

4. BE supports queries as well as rules (for dynamic facts)

3. BE supports State Models as well as rules (for case management, entity lifecycles, etc)

2. BE is designed as a stateful approach (for saving temporal information between messages)

and the number 1 reason is…

1. Real-time event-driven support already built in to the BE rule engine (for efficient Event-Driven Architecture use)

Apart from classic Complex Event Processing (event abstraction across time, source, type and attribute) applications for situation-awareness type problems, TIBCO BusinessEvents is also finding uses in sophisticated / dynamic event-driven processes that cannot be fitted easily / entirely within representations such as BPMN, BPEL, etc. Of course, there are many other ways of deploying complex processes across services: consider the wsper project, for example, that aims to exploit and combine WSDL, SCA and BPEL [*1]. Their provided example, interestingly, also maps very nicely onto an EDA using a combination of state model + rules, which have the added advantage of declarative rules that can handle any out-of-process (i.e. complex exception) event [*2] - something BPEL can’t handle [*3].

Notes:

[1] I don’t agree with the wsper metamodel (documented here), which defines an “event” as a subclass of operation, and “state” as an attribute only of event. This seems far too restrictive, although it might fit wsper’s SOA perspective.

[2] Consider the (unfortunate) case whereby, in the supplied HR example, your job candidate “expires” (RIP) in the middle of this process.  You would not want your business process to attempt communication with the dead - you need some flexible, declarative, cross-process exception mechanism. This is typically handled by a “rule”…

[3] On the topic of BPEL we also note one effort looking at retrofitting “event processing” constructs into BPEL. Why not event-driven COBOL, too, one wonders? A more interesting project would surely be standardize the event modeling level (e.g. extend BPMN for CEP, or map CEP to BPDM), rather than trying to force event processing into BPEL (insert here visions of pigs in party frocks). No doubt this topic will come up for some (lively) discussion at the EPTS meeting on CEP standards next month…

A few BI-related posts show how CEP and CEP-related thinking is starting to trickle into conventional thinking on Business Intelligence.

First off, Intelligent Enterprise reports on some solutions to the problems of using data warehouses for real-time BI. Note that the solutions offered include Event Stream Processing (although why Forrester references ESP instead of CEP is a mystery only known to the analyst who authored this report - unless there is an expectation that just simple streamed correlations can be done in real-time analytics?) [*1].

Secondly,  Jerry Held relates in 2 articles how cloud computing will “save the day” for BI. In a nutshell, Jerry’s hypothesis is that a lack of cheap distributed computing resources are what is holding back BI, and clouds of massively parallel operations on huge datasets will be BI’s saviours. Jerry, methinks, is ahead of his time, as I can’t see data warehouses migrating to the clouds without large doses of security provisions and even cheaper bandwidth. But certainly the idea of highly parallel and scalable event+data processing operations is here today…

Notes:

[1] IE also suggests “informational fabric” for real-time BI. This is “the real-time in memory, distributed caching infrastructure embedded in a service-oriented architecture or enterprise service bus for analytic and transactional apps.” This is also CEP-relevant - the TIBCO BusinessEvents CEP platform includes such a data grid.

Recently a customer commented that some manager had complained about TIBCO BusinessEvents not appearing on their favorite analyst vendor’s grid for Business Rule Engines. Ignoring any quips regarding the true value of such analyst quadrants, lets look at this in more detail:

1. Some analysts (like Gartner) have now put their Business Rule Engine market analyses under the general section of “Business Process Management”. This is because conventionally, BREs and their associated BRMSs are used to define automated decision services for business processes. Indeed, the last Gartner MQ on BREs dates back to 2005, and almost everyone who was on the “leader” side of the board has been acquired or renamed; Forrester has more recent analyses but only on “traditional” BREs (as invoked from BPMSs). [*1]
2. Business Rule Engines are applicable to pretty much any process that requires decisions - whether controlling manual processes (for BPM) or automated processes like CEP.
3. Most analysts are still gearing up to cover CEP and the relationships between events, processes, services, and decisions. BRE analysts can’t know everything that is going on in software technology.

So, does a “BRE” market really exist any more? BREs are a software technology used for automating decisions, and there is certainly a large market for decision automation and management; in TIBCO, for example, the TIBCO BusinessEvents rule engine is also embedded in our MDM and SOA SLA [*2] products as part of our Business Optimization suite.

So the BRE market is not just part of the “BPM” market, but part of the wider business optimization market. And the BRE “market” is not ending, its just evolving.

Notes

[1] In the category of “fascinating yet bizarre” commentaries on the BPM-BRE marketplace: a BPM vendor who has partnered with a BRE vendor, now claiming that the BRE market is stagnant and that in fact they are competitors …

[2] Also commented on recently by James Taylor.

… are, according to Mike Gilpin, events, processes, services and information. How does CEP fit in this? Is it the Fifth Element?

No, but CEP can be described in these terms as…

• a technology for automated processes
• for the continuous processing of events
• made up of 1 or more event-driven event-processing services
• about providing operational information to enable businesses to make (automated or manual) real-time decisions.