Why Is Rule Management Technology "Revolutionary" (Part 2)
In Part I we discussed why rules management technology can be considered revolutionary and we identified some of the capabilities needed in a rules management technology for it to be successful. These were:
- The ability to use and refine existing object/data models.
- The ability to interoperate with existing data sources.
- Sophisticated rule syntax
- Testing and management tools
- The ability to generate rule maintenance applications
- Frameworks for reuse
- Scalable deployment
Let's take each of these in turn and consider in some detail each of these functional requirements.
1. The ability to use and refine existing object/data models.
These models might be expressed in terms of Java classes, CORBA objects, relational models, XML schemas or any number of other formats. If rules management technology is going to be effective it must be integrated with these existing models. You must be able to "import" the designs of these models and allow rules to be specified against them. It must also allow such models to be extended to support temporary properties and objects required by the rule service. It must also allow lists of allowed values or other data-driven elements to be identified in existing systems and databases so that rules can be constrained using existing data.
Blaze Advisor from FairIsaac, for example, provides JDBC, XML, Java, and COM class import wizards with automatic data type mapping. Registering the design of these classes within the rules management technology allows rule services to be designed against them. Rules need to be able to include conditions that check property values or method results and actions that set property values in an object or data values in a relational table.
It should also be possible to add additional properties or to provide aliases when column table names or class method names are awkward or inconsistent. Blaze Advisor provides this capability at import time. This not only improves readability of the rules, but can be essential in avoiding confusion when data is being manipulated from several systems where different object naming conventions may conflict.
Since calculations and decisions made by a rule service commonly require storage in an object (such as "customer" or "visitor") the ability to add additional class properties is crucial. Additional classes and "temporary" (or "dynamic") objects must be defined so that the rule services can function effectively. These objects are sometimes needed by the rule services to store received data and calculated object property values. As an example, a rule service deployed in support of an insurance company's selling processes might need a temporary object called "policy application." It isn't a policy yet. It is a potential policy built up via an interactive dialog process. At the end of the dialog, and after all rules have been executed, the prospect and the insurance company may both say "yes." This is when a permanent database record will be created. The temporary "policy application" is not stored.
Throughout all of this, we need to ensue that this flexible access does not come at the expense of performance. At runtime, access to these objects must not involve a mapping layer or slow translation from one format to another. As with Blaze Advisor, the rules technology must access these objects directly.
2. The ability to interoperate with existing data sources.
Once designed, an effective rules management technology must allow data to be read in from any number of existing data sources so that this information can be used in rule services. It must also allow the rule service to update the external data according to the rules that you have established. This must be true regardless of how the data is currently stored and accessed (XML, relational databases, other object-based systems) - the rules management technology must allow you to treat all corporate, external, or transactional information as though it is a set of objects that your rules can manipulate.
The data should not need to be re-entered or maintained separately within the rule service. Blaze Advisor uses Business Object Model Adapters (BOMAs) to access data as required during rule service execution. BOMAs have been predefined for Java, COM, CORBA, RDBMS, XML, and other object or data models. Organizations with their own, custom data formats should make sure their chosen rules technology has the flexibility and power needed to make their objects available to rule services. With Blaze Advisor from FairIsaac, this capability is provided through custom BOMA kits.
Another use of existing data sources within the company is as a framework for constraining inputs and transactions. For instance, database tables may contain values to be used in selection lists and input choices presented with radio buttons and check boxes. A robust rules management system should be able to access these data sources at runtime for constructing and managing user interactions, as well as being able to create additional lists, values, and options based on rule execution.
3. Sophisticated rule syntax
Rule syntax should allow non-technical business users and policy makers to understand and maintain rules without learning arcane programming conventions. One approach is to provide natural language processing to attempt to interpret policy statements and form corresponding programmatic rules. However, the results can be inconsistent and matching the internal programming representation to the external definition is an exercise for highly trained software engineers. Often, a structured language syntax that uses familiar keywords and sentence structures is the best approach. This provides the power for sophisticated operations while maintaining an intuitive readability for business users.
A well-constructed rule syntax should support the simple representation of a complex processing concept. For instance, Blaze Advisor uses a Structured Rule Language with phrases such as "Whenever x is true…" and "If at least 2 invoices in invoiceList satisfy…" These formats replace explicit looping and iterations through value instances to match patterns in sets. Pattern matching and the use of regular expressions can significantly simplify and empower rule services. Without these constructs a rule service will end up with a very large number of oversimplified rules that are complex to assemble and manage as a set. Rules using the "whenever" construct can be triggered when a value changes or when information is required for another rule's calculation. Rules can even be defined that are triggered by the creation of new instances of a specified class.
Other syntax considerations lie outside the traditional world of keywords and operators. Power and flexibility are also achieved through the methods used to combine and deploy rules within a production system. We have found a great deal of value in combining declarative (non-procedural) rules syntax with procedural methods for combining groups of rules into structured process flows, for allowing rules to make sequence-based procedural computations, and for accessing external applications within both their condition and action clauses. It should be possible to give rules effective dates and times allowing automatic deployment starting, ending, or cycling over a defined period. It should be possible to use dates, times, durations, currencies and other specialized data types when comparing properties. It should be possible to tell the difference between null data, missing data and invalid data. Lastly, syntax constructs must fit within the global development/deployment environments of multinational companies. Rule, class, object, and variable names must be definable in languages ranging from French to Japanese to German.
4. Testing and management tools
Sophisticated testing and management tools are critical to the successful development and deployment of complex rule-based systems. A well-established rules management technology should support rule service partitioning, execution path testing, service assembly and service deployment. Tools should allow you to watch the execution of rulesets and ruleflows, set breakpoints, check data values during execution, use test instances and so on.
Testing a rule service involves being able to define test cases (sample objects, property values, and external data) and run them against your rules. It requires that the execution path determined by the rule processing algorithm can be traced and watched. It should be possible to perform all the traditional facets of debugging activity - setting watch variables, traces, stepping into and over rulesets and functions and so on. Interactive steps in the process should be represented by interactions with the tester without requiring complete integration with external systems.
5. The ability to generate rule maintenance applications
It is not enough to be able to give business managers and policy-owners access to the rule base. To effectively manage their own rules they need applications that completely hide the structured rule language. These applications must allow rules to be safely constructed and modified by the right people with the right data entry controls. These data entry controls must be driven by the actual data stored in existing systems and changes must be deployable on demand without service interruption or downtime. Conversely, multiple rule managers should be allowed to make revisions for deployment at later times, when scheduled and reviewed by systems personnel.
Browser-based Web access to rule maintenance applications, such as Blaze Advisor allows, have proven to be an effective method for providing remote, secure access to rule maintenance. Login and security controls allow access levels to be defined for various individuals or functional groups, each of whom has a different view on to the rules and differing levels of power over what may be changed. Users may be given the ability to add, modify, or delete portions of rules, individual rules, or entire sets of rules dealing with a particular logical function.
6. Frameworks for reuse
To promote enterprise consistency and reuse, a rules management technology must provide a framework allowing the reuse of rule structures and the sharing of rules between applications and service delivery channels. A single definition of rules to accomplish a business task should be stored centrally and made accessible to multiple applications. For instance, rules to verify a valid support contract would be called upon by a CRM system, a Web self-service site, and a voice response system rather than being programmed separately in each system. Application Service Providers often wish to allow a common set of rules that apply to all end users visiting their site, with individual rules applied as appropriate for the hosted company servicing the customer. Grouping rules into functional component blocks (Blaze Advisor refers to these as rulesets) permits them to use parameters, returned results, and inheritance to provide reusable functionality across a range of calling applications.
7. Scalable deployment
To support large scale systems, it must be possible to deploy rule services across one or many applications on one or many hosts in a large distributed computing environment. The rule service must support a wide range of platforms and it must take advantage of scalable architectures such as J2EE application servers so that it scales as well as they do.
To be truly scalable, a rule engine needs to behave differently when deployed as a standalone application and when deployed within an application server framework. For instance, it makes sense for a standalone deployment to be multithreaded and to allow both synchronous and asynchronous access. To be a well-behaved component in an EJB/J2EE framework, however, an EJB needs to be single threaded and synchronous. Thus the rule engine needs to be able to behave differently depending on the deployment. The rule engine should also be able to run effectively on a broad range of platforms to ensure that the most suitable platform- that with the best performance, reliability and scalability characteristics for the application being developed- can be used.
A complete rules management system usually includes some form of overseeing layer (a "rule server") to manage deployment of multiple threads and instances of the rule engine, allocation of services to multiple concurrent users, queuing of requests and responses, notification and replacement of rule changes, and simple access interfaces from calling applications so that programmers need not write low-level API calls to load, execute, and dismiss rules themselves.
Blaze Advisor from Fair Isaac is a complete rules management technology that includes all of these functions. How you build applications with Blaze Advisor is profiled in a white paper titled "How Blaze Advisor Works" available from http://www.fairisaac.com/white_papers. Blaze Advisor helps you go "beyond personalization" and revolutionize how you design, develop and maintain business applications using rules management technology.
Note from the editor
If you’re using a Business Rules product or tool, you can submit your own evaluation of the product and we’ll post it on our web site. Additionally, if you would like to see a write-up of a particular tool, let me know. My email address is:email@example.com
# # #