Do we need another diagram tool? Maybe not… But I think we can do better

For the last 20 years, I’ve been drawing and developing software. Almost every company I worked at started with some whiteboarding or sketching of boxes and lines. Then a translation period happened—taking these drawings and turning them into an artifact. Sometimes it was more detailed diagrams, sometimes code, and sometimes just a box-ticking exercise.

About 10 years ago, I stumbled across message-based architectures (EDA) and decided to dive deep into the subject. Something about distributed, loosely coupled architectures resonated with me.

I began building solutions using patterns and techniques from this style, and something amazing happened: I saw a velocity in product engineering I had never experienced before. The speed at which we could evolve our architecture and deliver features was incredible.

So, I spent the next decade diving even deeper—speaking around the world, advocating for message-based architectures, and now building open source tools for this niche full-time.

Along the way, I discovered domain-driven design and its community. I learned domain discovery techniques like EventStorming and EventModeling. I realized how well DDD and EDA fit together, and how much value there is in bringing “the business” and development teams closer.

But I also noticed a huge problem: event discovery and documentation. The pitfalls of event-driven architecture were everywhere, and people kept running into the same issues. During Christmas 2022, I built EventCatalog. Three years later, I now spend all my time working on a product and open-source project I love—one that delivers value to thousands of companies around the world.

Still, after speaking with hundreds of companies during this journey, I felt there was something missing. There seems to be a gap between design, collaboration, implementation, documentation… and back again.

Many teams use whiteboards or sticky notes to capture information between teams, then translate those artifacts into something else—or let them die.

So, I ask myself: can we do better?

Many teams use tools like Miro, Lucidchart, Visio, and the C4 Model. These are great for digital representations of thought and design. But I often wonder: what if we modeled and designed with the actual primitives (e.g. domains, messages, services) we’ve been talking about for decades—rather than just boxes and lines?

Patterns and primitives in software architecture tend to stand the test of time. Look at books like Domain-Driven Design or Enterprise Integration Patterns—both more than 20 years old and still widely referenced. If you take technology out of the equation, the patterns remain. They can be translated across industries and technologies.

So why can’t we design directly with the patterns and primitives we already know, and then export artifacts we can actually use? Not necessarily replacing techniques like EventStorming or EventModeling—but giving people a canvas and tool where they can do more.

For example: if we want to represent a message (e.g. an event) in a design, why can’t we define its name, rules around it, start planning its schema, and share it with teams in a tool? And in the future, if the schema changes, why can’t the tool help us see who will break?

If we want to do EventStorming or EventModeling, why can’t we assign views, actors, and services with more definition if we choose to? Why does it all have to be static boxes?

Most teams have their own patterns and golden paths in architecture. Why not capture these and let people design with them? If you have a particular way of doing change data capture, or handling dead-letter queues, why not create reusable blocks for them?

And with the rise of AI, if our designs have a standard output, why not let LLMs help us verify them? Generate templates? Move from design to implementation faster?

Either way, I think we’re leaving a huge amount of value on the floor—and I believe we can do better.

That’s why I started my next open source project; EventCatalog Studio.

So, do we need another diagram tool? Probably not. But I can’t help but feel we can do better.

Over the past few months, I’ve been putting together a new open-source tool called EventCatalog Studio, built around my own pain points. It’s a tool focused on primitives and patterns—technology-agnostic by design.

I have no idea if it will fail or succeed. But I’m driven to make this ecosystem better for everyone, and to push the boundaries of what we do today into a better future.

If you’d like to join me on this journey, feel free to hop into our Discord. And if you ever want to geek out, connect with me—I’d love to chat.