My very first BPMS Watch column, over three years ago, was titled “Without a BPMS, It’s Not Really BPM.” And to a large degree I still believe that, although today I would probably tone it down to...

Addicted to Code

Observations:

Do you notice how quickly business rules often turn into CodeSpeak? Instead of fully expressing business rules in the natural language of the business, a rules analyst sometimes expresses the business rules only in a structured syntax form or they quickly transform the incomplete or incoherent natural language form into a structured syntax form. The structured syntax form is usually an "If then Else" structure or decision table structure. While these syntax forms are necessary and useful to define the more detail specifications and contexts of the rule, these forms of expression are at a lower level of abstraction of the business rule than the natural language expression of the business rule. Also, the terms used in these forms are often wracked with acronyms and embedded codes. There is often a tendency to shorten the full expression in the writing of the business rule. This can result in expressions of business rules that are harder to read and comprehend, unless one is somewhat familiar with the "CodeSpeak" employed by the writer. "Easy to write, hard to read."

So why does one see this so often? Is it because the objective becomes to rapidly get the business rules ready for IT rules development and a subsequent automation system? Is there no diligence and discipline in fully defining terms, facts, and rules in the natural language of the business? Just take a look at various business rules examples. Sometimes, I think I'm looking at code from a legacy COBOL program. Note: For more information on levels of abstractions for business rules, see my article: Sustainable Business Rules: An Introduction - Part 1 of 3.

Solution Guidance to solving this CodeSpeak Dilemma:

From my research and experience, I've found that it is critical for the rules analyst to consider the following:

• Fully develop the business rule in the natural language of the business before transforming it to lower levels of abstractions.
• Define terms and facts in consistent business language.
• Constantly employ and expand the business glossary.
• Extend terms via contextual definitions of the terms.
• Take steps to eliminate ambiguity.
• Trace the natural language expression of the business rules to the related business policies and guidelines and well as to the detail specifications of the rule.
• Apply the principles of validation and verification to ensure the business rules are complete, non-redundant, consistent, and non-overlapping.
• Use guidelines such as BR Solutions RuleSpeak and Terry Moriarty’s Business Rules Grammar to improve the quality of the expression of the business rule
• Don't present decision tables and decision trees as a replacement for the natural language expression of the business rule. Instead, use them as extremely visual and analytical aids in understanding and presenting the detail specifications of a business rule.
• Use tool aids for expressing rules in the short term.
• Use a comprehensive rules management tool for the long term.

Summary

Rule Quality begins with the complete natural language expression of the business rules and it should continue through the life cycle of the business rule. Earlier problem discovery will result in flexible and agile business rules.

Watch out for CodeSpeak creeping into your business rules. The natural language expression of the business rule needs to be a living artifact. Otherwise, you will be rule harvesting and rule mining down the road once again to really understand "What does the business really mean?".

Ladd M. Bethune is a solutions-oriented technical consultant and innovator with expertise in Business Rules Approaches, Relational Database Tools technology and Reporting Information Systems with over 30 years experience in IT. He can be reached via email: lbethune_brdp@lambert-tech.com

Back to Articles, including BPM, SOA, BDM, BA & OP