One of the most frequently asked questions around is “Why would I want to use a Business Rules Engine?”. Usually this question is immediately followed and is related to: “When should I use a Business Rules Engine and when should I not?”.
Googling out there you will find several posts, papers and books about it. Examples:
From JBoss Rules Documentation
From Jess Documentation
Those questions are usually answered in terms of the benefits of using the core rules engine component (algorithm), and are all true. We can even state that they justify the need for themselves.
Although, one frequently under looked aspect is the benefit of rules governance you achieve when using a BRMS.
Business Rules require lifecycle management in the same way most other current Enterprise Technologies do.
If one looks at classical application development in an enterprise environment, no one can even imagine it happening nowadays without a control process, involving orchestration of activities, with authorization control for each of the steps, does not matter what is the actual used methodology. The whole process is usually supported by specialized tools, varying from Development Tools, Code Versioning Systems, Automated Integration Tests, and specially, Configuration Management tools.
In the same way, once Rules Engines allow us to separate Business Decision Logic from the application core code, it also allows us to implement a governance infrastructure for Business Rules. It means:
Allows specialized teams to work on each of the roles in a Business Rules lifecycle. For instance, business rules analysts are responsible for maintaining the business rules, while configuration management teams are the ones responsible for the deployment and application core developers worry only about using (interpreting) rules results. Allows for fine grained control on the access and maintenance of the rules that control the Enterprise Business. Allows for comprehensive auditing of implemented rules and all changes happening in the corporate environment. Allows for rule sharing between different applications and corporate business processes. This as we know, allows for consistency between corporate processes and decision making, as well as reduced maintenance costs: a change in the single rule instance will reflect throughout the whole organization.
These advantages are in sync with SOA architecture goals, as well as governance requirements.
So, when analyzing the advantages of using a BRMS, also think about Business Rules Governance and the benefits it brings to the organization.
For more details on the requirements and features of such platform, you can refer to Mark’s post about the JBoss Rules server.
[EDIT: Adding related links posted by fellow readers in the comments, as here it is more visible to other readers than staying in the comments.]
Thank you James for posting:
“There are a number of reasons why business rules can be better than traditional code and a lot of benefits to be gained.
There are also many excuses for not taking on business rules as an approach. I wrote more on these topics in my FAQ.”
Also, thank you Rajgo:
“Especially, considering that rules are intrinsically more structured than code, it makes all the more sense to use a business rules Management System.
In addition to governance & management, and decision automation, BRMS can provide businesss rules analysis that one could use to refine their policies to meet business goals“
