I did not mean to imply that identifying business rules and using rule engines doesn't provide value. Sorry if I was not clear.
I wholeheartedly believe that rules engines are a great asset for businesses to manage their business rules especially if they provide the ability to change rules on demand and to respond fast to changes in market and business conditions.
And yes, the rules belong to the business much the same way that requirements belong to the business. The only point I was trying to make is that no just any person on the business side can manage complex business rules. Most business rules engines, if they are to support complex rules, employ the use of some form of scripting/rule language which allows for unambiguous representation of the business logic. The business rules are then commands/instructions for the system.
The problem with that is that rules are, in principle, no different than code that programmers write: they can have bugs! Therefore the management and deployment of business rules, in my opinion, should follow a similar process as code so that changes to the rules can be first tested and validated in an environment other than production. I've heard many stories of production systems being severely impacted by "simple" business rule changes which were performed directly in the production environment. My point was that IT organizations generally are already very familiar with this type of change management and deployment process and therefore, it is not a bad idea for the IT group to manage the rules engines.
My other point was that the folks who modify the business rules should have experience and understanding on how to specify logic rules and the domino effect that one change can have on other rules. So, I believe that in most organizations the management of business rules should be managed by business analysts who not only work closely with the business folks but also with the IT side.
- Adrian