JT has posted his view on rules and decisions and how they relate. Given that James talks more about services than events, I thought it would be worth reviewing his post from both a Complex Event Processing and a TIBCO BusinessEvents event processing platform perspective.
[Caveat: we presented another view of decisions vs rules at last year’s RuleML conference – and I don’t think anything has changed. FYI RuleML09 is also being advertised as relevant to the CEP community…].
“Decision Services:
- Support business processes by making the business decisions that allow a process to continue
- Support event processing systems by adding business decisions to event correlation decisions (they are often called Decision Agents in this context)
- Allow crucial and high-maintenance parts of legacy enterprise applications to be externalized for reuse and agility
- Can be plugged into a variety of systems using Enterprise Service Bus approaches”
Complex event processing / event correlation (etc) can be intrinsically interwoven with business decisions; businesses may decide when some pattern of events is a “complex event”. For example, businesses may determine how they classify a fraud event, interpret whether a SLA is breached, and when and how to respond to these events. Such decisions may be interlinked, and therefore worthy of executing in the same runtime environment (for performance) but be managed separately (for management efficiency).
Interestingly, TIBCO BusinessEvents fulfils all the above “decision service” criteria. While at the macro level an event processing application is a “service”, the usual association of “service” in IT to request-reply synchronous (web etc) interfaces means it is probably not the best term to use. Maybe as a “business service” perhaps, to indicate the utility of some IT application; but frankly if any IT application is *not* providing some business service, what’s its purpose?
JT goes on:
“A decision service has some critical characteristics:
- Behavior understandable to the business
After all we are talking about a “business decision” here so the business had better be able to verify exactly what is going on inside - Supports rapid iteration without disruption
Business decisions change all the time so a decision service has to be both flexible and designed for this change - Integrates historical data
Business decisions are increasingly made “by the numbers” with much reference to historical data. Decision Services need a similar ability to use historical data, and trends/insight extrapolated from it. - Expects multi-channel use
While this is largely covered by the standard items it is worth noting as it means that VERY different kinds of applications will use the service – everything from ATMs and SmartPhones to Call Center applications and Bill Printing. - Manages exceptions well
Not only should it respond sensibly when it cannot decide, it should ensure that enough context is returned as to why it could not decide to assist a manual process - Must explain its execution
Many decisions must demonstrate compliance or conformance with policy. Any decision service must be able to log exactly how it decided and that information must be accessible to non-technical users”
All the above could well be requirements for any application component, of course. From a CEP perspective:
1 and 2: Model-driven engineering development tools to ensure business analysts can review how event processing elements are constructed and enable “rapid change”.
3: CEP systems incorporate event histories for time-based event patterns, so there is usually good support for “short term” historical data at least.
4: Event-driven systems can be as oblivious as needed on the source of events (although actually that might be interesting data for event processing metrics and KPIs).
5 and 6: Exceptions such as “missing events” or “unusual event patterns” are of course easy to stupilate in CEP systems; likewise “explanations” can simply be output events as decisions are made (although for performance reasons, we usually want to exploit the BAM-type features of CEP to aggregate this information to make it more useful).
From a TIBCO BusinessEvents perspective:
1. & 2: The use of standard models like UML State Diagrams, and Decision Tables, ensures that business visibility and development is catered for. Nonetheless, much of the CEP development process requires an understanding of boolean logic, production rules, queries, events and XML processing – the domain of the professional IT developer and analyst. Mind you, the same is true for the BRMS technologies James normally refers to – rule maintenance is a subset of a general and sometimes complex application development process.
3. BusinessEvents also incorporates its own event store (via a distributed OO cache) for event histories, necessary to avoid the cost of RDBMS transactions, although there is still a database interface if required.
4. BusinessEvents supports multiple channel types: by default it comes out of the box with RV and EMS (JMS). Of course, these are event channels, versus business interface channels, but the same message applies: if your channel can output a standard message, it can be read by BusinessEvents…
5. and 6: Decision logic exceptions can be handled in several ways: for example, use a state to describe that some complex event has NOT been detected, and what to do about it. One interesting facet in BusinessEvents Decision Tables is the availability of an “exception table”, as a detailed subtable for exceptions you don’t want to clutter your main table with. Explanations can be done through programming log outputs or, more likely, using scorecards to aggregate interesting information on behaviors.
“A multi-rule set decision typically has a decision flow (often called a rule flow by vendors) that lay out the steps involved in a decision, the branches and the loops and map the steps to specific rule sets. …This allows multiple decisions, for instance, to use customer segmentation rules as part of the decision without forcing a call to a decision service for customer segmentation. “
There are 2 main ways to define orchestrations: flow diagrams and declarative rules. The former are easier to read but don’t scale well with complexity. The latter may be more efficient but do not guarantee a completed “flow”. CEP tools tend to use one or other…
In BusinessEvents, we use State Models for a lifecycle of something like a decision process, or production rules to manage when to invoke a decision based on certain event and data patterns – in other words, the best of both worlds (as we see it!).
“Because rule sets are coherent sets of rules on a single topic, they typically have an obvious business owner – an individual or a group. This allows a clear separation of rule management (by rule set) from rule execution (by decision) – there is not one rule maintenance environment for each decision but one for each set of rules. This allows decisions to use rules owned by multiple parts of the business, something that is important as legal, customer service, marketing and product could all easily have rules that contribute to a decision. Models too can be injected into these decisions in a similar fashion as shown.”
Decision management is really a separate, if overlapping, topic to CEP: some event filtering and abstracting decisions may need to be maintained by the business, but others probably won’t.
In TIBCO BusinessEvents, we use a separate business application – the Decision Manager – to maintain decision (tables) under an event-driven workflow…
James summarizes with:
- “We separate decisions from processes, systems and events so they can be identified and managed explicitly
- We manage the rules for those decisions as coherent rule sets, each with a singular focus and common purpose
- The management of these rule sets is handled by those who are responsible for the source of those rules – legal documents, company policy, marketing strategy, call center expertise and so on”
Of course, decisions are intrinsically tied to events and processes in systems: James means the decisions are managed and maintained separately. Whether the “decision service” is a separate web service or an in-process function is neither here nor there, provided it can be accessed and updated separately.
Overall, CEP technology can be seen as a means to deliver “decision services” (or preferably: a means to serve event-driven decisions), subject to the availability of relevant business decision management tools (of the type in BRMSs or Business Events Decision Manager).
