Business Rules FAQ

Here are a few of the frequently asked questions about business rules. I'd like to share my thoughts and answers about each of them in future posts, but I also want to learn what others have to say. Please send me your comments or links to more information about:

1. How do you know when you're finished harvesting all the rules?
2. What rules belong in the business rule engine (BRE) and what rules should be hard-coded?
3. What is the real ROI of the business rules approach and technology? (according to actual customers, not BRE software vendors)
4. If business rules are that great for business, why haven't more business people heard about the business rules approach and business rules technology?
5. How will business rules affect the IT application development process/lifecycle?
6. What's a rule?
7. What's the difference (if any) between business rules and business requirements?
8. How do you know you're not missing any rules?
9. What is the best way to organize an enterprise business rules team: Should it be centralized with one group writing rules, or should departments have their own BR teams?
10. How do you select the right and best rule engine for your company?
11. How do you handle situations where experts cannot agree on one answer?
12. How can we track rule metrics and rule status during the rule harvesting project: how many rules were harvested? by who? how many rules are draft, approved, tbd, etc.?
13. How is the business rules development lifecycle different from the traditional software development life cycle? (similar to #5)
14. How can we design one enterprise rule-based system to support business units that need different rules?
15. What is the difference between data-based, rule-based, and knowledge-based systems?
16. Should we extract rules from legacy code? If so, what is the best way to do it?
17. What's the big deal with the business rules approach? What's wrong with the traditional hard-coding approach? How do business rules compare to hard-coded rules?