Business process, business rules and legacy modernization

I saw this article on bpm.com - Modernizing Legacy Applications. There was a lot to like in this article but I felt like it glossed over some critical issues in legacy modernization using BPM and SOA. Let's consider some of the quotes that struck me

"Legacy systems contain vital business rules embedded within the source code"
"Though programming languages have come a long way the emphasis is still on technology related artifacts rather than business rules and requirements"
"But as important is the fact that many business rules are manual actions by people involved in the process and not programmatic code"

All this is true. But the answer is not to put these rules into a BPM tool but into a business rules management system. Doing this allows them to be managed, coded and maintained at a business rule level. It also allows for business owners to be engaged in managing rules and yet retains the flexibility to package up these rules into various services (in an SOA) or more traditional components (such as COBOL code).

This latter is important as sometimes it is the framework or process implementation in a legacy system that should be retained and logic within that framework that should be exposed as a service and managed as business rules. The California DMV's experience is a classic in this vein - the process of issuing registration has no changed in 30 years but the rules for fees change all the time. Keeping the legacy process, updating the fee calculation engine to use a business rules management system and then deploying these rules not only to the legacy system but also to other, newer systems as a service worked wonderfully.

So do think about business rules in your legacy systems, and about processes hidden within the portfolio of systems, but don't assume you must modernize the process. You may be able to just modernize the decisions.

Technorati Tags: agility, BRE, BRMS, Business Rules, government, legacy modernization, services