Since its inception in the early 2000s, the OMG standard SBVR^[1] 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.

So why is there a problem with 'fact type' and 'fact model'?  Let me see if I can explain.

Why Not 'Fact Model'?

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 represent 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.

Back to SBVR

The world might or might not need another information modeling standard.  The point is debatable.  The soul of SBVR, however, lies in meaning^[2] 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'.^[3]  Now do you see why the SBVR shift to these terms is so important?!

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.

About Data

That brings me to the word 'data'.  Did you ever stop for a moment to think about the meaning of 'data'?  Most of us don't.  The term is so familiar and pervasive we simply take it for granted.  For Business Analysts and IT professionals, 'data' is about as basic as it gets.

Taking terms for granted, unfortunately, is the surest path to confusion.  It's the deep assumptions about the terms lying at the very heart of a subject matter that usually trips us up.  So let's take a moment to examine the meaning of 'data'.

Just so you know where this is headed, I'm embarking on a full frontal assault on the term 'conceptual data model'.  I've disliked that term for many years.  I think we should kill it off once and for all.  Why?  Two fundamental reasons:

• No business person would naturally say "conceptual data model" in everyday business conversation.  If we mean something by "conceptual data model" that business people should be able to talk about, then why have a name for it they can't easily understand?  Jargon just makes things harder.
  
  
• I believe what you really mean when you say "conceptual data model" is simply "concept model".  If "conceptual data model" doesn't mean that, then what in the world does it mean?!

Why Not 'Conceptual Data Model'?

The Wikipedia entry for 'data (computer science)' says, "… information in a form suitable for use with a computer."  The entry adds, "Data is often distinguished from programs … data is thus everything that is not program code."

Now let's substitute '… information in a form suitable for use with a computer' for 'data' in 'conceptual data model'.  The result of the substitution is 'conceptual information (in a form suitable for use with a computer) model' or simply 'conceptual information model'.  What exactly does that mean?  As far as I can tell, not much at all!

By all rights we should be permitted to terminate the analysis there.  In IT the Wikipedia definition is what 'data' has meant for well over half a century.  If you're interested and have the patience, however, let's be charitable and look more broadly at the term 'data'.  See the box.  Skip it if you like though — it leads nowhere and life is short.

As the box indicates, any attempt to make sense of 'conceptual data model' through fair-minded dictionary analysis of 'data' leads to nonsense or a dead end.  So, the term 'conceptual data model' must have an origin all its own.

Indeed it does — one definitively IT-based.  Reviewing the Wikipedia entry for 'conceptual data model'^[4] we find the synonym 'conceptual schema'.  'Conceptual schema' is a technical term dating at least from the 1970s.

Ironically, Wikipedia provides a great definition for 'conceptual data model':  a map of concepts and their relationships.  Bingo!  So why all the mumbo jumbo?  Why not just say "concept model"?!  Let's toss 'conceptual data model' and be done with it!

So, a concept model is a 'map' of noun concepts and their relationships based largely on verb concepts.^[5]  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 what is meant.  No more hidden meaning.

One Final Small Matter of Semantics

To be really, really picky about the term 'concept model' in SBVR, which of the following does it mean:  "model that is conceptual" or "model of concepts"?  Experts in the field make this distinction:^[6]

• Model that is conceptual:  "[a model] of real world states of affairs.  The value of [such] a model is usually directly proportional to how well it corresponds to a past, present, future, actual or potential state of affairs."
  
  
• Model of concepts:  "[a model] usually built by analysts who are not primarily concerned about the truth or falsity of the concepts being modeled" (emphasis added).  To be a good model, a model of concepts need not have the real world correspondence of a model that is conceptual.

An SBVR-style 'concept model' is most definitely the former.  The goal of business rules is not to specify the business as it might be, but to specify the business as it is (until the very next time you change it).  That makes a big difference!

References

[1]  Semantics of Business Vocabulary and Business Rules.  See the SBVR Insider section of BRCommunity.com for discussion.  SBVR 1.0 was released by the OMG in December 2007.

[2]  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).

[3]  Use of 'fact model' and 'fact type' was not discontinued in the vital portion of SBVR specifying its grounding in formal logic.

[4]  I can vouch for the overall accuracy of the Wikipedia entry since I wrote several books touching on the subject in the 1970s.

[5]  I say "largely" because certain important structural elements of concept models — including classifications and categorizations — are not based on verb concepts.

[6]  http://en.wikipedia.org/wiki/Conceptual_model#Models_of_concepts_and_models_that_are_conceptual

# # #