… which came from a prospective customer who had based their research on top analyst Woodman’s famous Ripple report on Business Rule Engines. Which TIBCO didn’t participate in. So obviously we don’t have a rule engine (despite a 1-second Google returning over 17,ooo hits…).

To be fair, though, you won’t see “rule engine” under the TIBCO products list on the main web page. But then you won’t find “XML Processor” or “Application Server” in that product classification either…

So:

• if you are a “top analyst”, note TIBCO has a rules engine. And a rule (decision) management system. And an analytics suite. Really.
• if you are a “rule engine customer”, you might want to include TIBCO on your evaluation list…

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…