Concept Model

1. Concept: The terms you are mapping. These are expressed as nouns. Formally, these are known as noun concepts.
2. Connections: The links between the concepts. These are expressed as verbs. Formally, these are known as verb concepts.
3. Instance: An single example of the concept. Only included if it helps to explain the concept
4. Properties: Attributes of the concept. Only included if they help to explain the concept.

A Concept Model is your greatest weapon against ambiguity. It clarifies the words and concepts used within a domain. It is especially useful when organisations have a lot of information and documentation because it helps people to know exactly what these words and concepts mean.

A good Concept Model provides the foundation for context-specific communication and analysis. It helps to make sure that people can communicate clearly and precisely, it ensures consistency of language, and it avoids misunderstandings.

A formal Concept Model consists of a visual diagram showing the concepts and how they relate to each other, as well as an accompanying glossary defining the terms used.

You can reason with your Concept Model. In the example above (based on the Jimmy website), you could document associated business rules, such as that an Instructional Guide must have both a Description and How-To steps—both a true statement and one of the rules of the actual site!

• When starting a new project in a complex problem space. Use a concept model to define and clarify the key concepts and terminology.
• When joining a project without an established glossary. Use a concept model to identify and define the key concepts and terminology already in use by the project.
• When reviewing or working with business rules. Use a concept model to understand and define the concepts and terms before defining any associated logic or rules.

1. Before you start, collect existing collateral and glossaries to use as reference, and gather a diverse range of people from your organisation or project.
2. Start with the most important concept in your context. This is often a customer, an order, an account, or a claim. Using a whiteboard (or a wall and sticky notes), write the name of your important concept and place it in the centre.
3. Draft a definition for the concept, ensuring that everyone agrees with it. Keep refining the scope of the concept or the definition until it is fully agreed upon. Don’t worry if it is not perfect—you’ll tidy it later. Agreement and understanding is what is important at this stage.
4. Repeat steps 2 and 3 for all the other concepts you use in your context. You’ll end up with a messy board and a rough glossary.
5. While you work on step #4, keep an eye out for:
   • Instances of a concept such as “Joe Biden” which is an instance of the concept “President of the United States”. Where helpful, add these as examples to the parent concept but don’t bother linking or defining them further.
   • Properties of a concept such as “Elected date”, which is an attribute of the concept “President of the United States”. Don’t add them as concepts. Instead, record them beside the parent concept, but only if they’re helpful to explain that concept.
6. Now that you have all your concepts on the board, go back to your first concept and ask: How does this concept relate to the other concepts? If there is a strong link, then draw a line between the concepts and add a verb to describe the relationship. Don’t worry about messy lines—the important thing is getting it recorded accurately.
7. Repeat the previous step for each of the concepts on the board, adding new concepts that you uncover along the way. Remember to define any new concepts in your glossary.
8. Now, working on your own (or with a smaller group), tidy the glossary to make the definitions as precise as possible. Identify and resolve any inconsistencies.
9. Still working on your own, tidy the board.
   • When one concept is sub-concept of another (e.g., “Female” is a subset of “Human”), link the concepts with a thick line.
   • In all other cases, just use a normal line.
10. Review the tidied glossary and board with the working group and refine definitions, concepts, and relationships until everyone agrees.

Ideally, once established, a concept model becomes a celebrated and widely shared artefact within the business, helping everyone to use language consistently.

• All concepts must be named.
• Each concept must have a relationship to at least one other concept.
• Relationships between concepts must have a descriptor verb.
• There must be agreement on what each concept means.

• Concepts should be defined in the glossary (this is highly recommended).
• If using a descriptor verb in a non-standard way, it should be defined in the glossary as well.

• Define the scope and purpose of the model! To avoid defining the entire world, make sure that it is clear what you’re trying to cover in your model. It rarely makes sense to model everything in an organisation in a single go. Better to define the scope of your concept model clearly and then rigorously stick to that scope.
• Struggling to write clear and concise definitions? Use ConceptSpeak to help you to craft awesome definitions for your concepts.
• Go with the flow. There’s usually a natural order to how you tackle concepts: e.g. customers have accounts, and accounts have an account balance… and so forth. Let the group pick the path.
• Focus on the differences. If you are defining a basketball, don’t try and define what a ball is, focus on what makes a basketball different from other balls.
• Don’t be intimidated! At the absolute minimum, people already have this information in their heads and your job is simply to get that tacit knowledge documented and agreed upon!
• Need more help? There’s a number of good books and online resources that really dig into the details of concept models. See references below for links.

• Starting from scratch! Most organisations have working glossaries that are a great help. They might be out of date, but it is insane to not use prior thinking!
• Narrow perspectives. Not including a wide range of perspectives on the concepts is likely to cause issues later. It is far better to find out up front that there’s a specific use for the term in your business. Diversity is your friend!
• Tech focus. A concept model should inform data modelling but it is not data modelling. Don’t get caught up trying to make the concepts work for their technical applications. That comes later (see ER diagram).
• Too much focusing on properties. The attributes of a concept matter far less than the concept itself. Only include properties in the model when they support the understanding of the parent concept.
• Too real world. It seems counter intuitive, but including instances (real world examples) of a concept in the model is rarely helpful. Joe Biden is not a concept, he’s a person. “President of United States,” or “American” is the concept.
• Writing a dictionary! It is a waste of time to define an established concept when there is nothing special about the use of that concept in your context. If you can reference the Oxford (or whatever) dictionary, then do so!
• Deadlines. It sounds sort of insane (until you’ve completed your first full concept model), but documenting concepts and terminology that are already established and in use is bloody hard work. Make sure you have the time and mental space to do it justice.
• Neglecting the glossary. It’s not the fun visual part of the model, but the glossary is actually where the value resides. Getting definitions down on paper and agreed upon is what will pay dividends later on.

Lots of books by Ronald G. Ross feature concept models (and to a far deeper level than captured here). I referenced Business Knowledge Blueprints and Business Rule Concepts when writing this method.