Software projects often fail before development starts. The team builds screens, features and integrations before everyone understands the workflow. The result can be technically functional software that supports the wrong process.
Workflow mapping helps prevent that. EventStorming is one practical method.
What EventStorming is useful for
EventStorming is a collaborative approach to understanding how a business process works through events, commands, decisions, actors and systems. In simple terms, it helps a team see what happens, in what order, who is involved and where complexity or uncertainty sits.
It is useful before building or modernising software because it surfaces:
- important business events;
- user actions;
- decision points;
- exceptions;
- external systems;
- data dependencies;
- unclear ownership;
- manual workarounds;
- hidden assumptions.
This is especially valuable when the software supports operational workflows rather than a simple content page or isolated feature.
Start with the business flow
Before choosing a technical solution, ask:
- What triggers the workflow?
- What happens next?
- Who makes decisions?
- Which systems are involved?
- Where does data move?
- Where do delays happen?
- Which steps are manual?
- Which exceptions are common?
- What output matters to the business?
These questions reveal whether the need is a custom application, an integration, a workflow automation, an AI-assisted tool, a reporting pipeline or simply a clearer process.
Why this matters for AI
NoA Ignite’s task-by-task GenAI planning is relevant because it starts with roles and tasks before technology. The same principle applies to software development broadly. AI should not be added to an unclear workflow. First understand the task, the actor, the data and the decision.
Once the workflow is mapped, AI opportunities become easier to evaluate:
- summarise a long input;
- classify a request;
- extract fields;
- prepare a draft;
- suggest the next action;
- flag missing information;
- route an exception.
Without the workflow map, AI use cases remain vague.
Avoid building the wrong feature
Twoday’s writing around the cost of building the wrong features is relevant to this topic. Software cost is not only engineering time. It includes opportunity cost, maintenance burden, user confusion and operational friction.
A workflow map can show that the requested feature is not the real need. The problem may be missing integration, unclear data ownership, poor reporting, duplicate entry or an approval step that should be redesigned.
Keep the output practical
The goal is not a perfect model. The goal is enough shared understanding to make better software decisions.
Useful outputs include:
- workflow diagram;
- key users and roles;
- main system interactions;
- data sources;
- integration needs;
- automation opportunities;
- risks and constraints;
- first delivery scope;
- open questions.
These outputs should connect directly to implementation.
Memory(One) perspective
Product-minded software engineering means understanding users, workflows and operating constraints before building. Memory(One) can use workflow mapping as part of Software Development, Application Modernisation, AI/Data/Automation and Integration work. The point is to build what the business actually needs, not what the first feature request seems to describe.
Sources and inspiration
- EventStorming official site: https://www.eventstorming.com/
- NoA Ignite — How we plan for GenAI task by task: https://noaignite.com/insights/how-we-plan-for-genaitask-by-task/
- Twoday — Blog and software delivery topics: https://www.twoday.com/blog
- Scrum Guide — Product Backlog, Sprint Planning and inspection/adaptation principles: https://scrumguides.org/scrum-guide.html