Extracted from Business Knowledge Blueprints: Enabling Your Data to Speak the Language of the Business, by Ronald G. Ross, 2020.
http://brsolutions.com/business-knowledge-blueprints.html

Should you depict the structure of your concept model using a diagram? Definitely. Visualizations are extremely helpful in portraying sizeable blueprints of anything complex. Just don't forget the definitions. A concept model is first and foremost about business meanings.

Use the diagrams to verify the completeness and consistency of your vocabulary and business definitions. Often, diagrams also help in simplifying the concept model. Always remember one very important thing though. If a diagram disagrees with the entries in your glossary, it's the diagram that's wrong, not the glossary.

Notation

What notation should you use for your diagrams? Never try to use data modeling, UML, or other software design conventions. Those conventions simply weren't designed for concept models.

A concept model is about capturing business knowledge and disambiguating business communications. It's about business meaning, not about designing computer systems or databases. Big difference — one that software and database professionals often have a hard time appreciating. Ignore this warning and you are likely to turn off business people to concept models pretty quickly.

Over the years, BRJ authors have presented their approaches to diagramming concept models in practice.^[1] [2] In our work we use ConceptSpeak™, the Business Rule Solutions, LLC (BRS) set of guidelines and techniques for designing business knowledge blueprints. ConceptSpeak includes a semantically-rich set of conventions for depicting a concept model as a diagram^[3], but it's important to note that ConceptSpeak is by no means simply a diagramming notation. It also includes a comprehensive and carefully coordinated set of guidelines for creating business definitions of terms.^[4] Without these, no approach can be suitable for concept models.

Pragmatics

Whatever conventions you use, here's an important rule of thumb for the boxes in your concept model diagrams: Never leave a new box undefined overnight. Without a definition, you have no shared concept at all, with or without a term. Take a stab at it. Sleep on it. What you wrote down will probably need significant revision, but at least you've put a stake in the ground. All bets are off with undefined boxes!

Inevitably, you will be asked to explain how to read your diagrams. Be careful about the words you use for that. Never use the word flow. Process models flow (i.e., embody a series of transforms). Concept models, in contrast, are always structural; they never comprise flows.

A consequence of the no-flow rule — one that can be initially hard for people new to concept models — is that there is no natural or preferred point to start 'reading' a concept model diagram. Any starting point is as good as another. Just dive in! That part will become easy once you get the hang of it. Also, you will always find that some concepts are more central than others, so those will naturally gravitate centerstage in your concept model and/or its individual neighborhoods.

References

[1] David Lyalin, "Applying Euler Diagrams and Venn Diagrams to Concept Modeling," Business Rules Journal, Vol. 21, No. 2, (Feb. 2020) URL: http://www.brcommunity.com/a2020/c021.html

[2] Thomas Frisendal, "Concept Mapping and Concept Modeling — Sensemaking at the Business Level," Business Rules Journal, Vol. 14, No. 5, (May 2013) URL: http://www.brcommunity.com/a2013/b700.html

[3] I will cover the conventions of ConceptSpeak in detail, beginning next time, in a multi-part series.

[4] A free primer on ConceptSpeak™ is available for download from the BRSolutions website.

# # #