The biggest problem with Event-Driven Architecture


This week I want to share some interesting insights with you. For the last ~3 months, I've had video-calls with a lot of people from different companies in different markets. Mostly banks, retail, and consultants. I kept these calls informal, like casual chats.

I didn't want to bias anyone toward any findings so I prepared myself to run "interviews". Have a look at The Mom Test. I asked open questions all the time and, from there, followed the conversations in a natural way. I tried not to give my opinion on any subject until the very last minutes of the call. Instead, I asked questions like:

  • How are you doing EDA right now?
  • How is it going?
  • What pain points are you struggling with?
  • Why do you think this is not working?
  • How would you improve that?
  • Why do you think this would work?
  • And, last but not least, "Tell me more about that..."

In no particular order. These are just examples from some conversations.

Would you believe the result? In every single conversation, we talked about the same problem: company culture. Funny, right? I wanted to discuss Event-Driven Architectures and found the problem is somewhere else. Well, not going to lie, I was kinda expecting it. I'm not new in the field and these were not the first time I spoke with companies about their challenges. However, what caught my attention this time is that every single conversation was about that.

This never happened to me before. I think the reason is that I've always been in the tooling provider side, first as the creator of AsyncAPI and later as a part of Postman. Also, I was never asking for these calls myself. Instead, they were coming to me asking if we could have a chat. At that point, everyone in these calls were already biased. They're coming to me as a tooling provider. They wanted to know more about the tools I was offering. And I was satisfying their demands telling them more about the tools.

This time it was different. I was expressing honest interest in their EDA adoption journey. The good and the bad but, you know, as problem solvers we tend to focus more on, well... the problems.

In one flavor or another, I was getting the same feedback in every call. Here are some ways they referred to it:

  • Leaders don't understand EDA benefits. They need to upskill their EDA knowledge.
  • Many engineers are used to work in a specific way and they're resisting change.
  • I want to improve things but people are not getting sold by my arguments.
  • The company lacks a long-term strategy to adopt EDA.
  • Leadership thought adopting a tool would solve their problem. It didn't and now they're looking for other tools to solve the same (or new) problems.

Sounds familiar? To me it's clear. People are trying to introduce a revolutionary change like adopting EDA but without thinking about the organizational and cultural challenges upfront. No blame here. I would have committed the same mistakes myself if I were in their position.

So, what's the solution in this case? Obviously, acknowledging and addressing the cultural issues as soon as possible. How? That's what I'll have to find next. In the meantime, I'll keep listening. If you feel represented in any of the examples above or you're facing different issues, please reply to this email. I'm always looking to hear from EDA or AsyncAPI practitioners first hand.

P.S. If you want personalized guidance in your EDA adoption and governance journey, a 1:1 call can provide the clarity and direction you need. Book Your 1:1 Consultation.

1 Question For You

What's your biggest struggle with EDA? If you're not doing EDA, what's stopping you from introducing it in your organization? Reply to this email.

Av. Joaquín Costa, 16, Badajoz, Badajoz 06001
Unsubscribe · Preferences

Fran Méndez

Hey hey! I'm Fran, the creator of the AsyncAPI specification (the industry standard for defining asynchronous APIs). Subscribe to my newsletter —The Weekly Shift— where I share expert advice about building Event-Driven Architecture and share my journey writing my first book, Shift: The Playbook for Event-Driven Architecture Advocacy.

Read more from Fran Méndez

On November 3rd, I announced I had joined Hookdeck to lead Outpost. It looked like the perfect setup on paper: a founder-like role, a smart team, and a problem space (EDA) that I’ve spent the last 12 years mastering. On November 24th, exactly three weeks later, I resigned. I’ve spent the last month processing this. I’m sharing the story not because I like talking about my mistakes, but because I bet a lot of you are stuck in the exact same trap I fell into. I spent over a decade in the...

9 years of AsyncAPI Initiative

Nine years. That is actually wild to think about. If you asked me back in 2016 if I saw this becoming a global standard, I would have laughed. I wasn’t trying to start a movement. I was just trying to fix a specific headache I had. I wanted to generate documentation and code skeletons for my event-driven services. I was using RabbitMQ, and the whole thing was a total mess. So I built a tool to fix it. For the first two years, I felt like I was speaking to a wall. I’d push code, write about...

Open Source Outbound Webhooks Infrastructure

I’m writing this to share some personal news that I’m incredibly excited about. I’ve officially joined Hookdeck as VP & General Manager of a new product called Outpost. This isn’t a decision I took lightly. My time since leaving Postman has been invaluable, allowing me to focus on building my own ventures. But when Alex at Hookdeck showed me what they were building, I saw a rare opportunity. A chance to solve a fundamental, unglamorous problem that plagues our industry and aligns perfectly...