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 does not have an innate concept/approach for “legality” in the sense of MWUD 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 ruleA 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 rulesA 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
Semantics of Business Vocabulary and Business Rules
Guest Post by Markus Schacher
We should first agree on the semantics of underlying concepts and only then start to think about the best terms for those concepts.
One particular technique I often apply in such cases is the following:
1. Name controversial concepts with proxy names such as “Greg”, “Mike” or “John” (or whatever name you prefer) to get potentially misleading names and their implicit connotations out of the way of progress.
2. Draw a concept diagram showing those concepts as well as important semantic relationships among them.
3. Formulate intensional definitions for each concept – still using the proxy names. Ensure that those definitions are consistent with the relationships shown on the concept diagram.
4. Identify one or more communities that “baptize” those concepts by giving them better names.
If synonyms and/or homonyms appear among those communities, that’s just how the world is; we simply have to live with it. This is why SBVR formally supports semantic communities as well as speech communities.
Building Business Solutions: Business Analysis with Business Rules (2nd Edition) … Just Out! http://www.brsolutions.com/b_building_business_solutions.php
Get it on Amazon: http://goo.gl/HXxN1fWhat It’s About: How to develop business solutions working directly with business leads, create blueprints of the solutions, and then use those blueprints for developing system requirements. Engineering business solutions, not just requirements.We have applied the techniques described in this book successfully in hundreds of companies worldwide.
Kind Words from a Practitioner: “We have based our whole business rules analysis practice on the methodology and techniques developed by the Business Rules Solution team. This book is an integral part of our practice. It’s an easy to read, useful guide with real life examples – we use it daily and couldn’t do without it!” – Michelle Murray, Inland Revenue Department NZ
New in this Edition: How Business Architecture corresponds with your projects and requirements work. Developing a Concept Model and how it will help you. How business rules align with the new terminology in the recently released IIBA® BABOK® Guide version 3.
OMG released version 1.3 of SBVR (Semantics of Business Vocabulary and Business Rules) last month – comprehensively reorganized for approachability, but not changed. 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.
Question: Can you spot the circularity among these three definitions?
Need: a problem, opportunity, or constraint with potential value to a stakeholder
Solution: a specific way of satisfying one or more needs in a context
Stakeholder: a group or individual with a relationship to a change or a solution
Answer 1: The definition of “need” references “stakeholder”, whose definition references “solution”, whose definition references “need”. The definitions don’t need to be circular. It’s simply bad definition/glossary practice.How can the circularity be removed? “Need” should simply be defined as “problem, opportunity, or constraint”. That’s the essence of the concept. Whether it has “value to a stakeholder” is an assessment. Just because one person says something (a need) has value and another person says it (the need) does not (which happens all the time by the way) doesn’t mean the thing is not a need to either: (a) the person who has it, or (b) the person who says it has no value. The latter person would say “that need has no value”. He/She just called it a “need”, so how can it not be a ‘need’?Answer 2: There is actually a second circularity in the definitions: need –> value –> stakeholder –> solution –> need. Changing the definition of “need” as I propose above will fix that second circularity too. “Need” is a very basic concept. If there were no need, there would be no reason to assess what value it has to what stakeholder (including the one who proposed it). If there were no need, there would be no solution, context or change (in the BA’s world). It’s a seedconcept.Principle: In developing a vocabulary it’s best to start from terms whose definitions use no other terms … i.e., from seed concepts.Otherwise, circularities will make Swiss cheese of your brain.www.BRSolutions.com
In a data modeling discussion forum, a practitioner recently asked:
Has anyone seen an object super-type used to encompass both Party and System Component?
Examples of Parties: people, organizations
Examples of System Components: projects, proposals, computer systems
In over a dozen responses, not one person asked for a definition!My ResponseI’m surprised … no amazed … no horrified … by this discussion. It pretty well illustrates my frustration with data modeling.I should simply point out that in the real world, projects and proposal are not system components in the sense probably meant, then stop right there. Clearly the question mixes apples and oranges. But let’s work it through a bit more.What is the thing that that the proposed supertype (more general concept) would represent? … Which is to say, how would you define the notion in your head when you say the corresponding thing exists in the real world?If you can’t define the concept in any coherent way, that should be the end of the discussion. This is why I recommend starting with concept models, instead of data models.Since I’ve done a few data models in my time, I’ll jump to the other side of the fence and propose a definition for the sake of discussion.
more general concept x: an agent that can make and respond to requests
Systems, people, and organizations can all do those things. However, proposals can’t … unless you are talking about a software object representing a proposal. So here’s a revised definition …
more general concept x: a software agent that can make and respond to requests
But any software object can basically do that. Is that what is meant? Are we talking about (a) things that exist (can be jointly classified) in the real world, or (b) things that exist in software representations of the real world?My fear is that concept x is simply a design artifact that doesn’t really correspond to anything. It’s just an optimization for technology’s sake. Do we really want to go there?!
When one company acquires another, or two companies merge, there is inevitably much consternation over data migration. Indeed, it’s always a hard problem.Underlying every data migration problem, however, is a concept migration problem. By ‘concept migration’, I really mean integration of business vocabularies. After all, business vocabulary comes before data. Consider the case of two airlines merging their frequent-flyer programs. (I live in Houston – Can you guess which airlines I might be talking about?) The airlines need business rules for how concepts from the respective programs line up with each other. (At the onset I’m sure they won’t.) Even better, the airlines should start with a business strategy for the business problem (what we call a Policy Charter) and set of business policies, then develop the business rules.A corresponding problem exists in building a new business capability. An existing set of concepts exists (probably implicit in the data and not well-formed). You also have a revised set of explicit concepts in the form of a structured business vocabulary (concept model, also called fact model). Yes, you will probably have a data migration problem, but first you have a concept migration problem. So before your business model is complete, you need to develop an appropriate set of business ‘migration’ rules to specify how the transition in business practices should take place. In other words, you need to ask:
Are there concepts in the current business capability that need to be reorganized for, or ‘mapped’ to, the new or revised concepts of the future-form business capability?
Here is an example ..
Current Situation: Currently marketing reps can make hand-shake deals with customers on the road (‘road deals’). In the past, these deals were usually based on long-standing connections, so proper documentation of the details (often missing) was not too important.
With faster rates of turn-over and more specialized products this traditional business practice has become problematic. So the business will no longer support road deals. A new concept is being introduced for ‘spontaneous’ deals, called spot deal, which provides better coordination.
When the future-form business capability is deployed, however, some road deals will still be in force. How should these existing road deals be handled?
Business Tactic (in the Policy Charter): ‘Road deals’ are to be discontinued.
Business Transition Rule: Any “road deal” made in the past by a marketing rep that has never been formulated into a contract must be considered a spot deal.
A business transition rule is really about semantic migration. That fancy-sounding term isn’t needed though. At issue simply is knowing exactly what the words we use mean. Tackle that issue as a business problem, and the system solutions will fall into place. ~~~~~~~~~~~~~~~My business partner, Gladys S.W. Lam, will be using the airline example in one of her talks at the Business Rules Forum Conference http://www.businessrulesforum.com/ Oct 28 – Nov 1 in Ft. Lauderdale.
From Drafting Contracts: How and Why Lawyers Do What They Do, by Tina L. Stark, Aspen Publishers – Wolters Kluwers, 2007, p. 204, based in turn on The Language of the Law, David Mellinoff, Little, Brown & Co., 1963, Chapter 9.~~~~~~~~~~~~ “The profusion of couplets and triplets [e.g., null and void] reflects the evolution of the English language. After the Normans invaded England in 1066, French slowly became the language used in English courts and contracts. It predominated from the mid-thirteenth century to the mid-fifteenth century.Not unexpectedly, the English came to resent the use of French and began once again to use English for legal matters. As the use of French began to wane, English lawyers were faced with a recurring problem. When they went to translate a French legal terms into an English legal term, they were often unsure whether the English word had the same connotation.The solution was obvious: Use both the French and the English word. For example, free and clear is actually a combination of the Old English word free and the French word clair. [Another example:] breaking and entering (Old English and Old French).Compounding this penchant for joining French and English synonyms was the English custom of joining synonyms, especially those that were alliterative and rhythmic.
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. 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 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 SBVRThe world might or might not need another information modeling standard. The point is debatable. The soul of SBVR, however, lies in meaning 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 RulesFor 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 LineSo a concept model in SBVR is a ‘map’ of noun concepts and their relationships based largely on verb concepts. 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!
 But not in the underpinning of SBVR in formal logic.
 Semantics of Business Vocabulary and Business Rules. See the SBVR Insider section of www.BRCommunity.com for discussion. SBVR 1.0 was released by OMG in December, 2007.
 I refuse to use the “S” word here. There’s really no need for it. Few business people I’ve ever met say “semantics” in the course of normal business conversation, except perhaps in the sense of “Oh, that’s just a matter of semantics.” (which indeed, to be fair, it usually is).
 I say “largely” because certain important structural elements of concept models, including classifications and categorizations, are not based on verb concepts.
“A great class that explains the importance of business rules in today’s work place.”
Christopher – McKesson
“We actively use the BRS business-side techniques and train our business analysts in the approach. The techniques bring clarity between our BAs & customers, plus more robust requirements for our development teams. We’ve seen tremendous value.”
Jeanine Bradley – Railinc
“Your work has been one of the foundations of my success in our shared passion for data integration. It has had a huge impact on innumerable people!”