-- Posted by Carole-Ann
The key premise of business rules management has been historically to empower business users. Since they own the business, they should be able to maintain the way they want to do business without being subject to IT interpretation and other backlog prioritization. This is the core value proposition. After 10 years of pitching this idea and making it real for hundreds of customers, one may wonder "can it really work?".
Given my responsibility of steering Blaze Advisor, you can guess that I have been a big fan of this idea from day 1. That said, regardless of the time and energy we have spent for over 10 years educating the marketplace, our work is not over yet... Let me illustrate.
I was recently in a friendly customer meeting. Several architects new to the product attended my presentation. I was surprised when one of them asked how business users could be trained to write performant rules. This is not a bad question when you know that some vendors put "lipstick on the pig". Providing a business user interface is far more creative than revamping the rule language with what looks like English or some business lingo. At least, it is if you want that exercise to be really successful.
The real secret for empowering business users is to separate the policies from the rule syntax, really. The approach I typically recommend is to design the rules maintenance application independently of what rules will be executed in the end. As a matter of fact, it does not even matter that a policy will eventually map to a rule, a portion of a rule, a function or a class or anything else. If you put those concepts forward, you will see yourself designing "business user" interface that appeals to rule developers, not business users. If you ignore those artifacts, you will likely focus on what those business users really care about: defining new mortgage or insurance products, drug interaction alerts or pricing schemes. Once you have collected the types of activity they need to perform, the complete screens they want to maintain (this is what we call the templates), you are then free to architect the business rules that support those and at that stage you (the IT person) can worry about performance and other important design considerations that should not be left on the business user's plate.
I often feel that this is underestimated. Too many rules specialists focus on rules that will get executed and not enough on the people that will maintain those rules, although this is where the success of the project resides.
Additional freebie for the Agile enterprise: when IT is working on the "rules content" of the templates, business users can start populating the rules repository. As long as the templates contain the display information, the business user interface is fully functional and therefore business rules can be authored. When those two parallel activities meet in time, you will be able to test the execution. With a fair amount of business rules available very early on, you can also adopt continuous testing for maximum agility.
So the answer is "yes" we can trust them but only if they can rely on IT to provide the right rules maintenance application. As always, it is teamwork.
