Decision Services in CEP?
Posted by Paul Vincent
One of the more obvious up-and-coming IT “best practices” is the area of “decision management” – as evangelised by James Taylor at Smart Enough Systems – which postulates that separating and managing decisions is as important as managing business processes. In a “conventional event processing” or synchronous SOA world, this means separate “decision services” invoked to make important decisions during automated processes, or prior to BPMN flow branches – with said decision services defined through entities like declarative business rules, decision tables, or outputs from predictive analytic models. But in an asynchronous EDA or complex event processing world, are “decision services” still valid?
Well, if you already have SOA services defined of any kind, including decision services, then a CEP system can of course invoke / utilize / exploit said services, for example based on the detection of complex events. But in the context of continuous event monitoring, where decisions are embedded along with data and trending statistics, it may not make sense to rely on external (and sometimes relatively high-latency) distributed decision services - especially when the decisions are closely related to the event processing. This means that instead of “decision services” we are talking about event processing elements that embed decisions - and ideally, managed decisions. So instead of “decision services” we can use the term event processing “decision elements”, or in a distributed CEP system, “decision agents”.
From a technology perspective, decision services and decision agents can share many components and ideas – business rules management and business user interface (for business control of the decisions), production rules engine (for efficient execution of declarative rule statements), etc etc. The difference is basicly between synchronous parameterised decision services versus asynchronous event-driven decision agents.
On the topic of the “analytical models” being used to define rules or rule parameters, these can be used to input production rules into a CEP-based “decision agent” just as well as a (say, web services) “decision service”. The main interesting delta here is the middle ground of “operational intelligence” as afforded by CEP systems with their event stores in-situ, continuously running “process refinement” rules as events occur (with such “process refinement” rules being “metarules”, predictive analytics expert systems, advanced statistical trend functions, etc). An obvious example here would be the use of sophisticated analytical functions such as TIBCO S+ functions within a “decision monitoring agent” that updates the decision agent rules (and rule parameters) in real-time.
Notes:
Although obviously one can consider TIBCO BusinessEvents as a source for decision agents and decision monitoring agents, you can also consider the “synchronous service invocation” pattern as a subset of “asynchronous agent invocation”. Which means that TIBCO BusinessEvents is equally adept running as a conventional decision service, for example to do business rule execution in a TIBCO BusinessWorks application (a relatively common use case).
Complex Event Processing (CEP), Rules | 08 October 2008 |
4 Comments
Other Links to this Post
-
Decision Services, Decision Agents and Event Processing » Smart (Enough) Systems, the blog — October 13, 2008 @ 16:48
RSS feed for comments on this post. TrackBack URI
By Neil Raden, October 22, 2008 @ 15:00
Paul,
This is a lot to think about. I guess I’d worry about the “embedded” aspect because one of the central principles in EDM is transparency of the rules, to facilitate modification and reuse by domain experts. Does your scheme allow for this? I’m not sure.
Will you be at the EDM Summit James Taylor and I are putting on next week in Orlando? I would like to talk to you about this as well my topic for the week, Process Intelligence and the end of the Domain/Reference Models.
-Neil Raden
By vincent, October 28, 2008 @ 02:48
Hi Neil - of course, “embedded” is a different dimension from “transparent”. In a conventional rule / decision service, you can’t see the compiled rules actually running* in the service whether or not it is a web service or a CEP process. The important things are:
- separation as a design principle
- separation in the model-driven software engineering process (which may be IT controlled through a BRMS).
* Caveat:some rule tools let you run a debugger against a running process to actually “look inside”. TIBCO BusinessEvents, for example, lets you create instrumentation events as rules fire so you can monitor such rules in a more generic way and inspect only rules of interest.
PS: see you at BRForum
By vincent, February 12, 2009 @ 12:27
Opher at IBM Labs added to the commentary on Decision Agents at http://epthinking.blogspot.com/2009/01/on-decision-agents.html, with further thoughts by James T at http://www.ebizq.net/blogs/decision_management/2009/02/event_processing_thinking_on_d.php .