What happened to the B and the M of BRM? ... and how the new notion of business rules documentation got introduced

What happened to the B and the M of BRM? … and how the new notion of business rules documentation got introduced

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