A business rule engine (BRE) lets people who aren’t coders express and understand business rules without the constant involvement of IT people. It may be a part of a single software package, or it can be a separate product with an API that many different business systems can use. Either way, it makes it easier to customize the way the software operates.
A rule might be something like ”If an expenditure exceeds $10,000, a senior manager must approve it.” An accounts payable system will apply it so that every payment has the required approvals before going out.
Rule engines can be easier to understand in some situations than normal computer code, even for software developers. They break each rule out into its own case, and the engine does the work of resolving dependencies and running rules in the proper sequence.
The evolution of rule engines
There’s no hard line between a rule engine and a programming system. As engines grow more complex, they may become just as powerful and hard to deal with as full-blown programming languages. We might even think of COBOL, created in the 1950s, as an early rules engine. It was designed to look like a restricted form of English, on the theory that it would be easier for non-programmers to understand. It ended up as just one more language for programmers to learn.
Rule engines grew out of ”expert systems,” which date back to the 1960s. Expert systems were considered a form of artificial intelligence, often employing heuristic methods and reporting probabilities rather than definite outcomes. Rule engines are more deterministic, triggering actions when specified conditions are met. However, the software which applies the rules is complex and sophisticated.
Today’s rule engines include open-source software such as Drools and OpenRules, as well as proprietary ones like Microsoft’s Business Rules Framework. The open source ones may define an interface which lets different kinds of software use them, or they may be specific to one application or suite. The proprietary ones work within the vendor’s software system.
Defining rules
A rules engine operates on a domain of information. The domain provides the objects it can act on, the attributes which they have, and the actions which rules can perform. Examples of a domain are an accounting or CRM system. The rules have meaning in the domain’s context.
Several approaches are available for defining business rules. However they’re created, the rules have a common structure. They’re conditional instructions, of the form ”if A then B.” The ”if” part consists of conditions relating to facts in a domain. It may combine several such relations using logical relationships. For instance, it might require either of two conditions:
if (purchase price > $5,000 OR category = "special")
The ”then” part specifies an action to take, such as:
then hold for approval
The domain which gives the rules meaning is the software which invokes the BRE and the information which it possesses. The software has to provide the values for ”price” and ”category,” and ”hold for approval” needs to be an action which has a unique meaning in the context of the rule invocation.
The language of the rules may be so-called ”natural language” or a simple syntax. Natural language doesn’t mean writing freeform text. There’s too much room for ambiguity that way. It’s something closer to COBOL, where rule authors create something which looks very much like normal language but is subject to strict constraints. The software guides them at each step, letting them enter their requirements in a dialog and converting it to statements with the correct syntax.
Simple rule-writing languages may seem less intuitive than natural language, but they can be easier to use after a little practice. Once the author knows the syntax, it’s possible to just write the rules without software aids.
Many systems provide graphic aids for constructing decision trees. A ruleset involves a chain of logic in which one rule selects the next rule to apply. Seeing the relationships as a graphic tree makes it easier to see how the rules cover all the possible cases.
Decision tables are another popular way to define rules. They show a set of possible conditions in tabular form, along with the action to take in each case. This technique is especially useful for selecting among a long list of options, such as all the departments in a company.
The role of BREs
Business rule engines are often promoted as letting people in a business set up rules without the help of programmers or IT staff. Sometimes this is possible, but it’s more useful to think of them as aiding collaboration between business and IT.
They allow greater flexibility. When business rules are part of application code, it’s necessary to modify and test the code every time a rule changes. Even when a change is very small, good programming practices require re-testing everything. Rule engines move the decision-making outside the application code, so it can be changed without endangering the application’s integrity.
However, an error in a business rule may be hard to tell from an error in the application code. The rules can have bugs, and an incorrectly written rule could have consequences as serious as a bug in the application. Whether business users or software developers write the rules, they need to track all changes and watch out for problems.
Writing rules for an engine may not require learning a complicated programming language, but it requires a very logical and detail-oriented mindset. Not everyone is able to do it well, so the job may still fall on specialists. Even people who can’t write the rules, though, will be able to see how they’re laid out and understand what they do. If a rule conflicts with what they wanted, they will be able to tell.
Another advantage of the BRE is that it makes organizing the rules easier. When computer code involves a large number of decisions, it can easily become a rat’s nest of instructions that even skilled developers have trouble keeping track of. With a BRE, each rule is self-contained, and the engine manages their interrelationships. It’s the part of the engine which applies the rules that gives it its power.
Applying the rules
The number of rules for even a moderate-sized department can be huge. If the BRE applied all the rules sequentially to every case, the process would be inefficient. Applying a rule may change the conditions which other rules use, so it would be necessary to go through them more than once. Some rules override others. BREs use sophisticated methods to run the applicable rules efficiently and deal with the effect of one rule on another.
An example is the Rete algorithm, which dates from the heyday of expert systems. It determines which rules are applicable and which ones have to be re-evaluated if other rules change the conditions. If a rule changes a condition, only rules which the change might affect have to be re-applied. This avoids a lot of error-prone programming logic.
Rules can have effects on one another that lead to an endless loop. Most rule engines will detect this situation rather than running till the user stops the process.
Using rule engines well or badly
Used well, business rule engines reduce the need for changes in application code and help users to understand what is happening. Used badly, they can collapse from over-complication. Certain mistakes ought to be avoided.
- Don’t expect business users to create the rules without training or help. No matter how user-friendly the BRE is, they’ll need a good understanding of it before they can start writing rules.
- Don’t combine too many rules in a single system. If a system has over a thousand rules, no one can understand all the conflicts they might have. If the number of rules threatens to grow huge, it’s better to have separate rule systems for different departments or applications.
- People who write rules should know what they’re doing. It doesn’t necessarily take a programmer to write them, but that doesn’t mean anyone can do it. People with excellent skills in other areas aren’t always strong at conveying their intent to a computer.
- Don’t make the individual rules complicated. The engine can’t determine the sequence of rules as effectively when each rule contains a large amount of logic. The idea of a BRE is to create simple rules and let the engine figure out their relationships.
- Using business rules to add new features to an application leads to trouble. Application logic which is inherently complicated usually belongs in program code, not in business rules. Pushing too much of the logic into rules may make the application appear simpler, but the overall process is harder to manage than before. Software bugs will be harder to fix, and the users will find the rules incomprehensible.
Business rule engines are most useful when there are a lot of frequently changing rules that would be hard to keep updated in an application. They help users to understand how the system applies the rules, and in some cases the users can write the rules. That can be a great help in making the software do what management wants it to do.
