OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules)[1] last month – comprehensively reorganized for approachability, but not changed.[2] Some thoughts … ~~~~~~~~~~~~~~~~~ Ever hear the conversation that three baseball umpires once had? If you don’t live in a baseball country, it’s an archetypical story, so you’ve probably heard some variant. By the way, in American English a ‘pitch’ is a throw of the ball for the batter to try to hit, not the field of play. Meanings matter!

• The first umpire says, “Some pitches are balls and some are strikes. I call them as they are.”
• The second umpire says, “Some pitches are balls and some are strikes. I call them as I see them.”
• The third umpire says, “Some pitches are balls and some are strikes. But they aren’t nothing till I call them.”

Most modeling techniques primarily focus on modeling the real world as it ‘really is’. They essentially take a first-umpire point of view or maybe second-umpire. I come from that tradition too. My 1987 book Entity Modeling was about doing that … modeling the real world as it ‘really is’. Pretty much all professionals with some IT background come from that world. Working with business people and business rules for the last 25 years, however, has taught me that business is really more of a third-umpire world. Think of laws, regulations, statutes, contracts, agreements, terms & conditions, policies, deals, bids, deeds of sale, warranties, prospectuses, citations, complaints, receipts, notices … and business policies. Even businesses that deal with tangible stuff (e.g., railroads, electrical transmission, infectious diseases, etc.) live in a third-umpire world. And many of the most automated organizations around have no tangible product at all (e.g., finance, insurance, government, etc.). They really exist only in a world of words (between people). It’s humbling to realize that the way the business world ‘really is’ is more directly the product of words exchanged by the players in a conversation game than anything IT professionals can model directly. But why would it be otherwise? Do IT professionals really know better than business owners, business managers, lawyers, engineers, subject matter experts, etc.? Really?! SBVR, in contrast to almost all other standards, doesn’t try to model the way the real world ‘really is’. Instead, its focus is on modeling what is said about the way the world really is. It’s fundamentally a third-umpire standard. You simply have to understand what the words mean – and that’s a human-communication issue. Yes, the SBVR world view is a game changer. It also happens to align closer with some of the most exciting new work in computerization today including cognitive computing and machine learning. I stand accused by peers in the standardization community of wanting to go beyond the ‘capture, exchange and production of information’. Sure, I can live with that. ~~~~~~~~~~ www.BRSolutions.com

I have said many times programmers, even semantic programmers, are not the wave of the future for business rules. The future lies with enabling business people and business analysts to have dialogs with machines coming as close to unambiguous statements as they can (e.g., in RuleSpeak). The machine should ask questions to reduce ambiguity to an acceptable minimum. To protect against liability, the machine should log all assumptions, major and minor, in translating to an internal (formal and unambiguous) form so that results are traceable and improvable. Consider IBM Watson. If machines can win at Jeopardy against the best players in the world, that’s a pretty impressive feat for natural language capability. Let’s compare apples to apples. There will always be translation of business ”requirements” from human form to machine form. Even some perfect (a.k.a. formal semantic) implementation language would not reduce translation errors to an absolute minimum. Coders would still have to translate, and errors compound with every translation. So I say disintermediate; eliminate the middlemen – i.e. the coders. If you look across a great many industries, that’s the trend. Why should development of business applications be any different? I also suspect that any “formal semantic” language for business rules would inevitably be English-biased. That’s simply not acceptable in a global economy. RuleSpeak[1] has gathered increasing attention around the world. There are now versions in the works for Norwegian, Polish and Japanese, in addition to the original English and the existing Dutch, German and Spanish translations. A growing number of people find that RuleSpeak strikes just about the right balance between structured and unstructured expression. I’m not saying, however, that other useful approaches couldn’t be more formal – or less formal – than RuleSpeak. Perhaps they could. And that’s been my point for all these years working on SBVR[2] as a business rule standard. We simply don’t yet know the absolute best approach for expressing all business rules in all circumstances. No one knows enough. Perhaps there isn’t one. SBVR is brilliant precisely because it captures semantics without dictating expression form. Long term, that’s exactly what the industry needs. No, there hasn’t been rapid vendor implementation of SBVR since release of 1.0. I wouldn’t expect there to be. It threatens virtually every interface and mindset on the planet. Most people in the IT field still just don’t get it. In retrospect, OMG may have been the wrong forum for SBVR for at least two reasons:

1. OMG is the bastion of best-of-breed programming standards. Obviously there is an important role for that, but as above SBVR isn’t about programming.

2. The SBVR vocabulary is extremely useful for organizing business conversations about business vocabulary and business rules. OMG doesn’t ‘do’ business-facing standards of that kind (i.e., ones that don’t “compute”). IMO, that’s a major shortcoming. There is ultimately nothing more important than improving communication at the level of people. Get it wrong there and I promise it will be wrong in business automation, no matter how elegant the implementation language.

The bottom line is that machines for business (rule) automation now must learn to ‘speak’ human languages. The other way around is simply no longer acceptable – or even necessary. www.BRSolutions.com  

---

 

Comment by DMN proponent: In common business use the term “decision” is often overloaded to mean “decision output”. So I “make a decision to do X” is the act, whereas I “use the decision as input to another decision” is referring to the decision output. I’m not sure there are any semantic issues with (i.e. possible problems caused by) this overloading? My response: Since DMN is a standard (and in particular claims to be a business standard), then it must stick with its own definition of terms in all cases. Otherwise, in what sense is it a standard (especially a business standard)? In defining “decision” DMN had two fundamental choices (from Merriam-Webster Unabridged dictionary): 1. a : the act of deciding; specifically : the act of settling or terminating (as a contest or controversy) by giving judgment 1. b : a determination arrived at after consideration : SETTLEMENT, CONCLUSION DMN explicitly chose the first meaning. I strongly prefer the second, but then I’m a big fan of all things declarative. So in BRS TableSpeak[1] an outcome by definition is a decision. Since DMN explicitly chose the first meaning, however, an outcome (conclusion) is by definition *not* a decision. A decision is an act, never the result of the act. Hey, I’m just reading what is written in the standard. If DMN somehow allows ‘overloading’ of the term “decision” — the central term in the standard — all bets are off. A term that you can use any way you want when it happens to suit you is a term that has not been standardized at all. The result is semantic muddle. Pretty big deal. Sorry! www.BRSolutions.com  

      In classifying ‘rules’ I go by the standards … Business Motivation Model (BMM): business policies vs. business rules

• Business rules are always practicable – workers can apply them directly.
• Business policies are not – they must be interpreted first.

SBVR: definitional rules (necessities) vs. behavioral rules (obligations) vs. advices (possibilities or permissions).

• Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
• Behavioral rules are about shaping conduct (and can be violated).
• Advices are non-rules; they provide practicable guidance but do not remove any degree of freedom.

I would add only these observations: 

• The kinds of rules you see in decision tables are generally definitional. Since they represent only a subset of all definitional rules I call them ‘decision rules’ for convenience.
• Condition-Action or Event-Condition-Action (ECA) rules are not business rules at all. They are representations of business rules (for a class of implementation platforms).
• My smart phone can tell me in spoken English where the nearest gas station is. It’s only a matter of time before machines start ‘reading’ regulations, contracts, agreements, business policies, etc. to help people formulate (through dialog) practicable (and implementable) business rules. Can you imagine the productivity benefits?!
• Decision tables are great. Everybody should use them. But they are a lot harder to design well than you might think.
• The DMN standard can move things along significantly … if it is good, and it isn’t overhyped (which it already has been in certain quarters). I’m looking forward to it impatiently. But standardization (in equal parts a political process and a technical process) do take some time!

1. No government or regulatory or similar body should issue operational policy unless the vocabulary is fully and precisely defined (in people language, as possible under SBVR) and the business rules are spelled out in practicable form (as in RuleSpeak). Try to imagine the amount of time and energy wasted because everybody has to do their own interpretation. Ridiculous in a knowledge economy. (Same basically true for legal contracts and agreements, etc.) There ought to already be an eMarket in off-the-shelf, industry-specific know-how models (vocabulary and rules). It will happen … sooner or later. 2. Is the DMN standard going to solve all your problems? No, of course not. It’s an important step in the revival and reinvigoration of decision tables, but you can already see all-too-familiar patterns of hype and misguided thinking. Yes, I would like the standard … needed badly (if it turns out to be good — an open question, but I sure hope so). 3. The OMG mission focuses on machine interoperability. When people need so badly to speak to other people precisely, and in a day and age when machines have become so powerful that they can begin to speak limited people language, isn’t perhaps the OMG mission a bit outdated or incomplete?

A person close to the DMN (Decision Model Notation) standard recently wrote:

In DMN a decision is deliberately defined very broadly … 

“a decision is the act of determining an output value (the chosen option), from a number of input values, using decision logic defining how the output is determined from the inputs”.

My Response I’ve already written that the DMN definition of “decision” seems to be a bit circular. (To know what a “decision” is you need to know what “decision logic” means. But since “decision logic” says “decision”, seems like you need to know what “decision” means.) Let me tell you what else I find wrong with the definition. (All dictionary definitions from MWUD.) Problem 1. MWUD defines “decision” as (1a) the act of deciding. It defines “act” as (1a) a thing done or being done. So which is it? Is a decision a thing “done” or a thing “being done”? In other words, is a decision the result of an action or process, or the performance of an action or process? Big difference! Which does the standard mean? Some clarity would be nice. Problem 2. MWUD defines “decide” as: to dispel doubt on: (a) to arrive at a choice or solution concerning which ends uncertainty or contention *decide what to order for breakfast*  (c) to infer or conclude from available indications and evidence So the real-world definition of “decide” talks about …

• Arriving at “a choice or solution”.
• Basing that choice or solution on “indications and evidence”.

Do you see anything in that definition that reduces what is used in making decisions to “inputs” and “outputs”?! That’s ITspeak, not businessSpeak. So let’s not pretend the DMN standard is really about business modeling per se. It’s business reduced to a system view. Problem 3. “Input value” is definitely ITspeak. Fields and attributes in files and databases are what have this kind of “value”. In the business world, people talk about cases, applications (appeals, requests, petitions), communications, situations, circumstances, trends, profiles, and the like. They don’t talk about “input values” to a decision. Get real. Again, the authors of the DMN standard should either be clear it’s really about system stuff … or admit to causing confusion, deliberately or otherwise.

A person close to the DMN (Decision Model Notation) standard recently wrote:

“Under DMN we would say that the automatic detection of the violation of a constraint is indeed a decision.”

My Response … Which part of any definition of any of the following terms in your statement would in any way, shape or form lead to the notion of “decision”?!

• automatic
• detection
• violation
• constraint

You’ve put you finger squarely on the three confusions (shortcomings) I fear most from the DMN standard — failure to:

1. Comprehend that behavioral rules are a quite different animal from decision (or definitional) rules.
2. View “decision” from a businessperson’s point of view.
3. Define “decision” as meant in the real world.

Is this going to put another standard emanating from an IT background parading as a “business” paradigm? Another standard where hype beneficial to existing vendor products outweighs true clarity and innovative leadership? I am hoping for the best … I want the standard (if good) to succeed … but fear the worst. I’m afraid your statement doesn’t instill much confidence.

An enterprise architect recently said to me, “The motivation (why) column of the Zachman Architecture Framework is the most underrated, underutilized construct in architecture.” Absolutely correct. Even worse, IT methodologies (that is, the people who create and use them) don’t realize how far afield they are on the matter. As a result they cause business people to focus on the wrong things … or to drop out entirely. Ironically, IT then becomes the impediment, rather than the solution, to much needed business innovation. A bit of background: The Business Rules Group (BRG – www.BusinessRulesGroup.org) identified the area of business strategy as a missing ingredient for business rules in the mid 1990s. In 2000, we came out with a standard for the area, now sponsored by OMG, called the Business Motivation Model. It’s a highly readable document with lots of good examples (and free): http://www.businessrulesgroup.org/bmm.shtml. It provides standard vocabulary and structure for strategy. Zachman, by the way, was a key participant. I am proud of my role as co-editor and author of the first working draft. My business partner, Gladys S.W. Lam, and I have just come out with a new book that explains how strategy (and business rules) can be an integral part of business analysis. It’s actually not that hard to do (if you have the right people, motivation, scope, and approach), and it doesn’t take all that long (ditto same caveats). Those are big myths. Gladys is generally given credit for some of the key ideas in the standard. She grew up in a highly entrepreneurial environment and has a natural sense of business risks and solution sinkholes. But I digress … See Chapter 4 of Building Business Solutions: Business Analysis with Business Rules – http://www.brsolutions.com/b_building_business_solutions.php.

If you want to hear state-of-the-art machines (bots) talk to each other, see: http://goo.gl/LEIMI Funny! Rude and petty … just like humans sometimes. I don’t think we’re quite there on Star-Trek-style communication with machines(!). If you want to see a suitable set of guidelines for writing unambiguous business rules that machines should be able to understand, see www.RuleSpeak.com (free). RuleSpeak was one of the three reference notations used in creating SBVR, the OMG standard Semantics of Business Vocabularies and Business Rules. (SBVR doesn’t standardize notation.) Don’t try to read the SBVR standard – it’s for logicians, linguists and software engineers. For insight into what SBVR is about, see the SBVR Insider section on www.BRCommunity.com. SBVR itself is a structured vocabulary – essentially a concept system. Clause 11 provides a structured vocabulary for creating structured vocabularies. Clause 12 provides vocabulary for business rules. ‘Structured’ in this context means it includes both noun concepts (nothing unusual about that) and verb concepts (highly unusual). You need verbs to write sentences (propositions). Try writing a 100 business rules without standard verbs. Well, you can do it, but what you’ll get is spaghetti logic and hopeless, bot-like(?) communication.