Event Storming, part 3 - Know your neighbors - You can't escape them!

Just like software projects benefit from first creating a walking skeleton of its solution, we get a similar benefit from the risk assessment example in the previous article: If stakeholders cannot verbally agree on responsibility boundaries and terms, we cannot possibly produce a maintainable software solution to support the business. We need to find Software-to-Business Alignment. The hard part of software architecture lies where the boundaries intersect. What's inside of each boundary is, generally and relatively, easy.

A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. - http://alistair.cockburn.us/Walking+skeleton

As an example of an identified conflict (i.e. two bounded contexts) in our exercise was the fact that parts of the business process saw the individuals that visited the event as Attendees whereas parts of the process identified them as Customers. A Customer should probably have some billing information attached, whereas an Attendee instead might have a attendance notation - did the individual show up?

The Shared Experience of performing the event storming, tends to establish bonds between the participants, which makes it easier for them to reconnect later.

Value mapping

The next part of our exercise (recap), was to attach little value stickies to the previously posted business events - which of the events were valuable and how did they add value? We also got an actor sticky to describe to whom value was generated.

This served both to validate the business events and also as another knowledge sharing exercise - where the group learned the different value being generated in different parts of the system. Imagine this sparking discussions of doing more or less of certain activities, knowing that the company - as a whole - will do better, although the activities - in the process which they are executed - has little to no effect.

What triggers events?

We were now transitioning from a business process mapping into something more akin to system modelling. Afterwards, we discussed that this exercise was in a completely different setting with a different audience - oftentimes a single agile team (product owner, developers/devop-ninjas, testers). Also, we reasoned, that this event should operate on a subset of the identified events - say an identified business domain or a specific event to drill deeper into. What we did instead, was to more or less fill the event storming wall:

We got the tip early on to name our cascading events and that we could model more than one cascading flow from a single source event. Naming examples could be Welcome Policy for the cascade that was triggered by the AccountRegistered event and dealt with sending a welcome e-mail and Cancellation Policy for the cascade that was triggered by AttendeeCouldntAttendAfterall event and dealt with possible reimbursement.

With triggers defined, Alberto guided us through what he called his repeatable building blocks for systems modelling in this fashion:

A human makes decisions based on logic and emotions (gut feeling, intuition ...). To be able to form some kind of idea on which to base a decision (i.e. execute a command; blue note), she will need some information - a read model. The command, in turn, might need some existing knowledge (known state) to execute and results in a number of domain events. These domain events might also be triggered by external systems and might, themselves, trigger additional, cascading events (Policies). Some events, however, simply updates a read model for another decision needing to be made by a human. Alberto pointed out that some parts of a system might need information not present in any computational process, giving an example that a human tends to be more ... humane towards its surrounding, if it gets presented a name and a picture of the person requesting something from her, rather than just a number (e.g. Customer 12345).

Summary

It's hard to explain Event Storming in words. To really get it, you need to experience it for yourself. I found the process very useful in a number of scenarios, however, ranging from individual sprint planning sessions to overarching business process modelling, since it had such a power in engaging the participants. There was no slack - everyone was busy doing work and was learning about the business as they went along. Well invested time!