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


We systemize tacit knowledge into explicit knowledge

Blog Enabling Operational Excellence

Posts Tagged ‘definitional rule’

Legality and Business Rules

How does legality work with business rules? To say that differently how should an intelligent tool work so as to help you establish the business regimen you want to follow where legality is involved? Consider the example of Same-Sex Marriage. Let’s suppose you want to make it illegal. SBVR[1] does not have an innate concept/approach for “legality” in the sense of MWUD[2] 1: attachment to or observance of law. So if you wanted “is legal” in the most direct sense, you must define a unary verb concept for the concept Same-Sex Marriage. In a looser sense, if you are in an organization (business) with the standing to define business rules, you could do several things, as follows. (I’ll make up a bit of vocabulary here.) 1. Specify a behavioral rule A behavioral rule is one that can be potentially violated by people or organizations. The relevant rule might be expressed as follows:

The people united in a marriage must not be of the same gender.

Then you would decide how strictly you want to enforce the rule. Options range from strictly enforced to guideline. The rule would be active when a relevant state of affairs arose (i.e., specific people get married). 2. Define several definitional rules A definitional rule is one that cannot be violated; it exists to ensure the consistency of the concept system you chose to follow. Relevant definitional rules might be expressed as follows:
    • The people united in a marriage are not to be of the same gender.
    • The people united in a same-sex marriage are to be of the same gender.
See the conflict? Your friendly intelligent tool would (immediately) disallow one or the other specification. The rules are clearly in conflict; the logical conflict would simply not be allowed to stand. 3. Define the relevant definitions
    • Marriage: the uniting of people of different genders in wedlock
    • Same-Sex Marriage:  the uniting of people of the same gender in wedlock
Again, your friendly intelligent tool would (immediately) disallow one or the other specifications. The definitions are clearly in conflict; the logical conflict would simply not be allowed to stand. Actually, under the covers, approaches 2 and 3 work exactly the same way In SBVR. SBVR recognized that some people prefer to do things via rules, some with definitions, and if truth be told, most times you will do some of both. ~~~~~~~~~ www.BRSolutions.com  

[1]Semantics of Business Vocabulary and Business Rules
[2]Merriam-Webster Unabridged Dictionary

Continue Reading

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

Classifying Business Rules: I Go By What the Standards Say

      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!

Continue Reading

Q&A: Simplifying Business Process Models and Achieving Dynamic Business Processes – All By Using Business Rules

The OMG standard  SBVR[1] distinguishes between two fundamental kinds of business rules[2]:
    • Definitional rules (including decision rules) are about shaping knowledge (and cannot be violated).
    • Behavioral rules are about shaping conduct (and can be violated).
Question: Should definitional rules be included in business process models? Answer: You might have 100s or 1,000s of business rules about determining creditworthiness. In what sense is directly including all those business rules in a model of a business process useful? (Note carefully I said business rules, model, and again business (process).) So my answer is no, don’t include them. Question: Or, to put it another way, do we simplify business process models by removing only the behavioral rules? Answer: Again, no. Question: And am I right in assuming that these behavioral rules are associated with decision points in process flow charts, and what we are being urged to do is eliminate decision diamonds from those charts? Answer: Assuming you mean binary branch points in traditional flowcharts, I’ve seen both definitional and behavioral rules modeled procedurally by those. Traditional flowcharting is spectacularly unsuccessful for behavioral rules, because as I’ve said many times, each generally has two or more flash points[3] where it could be violated and needs to be checked. Those flash points could be in completely different flow charts (or procedures or use cases). Consider this simple business rule: An agent must be assigned to a customer that has placed an order. Flash points:
    • When the first order is placed by a customer.
    • When an agent leaves the company (which could leave an order-placing customer without an agent).
How likely is the second event to be handled by the same flowchart (or procedure or use case or even business process) as the first? That’s why business rules need to be a first-class citizen in the requirements world. It is also why we need ‘watchers’ outside the process (automated as much as possible) to:
    • Detect violations of behavioral rules (like cops and referees).
    • Permit dynamic invocation of selective (read “selectively different”) responses.
Call the result dynamic process or what you will; behavioral rules are the pragmatic means to stitch together highly responsive business activity in real-time operational activity. ~~~~~~~~~~~~~~~~ If you liked this blog post you might also enjoy: http://www.brsolutions.com/2012/05/01/r-i-p-straight-line-old-school-processes/

[1]Semantics of Business Vocabulary and Business Rules. Release 1.0 of SBVR came out in Dec, 2007. For more information see the SBVR Insider section on BRCommunity.com.
[2]For logic wonks, the distinction is based (very carefully) on necessities (alethic modal logic) vs. obligations (deontic modal logic).
[3] For more on flash points see my blog post: Flash Points: Where Business Rules Meet Events http://goo.gl/pl9sT

Continue Reading

To: Business Process Manifesto … From: Business Rules Manifesto … Re: How Business Processes and Business Rules Relate

When the Business Rules Manifesto was published in 2003 (http://www.businessrulesgroup.org/brmanifesto.htm), I co-proposed the six items below related to business processes as an additional (eleventh) Article. The Business Rules Group (BRG) decided (probably wisely) to avoid that potentially controversial area, however, and concentrate on the core message of business rules. Since a Business Process Manifesto has been in the works, it’s worth going back over the proposed items. I believe they remain valid. So I dug them out of my Editor archives, cleaned them up a bit, and presented them below. Aside: In 2003 the BRG wasn’t careful about saying “business rule” (instead of just “rule”) and business process (instead of just “process”). But that’s what we meant – real-world rule and real-world process – not technical specifications. I’m very careful about that clarification these days. A great many people have a hard time seeing the difference. Item 1. Business rules guide business processes.

Comment: If this one is not self-evident, all bets are off.

Item 2. Business rules should be substituted for any activity in a business process where the result(s) of that activity can be produced by the business rules.

Comment: This item refers to what SBVR calls definitional rules – business rules that can derive, classify or compute something. For any given ‘something’, there might be only a single business rule, or a very large number of business rules. The ‘something’ could be an operational business decision requiring many dozens or hundreds of decision rules organized into decision tables.

One thing the item doesn’t say is that not all such ‘somethings’ need to be supported by business rules from the very beginning. In fact as Item 8.5 says, they don’t need to be. Business rules are very good for incremental development. (Development of what? Smart business processes.)

Item 3. Business rules can cause business processes to be initiated under appropriate circumstances.

Comment: Circumstances can arise that require the business to respond in a pre-scripted manner – e.g., low inventory status, potential fraud or intrusion, etc. Some business rule(s) should identify the circumstances involved in such ‘spontaneous’ business events.

Item 4. The default explanation or message for any error that occurs in a business process for a business reason is a business rule.

Comment: This item is truly ground-breaking. Business rules express the do’s and ‘don’ts’ of business activity; therefore, any error that occurs under a business process for a business reason is ‘explained’ by a business rule. What else could it be?!

Keeping systems carefully aside, and noting the obvious possibility of providing additional or alternative ‘explanations’, I like to say ‘the business rules are the error messages’. By the way, I’ve been saying that since 1994 – I have the slides (transparencies actually) to prove it. If you have doubts about this item, please provide examples(!).

Item 5. Any delay in the ability to enforce a business rule must be coordinated with business processes.

Comment: In SBVR, behavioral rules are business rules that can be violated. (Definitional rules can’t be.) An example where such delay might occur is a business rule that requires an approval or sign-off on something (e.g., an extra-large order on credit) by somebody (e.g., the branch manager) who is not immediately available. The business process for that particular something must be suspended until some future time.

Note: Additional business rule(s) providing appropriate suspense criteria (e.g., 24 hours) would be wise in such cases. We don’t want an order sitting in limbo forever(!).

Item 6. Business rules cannot constrain the workings of a business process directly, but only the following: (a) the state required for the business process to be performed; (b) the state while the business process is being performed; and (c) the results – that is, the state – the business process seeks to leave behind when finished.

Comment: I think of a business process as being like a black box with respect to business rules. The business rules cannot and should not ‘look’ inside. Instead, all matters of state should be externalized so business rules – and business people – can know it and talk about it. Get ready for this: This item indicts BPMN with its token-based approach to process state. The future lies with externalizing semantics. Sorry guys!

Continue Reading 24 Comments