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:
- How do you know when you're finished harvesting all the rules?
- What rules belong in the business rule engine (BRE) and what rules should be hard-coded?
- What is the real ROI of the business rules approach and technology? (according to actual customers, not BRE software vendors)
- If business rules are that great for business, why haven't more business people heard about the business rules approach and business rules technology?
- How will business rules affect the IT application development process/lifecycle?
- What's a rule?
- What's the difference (if any) between business rules and business requirements?
- How do you know you're not missing any rules?
- 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?
- How do you select the right and best rule engine for your company?
- How do you handle situations where experts cannot agree on one answer?
- 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.?
- How is the business rules development lifecycle different from the traditional software development life cycle? (similar to #5)
- How can we design one enterprise rule-based system to support business units that need different rules?
- What is the difference between data-based, rule-based, and knowledge-based systems?
- Should we extract rules from legacy code? If so, what is the best way to do it?
- 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?