BRM & BRE: Let the Business Manage the Rules

Total cost of ownership (TCO) plays a large part in the consideration of developing, purchasing and building of enterprise software applications. Not only does one need to consider how much effort and cost it will take to gather requirements, analyse, design and implement the system, but also what will the ongoing costs be.

One of the key factors to understanding in the costs of supporting and maintaining a system is how often the underlying requirements are expected to change. This would include the data structure (adding and/or removing required fields), process and work flow adjustments, user interface updates and changes to business rules.

When changes to arise, they are generally driven by the 'business'. This would normally mean that a business analyst(s) would work with the project sponsors and define and document the new requirements at great length and in great detail.

Then (historically) all of the above items would need to be reviewed, understood, managed and re-worked by the software developers in a build and test cycle. Once the unit tests were complete, full regression testing across the entire system would ensue, then the business would be required to test everything again during the user acceptance testing (UAT) phase. This of course would include other members of the tech team including Project Managers and Testers.

The things that usually change most often, and are the most expensive to update, are the business rules. A business rule can be anything from a simple statement such as:

IF AnnualSalary IS GREATER THAN $100,000 THEN Approved=True

... to a much more complex set of variables and logic that would result in a series of actions:

IF AnnualSalary x RiskScore IS LESS THAN 45 THEN EXECUTE
   Approved = Tentative
   Action = Forward to Telephone Representative
   Action = Print Tentative Acceptance Letter
   Action = Notify Manager of Possible Override
   END

Of course real-world examples would likely be even more complex (imagine the business rules associated with emergency services dispatch).

New tools have been created to give business users the ability to manage, test and implement business rules without the use of the software development team.

A Business Rules Engine (BRE) is the part of the system that allows for execution of the business rules against the data of your system. A Business Rules Manager (BRM) is the set of tools that allows you to create and update rules which are then stored in some sort of repository to be consumed by the BRE.

What this means is that the business analyst can be trained up to use a BRM to create, update and test business rules, and deploy them enterprise wide completely independently. Any business process oriented organisation (which is pretty much all of them!) can take advantage of moving the rules from the developers to the business analysts and save a great deal of time and money and reduce risk.

There are quite a few BRE/BRM systems out there. MS Biztalk ships with a BRE, however it is not nearly as flexible as some of the others (you can only do IF...THEN, which is VERY limited).

My favourite is from a group in Chicago called InRule (www.InRule.com). Very slick interface, great interoperability with Microsoft .NET (it was written in .NET) and very good linkage to Biztalk. They are also a great crew of people to interact with - excellent customer service. Other contenders include Drools, JRule, iLog, Visual Rules, Hayley, NXBRE and QuickRule.

Anyhow I could write dozens of pages about this topic but that would be a bit overwhelming for the readership. If you want to know more let me know via comment and I will set up a conversation with you.

.