Solving Event Modeling for the Enterprise, Part 1: How It All Started

Event Modeling works beautifully as a planning tool - until the model grows and a whiteboard was never built to keep it alive.

September 12, 2026 6 min read Event Modeling & Architecture By Martin Dilger

Solving Event Modeling for the Enterprise - Part 1: How it all started

October 2023 - I decided I’ll go all in on Event Modeling. I knew it since November 2021, ran a lot of projects with it, and was convinced. So I decided that would be my next big bet.

In February 2024 I started building an app for Miro, because I believed better tooling would make Event Modeling easier to run. I would not start this journey again.

I was right about the tooling. I was wrong about how small the problem was.

We ran dozens of projects with plain Miro, then far more once the toolkit existed. And every project taught me the same thing: modeling isn’t the hard part. Keeping the model alive is.

Event Modeling works beautifully as a planning tool. Teams get a shared language, meetings improve, decisions get clearer - literally from day one. But at some point those models grow, and if you want to use them for something bigger, like agentic engineering, they start breaking in ways a whiteboard was never built to handle.

There’s no history. Someone makes a change without really thinking about it, and there’s no way back. No one knows if the model still matches the code.

Nothing prevents you from doing the wrong things. On a whiteboard, anything is allowed - unfortunately.

Slowly, people stop trusting the model. They go back to reading source code instead. At least there’s some truth to that. The model gets abandoned over time.

For years my answer to this was “just be more disciplined.” Make deliberate changes. Always model together. Take screenshots so you have some kind of history.

That was never a real answer. And I knew it. It just avoided the truth: without tooling, Event Modeling won’t survive contact with the enterprise. Same as a company typically won’t try to do Scrum at scale without some tooling support.

For small teams, a bunch of sticky notes beats any tool. But at scale, sticky notes just don’t cut it anymore.

So I decided to solve those problems, one at a time, by building the best Event Modeling platform available - based on my years of experience and a ton of feedback from the Event Modeling Community.

The first commit was made on August 28, 2026 - about a year ago. I posted about this experiment here. It was just for fun first - can I port what we have in Miro to the web somehow? It worked, and pretty quickly so.

Later that year, I started to work more seriously on it. I already had a JSON specification for Event Modeling I was using for Spec-Driven Development, so the model could be read by agents and for code generation. Then I had generators - static and using LLMs - that turned that specification into working code. Then, as it got cheap enough, we let LLMs take over that generation completely. Then, so we didn’t depend on subsidized token prices or ship enterprise data off-site, we moved that generation onto local, on-prem models.

I didn’t abandon static code generation because it didn’t work - it’s just the effort to maintain those static code generators doesn’t justify the investment right now. Generating with LLMs is just faster and cheaper.

None of it was one big idea. Each step just solved the next real problem standing in the way.

That’s what EM-Studio and our current agentic workflows are. Not a leap. The next logical step in a chain that started with a Miro app three years ago.

What Are Those Enterprise Problems You Talk About?

Event Modeling solves problems most companies genuinely struggle with: unclear requirements, misaligned teams, specifications AI agents can actually build from.

But for years it stayed a niche practice, because nobody solved the boring, unglamorous problems that make it survive contact with a real enterprise.

Over the next few days I’m writing a series, “Solving Event Modeling for the Enterprise,” going through those problems one at a time - the ones that kept this practice small, and exactly how we solve each one now.

Part 2 - Mapping Event Models to Tasks & Tickets