You've got your fancy rule engine and you've got your sweet new rule editing environment. You've got natural language, syntax highlighting and checking, code suggestion and completion. So why, by all that's rule-based, would you want to generate your rules programmatically? Didn't we just take our rules out of code so we could maintain them more easily? And now we're putting them back in the code?

While programmatic generation of rules does seem like a step back, there are several good reasons to do it. Reasons to generate rules include:

• Generation of rules for testing - when you first start out with a rule engine, you may not have all of your rules figured out at the start, or, you may be adding many more rules as your business grows. You'd like to determine ahead of time whether your rule engine can handle the load, how many facts or records it can handle per second, and whether you have to buy ten, one hundred or one thousand servers to get the job done. Though you may not know all your rules, you probably know what your rules typically look like. You can generate copious numbers of rules and data that mimic your real rules and data in all salient point. You can then use these generated rules and data to test the performance of your engine.
• Conversion of existing rules - sometimes you replace a home grown rule engine with a commercial or open source rule engine. Rather than go through an error-prone hand conversion, an automated conversion should give you an error free start.
• Rule generating wizards for non-technical domain experts - you imagine that everyone that will use your rule-based system will edit rules through the vendor's rule editing IDE, but not everyone who needs to contribute to your rule-based system effort is tech savvy. One approach to solving this issue is to pair your non-technical resource -- doctors, financial experts, lawyers -- with a technical analyst. This approach may not fit your staffing model or be unworkable for other reasons. In that case, creating a wizard that simplifies the rule generation process may be a good solution.
• Rule-set consistency through generation - it's possible to create a rule-set that is inconsistent -- it can generate contradictory conclusions, e.g. "John is a man" and "John is not a man." Although it's beyond the scope of this article, it is possible to generate a rule-set, restricted to a particular format, that will terminate (not fire forever) and be consistent.
• Rule portability - until all rule engines have the same rule representation format (and execution semantics), you will have to write your rules in some proprietary format. If you think it likely that you'll be switching rule engine platforms at some point, representing your rules in a vendor independent format and then generating your rules into a vendor specific format is an approach worth considering.
• Dynamic rules - in some applications it is necessary to generate dynamic rules. Though not the only example of this, applications where learning needs to take place may require the dynamic addition of generated rules.
• Database driven rules - sometimes you either already have the details of your rules stored in a database or it's just more convenient to maintain them that way. You could write your rules so that you could pull the data into the knowledge-base at runtime. But you might have certain constraints -- embedded systems, etc. -- that prevent you from sending along a database or data file. Here you can generate the rules from your database and send it along to your application as a rule file.

Most business rule engine platforms use some sort of XML format for their rule files. Some provide an API for generating rules. If the vendor doesn't provide such an API but provides a DTD or XSD for the format, you can try and generate your own API. You'll also want to check if your rule engine allows the runtime addition of a rule to an existing rule-set.

It would be nice if we could have our domain experts write a small set of well-defined rules using a slick IDE. Then we could all take long lunches. You may not fall into any of the above scenarios right now, you may at some point in the future, so give some thought to programmatic rule generation when selecting your BRE platform.