Change the ration 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 stll 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.

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.

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.

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