A developers experience of working with ILOG JRules for two years. The good things he found, the problems he encountered and his general views on rule engines.

In recent years it has been discovered that business rules constitute an entire body of knowledge that has not been adequately addressed in either the analysis or design phases of system development. Typically, business rules have been buried in program code or in database structures. It turns out, however, that the identification of business rules is important in its own right. Moreover, it is different from the definition of data structure in a data model, and from the definition of processes.

This column is the next in a series that provides the reader with best practices on using or choosing a rules engine. The target audience for this series is typically the user of a rule engine, i.e., a programmer or someone with programming skills. All coding examples should be read as pseudo-code and should be easily translated to a specific target syntax for a rule engine that supports backward and forward chaining in an object-oriented environment.

I am asked this all the time. What is the difference between a business rule and a business requirement? It is simple, really. Business rules are lists of statements that tell you whether you may or may not do something, or give you the criteria and conditions for making a decision. One factor of a business requirement is what you need to do to enable the implementation of and compliance with a business rule.

The process of identifying business rules is often iterative and heuristic, where rules begin as general statements of policy. Even if the policy is formal and specific, it is typically described in a general and informal fashion, and it often remains for the employees to translate it into meaningful specific statements of what to do.