10th October 2026

Still need to sort out a hero image for it we don’t hate.

Find a Subject Matter Expert

Once we know the slice of reality we want to model, we need to find someone who lives in it. The Subject Matter Expert is our guide. The person who can describe how the organisation really works, in the language the organisation really uses.

Their words become the language of the Concept Model. Their stories become the Business Stories we capture in Step 3. The Concepts, their Relationships and the Relationship Rules we surface later all trace back to what they tell us. Without them, we model from systems, documentation and our own assumptions, rather than from organisational reality.

Who can give us the stories that describe this slice of reality?

We could cobble the Concept Model together by gathering the evidence ourselves, sifting systems and documentation like a crime scene investigator piecing together what happened.

However, when we want to understand the core context of the organisation, it is far easier toask someone who already holds it.

We want the actual story, told by the people who live it, in the language we are trying to capture.

The right person can tell us how the work really happens, what the important Concepts are, and what the organisation means by each one.

When we ask them what they mean by a Customer, we learn more in a sentence than a week of reading table definitions would ever teach us.

However experienced a data modeler we are, the answer is never us. Modeling Business Concepts is a collaborative activity. We never build the Model on our own.

It is tempting to turn to IT for this. They are close by, and they speak our language. That is the trap. We are not modeling the systems, we are modeling the organisation. Find the people who do the work, not the ones who automate it.

If we cannot get an expert at all, pause. A Concept Map built from assumptions is a list of guesses drawn in a diagramming tool.

We can prepare candidate Concepts from documents and existing models, but the Concept Map is not real until a Subject Matter Expert has walked it.

Find a Subject Matter Expert who knows how the work really happens. Who knows how the money is really made.

Who to look for

The ideal Subject Matter Expert has hands-on experience in the slice of the organisation we are modeling. They understand the individual tasks and the wider processes those tasks sit inside. And they can zoom out, simplifying the detail when a higher level of abstraction is all we need.

In practice they do the work, manage the work or lead the work. The operations manager who untangles every exception. The person in the store who knows why some orders ship from the other warehouse.

And often it is the person everyone else goes to when the process gets uncertain. Uncertainty is where the modeling magic happens, the weird edge cases reveal the missing rules.

Ask “who can tell me what happens in this process?” or “who knows how things work in this team?” and listen to whose name comes up first.

The right person starts talking about the work. The wrong person starts talking about the systems. The right person does not have to understand what a data model is, and it is often better if they do not.

Sometimes one person cannot cover the Scope and we need two or three. That is fine. If it takes a crowd, the slice is probably too big. Go back to the Scope and narrow it.

Two experts who disagree are the discovery. Every disagreement is a Definition or a Relationship Rule the organisation never wrote down, surfacing in a session instead of in production.

Our Subject Matter Expert is the retail operations manager. She has run stores, managed the warehouse roster, and chased more late deliveries than she cares to remember. She has never seen the order system’s data model, which is exactly what makes her perfect.

How do we invite our expert

Occasionally we hear that the people we need are too busy, and that even if they had the time they would not understand what we were asking. The opposite is true. People love talking about their work. They rarely get asked about it properly. When someone listens with genuine curiosity, the stories flow.

So ask for something small. A first discovery session for a well-scoped slice takes sixty to ninety minutes. Nothing to read beforehand, nothing to prepare.

Ask for their permission to help you discover and capture stories, not for attendance in a technical session. “We would like you to walk us through how an order really happens” is an invitation.

Tell them what they will see during the session. Their words going up on a wall or a shared screen as they speak, where they can correct them on the spot.

Say who else will be in the room. A Facilitator who asks the questions, and the Data Team, who mostly listen.

Tell them what they get back. A Concept Map drawn from their stories, brought back for them to check. And the Definitions that go with it, in their words. The next time someone asks what a late delivery means, the answer is ready to share.

Then talk about their work. Make new friends. Learn how the money is made. The relationship built in this step pays for itself for years.

We never draw a Concept Map on our own, send it to them beforehand and tell them the session is to review it. “Please attend our data modeling session” or “Please review our data model” sounds like homework. “Walk us through how an order really happens” sounds like show and tell.

25th September 2026

First iteration.

Still need to sort out a hero image for it we dont hate.

Find a Subject Matter Expert

Once we know the slice of reality we want to model, we need to find someone who lives in it. The Subject Matter Expert is our guide. The person who can describe how the organisation really works, in the language the organisation really uses.

Their words become the language of the Concept Model. Their stories become the Business Stories we capture in the next step. The Concepts, their Relationships and the Relationship Rules we surface later all trace back to what they tell us. Without them, we model from systems, documentation and our own assumptions, rather than from organisational reality.

Who can give us the stories that describe this slice of reality?

We could cobble the Concept Model together by gathering the evidence ourselves, sifting systems and documentation like a crime scene investigator piecing together what happened.

When we want the core context of the organisation, it is far easier to ask someone who already holds it.

The ideal Subject Matter Expert has hands-on experience in the slice we are modeling. They understand the individual tasks and the wider processes those tasks sit inside. And they can zoom out, simplifying the detail when a higher level of abstraction is all we need.

Someone like this can tell us how the work really happens, what the important Concepts are, and what the organisation means by each one. Ask them what they mean by a Customer, and we learn more in a sentence than a week of reading table definitions would ever teach us.

The question to ask ourselves is “who can give us a narrative description, a series of stories, that explain this slice of the organisational reality?”

However experienced a modeler we are, the answer is never us. Modeling Business Concepts is a collaborative activity. We never build the Model on our own.

It is tempting to turn to IT for this. They are close by, and they speak our language. That is the trap. We are not modeling the systems, we are modeling the organisation. Find the people who do the work, not the ones who automate it.

Occasionally we hear that the people we need are too busy, and that even if they had the time they would not understand what we were asking. The opposite is true. People love talking about their work. They rarely get asked about it properly. When someone listens with genuine curiosity, the stories flow.

And if it takes a crowd of people to cover a single slice, the slice is probably too big. Go back to the scope and narrow it.

Find a Subject Matter Expert who knows how the work really happens. Who knows how the money is really made.

First iteration.

First iteration.

These pages are the ones that get iterated the most during the Guide writing process.

We start with lengthy vague definitions and constantly iterate and refine them as we write the rest of the guide.

Until we end up with something that is clear and concise and defensible.

We stress test them, by asking questions and seeing if these four definitions survive.

For example, “when we define a defintion is it only a definition for a Concept so should it be called a Concept Defintion? Or are we actually capturing fefinitions for things other than a Concept?”

7th October 2026

First published iteration.
(multiple iterations have gone into the making of this current version)

First iteration.

Business Analyst

As a Business Analyst,
I want a quick and visual way to capture how the organisation actually works,
So stakeholders recognise it, data teams can design from it, and I can stop constantly having to translate between the two.

Product Manager

As a Product Manager,
I want to communicate how the organisation works on a single page,
So we can define each Information Product in a shared language and prioritise the next most valuable business problem solve.

Stakeholder

As a Stakeholder,
I want to explain how my part of the organisation works, once, in my own words,
So the things the Data Team builds match the reality I live in every day.

Data Analyst

As a Data Analyst,
I want a map of the Concepts, Core Business Events and Defintions behind the data,
So I can find and understand the right data faster and trust that Customer means the same thing in every table I join.

Data Engineer

As a Data Engineer,
I want to understand the data the organisationreally cares about and how they connect,
So I can design physical data structures and data flows, from that reality, not from guesswork over source tables.

Data Leader

As a Data Leader,
I want modeling patterns my teams can adopt and adapt,
So the knowledge of how our organisation works is shared and durable, not locked in a few heads.

Way of Working Coach

As a Way of Working Coach,
I want a set of easily explainable modeling patterns,
So I can teach and coach these patterns to data and analytics teams and help them experiment, iterate and improve their Way of Working.

Agreeing things like ‘Conceptual Model’ or ‘Concept Model’. Or do we “Discover the Relationships” first or “Surface the Core Business Events” first in the 11 Steps.

As well as describing the pattern for the 11 step process of Modeling Business Concepts the Guide will also provided example Pattern Templates people can use to get started.

One of the parts of the Guide we are working on right now is what do we capture in the Definitions Pattern Template.

I am more of a visual person and find experimenting with examples is the best way for me to codify something that is abstract.

I have been working on a number of open source standalone Pattern Template apps off and on, when the time and desire presented itself.

Pattern Template Apps like the ones I have published for the:

Information Product Canvas

https://github.com/AgileDataGuides/information-product-canvas

Business Event Matrix

https://github.com/AgileDataGuides/business-event-matrix

Business Glossary

https://github.com/AgileDataGuides/business-glossary

But wait there is more

Behind the scenes I have a bunch of Pattern Template Apps, in various state of undress, I haven’t published yet:

Modeling Business Concepts companion app

As I have said already one of the things Juha and I are working through right now is the Pattern Template for Definitions.

The Pattern Template will provide a recommendation and example of what would we capture as the actual Defintion for a Concept.

This will help us iterate this page of the Guide.

And specifically this part of the content on that page:

In one of the previous iterations of working on the Business Glossary app I stumbled across the “Aristotle’s definitions” pattern and started to use it as the format I used when I described a Concept.

Juha uses a format for Definitions which is based on the “intensional” and “extensional” Pattern which we used as the basis for the content on the Definitions step page:

1. What do you mean by <thing>

2. A few examples or subcategories

3. Possibly confusing special cases.

We have started discussing if we should recommend the Aristotle’s definitions pattern as the way to document “What do you mean by <thing>” part of the defintion.

Modeling Business Concepts companion app

Typically I would have jumped straight into creating a Google Doc or Google Sheet and started to create a Pattern Template for this.

As I have said seeing examples helps me understand and iterate things, it would also give Juha and I a shared language to work with.

But in the new GenAI world its much easier to quickly vibe code an app.

So that is what we did.

https://github.com/AgileDataGuides/concept-model

You can try a live version here:

https://agiledataguides.github.io/concept-model/

Step by Step

One of the decisions we made was to align the UX for the companion app wth the 11 steps process in the Guide.

We can iterate these to provide more guidance on the steps as we create it.

But wait there is more ….

And I had the benefit that I already had a bunch of components in this space, so of course I decided to extend the Companion App somewhat.

Concept Map

The obvious next thing to add was the ability to see the Concept Map.

We have styleed this to match the style of the Concept Map diagrams in the Guide.

I have also added an export to SVG option, so I can see if I can use it to generate the images for the Guide, rather than having to hand craft them.

We can also use the companion app for the example Concept Models we need for the Example (Orange) chapter, and then provide links to the full Concept Model examples.

And more and more and more …

As is the way we will now end up iterating the companion app as we iterate the Patterns, Pattern Templates and content in the Guide.

So follow along and provide feedback

We don’t want to flood this Substack with features we add to the Companion App, so follow the github repo if you want to know when we have added or iterated something.

https://github.com/AgileDataGuides/concept-model

If you have any suggestions of what we should add or iterate when you try using it, feel free to leave a comment here.

First iteration.

First iteration.

We need to add 2 more benefits to balance out the left hand page.

Learn how to map how your organisation works, with your Subject Matter Experts, in hours, which your Data Team can start designing and building from in minutes.

A Shared Picture Of The Business Model

Learn how to draw a single map that stakeholders recognise and data teams can build from. No more maintaining one diagram for the stakeholders and another for the engineers, with all the drift that comes from keeping two versions of the truth.

Model The Business, Not The Systems

Learn to describe the reality behind your systems, the things your organisation manages, tracks, and cares about, rather than technical details. When you replace the system, the model still holds.

Conversations Over Documents

Learn to capture Business Stories in natural language and distil them into Concepts, Relationships and Core Business Events, live, with the people who know the business model. The conversation builds the alignment, the Map just records and visualises it.

A Repeatable Pattern You Can Teach

Learn eleven steps you can run in order the first time, then adapt to your context. Teach them to your entire data team: when everyone knows the basics, modeling stops being a bottleneck.

Definitions Everyone Agrees On

Learn how to surface what your organisation actually means by concepts such as Customer, Order, and Product. Capture the core semantics of Concept Definitions before they become expensive misunderstandings.

A Map That Feeds Any Method

Learn how a Business Concept Map can be used for both solution design and organizational context for AI. The Map gives you a solid foundation to build on.

Climb the data mountain one step at a time

21 November 2025

an Agile Data Guide to Modeling Business Concepts

Learn how to bridge the gap between how the business works and how data teams design data that stakeholders recognise, understand and love.

11 November 2025

First iteration.

Agree the Definitions

In the Agree the Definitions step, we take each Concept from Step 4, and ask the Subject Matter Expert what we mean by it, then write the agreed answer down in plain words anyone in the organisation can understand.

We want everyone to mean the same thing when they say ‘Customer’, since the name itself is not self-describing, and without the Definitions each person reading the Concept Map applies their own context and takes away a different meaning.

What do we mean by ‘Customer’?

In any organisation larger than one person, the Concept of a ‘Customer’ carries several meanings, some of them contradictory. Even Concepts common in an Industry often hide complexity.

Is a person with an Account and no Sales Orders a Customer, or a prospect? Is the shopper who bought a bottle of Gin three years ago still one? When the person who pays and the person the Delivery goes to differ, which is the Customer?

So for every Concept we ask the Subject Matter Expert one question, “what do we mean by that?” Every time a new Concept is identified, we ask the same question and capture the defintion.

Expect a discussion, the question is simpler than the answer. Every meaning surfaced in the conversation now saves misunderstanding or an argument later.

Together the Definitions form the basis of a glossary, the second pattern template in this guide. Without a glossary the Map is useful. With one it is valuable, it can be understood and reused by anyone or anything.

A good definition is simple enough for a non-expert to understand, and precise enough to leave no room for misunderstanding. The balance takes a few goes, the traps are a wall of legalese on one hand and a tautology on the other, ‘Customer Type’ defined as “a type of Customer”.

A three-part pattern gives a good middle ground.

First, one or two sentences in everyday language on the nature of the thing, the conditions for calling something a ‘Customer’ or a ‘Product’.

Second, a couple of real-life examples, so a future reader has something concrete to build on. Only a few examples, never every possible one.

Third, the special edge cases, the points of confusion, the misunderstandings and arugements we can see coming. Each new one we meet gets added here, so it only happens once.

Do not chase perfection on the first pass. Agree the easy ones, flag the hard ones, keep moving.

Second iteration.

Have you ever suggested modeling before the build starts, only to hear “we don’t have months for that” and watch it get skipped entirely? And did you find yourself thinking “but skipping it is why everything takes so long”?

Have you ever delivered a customer count to your stakeholders, only to be told “that doesn’t match my number”? And then find out, that their customer and your customer were never the same thing?

Have you ever presented a data model to your stakeholders only to be told “that’s not what we do”? And did you find yourself thinking “but that’s what the source systems capture”?

If you’ve answered “yes” to any of these questions, welcome to an
Agile Data Way of Working!

You’re holding an Agile Data Guide for business analysts, data analysts, data engineers, data modelers, data leaders, and enterprise architects striving to capture the reality of their organisations in a simple map that stakeholders recognise and data teams can build from.

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.

First iteration.

Introducing Modeling Business Concepts

For too long, data models have been created by data practitioners, for data practitioners. They describe tables, columns and keys, and they are validated by the only people who can read them, which is to say, other data practitioners.

The problems aren’t with how they create those diagrams. They are with who the diagrams are designed to serve and what the diagrams try to describe.

Most data model diagrams describe a technical system. Very few describe the organisational reality.

Yet every piece of data work rests on an understanding of how the organisation works.

Every Information Product, every pipeline, every data platform table encodes somebody’s mental model of customers, orders, products and the moments that connect them.

Every piece of data work has a Concept Model. The only question is whether that model was consciously written down and agreed, or whether it lives in someone’s head.

Modeling Business Concepts is how we get that model out of heads and onto a single, shared page. One the whole organisation can read and understand.

Agile Data Guides are not linear step-by-step manuals. They are a choose-your-own-adventure, empowering you to discover, explore and experiment with patterns that potentially solve your current challenges.

Whether designing a data platform, documenting your organisational context for AI, or upskilling your Data Team, the patterns and templates in this guide are flexible, reusable, and adaptable.

Combine these to craft your own Agile Data Way of Working, tailored to your organisation’s context. The patterns outlined in this guide are not a rigid methodology, they are a pattern library, the culmination of years of collaboration, experimentation, and refinement.

This book is a guide to change the way data teams and stakeholders understand their organisation. It introduces Modeling Business Concepts, helping teams create a shared language, capture it as a Concept Model, and turn it into pictures and words that reflect how your organisation actually works.

We hope this guide inspires you to change the way your data teams work, delivering more value, faster, with less waste. Whether your journey ends in massive change or incremental improvement depends on your context, your journey starts here.

What This Guide Covers, a Model, Process, Map and Definitions

The Model is the Concept Model, a pattern for describing what we understand about our organisation. Its Concepts, their Relationships and the Core Business Events that connect them, written down and agreed in the language of the organisation, so stakeholders and data teams work from the same understanding.

The Process is Modeling Business Concepts, the core content of this guide. A series of steps that capture and distil conversations and stories into the Concept Model. A Pattern Storming process, run live with the people who hold the knowledge, drafting the Model together in hours rather than months. Agreement happens in the room. And nobody models alone at their desk or in a small dark cupboard.

The Map is the Concept Map, a pattern template that presents the Concept Model as a picture on a single page. Stakeholders recognise it at a glance. Data teams can design and build from it.

The Definitions are the second pattern template. They define everything in the Concept Model by answering one question, what do we mean by that. So everyone means the same thing when they say Customer, or Customer places an Order, and the Map can be read by people who were not in the room.

First iteration.

Capture Business Stories

In the Capture Business Stories step, we ask the Subject Matter Expert to tell us what happens in the organisation, as a story, as a narrative, using natural language.

We want real-life narratives of how work happens, in the organisation’s own words. The same stories we hear when we follow a customer’s journey or walk a process from end to end.

How do we get our expert to tell us the relevant story?

Ask the Subject Matter Expert one question: “walk me through what happens, from the beginning”. Then be quiet and write down or record what they say, in their words. Not in your words. And certainly not in the data platform’s our technical systems words.

A Business Story / Narrative sounds like the customer order story on the left hand page. Unremarkable, and that is exactly the job. It is how the expert would explain the organisation to a new starter over coffee.

No system names, no table names, no acronyms. If one creeps in, gently ask “and what actually happens in real life when that system does that?”

Some Subject Matter Experts can talk all day from one question, perfect!. Others need another way to begin.

Choose a protagonist. A person, a new customer, or even a thing, a credit card, a product. Follow them through their journey inside the Scope you have already chosen. “How does someone become a customer? Who do they meet?”

Follow a process. Skip the diagrams and ask the expert to narrate it in their own words. “Who does what? What is being processed?”

Walk backwards from the result. Start from the thing we most need to understand. Take churn. “What does a churning customer actually do, or stop doing, in real life?”

Capture a handful of stories, not one. The happy path first, it establishes the spine. Then the variations that make the expert grimace, “they return part of a delivery”. Variations surface Concepts and rules the happy path hides.

We both did this step unconsciously for years. Never conciously doing it caused us no end of problems when we came to draw the Concept Map together for this guide.

So make the stories explicit, and keep them. Every step that follows reuses them, and Step 11 walks the Concept Map back through them. When someone challenges the Concept Model in a years time, the stories are our evidence.

Initial draft and a light review by .

Will need to be iterated as we nail the core problems the book is solving as part of continue to draft it.

Information Value Stream
Define Once, Reuse Often (DORO)

Modeling Business Concepts is a pattern that delivers the highest value in the DESIGN, BUILD and ENHANCE stages. It can also add value in the DISCOVER and PRIORITISE stages.

Information Value Stream stages

leverage many

Ways of Working Patterns & Templates

During the DESIGN stage, the Business Concept Map is created and iterated to identify the Concepts, define and agree the Concept Definitions, discover the Relationships between them and identify the Core Business Events. This is where Modeling Business Concepts earns its keep, creating a shared understanding which the Data Team can build from.

During the BUILD stage, the Business Concept Map is iterated into an as-built reference, confirming the concept model maps to the physical data model that has actually been delivered. It keeps earning its value through the ENHANCE stage, updated every time the Information Product is iterated.

During the DISCOVER stage, a lightweight Business Concept Map can help surface the language and boundaries of a problem and assist with PRIORITISATION.

7th September 2026

Sorted out the design for the Concept map images, so update based on that.

Also iterated the text to tighten it up a little.

Identify the Scope

When we start modeling business concepts, the very first step is to decide which slice of the organisation we are going to model first. This is a question of scope, we want to identify the boundary of what we are about to model.

We want a boundary small enough that we focus on what matters right now rather than trying to boil the ocean.

What is the boundary we are about to model?

The Scope of a Concept Model is always a small slice of the organisation, the part we need to understand to deliver the next most valuable piece of data work

We often describe that slice as a Domain. A Domain is an area of the organisation centred on one important topic, where the things inside it relate more closely to each other than to anything outside it.

In each modeling iteration, the Scope might be one Domain, part of a Domain, or a deliberate combination of Domains.

Common ways to slice an organisation into Domains include:

• By business processes;

  “Order-to-Cash”, “Procure-to-Pay”

• By value chains;

  “Credit Management”, “Customer Deposits”

• By organisational design;

  “EMEA division” and “APAC division”

• By business capability;

  “Flight scheduling” and “Ticket management”

The problem we are trying to understand and solve sets the boundary of the Concept Model for this iteration.

Sometimes we need to model a very specific, finely cut slice, and sometimes a larger Scope is needed to make sense of the bigger picture.

The Concept Model then describes the things we care about within the chosen Scope.

Beware the ocean. We shouldn’t try to discover the entire organisation in one go, we iteratively build out the Model, one small slice at a time.

Beware the puddle too. If the Scope is a single report, we will model the report, and we will be back next week to model the next report.

And beware the system. We’re modeling the organisation, not a system or a database, so we take our cues from how the organisation actually operates, not how software stores the data.

One of the most common mistakes in Modeling Business Concepts is to look at a system instead of the organisation behind it.

26th February 2026

Change the ratio of the left page image so it fits the wide format of the book better,

Added an image to the right page to give it an example, will carry this through into the other page steps.

Iterated the text to tighten the language and recorded it to flow the “story” better.

Will still require a final iteration when the other steps are done, to make sure this chapter flows coherently across all the pages.

17th February 2026

Slight update to the intro text for this page.

I loved the prose that crafted for the opening of this page.

”Imagine you’re a landscape painter. You’re sitting outside on a hillside. On the left opens a view of rolling hills and fields. On the right there’s a dark forest of tall trees and brambles. What your painting ends up looking like depends very much on which direction you decide to look at!”

Unfortunately when I tried to extend the analogy to the pages for the other steps, it didn’t really work. Even with multiple goes using multiple LLM’s.

So back to the same format of opening for the Green book.

Still need to work on the #D Images for these pages, but started putting place holder images in there for now to see if they work as a concept.

18th December 2025

As I mentioned in the:

One of the first things and I needed to define and agree was the steps in that process.

Now we have done that we need to draft very rough content for each step to see what steps survive and which get iterated, reordered or removed completely.

So here is the first very rough version of the first step.

Structure of these pages

In the Agile Data Guides we use a pattern of describing a part of a Pattern Storming process or an area of a Pattern Template in across a consistent two page layout/spread :

• At the top left we give it a name, and top right we provide a question this step / area will answer to quickly give the reader of the page the context at a glance;

• Middle left we provide a short framing statement that explains the intent of the step or area and anchors why it matters before going into detail;

• Bottom left a zoomed in image that provides a visual clue of this step or area in the context of the complete process or template;

• First column on the right provides practical guidance on how to complete this step or area, including relevant examples;

• Second column on the right provides more context, examples or anti-patters to watch out for when completing this step or area.

We repeat this layout / content as a dedicated page for each step or each area.

As you can see there is a visual combination of text and whitespace, so we make multiple iterations of this content as we write the guide, until we have just the right level of text content that provides everything you need to know and nothing you don’t.

How should we add out thoughts?

As we have mentioned in previous articles we are writing in public for this Agile Data Guide, which means we will post our thoughts in the content as we iterate it.

Last article I used the comments part of Substack to do that, this time I am experimenting with my thoughts inline as part of the article, feel free to post a comment on which pattern you prefer we use, our thoughts inline or our thoughts added as comments?

Thoughts on the Scope content

I love the way Juha created the intro text by using something outside the data domain to explain the concept of what scope is and why we should care.

I am not sure we can carry this same example through all the step pages, but i’m very keen to retain this way of crafting the framing statement.

We are working on the full example Concept Model visual diagram we are going to use for the book at the moment so currently just a placeholder for that visual image in this page.

I like the way the content refers to “reality” this is a key theme of the guide, so its good to reinforce it where it makes sense.

Its tempting to add text that define what a Domain is, but I feel that its better to just provide examples of domains and let the reader create their own defintion. But I am up in the air on this one, something for Juha and I to discuss further.

We need to iterate the list of domains we currently provide as examples, so far we have:

• By business processes

• By value chains;

• By organisational design;

• By business capability;

And we probably need to create a longer set of content for these in both the Purple Pattern chapter of the Guide and the companion Substack site for those that want to read more.

Also not sure providing the examples Domains directly under the Domain boundary / type bullet point is the best visual option, not sure if it gets lost and should be on its own, or if co-locating it provides the best context.

• By business processes
  “Order-to-Cash”, “Procure-to-Pay”

• By value chains;
  “Credit Management”, “Customer Deposits”

• By organisational design;
  “EMEA division” and “APAC division”

• By business capability;
  “Flight scheduling” and “Ticket management”

The organisational design example is interesting, I always think of this one as Finance vs Sales vs Human Resources, but that often overlaps a lot with Business Capability. The regional / location division is an interesting example, but maybe only relevant to large organisations?

The second column needs iteration, there is a bit of redundancy in the text, but it is highlighting the two key points we wanted:

1. Don’t define your Concept Model based on your source systems.

2. Make each iteration of the Concept Model as small as possible.

Last thing is I think we have covered what a scope / domain is, and what not to do when identifying one, but not sure we actually cover the How to define one.

As always all comments and feedback on what works, what doesn’t, what you like, what you don’t like, whats missing etc is appreciated, so feel free to add comments.

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

10th October 2026

Slight tweak to the visuals on the journey diagram

9th October 2026

Simplifying to 10 Steps, dropping the Core Business Events steps from being a step to being one of the patterns we use as part of the other steps.

28th September 2026

More refinement of the wording.

Modeling Business Concepts

11 Steps

6th May 2026

Slight variation in wording and an iteration on the Pattern Definition.

16th February 2026

As we have been writing the draft content for the guide and I have also been testing the 11 step process as we go to see if it survives or needs to be iterated.

Of course it needs to be iterated, first ideas or drafts always do.

We both model in a way that is different, but also in a way that is closely aligned. While I think in terms of Core Business Events, Juha thinks in terms of Relationships between Entities.

As part of writing a book to teach the process of Modeling Business Concepts we need to understand and then converge our different ways of working, so we can write a shared approach that is easier to understand and follow.

One step that has stood out as a disconnect between us is the step of identifying the Core Business Events.

I tend to do it at the beginning in my modeling process, the Concept stage, Juha tends to do it at the Logical / Physical modeling stage.

So to test the steps we decided to use the process to “Draw the Map” for an example. As a result of that experimentation it became clear that its easier to teach the step of surfacing the Core Business Events later in the process, Step 8, rather than earlier, i.e Step 4 where we originally had it.

This is driven by the way we both capture the Business Stories / Narratives.

One of the things we have learned as we compared our slightly different ways of creating Business Concept models, is often we do a step unconsciously, especially when it comes to capturing the Business Story / Narrative, more on that later and in another article.

11 Steps

The latest version of the 11 steps are:

And the narrative version for them:

Both versions will need iteration on the text to tighten it up and make it a lot clearer, but that is always part of the book writing process.

As I said we tested this process somewhat by drawing the map based on it, which looked like this:

Step 1 - Identify the Scope

Step 4 - Identify the Concepts

Step 6 - Identify the Relationships

Step 7 - Describe the Relationship Rules

Step 8 - Surface the Events

Again the map style and notation will be iterated over time. And we will be writing pages in the book to support the different various different map styles and notations we know are commonly used. But we need to iterate one as the core of how we teach the process in the book, and this is the beginning of that process.

You will note that I havent pasted a version of Step 3 - Capture Business Stories, this is one of the steps we worked out we both capture unconsciously when talking to the subject matter experts.

And not defining this upfront when we started to draw the map caused us both no end of problems.

As part of my Data Day Texas presentation Juha and I ended up creating a Business Story / Narrative based on an anonymised example from an organisation I had worked with previously, and then running through the rest of the steps using it, which was a much smoother process.

Just goes to show we are on the right journey, but its still a journey with a long way to go.

27th November 2025

As I mentioned in the:

This Agile Data Guide is slightly different to the previous Agile Data Guide in that its both being co-authored and that its describing the Pattern Storming process of Modeling Business Concepts, rather than describing a Pattern Template you use to define or Map the Business Concepts.

One of the first things and I needed to define and agree is the steps in that process.

So here is the first very rough version that we have defined:

In the Agile Data Guides we use a pattern of describing the Pattern or Pattern Template in three different ways:

1. The left to right steps in image one

2. A narrative version in image two

3. A diagram or map version which we will create much later

The goal of this version is to elicit a conversation between Juha and myself. To be able to point at a specific step in the process and say “I don’t think it belongs there” or “I think it should be called something else” or “I think the description of that step needs to be iterated”, or just “WTF are you thinking”.

As part of our co-writing process I thought we could try a little audience participation.

So I am going to experiment with using the comments feature in Substack for this content to have the conversation with Juha on what I think we need to change.

Fell free to jump in and state an opinion if you so wish. We may agree with your comment and iterate the content based on it, we may not. But we will deffo read it.

When I wrote the Green Book, “an Agile Data Guide to Information Product Canvas” I spent an inordinate amount of time and effort on the structure of the book, as well as the layout and the colours.

To be clear the structure of the Green Book was an iteration on the Business Model Canvas book, a book I have loved and admired for many years.

This focus on the structure of the Green Book gave me a Pattern Template for the future Agile Data Guides I had backlogged to write. I was working in advanced to hopefully benefit from that effort in the future.

When I started drafting the Pink Book, “an Agile Data Guide to Data Persona Template” I got to test that Pattern Template, test whether this structure, layout and colours would survive a second iteration, and they did.

But it is a Pattern Template that only I understand and one I hadn’t documented.

Juha sent me a message on our shared slack channel, the message went:

“Shane Gibson for my thinking reference, could you give a brief overview of the various color chapters here? What’s each chapter for etc. You probably have this deeply ingrained in your brain at this point, but I’ve only read your information canvas book once so I keep forgetting which is which 😄”

(we are using Google Docs, Slack and Trello as our primary authoring and collaboration tools, yet another experiment to see how they go for two people to co-author a book remotely and asynchronously.)

I sent Juha back a short set of bullet points in the structure of the guides.

But I thought I might as well document or describe the Pattern Template structure of an Agile Data Guide in more detail here, because you might find it interesting.

Chapter 1 - White Chapter - Introduction

This chapter is an introduction to the guide, it tells the reader why they should care and why they should keep reading.

It sets the scene for the book.

It covers the problems the book is trying to help solve, the benefits the reader will get from reading it and who wrote it.

It also covers the definition of the Pattern or Pattern Templates described in the book, anchoring the reader to the semantic language or context used in the book.

Chapter 2 - Blue Chapter - Process

The colour of this chapter is different for each guide, it matches the colour of the cover, the name on the spine of the guide, in this case its the Blue Book.

This chapter is the meat and potatoes of the guide, this chapter explains the key Pattern or Pattern Template we are teaching or sharing in the guide.

The goal is for the person reading this chapter to be able to walk away and try to apply the thing we are describing in this chapter immediately after reading it.

For the Blue Book, this chapter currently has a placeholder name of “Process”, this will be iterated as we continue to write the book and discover a better name for the chapter.

Chapter 3 - Orange Chapter - Examples

This is where we provide example Business Concept Models (or Maps as we think of them), with some narrative about that example.

I found that providing example Canvases in the Green Book, was a great way of reiterating the patterns inherent in the canvas template and help people to understand what it is and how to use it.

We think Business Concept Map examples will achieve the same outcome.

The chapter is based on a pattern of learning by example so to speak.

Chapter 4 - Purple Chapter - Supporting Patterns

This chapter has all the additional content and information that is useful to support a readers understanding of the core Pattern or Pattern Template the book is focussed on.

While the book is always focused on one core Pattern or Pattern Template, there are always a ton of other patterns and templates that support its use, we describe those here.

For example in the Blue Book we are planning to cover how a Concept Map compares to an ERD, how Concept Maps can be represented as a Matrix, how a Concept Map with an enterprise focus might be different to one with an incremental delivery focus.

At the moment this chapter has a placeholder name of XXXX. We will wait until we have drafted a number of the Purple chapter articles and then the core theme for that chapter will emerge and that is what we will name it.

Chapter 5 - Green Chapter - Agile Data Way of Working

This chapter is repeated across all Agile Data Guides, it provides a blueprint of the patterns that I use to help a data and analytics team change the way they work.

This content will be iterated in each guide, as I learn more writing the next guide and will retrospectively be updated in the previous published guides.

I am intrigued on how working with Juha on this book will result in iterations to this chapter and the overachieving set of patterns that make up the current blueprint.

Chapter 6 - Grey Chapter - Frequently Answered Questions

Text based Q&A style content that answers the questions that get commonly asked.

This chapter reiterates the key messaging and content already in the book, just in a slightly different format.

It essentially uses a re-articulation pattern, deliberately repeating and reframing earlier content so the reader hears the same ideas from different angles.

I tend to collect these questions when running the course that the book has been tested and validated based on, so will be interesting to see how Juha and I gather these questions for this book.

Chapter 7 - Green Chapter - Continue Your Journey

This is the last chapter and provides more information on where people can get more great content to continue their learning on Modeling Business Concepts or other adjacent content that would be valuable.

We provide links to books and courses from other authors that would be valuable to the reader and we provide links to the extended content we have written to support this book.

We also get a guest expert to write a couple of pages on how they apply a related Pattern or Pattern Template in this area.

A way to write Agile Data Guides with agility

And that my friends is the repeatable structure of “an Agile Data Guide”.

As with all things in the Agile Data Way of Working there is both a structure that can be repeated, but also a structure that can be adapted given a particular context.

One of the interesting things with the Blue Book is that the core chapter in the Green and Pink books (Chapter 2) are both based on describing a Pattern Template. The supporting parts of those books describe the Pattern or process you can take to use and apply that template.

For the Blue Book, we are flipping that.

The core chapter, the Blue chapter, is describing the process you can use to Model Business Concepts, and the supporting parts of the book describe the Pattern Template of a map or a diagram that you can use to capture the content you elicit out of that process.

It will be very very interesting to see how much of the structure of the guide we need to iterate as a result of this change in context.

Data Teams model data to achieve the goal of using that data to deliver an Information Product.

This modeling process is constrained by a number of physical limitations. And that is ok.

But it also means that often the physical model itself does not match the business reality of how the business actually operates and what things are actually called.

Problem Statement

Option 1:

Option 2:

We need a way to create a shared language that both Stakeholders and Data Teams understand.

A language which provides a map of the reality of the business. And a map data teams can use to build the physical data structures they need to deliver the Information Products.

This shared language, this visual map, is called a Business Concept Map.