« The pace of change is increasing - it's official! | Main | Intelligent, Analytic Processes »

I was referred to this nice article in SOA/Web Service Journal by some colleagues at Oracle - Building Flexible Business Processes Using BPEL and Rules. Mohamad Afshar and Bhagat Nainani do a great job of showing how, and why, you should use business rules in this context. I'm not going to be able to add much to it but here goes:

• Don't underestimate how much change you might actually want in apparently "fixed" rules. The statement in the article that rules will change "if business analysts are involved in capturing the rules" is spot on. Indeed one of the examples given for a rule not likely to change is "If the customer does not have a credit rating, reject the loan" is a perfect example. Lots of lenders used to have this rule and probably thought it would never change. Now, however, there is a lot of pressure to sell to the "thin-file/no-file" folks who don't have a credit rating but who might be a manageable risk. This would involve changing this rule to a ruleset (multiple rules handling the various combinations of application data, credit ratings and external data that are allowed). If you had taken the service-based approach you would be fine - you would just be changing the "knock-out" rules. If you had hard-coded it you might regret it. Almost every customer I have spoken to wishes they had put more rules in their rules engine rather than fewer. Remember, the pace of change is increasing.
• An effective way to combine business rules and BPEL model-driven rules is to use decision services in conditions. Thus the model driven rule might be "Orders from Premier customers..." but the way a premier customer is determined might be a set of rules in a decision service. This allows flexibility in how you are defining business terms like "Premier" while still keeping the routing and handling rules in the process definition where they belong.
• Using templates to control which parts of which rules can be edited by a given group of business users is key to delivering agility. While you can get some agility from IT changing the rules, you get a lot more if those that decide to change the way the business is operating can also change the rules in the process itself. There's a lot to agility, but business rules and empowering business users to change them is key.
• Finally consider how you might re-use the rules in your decision service to environments not yet service-enabled, like legacy applications. Perhaps you can re-use a logical decision service by using a Business Rule Management System to synchronize rules between a formal web service and, say, COBOL code.

There are some other benefits to keeping rules and process separate and not over-synchronizing them. There's also a whole topic to be written on how to bring analytics to bear on decision services but that's a topic for another day.

Posted by jtaylor in Business Agility • Business Process Management • Business Rules • SOA |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/522