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

At API World 2017 in San Jose, California The best engineers I've ever worked with were all convinced they were the worst one in the room. I know, because I was one of them, and years later I asked around. When I moved from Badajoz to Barcelona, I landed at a company full of people I was sure were smarter than me. Then a startup founded by the people who'd go on to build Factorial, and I felt even smaller. Then New Relic, with engineers flying in from Silicon Valley, and I was certain I was...

A man staring at his laptop in a dark room.

Every time I talk to an engineer who’s thought about starting a newsletter or a blog, this is the sentence that comes up. Sometimes it’s framed as a question: “what would I even write about?” Sometimes it’s a confession: “I want to but I don’t have anything to say.” Sometimes it’s a defensive joke: “haha, who would even read it?” The mechanics are the same underneath. The engineer in question has decided their work isn’t interesting enough, their experience isn’t unique enough, their thoughts...

A picture of a captivated woman in the middle of an audience.

I’ve been writing a newsletter for about three years. But that number is misleading. I started it eight years ago, sent maybe seven or eight issues, then went quiet. The newsletter eventually became the official AsyncAPI newsletter and other people maintained it for years, sending monthly updates while I worked on the spec itself. Last year I split off my own version to write what I wanted to write. That’s the part that’s been running consistently. About one year of real, regular writing. The...