What rules belong in the BRE and what rules should be hard-coded? (FAQ #2)

Here's a great way to decide which rules belong in the rule engine and which rules could be hard-coded. The idea is that rules that you have no control over, such as compliance rules, must be rule-based so you can react quickly and implement them as soon these rules are changed. When a regulating authority tells you when the new rules become effective, you have no control whatsoever, and a rule engine enables you to change fast.

Rules that you control, where you can take your time and decide when the rules shall become effective, can be hard-coded if so desired. There still may be benefits to rule-basing these rules, but at least you can hard-code them if necessary.

Rules that should be in the BRE:

• Business Rules
• External rules
• Governing rules (Regulatory rules / Legislative rules / Compliance rules / etc.)
• Rules that you do not control
• Rules that change often (Promotion rules / etc.)
• Industry rules
• Market rules (Competitor rules / Pricing rules / etc.)
• Environmental rules (Seasonality rules / Weather rules / etc. )

Rules that could be hard-coded

• System Rules
• Internal rules
• Rules that you control
• Rules that never or rarely change

Idea credit to Paul Ulshafer. See PowerPoint slide of this idea.

FAQ

100 Rules for NASA Project Managers

Here is an interesting link from the IT Metrics and Productivity Journal:

"Jerry Madden, Associate Director of the Flight Projects Directorate at NASA's Goddard Space Flight Center, collected these 100 pieces of wisdom over a number of years from various unidentified sources. Jerry Madden retired from NASA in 1995 as Associate Director of Flight Projects at Goddard Space Flight Center. Considered by many of his peers to be one of NASA's premiere project managers, Madden's reputation for frank, on-target observations of project management continues to be celebrated today."

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?