If you've worked in a modern enterprise, you've probably felt it: that creeping sense of chaos as services multiply, events proliferate, and documentation falls hopelessly behind. On day one, five events and three services feel manageable. By day one hundred, you're staring at a thousand events and fifty services, wondering how things got so tangled.

In a recent episode of the Naftiko Capabilities podcast, I sat down with David Boyne, creator of Event Catalog, to talk about this universal challenge—and the approaches that are helping organizations find their way out of the mess.

The Documentation Gap

Event Catalog started as a straightforward side project: a tool for cataloging events in event-driven architectures. But David quickly discovered that the problem ran deeper than missing documentation.

"Most people out there, they build distributed systems, and it ends in chaos because no one's documenting anything," David explained. While tools like OpenAPI have helped with REST documentation, there's still a significant gap—especially when it comes to event-driven systems.

The real insight came when David realized this wasn't purely a developer problem. Different personas across the organization need visibility into architecture, each with different concerns. Product owners care about domains and business opportunities. Developers care about schemas and service contracts. Leadership cares about capabilities and gaps. The challenge is making architectural information accessible and meaningful to all of them.

From Events to Domains

What makes Event Catalog particularly interesting is how it's evolved beyond simple event documentation into a tool for domain mapping. Drawing inspiration from domain-driven design and event storming, David has built something that helps organizations visualize their architecture through a business lens.

"Why can't we take these things that we have and just add the meaning on top?" David asked. "So when we look from a business point of view, we can answer these questions—not just from a technical point of view all the time."

This shift in perspective is crucial. An OpenAPI specification can tell you what endpoints exist and what data they accept. But it can't tell you why a service exists, who owns it, what business process it supports, or how it fits into the broader organizational landscape. That context lives in people's heads—until it doesn't, because those people have moved on to other roles or companies.

Bridging Strategy and Tactics

One of the tensions in enterprise architecture is the gap between strategic thinking and tactical reality. Organizations create beautiful diagrams and domain models during planning sessions, often using tools like Miro and post-it notes. But these artifacts rarely survive contact with the codebase. They become stale almost immediately.

David sees an opportunity to close this loop. "Why do I have to go to a Miro board and use post-it notes when I already have the essence of the architecture somewhere?" he asked. The vision is documentation that can flow back into design—using the actual primitives of your architecture (REST endpoints, messages, schemas) to model workflows and business processes.

This isn't just about keeping docs up to date. It's about creating a living model of the organization that serves both the people trying to understand what exists today and those trying to design what should exist tomorrow.

The AI Foundation

As our conversation turned to artificial intelligence and the rise of AI agents, David offered a perspective that resonated: if you've documented your boundaries, your ubiquitous language, your services and how they connect, you've built a foundation that AI can actually use.

"Surely you can use that as a foundation for context for other things," David noted. He's been experimenting with queries like "I want to build this new feature—what APIs or events do we have, who owns them, and what are the schemas?" The results have been promising.

But David is also exploring more creative applications. Imagine taking a photo of an event storming session and having it automatically populate your catalog. Or using your documented architecture to generate implementation scaffolding. When your organizational knowledge is structured and accessible, the possibilities multiply.

Finding Signal in the Noise

This is exactly the kind of challenge we're tackling at Naftiko with our Signals initiative. While Event Catalog helps organizations understand themselves from the inside out, we're working on understanding enterprises from the outside in—identifying the signals and patterns that reveal what organizations are really doing with their APIs and integrations.

The common thread is visibility. Whether you're mapping your own architecture or trying to understand an ecosystem of partners and competitors, you need tools that surface meaningful information from overwhelming complexity.

Getting Started

If any of this resonates—if you're feeling the pain of undocumented systems, invisible dependencies, or architectural decisions lost to institutional memory—Event Catalog is worth exploring. It's open source, it's actively developed, and David has built a genuine community around it.

You can find Event Catalog at eventcatalog.dev, and David is active on LinkedIn sharing insights from his work with organizations of all sizes.

The chaos isn't going away. Our systems will only grow more distributed, more event-driven, more complex. The question is whether we'll have the tools and practices to make sense of it all. From what I've seen, Event Catalog is a meaningful step in the right direction.

‍