Step 1 - Define the Scope

Don't try to boil the ocean

As I mentioned in the:

The Steps to Modeling Business Concepts

One of the first things Juha Korpela 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.