It is inevitable… Business Rules add up over time… How many rules do you have per project? hundreds? Thousands? We have seen up to 1.2 million of rules in a project! Maintaining such volumes of rules can be tricky to say the least.
We have been thinking about the different ways you can keep those rulesets from growing like weed…
- Checking your rules in a different representation can help. When adding new rules or making modification to existing rules, get the proper context in the way that empowers you the most. Some have called it “business intelligence on rules”, and it is quite appropriate. If you can quickly visualize how existing rules function, you can more appropriately fit the new logic without duplication. You can check out how I leveraged that capability in this video.
- Have you ever added an “if true” rule in your ruleset because you need a default action? Those rules cloud the decision logic in the sense that they require the rules writers to know how they function. If you create this “if true” default action anywhere but the last position in an exclusive ruleset (exclusive means that the rule execution stops at the first rule that is satisfied), then you will shortcut some of your decision logic! This is the kind of knowledge that is often missed in documentation or internal knowledge transfers, leading to “weird behavior” that might be hard to debug. How would you do that? Our recommendation is to use default actions attached to the ruleset. If no other rule execute then the default action is triggered — you do not have to worry about setting your ruleset to exclusive or some other design you came up with. It is one less rule to maintain, and it is safe for the generations of rules to come.
- Do you have “if true” rules that set up variables used in your ruleset? You can get rid of those by creating variables in your forms of course. You can also add some pre- or post-processing in the definition of your decision steps or rulesets. Get rid of those rules that are not real decisioning logic by replacing it with procedural code in there. The “if true” rules go. The procedural code is safe from reordering or those pesky priorities that can mess up the original design. This is a good clean up!
- Look for the applicability of rules. Cleaning up business rules start with your business rules but don’t forget to consider the importance of those business rules in the context of your data! Some decisioning logic may be irrelevant as it never applies in real life… One person asked the question in our talk at BBC this year “how to retire rules?”… It starts with knowing those rules are outdated. Have logs or reports in place to give you this insight. That is what our customers that keep their rules tight have been doing.
I hope those tips will help you keep up with some of your New Year’s BRMS resolutions!
Caveat: all BRMS products do not support those tips.
