What this looks like in practice
The documentation gap is not a failure of effort.
Every legacy modernization project hits the same wall: the spec doesn't exist. There are screenshots, a few Confluence pages someone updated in 2014, and a 40-year-old developer who knows why the order total is rounded differently on Tuesdays. The business runs on tacit knowledge: rules so internalized that the people using them can no longer articulate them in the abstract. This isn't because nobody tried. It's because expert knowledge is stored as patterns and reflexes, not prose. Ask a senior claims adjuster to write down how they process a complex claim and you'll get a thin document. Watch them process one and ask "what just happened there?" and you'll fill a whiteboard.
Event Storming inverts the question.
Traditional requirements gathering asks nouns: what are the entities? what are the tables? what are the screens? Event Storming asks verbs: what happened? what happened next? what had to happen before that could happen? Thinking in events is how humans actually think about work. Nobody remembers the Customer table. Everyone remembers the time an order shipped twice because inventory was checked after payment cleared. When you anchor the conversation on domain events (things that happened, in the past tense, written on orange sticky notes), experts can suddenly contribute, because you're asking them to recall, not to architect.
The timeline forces disagreements to the surface.
Put ten people from four departments in a room and ask them to arrange a hundred orange stickies in chronological order. Within twenty minutes, you will have a visible fight: Sales believes the order is confirmed when the customer clicks submit; Accounting believes it is confirmed when payment clears; Operations believes it is confirmed when the warehouse picks it. All three are right, inside their own silo. None of them have ever realized the others disagreed. These collisions are the whole point. Every inconsistency on the board is a bug that was going to appear, sooner or later, in the new system. Finding them on sticky notes is free. Finding them in production costs six figures.
This is especially powerful for legacy modernization.
When the existing system has run for thirty years, the code is the only specification. But reading code tells you what the system does, not why. Event Storming recovers the why. It is the single most reliable way to separate essential business rules (which must be preserved) from accidental implementation details (which should be replaced). We pair the workshop output directly with our Discover phase: the domain events become the test cases, the commands become the API surface, and the bounded contexts become the service boundaries in the new architecture.
What you walk away with
- Domain experts contribute freely because they talk in verbs and events, not entities and schemas.
- Cross-department inconsistencies become visible in the first two hours, not the first two years.
- The output is concrete enough to drive architecture decisions: bounded contexts, aggregates, commands, events.
- You end up owning your business process as a living artifact. Not a wiki nobody reads.
- For legacy systems, it separates essential business rules from accidental implementation details.
- The cost of surfacing a misunderstanding drops by several orders of magnitude.