Concept models are a core technique mandated by the Business Agility Manifesto.^[1] Let's be very clear what a concept model is not.  A concept model is not a data model.  The focus of the two kinds of model is altogether different.

• A data model is aimed at how you best organize data for storage in a system.  A good one will start by trying to reflect the entities that exist in the real world, so the model is not skewed to a particular use or application.


• A concept model, in contrast, is aimed at disambiguation of the things people say and write.  Such communications can include requirements for system design but, much more importantly, things like business policies, regulations, agreements, notices (etc.) that may be far removed from system design activity.

In other words, a concept model^[2] is a technique for improving business communication across the board.  A capacity for disambiguation can obviously assist system design, but it's not about system design.

To appreciate the need for a concept model, first you must appreciate that business communication is often replete with ambiguity — full of semantic potholes.  If you've never been burned by miscommunication, then you'll never really appreciate the need for a concept model.  You can stop reading here.  But of course we've all been victimized in that respect!

The Real World Test

As above, a good data model will try to reflect the entities that exist in the real world, so the model is not skewed to a particular use or application.  Let's call that the Real World Test.  Of course, it's hard to prove what's actually in the real world, so the Test is more art than science.  There are no built-in checks that you have it right.  It's all about craftsmanship and informal consensus ('Yeah, that looks about right.').

A lesser data model will not apply the Test as diligently — or apply it at all.  As a consequence, if you don't share the designer's perspective on the problem space, then the data the data model ultimately defines is unlikely to hold much value for you.  Think silo.

Lesser data models can go off the rails for a host of reasons.  Common causes include these:

• The data model is created for some specific analytic purpose(s), and so 'sums up' the real world in a manner best suited to particular computations.


• The data model is created to support some specific points of data access or usage (e.g., GUIs, interfaces, migration, exchange, etc.), and so is skewed to those particular handshakes.


• The data model (usually a class diagram) is created to aid and support software development, and so gradually (or quickly) drifts toward reflecting the internal reality of the software system design.

But even diligent adherence to the Real World Test runs into difficulties when the things (entities) in the problem space don't actually exist in the real (physical) world.  Virtually every problem space includes at least some things that are purely inventions of the human mind.  At the extreme, think insurance and finance.  What do you do in that case?

Consistency Tests for Language

The two-part answer is to (a) entertain only ideas that are completely innocent of system design and (b) re-orient yourself toward ensuring the consistency of what you say and write about those ideas.  Now we're back to business communication and disambiguation — that is, to concept models.

A concept model necessarily focuses on natural language.  (There's no way to talk or write about complex ideas if they are not expressed in some form.)  A concept model provides patterns, both built-in and add-on, to 'prove' that what is said or written about a problem space is consistent (or not!) with everything else that is said and written about it.

If you are thinking about a concept model as primarily a diagram, you're missing the picture.  A graphical representation of the patterns in a concept model can be quite helpful, but it's a convenience, not a necessity.  This fact alone would make concept models distinct from data models.  Who would want a data model if not graphical?  You might as well go directly to the schema (database definition).

So, understanding a concept model requires full appreciation of what it brings to the table in determining the consistency of what is said and written.

The first and most fundamental step in ensuring consistency in what is said and written is robust business definitions of all concepts.  That's where the rubber meets the road.  All definitions must be unique, and each must express a distinguishable concept.

A simple glossary is a step in the right direction, but falls way short of the quality of definitions needed for disambiguation.  Internal to the wordings of robust definitions need to be worked-out schemes for such things as:

• generalization/specialization — e.g., a tiger is a mammal
• classification — e.g., Paris is a city
• partitive relationships — e.g., a chassis is a part of a vehicle

In other words, definitions not only need to be business-oriented, they need to act as artifacts of knowledge representation.  How else can you hope to prove the consistency of what is said and written?

Consistency Checks for Sentences

Try writing a sentence without a verb.  In most natural languages it's impossible.  Even in languages where it's possible, grammatical rules about defaults apply.  The bottom line is that there is always a verb in a sentence, even if implicit.

Sentences are how we communicate.   A sentence represents a complete thought (a proposition in logic).  A statement without a verb, explicit or otherwise, simply isn't a complete thought.  Incomplete thoughts, of course, are never high-quality thoughts.  Neither are sentences expressed using ambiguous or inconsistent verbs.

Not surprisingly therefore, concept models place as much emphasis on verb and verbs phrases as on nouns.  These verbs and verb phrases in your business vocabulary are 'add-on' patterns of expression.  Your business, for example, must decide whether it prefers 'party makes request' or 'party submits request' in sentences that are written.  Maybe either one is acceptable (i.e., they are synonyms).  Or maybe they mean something different altogether.

In writing complex thoughts, by far the most common cause of ambiguity (beyond misuse of nouns and poor definitions) is missing or inconsistent verbs.  When you step up to that challenge in business communication you'll realize doing a data model is nonsensical as a starting point.

Summary

A concept model is basically a set of language patterns that scales in disambiguating large amounts of business communication (including business rules, of course).  It provides built-in checks you have expressed something right.  It's not about craftsmanship and informal consensus; it's about engineering consistency and clarity where it counts the most — in the language we use to communicate business knowledge.

References

[1]  The Business Agility Manifesto:  Building for Change, by Roger T. Burlton,  Ronald G. Ross, and John A. Zachman, (2017) https://busagilitymanifesto.org/

[2]  Concept models are a central focus of the OMG standard Semantics of Business Vocabulary and Business Rules (SBVR). For more information on SBVR, see SBVR Insider on BRCommunity.com, http://www.brcommunity.com/standards.php?id=620

# # #