I don’t know how I missed this, but I just spotted James‘ and Neil’s sponsored article on “Technology for Operational Decision Making”, which includes one or two references to Complex Event Processing and supporting concepts.

Although one should refrain from commenting on other vendor’s marketing material, this document does not directly reference the (non-event processing) sponsors except in an appendix - so hopefully they and the author’s won’t mind me making a few observations from the CEP perspective…

• I note the title is “Operational” DM, not “Enterprise”. Is this a play for some new jargon like “ODM“  (i.e. Operational Decision Management)? Kind of makes sense, in that (CEP supports) operational decisioning is a component of operational intelligence, and we don’t see such attention paid to non-operational (strategic, BMM-level) decisions - yet. [But I don't think the ontologists will be happy if someone goes with ODM!]
• James and Neil refer to EDA and event correlation (winning brownie points from the CEP crowd) supporting operational decisions. But then they lose it, referring to “real time data” (and not “events”) driving the decisions. In case anyone argues that we should view “events” are merely some subtype of “data”, recall that we generally don’t see equivalent terms like “data driven architecture” (vs EDA) and “data correlation” (vs event correlation) in an “operational” context.
• The “event store” is defined as existing to “allow events not otherwise persisted to be analyzed”. Well, presumably you wouldn’t store events just to discard them, would you… The usual (CEP) usage for “event store” is as a (high performance) event persistence layer to allow events to be used in time-based event patterns (and over multiple Event Processing Agents on a distributed system).
• “Click stream data” processing can probably be viewed (where the stream is analysed on the fly) as a specialist application of CEP (or more accurately, ESP). But there are other event streams that are of use in specific decisioning application domains, too…
• “Decisions-as-a-Service” - not that sounds like something out of a Monty Python skit: “You want to return that parrot? Hang on a mo, I have to log on to ‘the cloud’…” [I know they were thinking of the analytics part, but anyway...]
• “It is this cross organization, cross-channel consistency that is best achieved using a Service Oriented Architecture (i.e., web services designs).” Actually, that is the sweet spot for EDA and the event servers that provide CEP - any event, from any channel, any time. And with low latency.

So overall: its an interesting read, but doesn’t paint the full picture from the CEP state-of-the-art perspective - for example it would need some updating to cover TIBCO’s growing CEP customer use-cases in this area.

Disclosure: Neil has worked with the TIBCO Spotfire group in the past. And Paul is an ex-colleague of James…

Paul Barsch (from Teradata’s Marketing Department) recently posted a blog on the acceleration of decision-making speeds in business, which is likely a concern to all software companies that have grown up around, and are tied to, traditional data-driven business intelligence and reporting. Paul specifically references an MIT Technology Review article and the “science of event processing” allowing responses in milliseconds - in other words, extremely low latency decisions.

The challenge with (1) speedy decisions is (2) ensuring accuracy - including regulatory compliance and matching decisions to business strategy etc - while achieving (3) low cost - taking into account both development and deployment - per decision and decision type. Combining all 3 is tricky - you need event processing for the speed, capabilities like decision management / inference rules / visualization tools / analytics for accuracy, and poweful integrated software development techniques to lower costs. In the past IT teams have had to get by with reduced capabilities here, such as not really achieving  (1) through needing to rely on a traditional database with its inherant file access transaction times, along with a traditional application server doing simple sequential processing of events. But nonetheless it is this combination of speed / accuracy / cost that is driving the development of Complex Event Processing technologies such as:

• event-driven rule-based distributed event processing - typified by products like TIBCO BusinessEvents
• distributed data sources for high performance data access - typified by developments such as TIBCO ActiveSpaces
• high performance middleware solutions - a long-term TIBCO speciality with TIBCO EMS and Rendezvous.

Notes: see also JT’s ebizQ  comments on this blog posting.

One of the interesting attributes of rule-based systems (whether in complex event processing, decision services, or whatever) is the ability for end-users to maintain the rules separately from the IT development cycle. Rule-based development tools (TIBCO BusinessEvents included) typically allow for the hot-deployment of these changes - usually where process instances are updated with the new application logic in between transactions or events. This update process is both inevitable and a requirement when the underlying ontology or Business Object Model changes.

There is however a class of update that is less obtrusive, and can be managed simply by a rule update event. This is where the rule design pattern (or template) does not change, but the change is a create / update / delete operation on such a pattern instance, stored as an object or concept. Alternatively the update could simply be to rule instance metadata (for example, champion-challenger status, or active status, or effective date). In an Event-Driven Decision system, such update events are simply a new type of event to be processed, and would typically be created by some suitable Business User Interface (or automatically generated by some analytics system). Of course, rule maintenance events themselves should be validated by the rule engine prior to deployment, and other controls such as security and authentication may be required.

Of course, with event-driven rule maintenance one has to decide where the *record* of the current rule instances is to be stored - either in running rule system (for example, exploiting the distributed cache), or local to the user interface. Alternatively one can resort to tradition, treat the rule instances as data in a database, and update them via a simple 2-tier UI using database-imported concepts in the rule-based system…