Data models and class diagrams are generally created to serve design purposes. If they include verbs at all, they are not vetted against business rules or other forms of operational business communication. Verbalization depends on well-constructed sentences, which in turn puts a premium on verbs. Fact models provide the basis for consistent and unambiguous verbalization, as well as for the design of IT artifacts. It is time to recognize full-fledged human communication as the starting point for anything written about business operations, including but not limited to, business rules and IT requirements. This month’s feature article explains.
Let me share something we have learned from our work on business rules. The world’s leading cause of ambiguity in expressing business rules — and other requirements — is missing verbs. The following example illustrates.
Business Rule: An order must not be shipped if the outstanding balance exceeds credit authorization.
As a first-cut statement, that’s perhaps not bad. The more you read it, however, the more ambiguity you’ll see. Clearly, some important ideas are hidden or missing. For example:
- The outstanding balance of what? …order? …customer? …account? …shipment?
- The credit authorization of what? …order? …customer? …account? …shipment?
The hidden or missing ideas are all verb-related. To eliminate the ambiguity, the relevant verb concepts — a.k.a. fact types — must be discerned, then the original business rule restated. Suppose the relevant fact types can be worded as follows:
- customer places order
- customer has credit authorization
- customer holds account
- account has outstanding balance
Using RuleSpeak® the business rule can now be restated as1:
Revised Business Rule: An order must not be shipped if the outstanding balance of the account held by the customer that placed the order exceeds the credit authorization of the customer.
Although the resulting statement is a bit wordier, it is far less likely to be misunderstood, misapplied, or mis-implemented. It is now enterprise-robust. Two key insights:
- Wordings for fact types are generally expressed using verbs. Note in particular the verb holds (or held) and the verb places (or placed). (I’ll come back to the pesky preposition ‘of’ later.)
- 2. Wordings for relevant fact types should always appear explicitly in expression of business rules. They are also essential in creating robust decision tables. For that matter, wordings should appear explicitly in any form of business communication you want to be unambiguous, including IT requirements.
Given that verbs are so crucial to effective business communication of all kinds, you might question why data models and class diagrams haven’t focused more directly on them. The answer, quite simply, is that these tools weren’t created for that purpose. They are first and foremost design tools for IT professionals.
What do IT professionals design? In general, they are focused on implementing data containers (e.g., tables) or software objects. That focus leaves them noun-ish, but not also verb-ish. The price we are paying for that shortfall in poor business communication practices is huge.
How can the problem be fixed? The answer is simply that verb-ish things should be included alongside noun-ish things as a fundamental part of any structural modeling. This article explains how.
What It Means to be Verb-ish
Many IT professionals associate verbs only with processes, as in “take order” or “pay invoice” or “hire employee”. Nothing in the real-world meaning of ‘verb’, however, limits its use solely to that concern. Have a look at the definitions of ‘verb’ and ‘predicate’ in the box below2 . Restricting use of verbs only to the naming of processes, tasks, or actions is very unnatural.
Verb:a word belonging to that part of speech that characteristically is the grammatical center of a predicate and expresses an act, occurrence, or mode of being ...
Predicate:[2] the part of a sentence or clause that expresses what is said of the subject and that usually consists of a verb with or without objects, complements, or adverbial modifiers
Experts in the field of linguistics explain that verbs play a far more crucial role. For example, Steven Pinker writes , “A verb, then, is not just a word that refers to an action or state but the chassis of a sentence. It is a framework with receptacles for the other parts … to be bolted onto.” Without verbs, literally there are no sentences.
Sentences are how you communicate effectively. Sentences are what you’re reading right now. A well-written business rule is always a sentence. In general, all business communication and many forms of business requirements should be sentences. When you start looking at things that way, it becomes obvious that verbs must be an integral part of any structural model.
Let’s take a closer look. Without going too deep into philosophical questions, every verb generally has two sides. Yes, you can think of a verb as designating some action. But you can also think of a verb as designating something you can know. Take, for example, the verb ‘to place’, as in a customer placing an order. You can look at ‘to place’ from two perspectives, both valid:
- There is something a customer can do — i.e., place an order. That’s an action or process.
- There is something that can be known — i.e., that a customer can place an order. That’s a fact.
The first perspective, of course, is very important. No one is saying you shouldn’t model processes. But taking even a cursory look at other challenges facing businesses today suggests the second perspective is also crucial:
- Achieving reusability or sharing of data (data design).
- Providing high-quality information (business intelligence — BI).
- Expressing business rules (criteria for operational decisions).
- Eliminating stove-pipe products (product re-engineering).
- Retaining know-how (knowledge retention).
Verbs are therefore the point of departure for addressing a host of broader needs facing businesses today.
Modeling the underlying verb concepts (as well as the nouns they involve) is the purpose of fact models. Think of a fact model as a verbal model, one serving for more effective verbalization of operational business knowledge. It’s high time we focus on the basics of business communication as the starting point for everything we do or design.
Fortunately, fact modeling as a discipline has a long and solid pedigree. It’s not something new; it’s been around for decades. The gurus of this space include Terry Halpin4 and Sjir Nijssen5 ; the standard for the space is SBVR . Actually, this discussion features only two new things:
- RuleSpeak and the now in-depth understanding of how business rules should be based on facts and fact models.
- The conventions used in this article to represent fact models graphically. We developed this graphical notation in large-scale client projects starting in the mid-1990s to provide a more business-friendly face for fact models.
Issues That Can Only Be Handled Well Using Verbs
Traditional data models and class diagrams fall short in a number of respects in their handling of verbs. The following discussion outlines three of these shortcomings, each addressed effectively in fact modeling. First, two quick points about terminology in the box below.
Verb: For convenience, I say verb although I really mean verb or verb phrase. For example, ‘owns’ counts as a verb, but in my usage so too do ‘rides in’ and ‘is being actively marketed’.
Verb Concept: SBVR has defined verb concept and fact type as synonyms. These two terms can be used interchangeably. A verb concept or fact type is always understood to include some relevant noun concept(s) as well as something verb-ish. So the verb ‘owns’ might be included in the expression of the verb concept (or fact type) ‘person owns vehicle’.
Unary Fact Types — Verbs about Only One Thing
A unary fact type always provides a simple yes-or-no answer to some basic operational business question. In other words, a unary fact type is always Boolean (i.e., true or false). The following example illustrates.
Figure 1. Fact model showing unary fact type.
Note on Notation
The starburst symbol always indicates ‘fact type’. Here, the starburst introduces the verb (phrase) ‘is being actively marketed’. The line between the noun concept ‘product’ and the starburst means nothing on its own; it simply shows where the verb (phrase) fits into the diagram.
The fact type worded ‘product is being actively marketed’ is unary because it pertains to only one noun concept, product. This unary fact type indicates that a given product either is or is not being actively marketed. The actual answer to the question, of course, depends on which particular product is being talked about.
Like any fact type, this unary fact type could be relevant to many kinds of business communications, including statements of business rules. The following sample business rule illustrates.
Business Rule: A briefing may be given only for a product that is being actively marketed.
Roles — Noun Concepts Whose Meaning Is All Tied Up with Verbs
Business people often have a special term for a noun concept they use only in the context of some particular fact type. The following example illustrates.
Figure 2. Fact model showing a role.
The fact type diagrammed above is: flight arrives at [destination] city. The term in brackets, ‘destination’, is simply a more specific term used to refer to a city when it is a city where a flight arrives. Such a role name designates the part (or ‘role’) the concept ‘city’ plays in the context of the fact type. It means nothing more than that.
Note on Notation
Like for unary fact types, a line representing a binary fact type means nothing more than the verb used in its wording. The little directional arrow that appears alongside the line simply indicates how to “read” the fact type. The proper wording for the fact type above is therefore understood to be ‘plane arrives at [destination] city’ — not ‘city [destination] arrives at flight’ (obviously nonsensical). A starburst is usually omitted for a binary fact type since what the line represents is generally obvious from the context of the diagram.
Roles are not the usual kind of noun-ish things IT professionals generally expect; that is, they are not ‘normal’ entity types or classes as understood in data models or class diagrams. Rather, the meaning of these noun concepts is inextricably tied to some verb (e.g., ‘arrives at’).
Role names are a particularly good way to handle terms that directly reflect the particular choice of verb in the wording of a fact type. For example, in the following diagram, the role name ‘owner’ directly reflects the verb of choice, owns.
Figure 3. Fact model showing a verb-reflecting role name.
Like any other term, a role name is frequently relevant to many kinds of business communication, including statements of business rules. The following sample business rule illustrates.
Business Rule: A parking citation may be given only to the owner of a vehicle.
Reversal — Verbs of the Opposite Persuasion
Even if a data model or class diagram gives a verb in one direction of a relationship, it seldom gives it in the opposite direction. Or if it does, it merely offers a preposition. For example, in the following data model, the opposite direction of the verb ‘is involved with’ is labeled simply ‘of’.
Figure 4. Data model showing a preposition for the opposite direction of a fact type.
Proper wording for the opposite direction of a fact type, however, is often needed to express business rules or to compose other kinds of business communication or requirement. The following sample business rule illustrates.
Business Rule: A vehicle must not transport more than 4 passengers.
In this business rule, the verb ‘transport’ is used to clearly express the appropriate meaning. Try substituting ‘of’ in some way into the statement and see how well that works to express the meaning. (It doesn’t.) In fact modeling, stand-alone prepositions for fact types are considered lazyman’s verbs. Literally, you can’t make complete sentences with only prepositions!
Actually, the communication problem gets even worse. In the real world, people can be involved with vehicles in different ways. ‘Passenger’ in the business rule above suggests just one way. Suppose that people and vehicles can ‘be involved’ with each other in at least four ways:
- People own vehicles.
- People lease vehicles.
- People drive vehicles.
- People ride in vehicles.
In data models, such differential ‘involvements’ are typically handled using a type code treated as ‘intersection data’. The following data model illustrates.
Figure 5. Data model showing a type code treated as intersection data.
This data model features a new noun-ish thing ‘vehicle-person’, in which the type code ‘veh-pers-code’ has been included. Four values of the type code are listed to distinguish the four kinds of ‘involvements’ from above.
Let’s see what now happens to the expression of the passenger business rule. We started with this:
Business Rule: A vehicle must not transport more than 4 passengers.
Using the terminology provided by the data model, the rule might now be expressed like this:
Rule: A vehicle must not be of more than 4 people where veh-pers-code = “pas”.
Do we really want business communications to sound like that?! No! The statement contorts the meaning (mangles the semantics) almost beyond recognition. Besides losing the clarity of ‘transports’, we’ve forced the business people to speak in terms of a type code. That’s unnatural. This example clearly illustrates the difference between a true business rule (the original version) versus what must be considered a data rule or system rule (the mangled version).
To emphasize this latter point, let’s consider a bit more complicated business rule pertaining to two kinds of ‘involvements’. First, here is the rule verbalized as a business person might expect:
Business Rule: A person must not lease a vehicle the person owns.
Using the vocabulary of the data model above, however, we get the following verbalization:
Rule: A person must not be involved with the same vehicle where veh-per-code = “lea” and veh-per-code = “own”.
Clearly, the more complicated the business rule, the worse the mangling. And a great many of your business rules are very complicated! Without further ado, let’s simply agree that’s awful and move on. The following diagram indicates how these semantics (verb concepts) would be fully handled in fact modeling.
Figure 6. Fact model showing multiple ‘involvements’.
Some key observations:
- Fact types are always bi-directional (or multi-directional) even if not worded as such explicitly. (All the fact types above have been worded in both directions for the sake of completeness.) Fact models then are very different from process models, which always designate uni-directional flows.
- Two or more noun-ish things can be related more than once if the meanings of the verbs are different. This differentiation has resulted in the four fact types above.
- Any verb concept can have a synonym if the meaning is considered exactly the same by the business. In the diagram above, for example, the verbs ‘transports’ and ‘carries’ are indicated to be synonyms in the context of the given fact type.
Now back to the business rules. The fact model gives us all the scaffolding we need to verbalize the business rules succinctly and naturally. You can verify that for yourself:
Business Rule: A vehicle must not transport more than 4 passengers.
Business Rule: A person must not lease a vehicle the person owns.
Using the fact model as a blueprint, we can have a real business conversation with business people and subject matter experts in natural language about whether these business rules are valid and complete. Indeed, business analysts should ask some hard questions, including perhaps the following.
- Is the person who drives a vehicle considered a passenger?
- Does the business rule also apply to buses, or just to passenger cars?
- Does the business rule mean a vehicle can’t carry more than 4 passengers ever, or just at any given point in time?
- Can the same person be a passenger in the same vehicle more than one time over time?
- Why do we really care how many passengers ride in a vehicle?
The answers to these questions could well indicate that the current fact model is incomplete. For example, if the business rules are from a city government, we might actually want to talk about when to issue traffic citations. The actual business rules might be:
Business Rule: A passenger overload traffic citation must be written for a passenger vehicle carrying more than 4 passengers.
Business Rule: A traffic citation may be given only to a person driving.
The noun concept traffic citation (and related fact types) does not appear in the fact model above. Clearly, some work on that is in store. Now ask yourself this: Would you rather work this out before or after you get to a data model or class diagram? The answer, I think, speaks for itself.
My point is this. The fundamental problem in business today is not design or implementation of databases or systems. Rather, it is the challenge of business communication. If you can’t clearly communicate (verbalize) what you know, you’ll never get the database or system (or decision table) you want.
Where does that take you? Directly to being able to write complete sentences, which in turn brings you straight to verbs. There’s simply nowhere else to turn. So give us back our verbs!
Author: Ronald G. Ross - Featured Speaker, www.AttainingEdge.com.
Co-Founder & Principal, Business Rule Solutions, LLC
Chair, Business Rules Forum Conference
For more about the author, see www.RonRoss.info.
1RuleSpeak is a set of guidelines for writing business rules in structured English. Free on www.RuleSpeak.com.
2from Merriam-Webster Unabridged Dictionary (emphasis added)
3Pinker, Steven, The Stuff of Thought: Language as a Window into Human Nature, New York, NY, Viking, p. 31 (emphasis added).
4Halpin, Terry (with Tony Morgan), Information Modeling and Relational Databases, (2nd Ed.), San Francisco, CA, Morgan Kaufmann, 2008.
5Nijssen, Sjir, An Architecture for Knowledge Base Software, Presentation at the Australian Computer Society Conference, July 1981. Available at: http://www.FBMf.eu
6Semantics of Business Vocabularies and Business Rules (SBVR) is a groundbreaking standard officially released in December, 2007 by the OMG. For more information see SBVR Insider on www.BRCommunity.com.
7Business Rule Solutions, LLC (BRS) in Proteus®, our methodology for business analysis, decisioning, and business rules.
NOTE: Top image © PictureP. - Fotolia.com