Dian over at BPM Enterprise had this post that led me to this piece on The RIsks and Rewards of Reuse by Marcia Kaufman of Hurwitz & Associates. Dian highlighted the problem of "Poor Process" as an issue from a BPM point of view but I was struck by a second point Marcia made - Poor Management of Code. She says:
"it goes without saying that the software code that codifies a specific business service may also change frequently"
and thus if you reuse the service widely you may have problems when it needs to change. It seems to me that business rules offers two benefits that help with this.
Firstly the use of business rules to define the service makes it easier to modify it and manage it over time. Not only do business rules help eliminate write-only code, they also allow more effective IT and business collaboration on the logic of the service. Because the business and IT can work together on the business rules changes are more likely to be right and more likely to be understood by the business, reducing impact analysis problems. In addition business rules can be easily reused between services, while still being managed once in a rule repository. This allows several similar services to be developed (helping to reduce unintended consequences) while still ensuring consistency and reuse because many of the rules are the same between them. She goes on to say
"A strategy for reuse of business services must include an approval process for changes which begins with the “owner” of the business service"
It seems to me that this too leads you inevitably to the use of business rules to help close the gap between IT and the business and deliver the gap between IT and the business that can be managed by the business.
