untitled
Rule Observatory
What happened to the B and the M of BRM?
...and how the new notion of business rules documentation got introduced
by Silvie Spreeuwenberg
At the last Business Rules Forum in Orlando — October 2008 — I heard some speakers using a new term. I don't believe they introduced a new concept... they only used a new word for a concept introduced earlier. The concept I am referring to is the notion that organizations should have an organized way to know what rules are around, why they are around, when they are used, how they are enforced, and who is responsible for them. This notion has been introduced with the name 'business rules management'. But it seems that something unexpected has happened with this term in recent years. Let's have a closer look at the three words in the term 'business rules management' to understand the problem.
business
The IT-hype cycle adds the word 'business' as a modifier to many words representing IT-related artifacts like process, application, requirement, service, and … rule. The meaning of the artifact itself hardly changes when adding this modifier; instead, this modifier is used to indicate that the concept is 'important to the business'. Now, the issue with 'business rule' is that the presentation form of a 'rule for IT' and a 'rule for the business' is very different. The two examples below indicate the different presentation forms.
Business rule (based on SBVR-RuleSpeak):
A discount of 15% must be applied on the shopping cart if the shopping cart contains between 2 and 4 items and one of the following conditions are met:
- the purchase value is greater than $100 and
the customer category is gold
- the purchase value is greater than $200 and
the customer category is silver
IT rule (based on PRR-OCL):
Rule discount
ruleVariable:
?customer: Customer = Customer->any()
?shoppingCart: ShoppingCart = ShoppingCart->any(c: customer | c=?customer)
Condition:
(?shoppingCart.containsItemsInRange(2, 4)
and
(((?shoppingCart.items->collect(i:Item|i.value))->sum()>100 and
?customer.category == "Gold")
or ((?shoppingCart.items->collect(value))->sum() > 200 and
?customer.category == "Silver")))
Action:
shoppingCart.discountValue = shoppingCart.discountValue+15
The meaning of the word 'business rule', following the previously-described trend of adding the word 'business' as modifier to IT-related artifacts, is often misunderstood as 'an IT rule that is important to the business'. Instead, it should be 'a rule that under business jurisdiction'. Unfortunately, the former notion seems to be prevailing in the market that is dominated by IT-related tool and service providers. |
rules
The efforts of the Business Rules Group, the SBVR team, and Ron Ross have disambiguated the word 'rule' in recent years. The now prevailing definition
"is a statement that defines or constrains some aspect of the business"
works very well and I don't believe there is much discussion any more on this topic. |
management
The word 'management' was thought to be unambiguous — 'management' being defined as the whole process of creation, updating, making available for others to use, and explore. However, again due to a prevailing IT-dominated perspective, it has been reduced in one of Gartner's reports (Business Rules Management: State of the Art ESC19_811,11/07, AE) to mean the management of rules through the application life cycle. |
Due to the misunderstanding around the B and the M, you can find business people who are highly disappointed by the support they get from Business Rules Management Suites. I see two important reasons for their disappointment. The first reason is related to the presentation form of the rules. A BRMS requires rules to be written in a rule-syntax ready for execution in an application, but business people are not programmers. Business people do not see the benefits of syntax since their first interest is in clear and understandable rule statements. The second reason is that the support for management of the deployment of rules applications is again more targeted towards IT-departments. Often missing is the support for management information about the rules so that business people can find and explore rules.
Some of the speakers at the Business Rules Forum intuitively felt that the word 'business rules management' did not bring the meaning they had in mind when explaining the improved process for the what, how, when, why, and who of business rules. They had improved the way rules were written in the first place, linked them to different artifacts — like (legal) sources, applications, forms, and brochures — and as a result could easily produce overviews of rules relevant for specific groups in the organization. When I heard them introduce the term 'business rule documentation' for this notion I knew exactly what they meant, and I believe the audience felt that as well.
The word 'business rule' refers now to a rule that is understandable to the business. The word 'documentation' refers to writing the what, why, when, how, and who of business rules. I believe the term 'business rule documentation' is useful to distinguish the real business needs from the IT needs that are now supported by the BRMS market. I am sure a BRD market for tool support will become a professional and well-recognized topic in the business rules community.
| standard citation for this article: |
| Silvie Spreeuwenberg, "What happened to the B and the M of BRM? ... and how the new notion of business rules documentation got introduced," Business Rules Journal, Vol. 10,
No. 3 (Mar. 2009), URL: http://www.BRCommunity.com/a2009/b467.html |
|
|
|
June 2012
Rules that Give You Too Much Freedom
November 2011
Use the Right Tool for your Job
July 2011
Learn from the Expert (Part 3): Get Organized in your Rule Thinking
May 2011
Learn from the Expert (Part 2) — Textual rules: Out of fashion or a Classic?
March 2011
Learn from the Expert (Part 1) — A Business Analyst must ask "Why?"
October 2010
Count your Rules!
July 2010
The Ten Most Common Mistakes Made By Corporate Adopters of Business Rule Management Systems (BRMS) And How to Avoid Them (Part 2)
Guest Column By Jan Purchase
May 2010
The Ten Most Common Mistakes Made By Corporate Adopters of Business Rule Management Systems (BRMS) And How to Avoid Them (Part 1)
Guest Column By Jan Purchase
January 2010
How to Deal with Exceptions in Software Support
December 2009
Exceptions are just 'some more rules'
September 2009
Rule Authoring Is a Creative Process
March 2009
What happened to the B and the M of BRM? ... and how the new notion of business rules documentation got introduced
October 2008
The Liberty of Rules
August 2008
The Inference Task
July 2008
Organizing a Set of Rules
June 2008
Procedural Logic in the Reasoning Process
May 2008
What about Methods in Rules?
April 2008
Different Kinds of Rules and How to Write Them Properly
March 2008
SBVR: Observations from Initial Experiences
January 2008
Rule History and Versioning (Part 3)
December 2007
Rule History and Versioning (Part 2)
November 2007
Rule History and Versioning (Part 1)
September 2007
Flexibility and Business Rules
March 2006
A World Without Rules
November 2005
The Semantic Web and the Business Rules Approach ~ Differences and Consequences
July 2005
The Semantic Web and the Business Rules Approach ~ Differences and Similarities
May 2005
Semantic Web
March 2005
End-user Programming
January 2005
Secret Rules
November 2004
Observations on Business Rules in Europe and the U.S.
|
Drs. Silvie Spreeuwenberg has a background in artificial intelligence and is the
co-founder and director of LibRT. LibRT helps customers assess and improve
the quality of their business rules. Silvie's experience with business rules
modeling has resulted in the development of tools and techniques to increase the
quality of business rules. She writes, "We believe that one should focus
on quality management of business rules to make full profit of the business rules
approach." LibRT is located in the Netherlands; for more information
visit