Last Thursday and Friday I attended the #EventModeling and Event Sourcing conference in Munich, organised mainly by
Martin Dilger
.
I had not planned to be there. Martin invited me on short notice because one participant could not make it. I am very glad he did.
The conference was small in the best possible way. Roughly forty people in one place, all with a strong interest in improving software development through better design. Not better design in the decorative sense. Better design in the sense of understanding what the business actually needs, making the behaviour of the system visible, and using that shared understanding as the foundation for implementation.
For me, this connected directly to a theme I have been writing about for a while now: we are still not doing the software development life cycle (SDLC) quite right.
We often treat business problems as if they were technical problems. We rush into tooling, architecture, infrastructure, coding standards, pipelines, tickets, backlogs, ceremonies, and controls. Many of those things matter. I have spent a large part of my career improving exactly those areas. But they do not compensate for a weak understanding of the problem.
If the business solution design is vague, the delivery system will faithfully optimise the production of the wrong thing.
AI makes this more urgent, not less.
AI will accelerate whatever shape we give it
One of the things I appreciated most at the conference was that the people in the room were not blindly excited about AI as a shortcut around thinking.
There was excitement, yes. But it was not the excitement of “now we can just vibe code faster.” It was the excitement of people who understand that AI needs structure. It needs context. It needs a shape in which it can operate.
Without that shape, AI will mostly produce more technical depth in less time. More code. More scaffolding. More local solutions. More apparent progress.
That may feel productive for a while. But if the underlying business design is weak, we are not moving faster through the mud. We are only digging deeper.
This is where #EventModeling becomes interesting, although I increasingly think we may need a different name when we speak with business stakeholders.
The value is not in the technical terminology. The value is in the discipline of creating a visible, structured, shared model of how the business process works over time. What happens first? What decision is made? What information is needed? What state changes? What must be shown to whom? What automation reacts to which business event? Where are the exceptions? Where are the controls? Where does auditability need to exist? Where does the business need evidence, not just execution?
That is business solution design.
From conversation to model
One very practical pattern discussed at the conference was the use of AI during the modelling phase itself.
Imagine a workshop where stakeholders and subject matter experts discuss the business problem. The conversation is recorded and transcribed. An AI assistant uses that transcript to create a first draft of an Event Model.
Not the final model. That distinction matters.
The first draft is a starting point. It gives the group something concrete to challenge. The model becomes a thinking surface. People can point at it and say, “No, that event is too early,” or “We are missing a compliance check here,” or “This is not a decision by the system, this is a decision by the underwriter,” or “This screen exists only because the downstream process is broken.”
That is already a huge improvement over the classical requirements handover.
Too often, the business discussion disappears into meeting notes, user stories, Jira tickets, acceptance criteria, and architectural assumptions. Every translation step loses information. Every role sees only part of the picture. By the time implementation starts, the team may be very busy, very disciplined, and still not aligned.
A visual behavioural model changes the conversation. It keeps the system grounded in the business timeline. It shows the flow of decisions, events, information, and reactions. It allows business, product, engineering, architecture, QA, security, compliance, operations, and audit to talk about the same thing.
That is the point I keep coming back to: good business solution design must become a joint endeavour.
From model to implementation
The second AI use case is implementation.
This is where things become both powerful and dangerous.
If we ask an AI coding agent to “build the feature,” the result depends heavily on what “the feature” means. In many organisations, a feature is still a bundle of vague text, implicit assumptions, partial UI ideas, undocumented rules, and technical guesses.
That is not enough.
But if the model is structured into clear slices, the situation changes.
A slice can be one of a few fundamental building blocks. A state change. A state view. An automation. A translation. Each slice has a clear role in the overall business process. It has defined inputs and outputs. It produces or consumes business events. It can be discussed, implemented, tested, reviewed, and evolved independently.
This is where AI-assisted delivery starts to make sense.
An implementation agent can work slice by slice. A custom skill or custom agent can be optimised for the slice type. The implementation can follow templates. Tests can be derived from the examples and business rules. The agent can run in a loop, implement the slice, run the tests, adjust, and move on.
That does not remove engineering discipline. It makes engineering discipline more explicit.
In fact, the better the model, the more boring the implementation should become. Boring in a good way. Predictable. Repeatable. Reviewable. Observable.
This is also where architectural choices matter. I am increasingly drawn to aggregate-less Event Sourcing and CQRS in this context. Not because I want to introduce more technical fashion into the discussion, but because the architectural style can support the independence of slices.
Each slice should be as independent as possible from the others. The coupling should happen through well-documented business events. Those events are the contracts. They are not implementation details. They are part of the business design.
This supports the open-closed principle at a business-solution level. We can add new behavior by adding new slices that react to existing events or produce new events, rather than constantly reopening and disturbing existing behaviour.
That is a very different mental model from the usual “change the service,” “extend the entity,” or “add another branch to the workflow.”
The vocabulary problem
One point that resonated strongly with me was the need to change our vocabulary.
Many of the terms we use in our technical communities are useful among practitioners, but they are terrible entry points for business stakeholders.
Aggregates. Entities. Bounded contexts. Ubiquitous language. Event sourcing. Commands. Projections. Read models.
These terms may be precise. They may even be necessary at some point. But they also create distance. They signal to non-technical stakeholders that the conversation has moved away from their world into ours.
That is a problem.
If we want business people to participate in business solution design, we should not start by asking them to learn our internal language. We should first meet them in theirs.
What decision is made? What happened? Who needs to know? What evidence do we need? What should be visible? What must never happen? What must be checked before we continue? What changes over time?
These are business questions. They can be understood without introducing a DDD glossary.
This is why I like the phrase “business solution design.” It describes the actual intent better than “EventModeling” does for a non-technical audience.
EventModeling remains the method. Business solution design is the conversation we need to invite people into.
The real shift
The conference confirmed something for me.
The future of software delivery is not simply AI-generated code. That is too small a vision.
The real shift is from ticket-driven delivery to model-driven delivery. From fragmented requirements to shared behavioural blueprints. From siloed SDLC phases to collaborative design. From AI as a coding shortcut to AI as a participant in a structured system of thought.
This matters because most of our current SDLC pain does not come from slow typing. It comes from misunderstanding, late discovery, hidden assumptions, weak feedback loops, misplaced controls, and the constant translation loss between business and technology.
AI can help with all of this, but only if we give it the right operating model.
Otherwise, we will automate the very dysfunctions we should be fixing.
What I took away
I left Munich encouraged.
Not because I saw a magic method. Not because any tool will solve the problem for us. And not because AI will suddenly make software development easy.
I left encouraged because I met a group of people who are asking the right questions.
How do we make business behaviour visible? How do we keep stakeholders involved without drowning them in technical language? How do we turn models into living documentation? How do we make implementation more structured without making the process heavier? How do we use AI without giving up control? How do we create systems where governance, security, compliance, auditability, and observability are designed into the solution instead of being inspected later?
That is exactly the conversation I believe we need more of.
A big thank you to Martin Dilger for the invitation and for organising the conference, to Adam Dymitruk and Allard Buijze for their keynotes, and to everyone I had the chance to speak with during those two days.
For me, the message is clear.
Before we let AI build faster, we need to become much better at deciding what is worth building.
And that starts with better business solution design.
Originally published on LinkedIn (2026-06-29): https://www.linkedin.com/pulse/blueprint-before-agent-gabriel-n-schenker-4mk2e
