Can you understand that all three of the following business rule statements mean the same thing? Here’s what must be true: If you mow the lawn on Sunday your lawn mower is to be electric; otherwise the lawn is not to be mowed on Sunday.

1. It is permitted that the lawn be mowed on Sunday only if the lawn mower is electric.

2. It is prohibited that the lawn is mowed on Sunday if the lawn mower is not electric.

3. It is obligatory that the lawn not be mowed on Sunday if the lawn mower is not electric.

I’m fairly certain you can. And if you can determine they all mean the same thing, I contend a machine ought to be able to do so too. I mean as stated in this exact same human-friendly, structured natural language form. And tell you that the statements mean the same thing (in effect, that they are redundant). That’s the kind of language-smart (cognitive) capability that business innovators should be expecting – no, demanding – from software vendors.

P.S. In the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR) the three statements are a restricted permission statement, a prohibition statement, and an obligation statement, respectively. You might prefer one or another of these forms of statements, but each is correct and reasonably understandable. Here are the RuleSpeak^©[1] equivalents – even more friendly:

1. The lawn may be mowed on Sunday only if the lawn mower is electric.
   
   
2. The lawn must not be mowed on Sunday if the lawn mower is not electric.
   
   
3. (same as 2)

~~~~~~~~~~~~~~~~~~~

Get trained: Instructor-led, online, interactive training: April 4-6, 2017 – Business Analysis with Business Rules: From Strategy to Requirements. http://www.brsolutions.com/services/online/strategy-to-requirements/

©Business Rule Solutions, LLC 2017. www.BRSolutions.com

[1] Free on www.RuleSpeak.com

The standard Semantics of Business Vocabulary and Business Rules (SBVR)[1] offers fundamental insights about how to express business rules well. These common-sense insights can and should directly inform all expression of business rules – and any language that purports to support them. The first of these insights is the notion of practicable, which I discussed in my previous post. See: http://www.brsolutions.com/2015/06/29/practicable-insight-for-expressing-business-rules-well/ The second of these insights is the principle of wholeness. The descriptive text below is taken directly from SBVR itself.[2]Wholeness essentially means each business rule statement can be taken as fully trustworthy even in isolation from all other rules. The principle precludes priority schemes and rules that disable other rules, both of which can act to make any given rule less than fully trustworthy. ~~~~~~~~~~~~~~~~~~~                          Principle: An element of guidance means only exactly what it says, so it must say everything it means. Explanation: Each element of guidance must be self-contained; that is, no need to appeal to any other element(s) of guidance should ever arise in understanding the full meaning of a given element of guidance. The full impact of an element of guidance for a body of shared guidance, of course, cannot be understood in isolation. For example, an element of guidance might be in conflict with another element of guidance, or act as an authorization in the body of shared guidance. The Wholeness Principle simply means that if a body of shared guidance is deemed free of conflicts, then with respect to guidance, the full meaning of each element of guidance does not require examination of any other element of guidance. In other words, each element of guidance can be taken at face value for whatever it says. ~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

The standard Semantics of Business Vocabulary and Business Rules (SBVR)[1] offers fundamental insights about how to express business rules well. These common-sense insights can and should directly inform all expression of business rules – and any language that purports to support them. The first of these insights is the notion of practicable. The descriptive text below is taken directly from SBVR itself.[2]Practicable essentially means all ambiguity has been resolved. As a result, a practicable business rule can be given either to workers to apply ‘manually’, or to IT to implement under some platform, and the results will be exactly the same either way (barring human error or malfeasance). ~~~~~~~~~~~~~~~~~~~~~~~~~~ Definition: the element of guidance is sufficiently detailed and precise that a person who knows the element of guidance can apply it effectively and consistently in relevant circumstances to know what behavior is acceptable or not, or how something is understood Dictionary Basis: able to be done or put into practice successfully; able to be used, useful [Oxford Dictionary of English] Notes:

• The sense intended is: “It’s actually something you can put to use or apply.”
• The behavior, decision, or calculation can be that person’s own.
• Whether or not some element of guidance is practicable is decided with respect to what a person with legitimate need can understand from it.
  • For a behavioral rule, this understanding is about the behavior of people and what form compliant behavior takes.
  • For a definitional rule, this understanding is about how evaluation of the criteria vested in the rule always produces some certain outcome(s) for a decision or calculation as opposed to others.
• A practicable business rule is also always free of any indefinite reference to people (e.g., “you,” “me”), places (e.g., “here”), and time (e.g., “now”). By that means, if the person is displaced in place and/or time from the author(s) of the business rule, the person can read it and still fully understand it, without (a) assistance from any machine (e.g., to “tell” time), and (b) external clarification.

 ~~~~~~~~~~~~~~~~~~~~~~~~ www.BRSolutions.com

I get this question all the time, and it’s a painful one, so let me answer on the record. Question: In our enterprise architecture tooling, there’s a business dimension in which we define Business Concepts (the real business language), and an IT dimension containing Information Objects (data organization model). How can we solve the problem that business expresses rules as they relate to Business Concepts, while IT needs to translate these into rules related to Information Objects? We don’t want to bother business with IT model concerns, nor duplicate the rules in two places. Can you please shed light on an elegant approach to this dilemma? My answer: The standard SBVR[1] provides the ‘elegant’ approach, which is technology that can “read” language based on the business vocabulary (e.g., RuleSpeak) and/or dialog with people to disambiguate those statements. Until such technology is commercially available – and why not, look what IBM Watson can do! – two forms of each statement are unfortunately necessary. The key for your rule management regime is to maintain traceability between them. By the way, the mapping is almost certainly 1:m, not 1:1. I wish I had a better answer, but there just is none today. All I can say is that current implementation technologies for business rules are very, very primitive. ~~~~~~~~~~~ Acks: Tom Andries www.BRSolutions.com