EWA Systems - BRMS Rules Editor

EWA Systems' Rules Editor Features

The Rules Editor: EWA Systems' Complete Rules Editor
- Supports Multiple Rule Definition Languages: Define Rules How You Are Most Comfortable Improving Your Efficiency And Reducing Your Errors
  - Natural Language Interface: Business Users Define and Modify Their Own Rules. (See Demo Below)
  - Programming Languages: Use Java or Your Programming Language of Choice To Define Your Rules.
- Rule Validation: The Rule Wizard Pre-Validates Rules Minimizing Rule Definition Errors and Greatly Simplifying the Rule Definition Process.
- Rule Search: Searches Rules and Discovers Possible Rule Conflicts Before Deployment.
- Rule Flow: Conditional, Serial and Parallel Rule Flows Are Easily Captured By The EWA Systems' Rule Flow Interface.
- Complete Real-Time Rule Debug and Testing Environment: Create, Test and Optimize your RuleSets Prior to Deployment.

BRMS Rules Editor Natural Language Interface

The following demo shows how easy it is to define a condition inside EWA Systems' Rules Engine. As you build the condition, pieces which require further definition appear in red. Context-sensitive pull down menus guide the user through this definition process. To undo or change a portion of the condition, use an operator's "Clear" pull-down menu pick. At every step of the definition process, the validity of the rule is checked and displayed via the checkbox on the right of the condition.

EWA Systems' Natural Language Interface Demo (Writing a Rule Condition)

If this applet is not running in your browser, download the jar file and run it like an application. In most systems, just double-click on the jar file to run it.

In this demo, the user is building a condition to apply against a credit card application. So the context of this natural language interfaces contains parameters and variables that are pertainent to a credit card application.

Using typical rules engines in the financial industry, FICO scores would be tested against a minimum required FICO score which would be found via a decision table, which amounts to hundreds if not thousands of rules. In this case, two conditions would be made "Applicant's Zipcode equals a specific Zipcode or group of Zipcodes" and "Applicant's FICO score is greater than a specific number". These rules are made starting with the "Equals" or "Greater than" Functions, respectively, and then filling in the appropriate applicant parameter on one side and the constant value on the other. These thousands of rules can be handled dynamically and faster by using MetaRules™, which reduce all of these rules to a single rule, "Applicant's FICO is greater than model's minimum acceptable FICO score for the Applicant". This rule is created by selecting the "greater than" function, and filling in the applicant's FICO score on one side and the function for the FICO data-mining model on the other, specifying the applicant as the source of the model's parameters. Thousands of rules are reduced to just one reducing rule maintenance effort and increasing performance both in speed and accuracy of getting the desired business-goal result.

In an e-commerce situation, MetaRules™ simplifies and enables price/revenue optimization. Data Mining and optimization algorithms behind price and revenue optimization are accessible as functions, just like the FICO score model was available above. So rules like "Set price to the optimized price for the customer's shopping cart under the specified operational conditions". The model is updated in the background as additional offers, whether accepted or not, are offered. The advantage of this system is that fads or fraudulant circumstances are caught and dealt with earlier maximizing profits and minimizing costs.

Since the task of creating these seperately-encoded rules did not require as many technical hurdles, the creation of these rules could be shifted to the business analysts/managers who initially requested the changes where the cost of rule maintenance could be lessened. The idea was that the implementation chain would be further shortened, reducing errors in translation, and the usual engineering bottleneck could be avoided, further speeding the roll-out of the revised business policies. Since most business users are not analysts or engineers, many BRMS (including EWA Systems') implemented a natural language interface simplifying and removing the detailed math equations from rule creation. With technically-savvy business users who still interact with the BRMS technically using math equations, this reduced maintenance benefit is real. On the other hand, this benefit is debateable when attempted with non-technical business users who use the natural language interface. The source of the problem is that the natural language interface used by business users is just as likely to interpret a rule correctly as incorrectly. These badly formed rules are hopefully caught later in the debug/testing stage which needs to be introduced in order to find them.