6 Living Specification
The four chapters you’ve just read might have looked like separate observations.
They weren’t.
They were all different ways of looking at the same question.
We started by asking why software engineering is so difficult.
At first, I thought I was dealing with a technical problem.
After all, we were replacing a large COBOL system. There were decades of accumulated complexity. Integrations. Legacy code. Countless business rules.
But the longer I worked on the project, the less convinced I became that technology was the real challenge.
Again and again, I realized that the difficult part wasn’t changing the software. It was understanding the business well enough to make the right decisions.
That realization quietly connected everything else.
On the car rental project, we struggled because we were trying to replace a business we didn’t fully understand yet.
Later, on the SAP migration for the fashion manufacturer, I experienced something different. Event Storming showed me how quickly shared understanding could emerge when the right people explore the business together. For the first time, I saw the power of having a model that everyone could gather around. Instead of trying to explain the system from memory, we could point at the wall, ask questions and improve the model together.
But once the workshop was over, something else caught my attention. The customer monitoring application we built during the project stayed useful because it remained connected to reality. It continuously reflected what was actually happening in the business. People looked at it every day. They discussed it. They made decisions based on it. Long after the workshop had ended, it was still part of the team’s conversations.
That observation stayed with me. If an operational model could remain valuable because it evolved together with the business, could a collaborative model do the same?
Looking back, all these observations came together around 2018.
By then I had worked on the car rental project. I had experienced Event Storming on the SAP migration. I had seen how powerful collaborative modeling could be, but I had also seen how quickly the workshop artifacts became outdated.
At the same time, I started wondering whether the Event Storming conversation really had to end when everybody left the room.
That wasn’t a particularly popular question.
Back in the days, the common opinion in the Event Storming community was that the workshop itself was the important part. Alberto Brandolini, who created Event Storming, once answered the question “What is the best tool for remote Event Storming?” with a simple reply:
“A plane ticket.”
I understood exactly what he meant.
Event Storming is about people standing in front of the same wall. Conversations happen naturally. Somebody reaches for a sticky note. Another person moves it. Questions appear almost faster than anyone can answer them. There is an energy in the room that is difficult to recreate remotely.
I wasn’t trying to replace that.
But I couldn’t stop thinking about something else.
Why should the collaboration end once the workshop was over?
That question had been bothering me ever since the SAP project.
The customer monitoring application had shown me that an artifact could remain useful if it stayed connected to reality. Event Storming had shown me how collaborative models helped teams build shared understanding. I kept wondering whether those two observations could somehow be combined.
What if the collaborative model itself could remain part of the team’s daily work? Instead of becoming a photograph of one successful workshop, it could continue evolving every time the team learned something new.
That question eventually led me to start experimenting with Continuous Remote Event Storming.
At the time, I wasn’t trying to build a product. I was exploring an idea.
If collaborative modeling helps create shared understanding, could it also help maintain it?
Those experiments eventually led to prooph board. Over the following years, I worked with teams that didn’t use the board only for workshops anymore. They used it between workshops. During refinement. During implementation. During production incidents. The model slowly became a place where conversations continued instead of restarting.
I didn’t have a name for that idea back then.
Today I do.
I call it a Living Specification.