Business rules engines can separate out key decision logic of a process and put it in a much more business-friendly language than application code. This layer of abstraction makes changing rules faster and easier, but it does add some complexity to the system.
Use a business rules engine and you can avoid doing a small IT project for every rule that needs editing. This article explores that time-saving benefit and others, providing expert, user and analyst views on the advantages and difficulties of using a rules engine.
Business rules can become deeply embedded in process flows, touching data and services across a system. If those rules are hard-coded into the applications themselves, a developer might have to spend some serious time ensuring that changes are recognized at all touch points, according to consultant, author and open source evangelist, Jeff Genender.
A business rules engine takes little decision points that are spread throughout application workflows and makes them available through a centralized syntactic layer, Genender explained. Users can usually access the rules through an interface that presents them in declarative statements such as: "a customer gains preferred status if total account value > $100,000."
This approach can be used in conjunction with a business process management (BPM) system—though that isn't usually the case.
Genender said BPM systems act like rules engines in a lot of ways, but don't have that abstracted syntactic layer. If a company wants its business users managing and updating rules however, that layer would likely be important.
Forrester Research analyst John Rymer pointed out that some business rules change more frequently than others.
"You don't change your accounting policies on a whim," said Rymer. "If you put in place certain regulatory policies in banking like the Patriot Act, those things don't change on a whim. But they do change." Policies that touch on areas like discounts, promotions and sales can change often, he said.
Unfortunately, there are no clear standards for rules just yet, Rymer said. It will probably be some time before there is something like "SQL for rules," he continued.
This lack of standards makes it important to choose a rules engine carefully. Analysts and users have both raised issues with the difficulty of porting rules from one engine into another. Often, it is difficult to apply rules even from one internal application environment to another under the same rules engine. Rymer said he has heard from numerous companies who have deployed a rules engine that never got used more broadly than it was in its first project.
In his book, SOA in Practice, systems architect Nicolai Josuttis wrote that ever since object-oriented programming went mainstream, "having a common business object model(BOM) became a general goal." A business object is a programmatic representation of business domain entities, such as a customer order. Rules are often used to enforce company policies relating to these objects. Unfortunately, the BOM turned out to be a recipe for disaster for large systems, Josuttis added.
"Because large distributed systems typically have different owners, it was tough to reach agreements," he wrote. "Either you didn't fulfill all interests, or your model became far too complicated, or it simply was never finished."
The struggle then becomes determining how much of your business logic should be handled by a centralized decision point as opposed to inside the individual domains. While application runtimes do pay a performance penalty for repeated checks to the same rules, Josuttis wrote, eliminating redundancy can be more work than it is worth to an enterprise.
In practice, Josuttis recommended having some central place for the business rules that change frequently. This is where a rules engine could come in handy.
To BRE or not to BRE
Some companies find that by focusing enough on the data architecture, they could eliminate the need for a rules engine from most of their systems. When the Northern California Power Agency (NCPA) first built out its service-oriented architecture, it included IBM's ILOG rules engine. After tying ILOG into a few projects, the NCPA wound up building its own rules management system, said Mark Myers, IT manager.
The NCPA used The Zachman Framework as part of the project. Following this framework, Myers said the team took a very formal approach to definition of terms, the establishment of business processes and the categorization of rules. From all of this, the company put together a very detailed design document.
"To do a rules project correctly the key is the identification of the vocabulary and writing the rules correctly," said Myers. The company found that with a good enough design document, a rules engine was not completely necessary in its SOA, Myers said.
In the wholesale power market, Myers said, the business rules do not change very frequently, so business users did not really need a centralized interface to change them at a moment's notice.
At one point, while the NCPA was developing its SOA, IBM released a new version of ILOG. Myers said his team had to do a lot of re-coding when migrating business rules up to the new version. Needless to say, the workload of having to rewrite all those rules was not exactly welcome. Myers said the "a ha" moment came when, in an architecture meeting, somebody asked, "well, why do we need a rules engine?"
So he brought much of the workflow logic back out of ILOG.
In doing this, Myers said it was important to keep a layer of abstraction between "data objects" and "rule objects" so that each type could be reused separately throughout the whole system. For the parts of the architecture where ILOG still runs, rule objects can be passed into the rules engine without having to be modified. Most rules now take about a day to change, which Myers said works for his company.