-- Posted by Carole-Ann
In the early days, we use to think about Business Rules as a great way to extract logic from the code. The vision of several nested if-then-else statements evoked the type of spaghetti code we all wanted to get away from, and we did.
Now that Business Rules Management Systems (BRMS) have made it to the typical application blueprint, the fear and pain of maintaining spaghetti code is well behind us... But should it?
Don't take me wrong, I would never even dream of saying "let's go back to those days". I have a passion for Decisioning Technologies and really appreciate the benefit it brings to the table.
But what if we created a new type of problem? Now that complex, really complex business rules can be created with ease, is it possible that we are toying with new limits?
I have seen some very large systems with tens of thousands of business rules. Granted you don't have to worry about the inter-dependencies. But you still have to figure out what rule you need to update, what context it refers to. With tens or hundreds of rules, not a problem. With thousands it become more challenging. If you have even more business rules, it may become a hard problem.
A customer I worked with a little while ago showed me how they navigated a world-wide repository of business rules. I was amazed by the time they spent clicking around to find where some piece of logic were located (country- or region-level for example), and make sure that they applied the right rating table for the right population of end customers. Navigating, selecting, browsing, validating, updating... What could have been a simple update, in the end, relied on many error-prone user-maintained naming conventions and a lot of time wasted navigating what could have resembled Business Rules Spaghetti! No blame on the customer, they did what they were supposed to but the nature of business rules, regardless of the technology you use, opens the door for those issues.
If you allow me analogy here, it is like your file system. It is not bad at all (I don't know how we could do without one actually) but when you manage a 500Mb or 1Tb disk with tens of thousands of files, you are bound to click around to find the picture you archived a while ago. This is why Google desktop and other search techniques are so useful.
Back to the Business Rules world, this is what happens with maturity. You end up with large volumes and eventually complex dependencies that may be contextual (when editing rules related to product ABC you want to pick one of the Pricing tables for Product ABC, other pricing tables are irrelevant).
We have a formidable opportunity now with new approaches and technologies to better handle content. Instead of thinking "the old storage way" about structuring a rules repository, why not adapt like Google, and think in terms of tags, dynamic structures, dynamic context and dynamic filtering. This is elegant and flexible.
I am impressed by the potential of such technologies applied to BRMS. The customer I talked about is able to boost the productivity of the business analyst or business users in charge of the maintenance with very little changes to their rules. Actually only the structure of the repository and a few data providers changed. Dynamic filtering and linking turn an old Rules Maintenance Application with growing pains into a slick and empowering tool.
