Pitfalls and Lessons Learned of Business Rules Implementation - A Technical Perspective

Senior Artemis Alliance staff, drawing on their practical experience with what can go wrong from management, technical, and business analysis perspectives, provided insight into how and why business rules initiatives fail and strategies to assure the success of such initiatives.

by Krzysztof Karski, Artemis Senior Consultant

Significant technical pitfalls include failing to:

• Architect the concept model at the beginning of the project.
• Manage change.
• Establish an overall design vision for the rules engine and repository at the beginning.
• Establish appropriate testing methodology.
• Understand the capabilities and limitations of the rules engine.
• Understand that rules are not ‘just’ code or a new way to write if…then statements.

Success Strategies
For the concept model:

• Reduce change by having a well thought out and architected concept model.
• Have enough of a concept model architected so that future changes are additive, not structural.

For managing change:

• Establish a communication process between teams that might affect the concept model.
• Ensure the external entity model and the concept model evolve in the same direction.
• Agree early on data types, data constraints etc.
• Preferred approach: Iterative.
• Iterate quickly and often.
• Communicate frequently
• Integrate differences quickly and often
• Alternate strategy: Delay concept and entity model integration.
• Isolate concept model from external entity model churn.
• Figure out rules and concept model first, then figure out how to integrate with the external entity model.
• Get the concept model correct first and then figure out how to integrate it with external models.

For establishing an overall design for the rules engine:

• Choose an organizational paradigm and follow through.
• Establish rule organization, naming and categorization standards.
• Establish a vision for evolving the repository.
• Architect for rule portability and compatibility across the repository by having a well thought out and architected concept model.

For testing:

• Test early and often.
• Do not skip rule authoring steps including testing inside the rule authoring tool.
• Test in your environment first, not in application.
• Conduct quick, targeted testing.
• At minimum, set up quick and targeted smoke tests for your rules.
• Establish a reusable base of testing plumbing and base test data.
• Catch 80% of mistakes in the tool.
• Let the application testing strategy catch the remaining 20%.

For best use of the rules engine:

• Understand configuration options and their differences.
• Use wizards and auto generation techniques where possible.
• Use full tool set.
• Use the appropriate data types, built-in functions, etc.
• Understand your vendor’s work flow:
• Take full advantage of productivity aids by following the vendor’s rule authoring workflow.
• Understand the order of events when writing rules to avoid rework or unnecessary manual work.
• Use the rules engine for rules.
• Rule engines are not integration, data transformation or translation platforms.
• You should not have to write a ton of rules just to access, understand and return data.

For understanding why rules are not ‘just’ code:

• Use intermediary concepts.
• Define intermediary concepts globally and reuse them.
• Define simplification concepts that are used in everyday conversation and use them in the rules.
• Revisit OO analysis fundamentals and apply them.
• Write rules that sound like English.
• Follow rule writing best practices.
• Have each rule deal with one issue.
• Break up large decision logic blocks into many rules.
• Don’t write techie rules.
• Remember that rules are just not a different way to express if….then expressions.