20th October 2026
Updated to the new 4 page format.
Identify the Concepts
With the Business Stories captured, the listening turns into action, and defining the Concept Model begins. We search the stories for the nouns, the things the organisation counts, manages, or tracks.
We want a shortlist of things that matter inside our Scope, named in the language the organisation uses, the first building blocks of the Concept Model.
What things does the organisation care about?
The Business Stories we captured in Step 3 hold everything the Concept Model needs, the core idea is simple, we start by identifying the nouns.
Read the stories and highlight the nouns. ‘Customer’. ‘Order’. ‘Product’. ‘Channel’. ‘Supplier’. ‘Employee’. ‘Warehouse’. Each noun is a candidate for a Concept.
Concepts are the things we care about, the same things every process and system the organisation operates describes. They form the core of the Concept Model.
A good Concept follows a few basic rules:
It is a noun, picked from the Business Stories;
It is countable, asking “how many do we have” makes sense;
It describes a thing in the real world, an event, a person or role, a place, a physical object;
It represents something important enough to maintain information about it.
Run every noun through all four. Most prove themselves in seconds, the rest earn a follow-up conversation with the Subject Matter Expert.
‘Customer’ passes all the rules. ‘Customer name’ fails the third, it is information about a Customer, not a thing in the real world, park it for later.
This is the step to take care over. When a Concept Model seems confusing, it is often poorly chosen Concepts, and no amount of technical finesse can save it.
Expect ten to twenty Concepts. Less than five and the Scope is a puddle, more than twenty-five and it is an ocean, or attribute details are sneaking in. A puddle or an ocean sends us back to Step 1 to redraw the boundary.
We end this step with a list of Concepts, each one the equivalent of a sticky note on the wall, sorted by Domain. No Relationships yet. The temptation to start connecting or defining them is enormous. Resist, they are the next steps.
Keep the list where everyone can see it, every step that follows reads from it.
Categorise the nouns
Not every noun is a Concept, but every noun leads to one. The four rules say whether a noun could be a Concept, the four categories say what it actually is, and what we do with it.
Things: Nouns that stand on their own. ‘Customer’, ‘Order’, ‘Product’, ‘Supplier’, ‘Warehouse’, ‘Employee’. These are our candidate Concepts, they go straight onto the list.
Facts about things: Nouns phrases that tell us something about a thing. “Stock level”, “Order quantity”, “Delivery date”. They become attributes of the Concept they describe, or a Relationship in waiting, park them. A metric is a fact about many things at once, “order to delivery time” is the days between a ‘Sales Order’ and its ‘Delivery’, averaged over a period, so it is related to the Concepts it is made of and never becomes one.
States of things: A thing in a condition, often wearing the condition as its name. “low Stock” is ‘Stock’, a “paid Order” is an ‘Order’, an “active Customer” and a “lapsed Customer” are both a ‘Customer’. We model the thing and keep the state as a fact about it.
Examples of things: One particular instance, named. The “website” and the “store” are examples of a ‘Channel’. “Kate Blackadder”, “a hammer” and “Edinburgh” are all examples of things. So we ask about them, and listen for the noun that comes back. “What does Kate do?”, “she is one of our Warehouse Employees”, an ‘Employee’. “What is a hammer, to us?”, “one of the Products we sell”, a ‘Product’. “Why Edinburgh?”, “it is the Location of our second warehouse”, a ‘Warehouse Physical Location’.
The story is where everything starts, and people tell stories in nouns, not Concepts. The four categories get us from their nouns to our Concepts.
Name them, and watch for the traps
Use singular names, ‘Customer’ not ‘Customers’, so the Relationship defined later ‘a Customer places a Sales Order’ reads cleanly.
Name Concepts in the words the organisation uses, even when a system disagrees. If the expert says “purchase order” and the system says “procurement document”, the Concept Model should say ‘Purchase Order’.
Name the noun fully, ‘Sales Order’ not ‘Order’, so it never collides with ‘Purchase Order’. A ten-second naming question now reduces the likelihood of a Definitions argument in Step 5 later.
Then check the list for the classic traps, the nouns that fit none of the four categories.
Technical objects: “SAP”, the “dashboard”, the “pipeline”. Not Concepts. Find the real-world thing they hold data about, SAP holds the ‘Purchase Orders’.
Artefacts: A report, a printout, a list. Ask what is being listed, not “Bank Statement” but ‘Financial Transaction’.
Things we cannot count: The supply chain, staff, paperwork. Ask “what is one of these?” Not “Staff” but ‘Employee’, not “the supply chain” but ‘Supplier’, ‘Purchase Order’ and ‘Warehouse’.
Nobody in particular: “Someone” raises the purchase order. Ask “who makes that step in the process happen?”, the way Step 3 did, and the answer is an ‘Employee’.
Clever generalisation: “person role type” is not a thing in the real world. Model ‘Person’ and ‘Organisation’ before reaching for “party”.
7th September 2026
First iteration.
Identify the Concepts
In the Identify the Concepts step, the listening turns into the first step in describing the Concept Model, we mine the Business Stories for the nouns, the things the organisation counts, manages, or tracks.
We want a shortlist of things that matter inside our Scope, named in the language the organisation uses, ready to become the first set of boxes on the Concept Map.
What things does the organisation care about?
The Business Stories we captured in Step 3 hold everything the Concept Model needs, the core idea is simple, we start by identifying the nouns.
Read the stories and underline the nouns. ‘Customer’. ‘Order’. ‘Product’. ‘Channel’. ‘Supplier’. ‘Employee’. ‘Warehouse’. Each noun is a candidate for a Concept.
Concepts are the things we care about, the same things every system and process the organisation operates describes.
A good Concept follows a few basic rules:
It is a noun, picked from the Business Stories;
It is countable, asking “how many do we have” makes sense;
It describes a thing in the real world, an event, a person or role, a place, a physical object;
It represents something important enough to maintain information about it.
“Customer” passes all the rules. “Customer name” typically fails the countable rule, it is information about a Customer, not a thing, park it for later.
Use singular names, “Customer” not “Customers”, so the Relationship “a Customer places a Sales Order” reads cleanly, not “Customers place Sales Orders”.
Name Concepts in the words the organisation uses, even when a system disagrees. Name the noun fully, “Sales Order” not “order”, so it never collides with “Purchase Order”. A ten-second naming question now reduces the likelihood of a Definitions argument in Step 5 later.
When a Concept Model seems confusing, it is often poorly chosen Concepts, no amount of technical finesse can save it, so watch for the classic traps.
Technical objects posing as Concepts, applications, reports, system tables, find the real-world thing behind them. Model “Person” and “Organisation” before reaching for “Party”.
Expect ten to twenty Concepts. Less than five and the Scope is a puddle, more than twenty-five and it is an ocean, or attribute details are sneaking in.