A primer on influence of business rules on application architecture, a brief guideline on rules modeling and design.

1. Rule Design Guidelines and Best Practices
1
Keshav Deshpande
Software Developer
kdeshpande1@verizon.net

2. • Application Architecture with Business Rules
• Separating Business Procedures from Business Rules
2
• Structure of a Business Rule
• Anatomy of Rule Execution
• Business Rule Modeling, Best Practices and Guidelines
• Business Rules vs Validation Checks
Topics

3. Application Architecture with Business
3
Rules

4. Application Architecture with Business
4
Rules

5. Application Architecture with Business
5
Rules
• Business procedure/workflow distinct from Business Rules
• Business Rules hosted and executed within rules engine
Implications
 Separation of concerns
• generally accepted as good application design pattern
 Business rules can be independently modified
• Modifications done outside of application code
 Business Analysts can access/simulate/run/test Business
Rules
• in isolation from application

6. Business Procedure Vs Business Rules
6
Example Business Procedure:
An incoming claim is routed to appropriate claim processor
team, based on claim amount
Example Business Rule:
claim amount is greater than $10000
route claim to Team A
Vs.

7. Structure of a Business Rule
claim amount is greater than $10000
7
route claim to Team A
A rule
 is a Declarative Expression comprising of –
and
 can have multiple (and-ed/or-ed together)
multiple (and-ed together)
Rules can be grouped together –
expressed as or
Assertion
Action

8. Anatomy of Rule Execution
A Rules Engine is a
• ‘Fact-Assertion-Action’ engine (forward-chaining inference)
• Container for rule execution
8

9. Anatomy of Rule Execution
A Rules Engine is a
• ‘Fact-Assertion-Action’ engine (forward-chaining inference)
• Container for rule execution
9

10. Business Rule Modeling
 Mining Business Tier for Business Rules
• Harvesting Business Rules – highly analytical, cross-functional
team undertaking
 Segregate Business Procedures from Business Rules
 A Business Rule exists to facilitate Business Operational
Decisioning
• imperative - frequent modifiability
 Business Rules provide control and governance
• “way-we-do-business”
• influence behavior of business
10

11. Business Rule Modeling
Frequently encountered question:
What about validation check “rules”?
Examples:
• social security number validation
• telephone number validation
Can I implement validation check routines as “business rules”?
You can, but should you?
11

12. Business Rules Vs Validation Checks
Business Rule Validation Check
• Strategic, ‘big picture’
connotation
• Business decision-oriented
• Frequently modified
• Modifications – consequence of
dynamic operational
environment
• Influences “way-we-do-business”
 Validation checks best NOT modeled as business rules
 If you absolutely have to - use the ‘frequency of modification’ as final
12
decision point
• Tactical, narrow focus
• Data-oriented
• Not modified as frequently
• Modifications are aspect of
data governance
• Amount to pass/fail checks,
failures equate to errors

13. Business Rule Modeling
Generally, these are NOT good Business Rules candidates:
After all, why use a Rules Engine to execute –
 Logic that is not likely to ever change, once implemented
 Logic that does not have “way-we-do-business” connotations
 Database lookups, data validation checks
 Data transformations, long-running processes
 Logic that has little influence over business operational
13
behavior

14. 14
Thanks!
Please stay in touch at - kdeshpande1@verizon.net