Businesses run on rules. They define business processes, and describe just what happens if something goes right - or if it goes wrong. Do all the gold-rated customers get a 10% discount, and what happens if one calls customer support? Business rules are part of the decision support systems that underpin every business process.
You can write the rules into your application business logic, but they quickly become spaghetti code, as you try to wrap each and every rule into a self-referential chain of "
if then else", "
case endcase" and "
do while" statements (depending on your language of choice). Business rules change more often than the applications behind them. Debugging every case can add days and complexity to application tests, and meanwhile the business process owner is waiting for you to make the last set of rule changes...
You don't have to write the rules code yourself. It's often easier to employ a business rules engine to handle the rules, orchestrating and managing your applications and services. Rules engines are declarative, allowing you to put together quickly groups of rules that trigger events and services, without having to resort to procedural programming. If the engine offers sufficiently high level tools (which could be anything from simple text editors to complex graphical rule and workflow diagrams), responsibility for rules creation or editing could even be passed over to the business process owner. This means that your development team doesn't have to change its code every time the discount rate changes by .5%, or marketing defines a new class of customer.
The move to SOA and a process-centric way of thinking about IT makes it easier to implement a rules engine as a key part of you enterprise architecture. You can make it part of either an enterprise service bus, using rules to handle content-based routing of messages, or part of a process orchestration tool, with rules choreographing service interactions. In an ideal world, IT departments and development teams would build business services and work with the business to define the processes that link them together, with the process owners defining the rules with a rules engine. As rules are declarative, they can be defined in simple statements: "
IF customer_type IS gold THEN discount is 10%". Rules can then be weighted and given dependencies, modelling the decisions made during a business process.
Rules engines work by evaluating collections of facts, and using the results to determine new facts. One approach uses rules to infer the answers to questions of the form "given these facts is this customer a good credit risk?" Others respond to patterns of events, and then act on them. The order the rules are applied doesn't matter - it's the aggregate result that matters.
Some systems work by chaining rules and capturing exceptions, while others "sieve" information through rules and then work with the information that's been left after all the rules have been applied (and of course, it's possible to do both). It's also possible to weight rules so that one set has a higher priority than others. This could be as simple as "300 instances of SKU item A have been sold" triggering an out of stock alert. A more complex reactive engine could be handling multiple information sources (which could include external information sources) to help automate purchasing or sales decisions.
The biggest problem facing anyone wanting to implement a rules engine isn't finding the right technology - there are plenty of tools on the market - instead it's getting the right rules definitions. It's important to capture all the rules currently used (usually as part of a “business process re-engineering” exercise linked to an SOA implementation). However, rules capture isn't simple - rules are as often implicit as they are explicit, relying on experience as well as defined processes.
It's a problem that's been around since the early days of knowledge management and knowledge-based system design. While business rules are often part of a closed domain, so easier to codify, the process of defining the rules that manage a business process can still be slow and tricky. It's important to make sure that rules are agreed, and tested, before they're deployed. While some basic rules and rule sets may work across industries, verticals will often need to develop their own specific sets, relating them to specific business processes and industry standards.
Rules engines are rapidly becoming key components of development frameworks. Java EE has one in the shape of the Java rules engine, defined in JSR 94. Meanwhile .NET developers can take advantage of the Rules Engine that will be delivered with the Windows Workflow Foundation (WF) components of the 3.0 release of the .NET Framework later this year. WF will add a graphical rules development tool to Visual Studio.NET.
If you don't want to roll your own rules code, you can implement any one of many off-the-shelf engines. JBoss Rules is the supported release of the open source Drools project. Built into the Eclipse IDE, its rules can be embedded directly in your Java applications. NET developers don't need to wait for the release of .NET 3.0 and WF, as Ilog has .NET and Java versions of its Rules package, as well as a set of C++ class libraries. At a higher level, Microsoft includes a rules engine in its Biztalk process orchestration platform. Similarly, Fair Isaac's Enterprise Decision Management tools include its Blaze Advisor tool, which adds the ability to work with predictive models to your rule sets.
The world of rules engines is a complex one, but one that will become more and more important to businesses. By mixing declarative programming with a service oriented approach, a business will be able to build flexible infrastructures that can be quickly reconfigured in response to changing business needs. Simple rule changes won't even need the intervention of developers, who'll be able to concentrate on service, workflow and application development and enhancements.
In the next part of this article, we will compare and contrast the commercial rules engines from Ilog and Fair Isaac; together with a side look at JBoss Rules. ®