Following up on my post from a few weeks ago, I would like to drill down into the technique I recommend for handling exceptions in your business logic. You can also watch the recording of the webinar we hosted on that very topic (https://www.youtube.com/watch?v=O5ktSF_pLh4), and more types of exception too.
Before I explain the solution, I want to summarize the challenge at hands. Let’s say that you have global policies that you want to apply consistently across all segments, where segments can represent geographies, customer segments, client configurations, etc. For simplicity, I would assume that segments are tied to geography. Each US State might impose different regulations, that cause the business rules in the global policies to vary from state to state. In some cases, business rules might need to be changed slightly. In some cases, business rules might not be compliant with the local regulation and would need to be excluded. In some cases, additional business rules might need to be added.
Not Recommended Design
What seems intuitive is not always the right thing to do.
What we have seen as the design of choice in most cases, is a copy-and-paste of the rules. While it is simple and easy to do initially, it is not a sustainable solution when you have more than a handful variations of your business rules, or when each ‘leaf’ decision is made of a significant number of rules.
Setting up one of these configurations may not be that bad, but the maintenance is a real nightmare. When changing a single business rule, the usual search-and-replace can save you time. It might lead to manual errors though: you might miss one of them as you skip through the configuration, or a simple edit to the rule might make it invisible to the search. Also it requires some thinking for each configuration to question whether or not the change is applicable. How do you know that a business rule has been overridden and should be subject to the change in question?
We have seen business rules practitioners that got caught in this design, and unfortunately struggles with spaghetti rules that were almost impossible to maintain, with a backlog of change requests…
Recommended Design
I would follow 2 simple rules for a clean design:
- Do not write the same rule multiple times if you do not have to
- Keep track of your overrides, whether they are changes, additions or deletions
With that in mind, we made a parallel between business rules and object oriented design. While business rules are certainly easier to understand for business analysts, we could not ignore that, as developers and architects, we had to face the same challenge in a past life. Object oriented design made it simple to define attributes and functions at a high level, and then let any derived class override them. What if we could hide the complexity of the implementation, but still expose a powerful derivation model for the maintenance of business rules?
By cascading decisions, you can actually define your rules at the top level, and specify the hierarchy from top to bottom. The beauty is that the Global Policy level can allow a business analysts to make a change that percolates down the chain to all the derived decisions. No more copy and paste of that change. And since it is that easy to make the change, it is that easy to test it. You could run a quick simulation and estimate the business impact of that change, without having to wait days for the team of analysts to change your many projects.
In order to make a change to a business rules for the state of California, you need to see what rules are derived in the first place. We believe it is important to make these business rules read-only so that the Global Policy rules will not be impacted. It would be disastrous to have the CA business analyst suddenly change that policy for all states when he / she thinks that he / she is only modifying the rule for California! But when the time comes to make that change, he / she should be able to explicitly request an override of the rule. The rule can then be modified, but the new version would only be visible to the state of California, and to the decisions that cascade from there (San Francisco, Los Angeles and San Diego for example). The change could be a modification, and addition or a deletion of course.
What I love about it is that you really do not have to look very far to see what is specific to the state of California. The chain of command is obvious, and you can compare at any time your override with the master business rule. There is no limit either to the number of layers.
One interesting thought is that you can assign responsibilities for layer or branches. While we often see that business analysts are forced to take a divide-and-conquer approach to business rules management due to the lack of true collaboration tools, this organization is certainly allowing layers of responsibility or expertise to be enforced.
Finally, your repository does not grow exponentially. Your projects remain fast and slick.
Learn more about Decision Management and Sparkling Logic’s SMARTS™ Data-Powered Decision Manager
