In my work I tend to include concept maps – which can be a bit of an elastic or confusing term. But in essence we capture the concepts that describes the domain that we intend to manage – and articulate the concepts relation to each other. So in a business context it will be the business concepts and their relation to each other. There is an example to the right:

The diagram shows
- The name of the concepts.
- The characteristics of a concept (truck has capacity, axels and registrationID). Notice that these are concepts as well, but on a more granular level that we might or might not drill down to as another exercise.
- How a concept relates to complementary concepts (truck drives on road).
- How a concepts can be specializations or generalizations another concept (truck is kind of vehicle).
The Theory of Concept Maps
The link below leads to a page that has some serious evaluation and discussion on general learning in relation to concept understanding versus rote learning.
For me, concept maps is the highest level of domain understanding. – and below that we have the logical and the physical data model. But its not a strict science – and sometimes the different levels are almost the same and other times we need seriously complex mapping between the levels – which is not good for complexity management.
Concepts maps also have a nice page in wikipedia.
Complex Models
Its quite easy to cook up more complex models like for instance:

In colloquial speech all the concepts here most likely makes good sense, but when we want to build IT systems we need to go over all concepts and relations and ensure we have them defined precisely. And when I look at the diagram I right away spot that some of the relations are expressed so vague that its not useful for any real modelling effort. Like for instance: “Customer>in>Bank” - that relation does not say anything about how to operate or manage.
What I’m getting at is that Concept Maps are not as easy as the first example indicated.
What can Concept Maps be used for?
The primary function of this tool is to serve as a visual map, akin to geographical maps, allowing users to define domain boundaries and granularity through setting an area and zoom level.
Additionally, it can be utilized in the design process to evaluate the concepts required to effectively manage use cases. Lets for instance look at this example:
You are in the process of conceptualizing and developing a “Parcel Router,” which refers to a software solution responsible for calculating the optimal transportation route for parcels from location A to location B. This entails considering various feasible options for efficient parcel delivery:
- Truck and Road Net
- Boat and Port
- Plane and Airport
And, naturally, it is possible to combine these modes. However, when developing a piece of software with effective functionality, it becomes apparent that the introduction of generalized concepts is essential for its success. These concepts may include:
- Tranport Mean
- Transport Network
- Transport Lane
- Network Node
- Network Connection
- Goods Carrier
You can envision how challenging it is to get everything right, but a concept map can assist you in identifying the necessary concepts and outlining their relationships.
Concept Maps and Concept Data Models
In the literature there is a distinction between conceptual maps and a conceptual data model. In practice a see the transition quite fluent and somewhat dependent on purpose and precision. For me concepts maps are informal, and the purpose is information sharing and conceptualization. Conceptual data model on the other hand typically uses a more formal diagram framework and are focused to build a model that can support a set of use case or to document an existing data model.
Two variants of conceptual data models
As I was trying to get to the foundations of concept maps I bumped into an online presentation by David Hay (author of Data Model Patterns: Conventions of Thought) :
“Kinds of Data Models – and How to Name Them”
His take is that there is two typical ways to use conceptual data models:
- Semantic Model: In terms of the business language, as used. The vehicle for identifying semantic conflicts.
- Architectural Model: In more abstract terms: General categories that cross departmental boundaries. Also called convergent models.
I my opinion the first variant here is quite similar to conceptual maps.
Leave a reply to V-model and the Concept Leap – sunevang Cancel reply