Celebrating the 10^th Anniversary of the Business Rules Manifesto http://www.businessrulesgroup.org/brmanifesto.htm Question: What does the business rules ‘mantra’ mean? The traditional business rule mantra, a central idea of business rules, dates back to at least the mid-1990s. It is expressed in the Business Rules Manifesto (Article 3.1) this way:

Rules build on facts, and facts build on concepts as expressed by terms.

Perhaps not obvious in the statement is the insistence on declarative expression of business rules. When business rules are expressed declaratively, no meaning (semantics) can be hidden in the sequence of the statements (“in between the lines”). Literally, you can read the statements in any order, and get the same meaning. The liberation of business rules from procedural means of capture and expression (e.g., processes, procedures, use cases, etc.) means that each statement can be validated on its own merit. It also produces the highest degree of reusability (for the business rules). The importance of ‘rule independence’ is expressed by the subtitle of the Manifesto: The Principles of Rule Independence. What do you get when you express business rules declaratively? Encoded knowledge, or as I prefer to say, know-how. The importance of capturing and retaining core business knowledge (know-how) is even more urgent today than when the Manifesto was written in 2002. It is emphasized by the heading of Article 3: Deliberate Knowledge, Not a By-Product (of requirements and IT development). Additional Note: In early 2012, SBVR was revised to focus more directly on real-world language and concepts (always its original intent)[1]. So the Mantra today would be more accurately expressed:

Business rules are based on verb concepts, as expressed by wordings. Verb concepts are based on noun concepts as designated by terms and names.

Literally, you need nouns and verbs to write sentences. A good business rule statement is always a sentence.      

Consider the business rule: A vehicle must not exceed the posted speed limit. Some of the issues for this business rule are (a) how do you detect a violation and (b) how do you respond to a violation. These issues raise the question, whose process is it? Are we talking about the process of the person driving down the street, or the process of the policeperson operating the speed trap? The two processes are obviously related in some way, but definitely not the same. The cop’s process is best viewed as interrupting the driver’s process. Let me come back to that point in a minute. There are two fundamental kinds of business rules[1]:

• Decision rules (or a little more broadly, definitional rules). These are the kind of business rules that expert systems traditionally addressed. It’s the kind you find in decision tasks – e.g., whether someone should be given credit.
• Behavioral rules. These are business rules that can be violated – e.g., speeding down the street, or being off-sides in football. For behavioral rules you need cops or referees or whatever to interrupt a more basic process when a violation occurs. It’s just the natural way to do things (if you don’t want anarchy).

Aside: You might say the examples of behavioral rules I’ve cited (speeding and off-sides) are not automatable. Well, I’m less and less sure about that these days. I see a lot of cameras where I live ‘watching’ for cars running red lights. The camera takes a picture of your license plate and the position of the car in the intersection and you get a ticket in the mail. For the record, I haven’t gotten one. But they do make me more careful about yellow lights. In any case, a great many behavioral rules are automatable. They arise as interpretations of some law, act, statute, regulation, contract, agreement, business deal, MOU, business policy, license, certification, warranty, etc.  For these kinds of business rules, you need a ‘watcher’ outside the process, standing ready to interrupt the process if a violation occurs. A classic example: The fuel rods in a nuclear power plant must be covered with water. If a process of operating the power plant ever violate that rule, I want an immediate violation response to interrupt the guilty process(!). That business rule is about operating a power plant, but the same idea holds true for business processes in general. Detecting violations of behavioral rules is how you can stitch together dynamic processes in real time. Such dynamic processes cannot be achieved by embedding business rules in either a model of the business process, or the process itself. The ‘watcher’ must be on the outside, protecting the interests of the larger (business) community. Such rule independence is the fundamental idea of business rules, as expressed by the Business Rule Manifesto[2]. R.I.P traditional, hard-wired processes!      

For IT professionals the state of processes has always reigned supreme. In procedural approaches the internal state of a process is represented by some token. Most computer languages use that approach (the token generally falls through lines of code sequentially). Many current approaches to business process modeling do as well, at least implicitly. But why should business people care about the internal state of any process? For example, if a business person asks How far along are we in processing this order? the person is really asking: Has the order been credit-checked? Has it been filled? Has it been shipped? (etc.). In business operations it’s the state of each operational business thing that matters. True business agility cannot be achieved so long as business processes are perceived as managing state internally (privately). That’s a fundamentally flawed paradigm for business operation today. Instead, business processes must externalize semantics so business people can understand and manage the state of operational business things directly. Externalizing semantics is accomplished by means of SBVR-style structured business vocabularies (concept models) and single-sourced business rules. ~~~~~~~~~~~~~~~~~~~~~~~~~~ This post excerpted from our new book (Oct, 2011) Building Business Solutions: Business Analysis with Business Rules. See:  http://www.brsolutions.com/b_building_business_solutions.php  

In a dramatic development, the new release of SBVR (1.1) has replaced the term “fact type” with “verb concept”, and the term “fact model” with “concept model”, for all business-facing use.[1] Why the problems with “fact type” and “fact model”? Let me see if I can explain. First some background: Since its inception in the early 2000s, the OMG standard SBVR[2] has focused on “fact type” and “fact model”. That’s no accident – the underpinning of SBVR in formal logic is based on the work of Terry Halpin, who in turn based his work on Sjir Nijssen’s. Sjir Nijssen was using the terms for database models as early as the 1970s. By the way, both bodies of work are world-class. Now to the problems: If someone gives you an example or instance of a customer, where is that customer? In a database? No, of course not. The customer is out there in the real world. Similarly, suppose someone gives you an example of some customer visiting some retail store. Where did that visitation take place? In a database? Again, of course not. The visitation also happened out there in the real world. The bottom line is that when most people talk about things, those things exist or happen in the real world. But not if those people happen to be logicians or database gurus. Then instances of the things they talk about formally are likely to be in some database – i.e., data. The formal terminology is usually more refined – e.g., “population of facts” – but it is what it is. And it’s not the same stuff as is in the real world. Where does that lead you? If you’re a logician or database guru, you need to classify all the facts – hence “fact type”. You also need a model of all the fact types – hence “fact model”. If you’re not a logician or database guru, however, you’re clearly going to need something else. What exactly fits the bill? Here’s a clue: Databases hold data; those data represents facts. Those facts have meaning, but to understand that meaning you need to understand the concepts that are used. In business basically all we have is words to refer to things in the real world. What do those words communicate? The words communicate what you mean; that is, the ideas or concepts you have in your head when you say or write them. So what we need – or more precisely, what we need to share – is a model of what you mean by those words. In short we need a concept model. More on SBVR The world might or might not need another information modeling standard. The point is debatable. The soul of SBVR, however, lies in meaning[3] and language – what concepts we mean by the words we use in business communications (especially but not exclusively business rules). In the standards landscape that focus sets SBVR apart. What kind of language concepts do we need in organizing and expressing meaning? The answer is really quite simple (once you see it) – you need nouns and verbs. Those nouns and verbs stand for concepts – noun concepts and verb concepts, respectively. For example:

• The noun “customer” might stand for what is meant by the definition “one that purchases some commodity or service”. 
• The verb “visits” (as in “some customer visits a retail outlet”) might stand for what is meant by the definition “customer physically appears at retail outlet”

There is no other practical way to communicate business concepts and establish relationships among them. You need nouns and verbs to write sentences and convey meaning – it’s as simple as that. Once you look at the problem this way, forcing “fact model” and “fact type” on business people is unnatural and unnecessary. It commits a cardinal sin in business analysis – using unnatural terms for natural business concepts. The most natural terms for the concepts meant by SBVR are “concept model” and “verb concept”. About Business Rules For my part, I didn’t arrive at this understanding through the path above – or for that matter any other path you are likely to guess. The need for the shift dawned on me when I saw business rules being included in populations of facts. Hold on, how could a rule be treated as a fact?! Well, exactly! To a logician or database guru, however, treating a rule as a fact makes perfect sense. Formal logic is all about propositions. A business rule is a proposition taken to be true – in other words, a fact. So of course business rules belong in populations of facts and therefore in fact models. It couldn’t be any other way. And I agree. The only problem is that in SBVR we want to talk directly about the real world. The Bottom Line So a concept model in SBVR is a ‘map’ of noun concepts and their relationships based largely on verb concepts.[4] Actually, it’s more than that. By ‘map’ I don’t mean either of the following on its own:

• A set of concepts and definitions loosely related (e.g., a glossary) – although definitions are clearly essential. 
• Some diagram(s) – although often quite useful.

Rather, I mean a non-redundant, integrated, anomaly-free structure of concepts based on interlocking definitions – a blueprint of meanings. How is an SBVR-style concept model different from (and better than) a traditional “conceptual data model” (or entity-relationship diagram)? Instead of mere lines to represent relationships between noun concepts, with an SBVR-style concept model we have verbs. These verbs reveal the intended meanings of the relationships. With verbs I can verbalize – literally communicate (and demonstrate) what is meant. No more hidden meaning!

One thing that concerns me about ‘decision’ or ‘decision management’ is that everything potentially becomes a decision. Software vendors love it when complex problems can be reduced to a single buzzword. Engineers of true business solutions should hate it. I’m sure I’ll be accused of negativism, so for the record, let me say that top down analysis of operational business decisions is extremely useful, either along with, or outside of, business processes. We have a highly pragmatic approach for decision analysis based on ‘question charts’ (Q-Charts). We use it extensively to capture decision rules. But do I think that decision analysis is the most important part of delivering a winning business solution? Not by a long shot. Your strategy for the business solution is much more important. Even that’s not enough though – strategy only tells you why. We need business models that cover all aspects of a business solution (think what, how, where, who, and when). So no, it doesn’t (or at least shouldn’t) all boil down to ‘decisions’ … unless by that you mean anything and everything. And what good is that? I’m always very careful to say ‘operational business decision’ instead of simply ‘decision’. Immediately that excludes governance decisions (e.g., creating a business policy) and strategy ‘decisions’ (as in MBA-school ‘business strategy’). That’s an important first narrowing of the field. Something else commonly mistaken for an operational business decision is a simulation of “what would happen if we did this operational task right now”. For example, let’s run a claim by all the behavioral business rules and see if the claim is acceptable before we do it for real. That’s simply a test, not a decision. That’s a second important narrowing of the field. Clearly we need a solid definition of what a decision is and isn’t in the context of business analysis. We define an ‘operational business decision’ as: a determination in day-to-day business activity requiring know-how or expertise; the resolving of a question by identifying some correct or optimal choice. To make such decisions you need decision rules (think classification or inference rules) that ‘map’ cases to outcomes. Decision rules are one type of definitional rule. The two types of business rules in SBVR are definitional rules and behavioral rules. Business capabilities do usually involve large numbers of decision rules, but they also always involve large numbers of behavioral rules. Behavioral rules are rules you can violate, like speeding through a school zone. There’s no decision to that … you either are or you aren’t speeding. Well, you may have made a personal decision to speed, but let me tell you, City Hall doesn’t care. Personal decisions – out of scope too, a third important narrowing of the field.

A practitioner recently said this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, in my opinion this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Exactly! And why would that be a problem?! Here’s an additional advantage: The core concepts (concept model or fact model) of an operational business area are very, very stable. Don’t believe it? As proof see http://www.brcommunity.com/b594.php (short case study, well worth a quick read). The problem with current data modeling practices is that a large gap often exists between the business view of things (operational business things) and the ‘data’ view of those things – even when trying to keep to a ‘conceptual’ view. This gap gives business-side people a ready excuse to drop out. But data modelers alone can’t provide the necessary business know-how for a robust, complete model. The problem is so big, it’s hard to see. Current data model practices evolved bottom-up, from database designs. (I believe I can speak with some authority here. I was editor of the Data Base Newsletter, 1977-1999, and wrote three books related to the matter in the late ‘70s and early ‘80s.) It’s time for us to approach the problem top-down. There is a natural way to build concept systems – it starts with basic business communication. The standard for such an approach already exists – SBVR. (For discussion see BRCommunity’s SBVR Insider section.) We’re already living and working in a knowledge economy … We need to start acting like it!

As part of a continuing dialog, I recently asked these questions: What does the term “conceptual data model” really mean? Is it the best term for what is meant? To me, it sounds like “conceptual data model” might be about “conceptual data”. Surely not(?). What exactly then? (Some of my thoughts on the matter: http://goo.gl/8GX5o.) A practitioner responded with the following 3-part challenge below. With each challenge is my response. Challenge part 1: Which of the following, if any, would you see in a conceptual data model: primary keys, foreign keys, abstract keys, constraints, nulls, non-nulls, 1:1s, 1:Ms, optionality, cardinality, etc.? My response: Wrong approach. Bad definition practice one three counts. 1. Things should be defined in terms of their essence, what they are, not in terms of what are allowed or disallowed. 2. Suppose none of the above were allowed. You’d end up simply with a description of what the thing is not, not what it is. Since you can’t possibly list everything it’s not, the definition is woefully incomplete. 3. The list attempts to describe something in terms of an implementation or design of the thing, not in the thing’s own terms. That’s simply backwards. Challenge part 2: So let’s turn the question around. What would be the minimum types of objects you need to explore a concept, produce a mini model, and convey knowledge about the concept and its relationship to other concepts? My response: To develop a concept you need: 1. A concise definition for the concept, which distinguishes the concept from all other concepts and conveys its essence to the business. 2. A business-friendly signifier (term) for the concept that has only that one meaning (or is properly disambiguated by context). 3. A set of facts that indicates the place of the concept within a structure of other concepts (e.g., classification, categorization). 4. A set of verbs that permits the business to communicate unambiguously about how the concept relates to other concepts (e.g., customer places order). 5. A set of structural rules for the concept and its relations to other concepts, as needed. Why the verbs? Because you can’t write sentences without verbs and business rules can always be written in sentences. ‘Requirements’ should be too(!). Challenge part 3: When you are finished do you call that a ‘conceptual data model’? My response: You notice that I didn’t say anything, directly or indirectly, about “data”. That term is irrelevant. Taking away “data” leaves “conceptual model”. But that term suggests what the model is made of (concepts), not what it is about. Of course the kind of model we’re talking about is made up of concepts – it’s certainly not made of physical material (e.g., wood, plaster, etc.) or through use of math (some formula). That leaves “concept model” (also sometimes called “fact model”). Bingo. Is there a standard for this kind of model? Indeed there is: SBVR (Semantics of Business Vocabulary and Business Rules). See the SBVR Insider section on www.BRCommunity.com for more information.

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.

Is there any proven way to demonstrate data models are correct, complete, and stable with respect to the operational business and its needs? No. That’s distressing.  Is there an alternative that does? Yes, fact modeling, which is to say structured business vocabularies (concept systems). The core concepts (fact model) of an operational business area are very, very stable. I have outstanding proof (short case study).  See: http://www.brcommunity.com/b594.php. Definitely worth a quick read. I recently made these statements in a data modeling forum, and a practitioner came back with this: “Even if we assume that a technical methodology might exist to generate a complete and correct data model from a set of articulated business rules / facts, IMO this approach just moves the target from the data modeling area to the need to verify the articulation of business facts / rules for completeness and correctness.” Missed the point. Concept anaysis is brain work. You’ll never generate a ‘complete and correct data model’ … you must create it … ith business people and SMEs. The problem with data modeling as practiced today is that there is a large gap between the business view of things and the data model. It gives business-side people a ready excuse to drop out. And its an art rather than a science. You really have no justification building a system until you have a concept blueprint. Currrent data models evolved bottom up, from database design. (I know, I watched it happen. I was editor of the Data Base Newsletter, 1977-1999.) It’s time to approach the problem top-down. There are natural ways to build concept systems. The standard for the new approach is SBVR. (For more, see BRCommunity’s “SBVR Insider”), which in turn is based on ISO 1087 and 704.  We (all of us) need to start practicing like we’re living in a knowledge economy … which in fact we actually already are.

The other night I watched the movie Butch Cassidy and the Sundance Kid for about the 50^th time. It’s a highly entertaining movie – all you have to do is suspend judgment.  As a rules person, the classic scene for me is Harveychallenging Butch to a knife fight (with a knife about the size of a machete) for leadership of the gang. Now Butch is the one who’s always thinking. Stalling for a bit of time he walks an angling path toward Harveyand says, “No, no, not yet. Not until me and Harvey get the rules straightened out.” Harvey, thrown off guard, says (paraphrasing), “Rules?! There are no rules in a knife fight!” Well, exactly! Poor Harvey pays for his moment of verbal clarity with a challenge-ending reminder that, well, there are no rules in a knife fight.  In SBVR terms, Harveyexpressed an advice, a non-rule. If Harvey had been a rule analyst (doubtful) he might have said: “Any action is permitted in a knife fight.” The statement is not a rule because it removes no degree of freedom. Butch, always thinking, complied completely.