Pattern Reading in Visual Discovery and Modelling

--

There is a long list of things I love about visual discovery and modelling techniques like Event Storming and Example Mapping. But there is one benefit of visual techniques which I find so valuable and yet doesn’t get the recognition it deserves: pattern reading.

What I mean by pattern reading is looking at the visual artefacts and making inferences about what the layout may be telling us. In every workshop, I always ask everyone “Imagine there is no text here. What is this arrangement of colours and shapes telling you?”.

I’ve invented the term pattern reading but I’m happy to be corrected if there is an existing term or you can think of something better.

Pattern reading is cool because you can do it with any visual technique almost at any time. As someone with no existing knowledge of the industry you are modelling, you can uncover important insights and ask valuable questions just by reading patterns or inviting others to.

Reading Domain Patterns

In the example Event Storm below, orange represents events and red represents hot spots (aka discussion points) about the events they are next to. What can you read from these patterns?

A cluster of red hot spots

You can see in the above example that a cluster of hot spots are located around a single event in the timeline. This is an indicator that the event in question is something we might want to zoom in on in more detail because multiple people have flagged it.

It’s important to keep in mind that patterns don’t tell the whole story. Maybe the same person put all 4 hot spots, or this cluster represents bike shedding and isn’t really worth exploring in further detail.

Looking at the example above, we can also see that the 5 events are in a tidy straight line with no branches. That’s always super suspicious to me. It suggests that there is a lot more hidden complexity, like edge cases.

Reading patterns is applicable when using event storms to break a business up into domains. What do you read from the image below, and what might you propose to do next in the workshop?

Two domains identified on an event storm

In this situation, you could take the visualisation at face value and infer that domain A is far bigger than domain B. But it can also be read differently: there are more events for Domain A than Domain B, but rather than domain B being smaller, maybe the people who understand domain B aren’t in the workshop and we need to invite them or organise a follow up with them. Maybe they weren’t invited for political reasons….

Reading Strategy Patterns

One of the techniques I use frequently for visualising business, product, and technology strategy is Core Domain Charts. This technique plots the business differentiation and domain complexity of a business’s domains.

I often describe Core Domain Charts as a simpler version of Wardley Mapping or a gateway to Wardley Mapping.

Reading the patterns on a core domain chart can lead to some great conversations, and quite often some major concerns. What do you see in the example below?

Everything is the core domain

In the above example we have the most classic of all problems: everything is the core domain or everything is the top priority, we’re spread too thinly and not focused enough. But there are far more interesting patterns than this one, like the one below:

A strategy with no future advantages

The above example is a warning: we expect that in two years, our core domain will no longer be our source of competitive advantage, and we have nothing else lined up to replace it. We’re not investing enough in potential future innovations and sources of revenue. And the example below shows another worrying phenomena: we’ve got too many people working on less important things (often due to political or legacy code reasons) that could potentially be outsourced and that’s stopping us investing more time in our core domains.

Why are so many people working on lower priorities and so few on the core domains?

Technically speaking, some of the diagrams contain text, like the numbers above. However, this isn’t information about the business or domain, and that’s what I really mean by “pretend there is no text here”.

Learning to Read Patterns

The great thing about this technique is that there is nothing fancy about it and no jargon to learn. All you really need to do is one thing: at regular points during your workshops, stop and ask: “if we ignore all of the text here, what are these patterns of colours and shapes telling us?”. You can do this with almost any visual workshop technique.

The barrier to entry is low but you will get better with practice. It becomes something you do subconsciously and you are quicker to recognise recurring patterns.

But beware of the caveats: the pattern doesn’t tell the whole story and patterns you see in different workshops might not really be that similar. On the positive side, collaboratively reading patterns usually results in good conversations regardless of the outcome.

--

--

Nick Tune
Strategy, Architecture, Continuous Delivery, and DDD

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)