This post discusses the challenges involved in authoring business rules using the commercial and open source rules engines available in the market and how to bridge the gap by using a generic Rules Maintenance Application designed to work with any rules engine.
Business Rules Engines
There are several business rules engines available in the market. The market leaders are Blaze Advisor® from FICO® and ODM ® from IBM ®. These commercial rules engines have matured over the last 15 years and offer several advanced rules management features.
The use of open source rules engines like JBoss Rules ® is catching up fast. The open source rules engines offer exciting rules processing capabilities but their rules management features are still lagging behind the features offered by commercial rules engines like FICO Blaze Advisor ® and IBM ODM ®.
Business Rules Management Features
Commercial BRMS tools like Blaze Advisor and ODM provide advanced features to edit and maintain business rules by business users. The features include:
- Define Business Terms and Domain Values
- Rules Organization (in folders and rulesets)
- Rules Metaphors like Decision Tables, Decision Trees and Score Models
- Customizable Rules Metaphors
- Rules Versioning
- Migration of rules
- Rules Testing
- Authentication and Authorization features
Challenges in Adopting Business Rules Engines
The cost and complexity are the two main challenges involved in adopting commercial rules engines. The commercial rules engines can be expensive and require special training to be able to fully utilize their BRMS features. Creating custom rules maintenance applications require deep understanding of the template and repository management APIs of the BRMS tool used.
Open source rules engine – JBoss Rules eases the cost aspect, but the rules maintenance features are not at the same level as offered by commercial rules engines.
Rules Authoring in FICO Blaze Advisor ®
FICO’s Blaze Advisor® is the leading rules engine in the market with the most advanced and flexible features to create a user friendly rules maintenance application. The tool comes with a very powerful template architecture which can be used to create highly customized web based rules maintenance applications.
To create robust and powerful rules maintenance applications, the rules developer and the architect must be familiar with the Blaze Advisor’s template architecture. Understanding the complex template architecture is a big challenge. One needs to get formal training from FICO to be able fully utilize all the features of the tool.
Here is the list of typical BRMS features and the challenges involved in using them in Blaze Advisor:
|Define business terms||Business terms can be defined either at the BOM level or by using custom value list providers. Require training and experience to create custom providers for the templates.|
|Defining domain values||Domain values can be hard coded inside the value list providers or by creating a custom value list provider hooking up to an external repository of domain values.
Needs custom templates to allow business users to add domain values
|Rules organization (in folders and rulesets)||Rulesets and rules can be organized in folders easily.|
|Rules Metaphors like Decision tables, Decision Trees and Score Models||Uses Java Applets which are slow and cumbersome to use. Recent versions of Blaze Advisor has released better interface, but still slows down the performance when coding large decision tables|
|Customized Rules Metaphors||Require in depth knowledge and formal training of Blaze to be able to fully utilize all features of custom templates and providers|
|Versioning||Versioning feature available. Versioning must be enabled to the entire repository even though it is mostly needed at rules and rulesets level. Further, older version of instance files are linked with the most recent version of the corresponding template. This prevents viewing of older versions of rules that were created using a different version of rule template|
|Migration of rules||Migration of rules from one repository to another requires writing custom code. Requires heavy customization of the rules maintenance application if business users want to migrate rules themselves.|
|Rules Testing||Integrated rules testing was made available in recent releases. Requires heavy customization/training if business users want to create test cases. Not much user friendly interface. The test cases must be stored in the repository itself making rules repository bulky.|
|Authentication and Authorization||Customizable authentication and authorization framework is available which can be hooked up to any existing AA infrastructure.|
Rules Authoring in JBoss Rules ®
Authoring rules in JBoss Rules ® require low level understanding of Drools rules language syntax. The DSL feature provides some relief in hiding low level details, but creating DSL for each and every rule condition is overwhelming for rules developers and rules authors. Grouping rules in a rule flow group requires the rule author to key in the group name creating opportunities for mistakes. Managing domain values in a centralized location is another challenge.
|Define Business Terms||Defining business terms requires creating DSLs which can be overwhelming for a large project.|
|Defining Domain Values||Domain values can be specified in the DSL section, but there are several maintenance issues because the domain values must be created for each package (or ruleset) level. This creates lot of duplicate lists and is a maintenance nightmare, especially for medium to large sized projects.|
|Rules Organization||Packages must be created separately to neatly organize rules, but this causes duplicate items in the DSL library (see above)|
|Rules Metaphors||Decision tables are available in the form of Guided Editor. No export/import feature available. No Decision trees templates are available.|
|Customizable Rules Metaphors||DSLs can be created for customized rules entry, but DSL does not support any drop downs. DSLs can not be shared across packages.|
|Versioning||Versioning feature available. However, each save creates a new version causing unnecessary versions for each repository item|
|Rules Migration||Migration of rules from one repository to another requires writing custom code.
Requires heavy customization of the web front end if business users want to migrate rules themselves./td>
|Rules Testing||Testing feature available, but requires low level understanding of Drools to write technical test cases. Unsuitable for business users to create test and run cases.|
|Authentication and Authorization||Out of the box authorization feature is available.
Customizable authentication and authorization framework is available which can be hooked up to any existing AA infrastructure.
A simple easy to use web based Rules Maintenance Application which provides advanced rules authoring capabilities bridges the gap. With a desktop like web interface with capabilities to group rules in rulesets under hierarchical folders provides easy lookup for rules. Generic condition and action structures provide easy to author business rules using business terms coined by business users. A centralized domain values repository provides easy to maintain list of domain values lists. The rules are stored on a file system or a database for additional security in a rules engine agnostic format.
The rules entered in the generic RMA can be translated into commercial or open source rules engine’s native format by plug ins. The generated code can be compiled and deployed using native rules engine’s tools.
Using the generic RMA, reusable repository patterns and templates can be created and provided to the clients for rapid application development.
The following screen snap shots compare the look and feel of the rules entered using Drools and the Generic RMA.
Rules Authoring in Generic RMA
All product and company names are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.