3.4 Tactical event storming

Tactical event storming adds fidelity to your business processes and event maps. It extends your "line of sight" down into the technical design while still protecting core customer value.

Edge of the desert in Erg Chebbi, Morocco.

Introduction

In chapter 2.3 Strategic event storming, we explored how to use event storming to reveal a lot about your product, its features, and what makes a successful delivery. The goal with event storming in that exercise was to model your business events and bring clarity to how different processes interoperate. The focus was on the business and not on technology.

In many regards, tactical event storming is an extension of strategic event storming.

This is were we transition from thinking about what is happening (the business process) and start thinking about how it happens (the technical implementation under the hood).

During this activity the team dives deeper into each bounded context, adding fidelity to your design artifacts. Technology team members drive the conversation but will work closely with the whole team to explore and document that understanding.

Aligning business and technology

Until now, we’ve largely focused our activity around building a very deep understanding of the product. Event storming, business capabilities, context maps and user journeys are some of the tools we’ve used to build this understanding.

As we shift our focus toward technical value it’s important to make sure we don’t lose sight of our original business value — that is, what matters to your customer.

I find that many teams make mistakes here. Those mistakes cost a lot to fix.

Shifting from a business context into a technical one often creates failures in translation. Much like an impedance mismatch in a complex circuit, a shift in focus can likewise cause misunderstanding.

For example, think about old-world monolithic projects where a product team wrote out requirements, then handed them to a separate architecture team for design, who handed their output to developers for specification. Each step introduced compounded risk that the message would be mistranslated.

The inevitable outcome is losing sight of the original value proposition — the desired behavior of a customer feature that was so important in the first place.

That’s why this exercise in tactical event storming very carefully adds fidelity on top of the business value we’ve already described. We’ll literally start by taking those “business facing artifacts,” like event maps, and give them more detail.

Once we’re done, we’ll have added technical specifications to the business events. We’ll weave commands, queries, and aggregates into those events, helping us to see how the underlying logic will be executed. We’ll also make sure that our APIs make sense and align with preconceived notions of business context. And throughout, we’ll still keep involving the whole team to make sure everyone agrees with the evolving design.

This approach preserves our value stream. It creates a direct line of sight back to the original customer driven value — and we’ll keep that line of sight alive throughout the technical design to make sure we don’t drift off-course.

If you use the referral button below, you’ll earn free premium access to Customer Obsessed Engineering. Just three referrals will earn a free month!

Getting ready for tactical event storming

The activity picks up by adding detail to your strategic event maps. In that regard, it should feel quite familiar.

You’ll be adding detail to the event maps from chapter 2.3 Strategic event storming. You’ll answer questions that inevitably come up regarding those event maps. Having your context maps (from chapter 2.5 Context mapping) and your user journeys (from chapter 1.4 Business capabilities & functions) readily available will help answer those questions.