Business rule execution: stateless/transactional, stateful/monitoring, or both?
Posted by Paul Vincent
TIBCO was recently invited to discuss the technology needs for a large rule-driven insurance risk management system. Interestingly, the specified requirements had nothing to do with CEP, and everything to do with traditional (stateless) business rules execution:
- replace an existing rule engine
- map existing rules to the new rule engine
- migrate to standardized server platforms.
So why would a rule-driven CEP engine even be considered for this problem? Lets take a look at some of the longer term needs of such an organization:
- exploit the huge amounts of operational data being collected
- increase straight-through-processing transaction rate, avoiding manual intervention
- move to more customer-centric, portfolio-based underwriting (rather than simply policy-based).
These don’t necessarily align best with conventional stateless rule services.
1. Business activity and business performance monitoring: direct feedback over time / time periods / regions / etc of which rules are used and which aren’t, and information on trends for different regions, policy types, take-up rates, etc. This requires monitoring large amounts of events over time, and is best done by correlating events directly in the rule engine.
2. Increased “Complex Rule Processing”: to automate more policy decisions, more rules are likely to be required on more “data”. Naturally, hitting a database with multiple transactions to get different views required for different decisions is going to be bad news for the rule server, development team, database administrators, and the database itself. Storing event-related information in situ (or transparently via a high performance distributed cache) would make complex rule processing easier to implement and (crucially) maintain.
3. Customer-centric (portfolio-based) view of policies: if a customer is acquiring overlapping policies, does the carrier want to know about it, or even let the customer know? Or if a customer has policies that have gaps, shouldn’t they/their insurance agent be informed? This again is easiest to achieve by maintaining state about the customer between transactions.
So it looks like stateful rule services, for monitoring business events wider than the current transactional (stateless) context, might be useful after all.
Notes:
CEP can also be used in insurance to support the standard insurance carrier’s investment activities, in areas like BAM such as for documentation track ‘n trace.
BAM, Complex Event Processing (CEP), Rules | 03 March 2008 |
6 Comments
Other Links to this Post
-
A post to replace a comment because Tibco can’t count… | Smart (Enough) Systems, the blog — March 4, 2008 @ 18:21
-
Behind the CEP curtain - it’s about time, not the cache « Commercial Intelligence — March 5, 2008 @ 09:46
RSS feed for comments on this post. TrackBack URI
By Paul Vincent, March 5, 2008 @ 00:55
Comments work using my external non-TIBCO ISP. Maybe it IS Complex Comment Processing in action?
By vincent, March 5, 2008 @ 01:07
James views items 2 and 3 above as “have a CEP engine what do I do with it” issues (ie solutions looking for a problem). Which means we need to blog more about CEP frameworks vs conventional traditional approaches to some of these problems (how CEP marries events, business rules, and persistence with analytics, against the expense of doing all these items separately, CEP and case-based reasoning, CEP versus BPM and case management in favor of customer management, etc).
By Paul Haley, March 5, 2008 @ 09:54
The bullets didn’t hit me at all, but hitting on the fundamentals in #1 really highlights why BRMS vendors need to move in your direction, but #2 is too much detail about technical battles that have yet to be waged to clear victory, imo. James and others have good content on #3, but I don’t see why you think it warrants a CEP/BRMS distinction. (Sounds like you want the whole enterprise in RAM and damn the join complexity!-)
By vincent, March 6, 2008 @ 08:19
Yes, we’ll have to elaborate further on points 2 and 3.
2. Complex rules often include references to more data (and in particular data analysis, stats etc) that of course can be delegated to a DBMS, but at a cost. This is where high performance cache comes in handy, to handle “deeper data”.
3. Wider views on customer / region / time-based policies benefits also from having the data “always available” - this is similar to 2 but “wider data”.
The main point here is that with stateful rules (as in, but not exclusively so, a rule-driven CEP engine), and a built-in OODB mechanism, means that I don’t need to have an SQL writer alongside every rule writer.