|
untitled
Top 10 Mistakes Business Analysts Make When Capturing Business Rules
Mistake #9: Not Having a Business Rule Methodology
by Gladys S. W. Lam
My husband is the chef in our family. Everyone who knows us knows that. He cooks like any Chinese would cook … no recipe. A dash of this, a pinch of that … voila! A tasty dish! Now that our daughter is away at university, he has decided to open a restaurant as a pastime. He determined very quickly that he cannot be the sole chef of the restaurant. He needs some way to pass down to his hired chef methods of how to create his signature dishes. To do that, he would have to create a set of recipes. A recipe would allow him to ensure quality when different chefs are working on the same dish.
There's no difference when adopting a business rules approach. If you are the only person doing the work and if you know what do to, a formal methodology might not be necessary. You can adjust, adapt, and learn as you go. However, if there is a team who needs to produce deliverables that have to fit together at the end, it is good — in fact, necessary — to have a recipe (i.e., methodology). A methodology allows you to have:
- A repeatable process,
- Consistent deliverables,
- Sharable knowledge.
For business rules projects, you need a methodology that addresses the following areas:
- Rule harvesting.
A set of processes and techniques to extract rules from:
- Subject area experts in facilitated sessions or one-on-one interviews,
- Documentation by identifying processes, decisions, and policies and by asking the right questions to extract business rules,
- System code by reversing engineering system logic to business logic and by distinguishing business rules from system rules.
- Rule specification.
A set of processes and techniques to:
- Write business rule statements in a consistent manner. We use RuleSpeak®.[1]
- Develop decision logic. We use a Q-Charting technique, which is based on Question, Condition, Outcome, and Exceptions.[2]
- Specify decision tables. Our decision table layouts are described in the same Q-Charting paper.
- Rule analysis.
A set of processes and techniques to analyze for:
- Duplication, redundancy, subsumption, and conflicts in rules,
- Impact to existing rules when a rule is changed, deleted, or added,
- Reuse of existing business rules, rather than creating new ones for each initiative or each business area.
- Rule management.
A set of processes and techniques to:
- Provide governance when business rule changes are needed,
- Organize a large set of business rules,
- Report on business rules from different perspectives,
- Establish relationships between business rules or business rule sets,
- Set up traceability of business rules from source to implementation.
- Vocabulary management.
A set of processes and techniques to:
- Define business concepts,
- Organize business concepts,
- Resolve synonyms and homonyms.
The methodology that I am advocating in this article focuses on the business side of the business rules approach. I believe that is the critical stage of a business rules approach. Paul Avilez, Principle Software Developer, Liberty Mutual, shares my view:
“Do invest your time in your rule harvesting and elaboration work. On average we now find that close to 75-80% of the time it takes to complete a rule is spent in the elaboration (specification). Coding the rule and testing it takes next to nothing once the elaboration is done.”[3]
Naturally there is methodology required for business rules implementation. This implementation methodology will need to be heavily dependent on your business rule technical environment (i.e., specific business rules engine or different implementation platform).
Once you have a methodology, I strongly recommend that you fine-tune it from your everyday learning. In my experience, an established, proven methodology is good for helping an organization kickstart the business rules approach. However, the methodology is most beneficial when it is refined over time, based on the maturity level, skill sets, timeline, and culture of the organization.
Just Remember…
Plainly speaking, here are some of the main things you need to remember:
- A methodology allows you to have a repeatable process, consistent deliverables, and sharable knowledge.
- A business-focused methodology for capturing, specifying, analysing, and managing business rules and business vocabulary is as important as a system implementation methodology.
- Your methodology needs to be refined as the organization matures through the business rules approach.
References
[1] For RuleSpeak, visit http://www.rulespeak.com/en/
[2] A paper on Q-Charting is available at http://www.brsolutions.com/b_decision.php
[3] "Business Rules Forum 2009 Practitioners' Panel: The DOs and DON'Ts of Business Rules," Business Rules Journal, Vol. 11, No. 4 (Apr. 2010), URL: http://www.BRCommunity.com/a2010/b530.html
| standard citation for this article: |
| Gladys S. W. Lam, "Top 10 Mistakes Business Analysts Make When Capturing Rules — Mistake #9: Not Having a Business Rule Methodology," Business Rules Journal, Vol. 13, No. 1 (Jan. 2012), URL: http://www.BRCommunity.com/a2012/b633.html |
|
|
|
January 2012
Top 10 Mistakes Business Analysts Make When Capturing Rules —
Mistake #9: Not Having a Business Rule Methodology
October 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules —
Mistake #8: Not Having the Right Skill Set
August 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules —
Mistake #7: Not Having a Well-Defined Scope
June 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules —
Mistake #6: Not Having Strong Sponsorship
April 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules —
Mistake #5: Not Having the Right Business Infrastructure
February 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules —
Mistake #4: Not Managing Business Rules from the Start
January 2011
Top 10 Mistakes Business Analysts Make When Capturing Rules —
Mistake #3: Assume Everyone Knows What a Business Rule Is
December 2010
Top 10 Mistakes Business Analysts Make When Capturing Rules
Mistake #2: Not Focusing on Terminology
November 2010
Top 10 Mistakes Business Analysts Make When Capturing Rules
Mistake #1: Treating Business Rules Initiatives Simply As IT Projects
May 2006
Business Rules vs. Business Requirements
October
2004
Organizing
A Pile of Rules
June
2004
Family
Reunion... Facilitated Session… Having the Right People Doing the Right Things
November
2003
Family
Reunion ... Facilitated Session -- Same Difference
September
2003
A
Relationship between Process and Business Rules
July
2003
The
Hidden Secrets about a Business Rule
May
2003
Plainly
Speaking: What Is A Rule?
May
1998
Business Knowledge ~ Packaged in a Policy Charter Policy Charter as a Deliverable
|