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.DevelopmentAnalysisTestingProject 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.
View the original article here

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 frequentlyIntegrate 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.

View the original article here

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:PurchasesCulture/process changeEducationImplementationTestingMaintenance

Regarding the strategic benefits:

Examine all the benefits of business rules.Think of business rules as a strategic tool.IT agilityManagement of knowledge as an assetLeverage 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.

View the original article here

Managing Business Rules

So…maybe this post will sound like a rant, but why aren’t there any fully mature business rule management systems (BRMS) to be found anywhere?! I can’t even count the number of times clients ask me to recommend a system and I have to give them the bad news.

Naturally, each rule engine vendor will tell you that you can perform full rule lifecycle management within their authoring/development environment. Very quickly however you will discover that although it might be possible, the solution is generally about 80% skewed towards the vendor’s rule engine and the management aspects always take second place. Simply not good enough for business users!

Our clients’, you, more and more require a truly focused approach for large scale rule management. While managing and versioning Word/Excel documents in a code repository and providing change management via a defect/issue tracking system sometimes works, I think rules have become such a significant part of a system these days, that they really do need their own management environments. Similarly requirements systems, while a frequently used approach, still don’t provide adequate support for ensuring that rules conform to the fact model and that proper rule syntax/patter is being followed. Better for business users, but still not great.

There seem, however, to be some promising efforts under way! I am sure anyone who has actually spent some time looking has come across RuleArts' RuleExpress, and BRSolution’s RuleTrack. These two I believe have been around the longest.

Next, as a result of the new SBVR specification, Unisys is working on a business rule manage ment system that closely integrates with MS Word. You’ll have to dig deep on their site to find it however. Just give them a call-- they will happily show it to you.

Quite understandably the IRS has a massive rule management need and will share their experiences with BRMS systems at their BR Forum Conference presentation coming up in November in D.C. Bummer, the presentation is scheduled for the same day and time slot when I’ll be presenting Open Source Rules just next door.

So, I guess the question is…what is a “good enough” business rules management system? Artemis Alliance can certainly help you and your organization answer that question more precisely, but, as a brief blog entry, I have compiled the flowing preliminary wish list of features in no particular order. Please feel free to add in the comments section:

Overall change and history tracking at the rule levelEnforcement of the rule management processRole based security Rule authoring, storage, search and retrievalTerms DictionaryFact modeling capabilitiesRule language and pattern definitionNatural language rule writing (yes…no…maybe?)Enforcement of fact model within the rule expressionRule syntax, grammar and spell checkingLinking or matching of fact models from different departments/divisionsCapability to document rules as decision tables/treesEasy access to rules by business peopleAbility to support both distributed and centralized rule management approachImport/Export capabilities of rules using available standardsThis I believe represents a list of maybe the “obvious”. Note however, that at this time, I doubt you will fine any one solution that will offer all of the above features and be usable by your average business user. I naturally welcome any disagreements with this list and hope to hear from those who would wish for something different. Again, your exact needs will heavily depend on your organization, application and approach.

View the original article here