Pitfalls and Lessons Learned of Business Rules Implementation - A Business Analyst Perspective 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 Alyce Neperud, Artemis Principal and Senior Business Analyst

Significant analysis pitfalls include:

• Resistance to change
• Separation of rules from requirements
• Poor repository planning
• Selecting the wrong people to be rules analysts
• Solving the same problem in different ways
• No champion

Success Strategies
To overcome resistance to change:

• Educate to provide better understanding of why the organization is doing it this way.
• Build support within all areas.
• Development
• Analysis
• Testing
• Project Management
• Enable them to “skin their knees”.
• Let the team make mistakes quickly and see the value of the approach.
• Bring understanding of the “big picture” and the value of the approach down-stream in the development process.

To prevent the separation of rules from requirements:

• Teach them to write good requirements and good rules.
• Avoid having one group writing requirements and another writing rules.
• Use concrete examples.
• Show the new version of artifacts after introducing the concrete examples.
• Tell the entire story in an integrated manner.
• Use short, fast iterations with experienced review to provide experience and feedback

To encourage good repository planning:

• Do not take a document centric approach--focus on writing good rules rather than on where they fit in the document.
• Use knowledgeable people in designing the rules repository.
• Work through the versioning and change management in detail.
• Execute full rule lifecycle testing of the repository.

To select the right rules analysts:

• Do not assume that every subject matter expert will be a good analyst.
• Do not assign critical tasks to people who are unproven.
• Have internal or external mentors who have time to help
• Pair experienced people with inexperienced.
• Explicitly determine skill levels of team members.

To avoid different solutions to the same problem:

• Establish model for sharing information and lessons learned.
• Consistency is essential to precision.
• Do not let separate groups make their own decisions.
• Have some experts looking across the entire set.
• Do not overwork your experts.
• Be careful in how you tasks are assigned to avoid overlapping work.

Alyce’s advice for the ‘no champion’ problem ia simple: Get one! No champion equates to a greatly reduced probability of success.

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.

Pitfalls and Lessons Learned of Business Rules Implementation - A Management 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 Michael Krouze, Artemis CTO

Significant management pitfalls include:

• Management sees the initiative as ‘only’ a technical investment or enabler, and fails to take into account ALL of the costs involved.
• Management views business rules as a tactical, single application investment, and does not see the ‘big picture’, strategic benefits.
  
• Management hasn’t bought into the value of business rules, and fails to provide consistent support.
• Management does not understand the scope of the initiative and short changes the investment.

Success Strategies
Regarding determining the costs:

• Clearly analyze all rule costs and communicate to management.
• Make sure to include the following types of costs:
• Purchases
• Culture/process change
• Education
• Implementation
• Testing
• Maintenance

Regarding the strategic benefits:

• Examine all the benefits of business rules.
• Think of business rules as a strategic tool.
• IT agility
• Management of knowledge as an asset
• Leverage the investment in tools and skills.

Regarding management support:

• Educate, review competition, review success statistics to build confidence.
• Communicate strong support.
• Don’t vacillate – make a decision and stand behind it.

Regarding not short changing the investment:

• Understand the costs.
• Recognize needs for education and/or consulting support.
• Allow for proof-of-concept work and learning curve.
• Contract for support services from vendor.

Based on Michael’s experience, shortchanging the investment and viewing a business rules initiative only as a short-term, tactical investment are the two biggest barriers to a successful project. Management must understand that a business rules initiative is strategic in nature and represents a new way to manage its business.