Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence
Enabling Operational Excellence

TURNING OPERATIONAL KNOWLEDGE & COMPLIANCE INTO A COMPETITIVE EDGE

We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘Semantics of Business Vocabulary and Business Rules’

The Two Fundamental Kinds of Business Rules: Where They Come From and Why They Are What They Are

The two fundamental kinds of business rules relevant to business analysis are definitional rule and behavioral rule. These two kinds of rule come from OMG’s SBVR (Semantics of Business Vocabulary and Business Rules) standard.[1] They have very precise meanings based on formal logic. Here’s some background about that – more than business analysts really need to know, but informative nonetheless. At the end of the discussion I give pragmatic definitions. And the answer to the photo quiz. The SBVR definition for rule is deeply embedded in formal logic, which deals with propositions.  In modal logic, propositions can claim different modes. For business rules the two relevant modes are alethic and deontic.  
  • Alethic rules are true ‘by definition’. As such they cannot be violated.  They are about how concepts, knowledge or information are defined or structured.
  • Deontic rules are rules that can be violated. They are rules about behavior, not concepts, knowledge or information. Deontic rules are really about people, what they must and must not do, even if their activity (and the rules) are automated.
Both kinds of rules are important, of course, but deontic rules – people rules – are especially so since ultimately, businesses are about the activity of people. This situation is very different than in the semantic web, for example, where it’s all about only knowledge. Under modal logic, every rule must therefore ‘claim’ one of two modes. (In practice, the ‘claim’ arises naturally from the syntax of a rule statement or as a meta-property.)
  • Alethic implications (rules) are established by ‘claiming’ necessity. Things are necessarily true. A concept is what it is; says what it says. That’s just the way things are.
  • Deontic implications (rules) are established by ‘claiming’ obligation. Behavior is ‘obliged’ to follow the rule. But of course, people don’t always follow the rules, so there can be violations. Major difference.
So a rule ‘claims’ either necessity or obligation, which establishes what kind of rule it is. Therefore the SBVR definitions for the two kinds of rule are:
  • Definitional rule:  rule that is a claim of necessity
  • Behavioral rule:  business rule that is a claim of obligation
Why doesn’t the definition for definitional rule say “business rule” like the one for behavioral rule? Because some definitional rules are not ‘under business jurisdiction’ (in other words, business has no choice about them). Examples include the ‘law’ of gravity and all the rules of mathematics. Those rules are simply universally true. I recommend the following pragmatic definitions for business analysts.
  • Definitional rule:  a rule that indicates something is necessarily true (or untrue); a rule that is intended as a definitional criterion for concepts, knowledge or information
  • Behavioral rule:  a business rule that places an obligation (or prohibition) on conduct, action, practice, or procedure; a business rule whose purpose is to shape (govern) day-to-day business activity
Synonyms:  Early in the development of SBVR I introduced the terms structural rule and operative rule for the two kinds of rules, respectively. That was before the full implications of modal logic became clear. Since then the terms definitional rule and behavioral rule have become preferred, even in all internal SBVR discussion. The synonyms, however, remain valid. P.S. Did you guess correctly which kind of rule is represented in the photograph? Behavioral, of course. And the photo itself is a violation of the rule. www.BRSolutions.com


[1] For more information about SBVR see the SBVR Insider section on www.BRCommunity.com.

Continue Reading

What is a Concept Model?

A concept model organizes the business vocabulary needed to communicate consistently and thoroughly about the know-how of a problem domain. A concept model starts with a glossary of business terms and definitions. It puts a very high premium on high-quality, design-independent definitions, free of data or implementation biases. It also emphasizes rich vocabulary. A concept model is always about identifying the correct choice of terms to use in communications, including statements of business rules and requirements, especially where high precision and subtle distinctions need to be made. The core concepts of a business problem domain are typically quite stable over time.[1] Concept models are can be especially effective where:
    • The organization seeks to organize, retain, build on, manage, and communicate core knowledge or know-how.
    • The project or initiative needs to capture 100s or 1,000s of business rules.
    • There significant push-back from business stakeholders about the perceived technical nature of data models, class diagrams, or data element nomenclature and definition.
    • Outside-the-box solutions are sought when reengineering business processes or other aspects of business capability.
    • The organization faces regulatory or compliance challenges.
Definition of Concept Model

a model that develops the meaning of core concepts for a problem domain, defines their collective structure, and specifies the appropriate vocabulary needed to communicate about it consistently

The standard for concept models is the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR).[2] Concept Model vs. Data Model A concept model differs from a data model in important ways. The goal of a concept model is to support the expression of natural-language statements, and supply their semantics – not unify, codify (and sometimes simplify) data. Therefore the vocabulary included in a concept model is far richer, as suits knowledge-intensive problem domains. In short, concept models are concept-centric; data models are thing-entity-or-class-centric. Data models can usually be rather easily derived from concept models; the reverse is much harder (or impossible). Like data models, concept models are often rendered graphically, but free of such distractions to business stakeholders as cardinalities. The Components of Concept Models[3] Noun Concepts. The most basic concepts in a concept model are the noun concepts of the problem domain, which are simply ‘givens’ for the problem space.
    • For BACCM these basic noun concepts are: need, stakeholder, value, change, context, and solution.
    • In finance, basic noun concepts might include financial institution, real-estate property, party, mortgage application, lien, asset, loan, etc.
Verb Concepts. Verb concepts provide basic structural connections between noun concepts. These verb concepts are given standard wordings, so they can be referenced unambiguously.
    • In BACCM some basic wordings for verb concepts include: Value is measured relative to Context, Change is made to implement Solution, Stakeholder has Need.
    • In a financial business, some basic wordings for verb concepts include: Lien is held against Real Estate Property, Party requests Loan, Asset is included in Mortgage Application.
Note that these wordings are not sentences per se; they are the building blocks of sentences (such as business rule statements). Sometimes verb concepts are derived, inferred or computed by definitional rules. This is how new knowledge or information is built up from more basic facts. Other Connections. Since concept models must support rich meaning (semantics), other types of standard connections are used besides verb concepts. These include but are not limited to:
    • Categorizations – e.g., Person and Organization are two categories of Party.
    • Classifications – e.g., ‘Toronto Dominion Bank’ is an instance of Financial Institution.
    • Partitive (Whole-Part) Connections – e.g., Dwelling and Land are two Parts of a Real Estate Property.
    • Roles – e.g., Applicant is the role that Party plays in the verb concept Party requests Loan.
Strengths A concept model:
    • Provides a business-friendly way to communicate with stakeholders about precise meanings and subtle distinctions.
    • Is independent of data design biases and the often limited business vocabulary coverage of data models.
    • Proves highly useful for white-collar, knowledge-rich, decision-laden business processes.
    • Helps ensure that large numbers of business rules and complex decision tables are free of ambiguity and fit together cohesively.
Limitations A concept model:
    • May set expectations too high about how much integration based on business semantics can be achieved on relatively short notice.
    • Requires a specialized skill set based on the ability to think abstractly and non-procedurally about know-how and knowledge.
    • Involves a knowledge-and-rule focus that may be foreign to stakeholders.
    • Requires tooling to actively support real-time use of standard business terminology in writing business rules, requirements, and other forms on business communication.
For more information about Concept Models, refer to Business Rule Concepts 4th ed, by Ronald G. Ross, 2013, Part 2. www.BRSolutions.com


[1] Ronald G. Ross, “How Long Will Your Fact Model Last? — The Power of Structured Business Vocabularies,” Business Rules Journal, Vol. 12, No. 5 (May 2011), URL:  http://www.BRCommunity.com/a2011/b594.html
[2] This discussion is consistent with that standard, but explains concept models from a business point of view. See the SBVR Insider section of www.BRCommunity.com for more information about SBVR.
[3] The first set of examples in each of the following two subsections is from the Business Analysis Core Concepts Model (BACCM), a part of the IIBA’s Business Analysis Body of Knowledge (BABOK), version 3.

Continue Reading

Single Source of Business Truth

Re-engineering knowledge work is the central problem of the knowledge economy. In recent work at Centers for Disease Control (CDC) and current work a major bank in Canada we used RuleSpeak® to create what I call a “single source of truth for operational business IP (intellectual property)”. This is far more than a conceptual data model. Beyond structured business vocabulary its central feature is comprehensive rules. It may be like what some professionals call a “conceptual ontology” (as opposed to an operational ontology to be embedded in IT systems). But we would never use the term “ontology” in our work.  Most business people and SMEs simply wouldn’t ‘get’ that. The idea is that all audiences (or subcommunities) in an organization should work off a single trusted source of explicit know-how (business vocabulary and business rules), no matter what their specific responsibilities:
    • producing training materials for line workers.
    • making changes in operational policies.
    • providing proof of compliance for auditors.
    • creating new products.
    • communicating with IT.
Here are some key observations about our work to create a single source of business truth:
    • Our primary audience is not IT. Yet our work is of sufficient precision that straightforward translation into an implementation form can basically be taken as a ‘given’.
    • Our approach recognizes that people are the essential ingredient in business (as opposed to other kinds of knowledge problems). People can violate rules. For coordinating the work of people, direct support for behavioral rules, not just definitional or decision rules, is a must.
    • Our work could not be undertaken without a structured natural language for business rules like RuleSpeak. The non-IT audiences do need rich business semantics, but they have no desire whatsoever to become semantic programmers. They simply would not commit if the work were conducted on that basis.
    • No one today knows what the optimal syntax is for expressing all forms of business know-how in all circumstances. I suspect there isn’t one. That fact, plus the exponential increase in computer capability for processing natural language, indicates clearly that focusing on syntax is simply the wrong direction. RuleSpeak is based on, and was one of the reference languages for SBVR (Semantics of Business Vocabulary and Business Rules, on OMG standard), which supports a non-syntax approach. A language for ‘speaking’ with computers that is not a computer language – now that’s an idea whose time has definitely come!
www.BRSolutions.com

Continue Reading 1 Comment

What is a Business Rule?

It’s become more and more apparent that software vendors are misleading people (badly) about the true meaning of ‘business rule’. Time to set the record straight. Here is an authoritative 3-part explanation. Take a moment and reacquaint yourself. As a business-oriented professional you’ll be glad you did!

   Reference Sources

[MWUD] Merriam-Webster Unabridged Dictionary (Version 2.5).  [2000].  Merriam-Webster Inc.
[SBVR] Semantics of Business Vocabulary and Business Rules (SBVR) (Version 1.0).  [January 2008].  Object Management Group.
  1. Rule When we say rule we always mean real-world rule. Here’s the dictionary meaning of “rule”. That’s what we mean.

[MWUD ‘rule’ 1a]:  guide for conduct or action; [MWUD ‘rule’ 1f]:  one of a set of usually official regulations by which an activity (as a sport) is governed [e.g.,] *the infield fly rule* *the rules of professional basketball* ; [MWUD ‘criteria’  2]:  a standard on which a decision or judgment may be based

A real-world rule always tends to remove some degree of freedom.  If it does not, it’s not a rule.  2. Under Business Jurisdiction    When we say business rule we mean only rules that the business can opt to change or to discard. A business rule is always under business jurisdiction of your organization.  The point with respect to external regulation and law is that your organization has a choice about how to interpret the regulations and laws for deployment into its day-to-day business activity – and even whether to follow them at all. So external regulations are not business rules per se. Business rules include only the rules that a business creates in response to external regulation. SBVR explains: 

“The laws of physics may be relevant to a company … ; legislation and regulations may be imposed on it; external standards and best practices may be adopted. 

These things are not business rules from the company’s perspective, since it does not have the authority to change them. 

The company will decide how to react to laws and regulations, and will create business rules to ensure compliance with them.  Similarly, it will create business rules to ensure that standards or best practices are implemented as intended.”

3. Business Rule

[SBVR]:  a rule that is under business jurisdiction

A business rule is a criterion used to:
    • guide day-to-day business activity
    • shape operational business judgments, or
    • make operational business decisions. 
A number of years ago, a colleague of ours, Mark Myers, came up with a highly pragmatic test to determine whether some statement represents a business rule or a system rule.  It almost always works.  Imagine you threw out all the systems running your business and did it all by hand (somehow).  If you still need the statement, it’s a business rule.  If you don’t, it’s not.  A colleague on the SBVR standardization team, Don Baisley, puts it another way:  “Business people don’t set variables and they don’t call functions.” Some people think of business rules as loosely formed, very general requirements.  Wrong.  Business rules have definite form, and are very specific.  Each should give well-formed, practicable guidance Here are a few simple examples expressed in RuleSpeak:  

A customer that has ordered a product must have an assigned agent. 

The sales tax for a purchase must be 6.25% if the purchase is made in Texas. 

A customer may be considered preferred only if the customer has placed more than $10,000 worth of orders during the most recent calendar year.

Business rules represent a form of business communication and must make sense (communicate) to business people.  If some statement doesn’t communicate, it’s not a business rule. 

Consider this example:  If ACT-BL LT 0 then set OD-Flag to ‘yes’.  Not a business rule. 

Consider another example:  An account must be considered overdrawn if the account balance is less than $0.  This statement communicates and therefore is a business rule. 

More observations about business rules:
    • In SBVR a business rule can be either a behavioral rule or a definitional rule.
    • Business rules can be technical, but only in terms of the company’s know-how or specialized product/service, not in terms of IT designs or platforms.
    • Expression of business rules should always be declarative, rather than procedural.
    • A business rule statement should use terms and wordings about operational business things that should be based on a structured business vocabulary (concept model).
    • Your company’s business rules need to be managed and single-sourced, so we strongly recommend rulebook management.
Business rules are not about mimicking intelligent behavior, they are about running a business Mimicking intelligent behavior in a generalized way is far harder (an order of magnitude or more) than capturing the business rules of an organization.  Unfortunately, expert systems have generally focused on the former problem, causing considerable confusion among business practitioners.  ~~~~~~~~~~~~~~~~~~~~  Excerpted from Building Business Solutions: Business Analysis with Business Rules, by Ronald G. Ross with Gladys S.W. Lam, An IIBA® Sponsored Handbook, Business Rule Solutions, LLC, 2011, 304 pp,http://www.brsolutions.com/bbs

Continue Reading