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
A puzzle

I've spent the last few weeks on over 20 calls with all kinds of companies. From tiny startups to huge enterprises. Every single one of them is wrestling with Event-Driven Architecture, trying to make sense of its promise and its messy reality. And as I listened, patterns started jumping out at me. We're not just talking about tech problems here. We're hitting the deep, human stuff that comes with a big shift like this. One story kept popping up, louder than all the others: culture. Forget...

Writing Shift is proving to be challenging to me. Not in a bad way but in a really really good way. Yesterday, in a conversation with Laïla Bougriâ, I told her that I'm writing the book for me, to learn. Obviously, I'm taking into account the target audience all the time but, even this, is part of the challenge. It's not the first time I've done this though. When I drafted the first AsyncAPI specification, I did it for me, so I could learn the ins and outs of OpenAPI and also Event-Driven...

Addressing a culture problem with a tool is like taking a hammer to your own head. The more powerful the tool, the more painful the blow.

This week, I had an interesting discussion with a client. It's a Civil Engineering corporation that's present in multiple continents. The "company culture" challenge becomes especially important when different cultures all around the globe are mixed toward a same goal. Building a globally-distributed Event-Driven Architecture is no exception. Everywhere I look, people are trying to fix culture problems with tools. Not because they're dumb or stupid, actually, I'd have committed the same...