Search ::     [ Advanced ]
Username:   Password: Auto login next time?  


RuleXpress: The business tool for expressing and communication business rules.

AttainingEdge : World Class Training For Critical Business Innovations

 

 

 

 

     LAM ARCHIVES ...
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:

  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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/return to article

[2]  A paper on Q-Charting is available at http://www.brsolutions.com/b_decision.phpreturn to article

[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.htmlreturn to article



standard citation for this article:
Gladys S. W. Lam, "Top 10 Mistakes Business Analysts Make When Capturing RulesMistake #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

 

 

 about . . .

 GLADYS S.W. LAM


Gladys S.W. Lam is an expert IT project manager, consultant, and seminar leader. She has extensive experience in various business contexts, including BPR, strategic IT planning, and managing and implementing information systems. She works closely with companies in developing Business Rule solutions.

Ms. Lam has gained a reputation for fostering positive professional relationships with principal and support staff in projects. Her wide business and technical knowledge is invaluable in achieving consensus among project participants. She has also developed an impressive track record of completing projects on time and within budget. She is committed to achieving quality results within available resources.

 

 

 





[ Home ] [ Staff ] [ About BRC Publications ] [ Editorial Feedback ] [ About BRCommunity ]
[ Contributor's Guidelines ] [ Privacy Policy ] [ Technical Support ]