Dear Architects podcast

Luca Mezzalira

Dear Architects is where software architecture meets the real world.
Hosted by Luca Mezzalira, the voice behind Dear Architects, this podcast cuts through the theory to explore how architects actually work.

Each episode features conversations with practitioners who are shaping how we think about distributed systems, team topologies, and the evolving role of the architect. Whether you're designing microservices, leading technical strategy, or figuring out how to align engineering with business goals, you'll find practical insights you can apply immediately.

Play

Open in

8 episodes
monthly
Avg 1 hr 5 min
English

Episodes 8

Newest Oldest Longest

All8 Unplayed8 In progress0 Played0

S1 · E8
September 15 · 1 hr 4 min
Killing the ivory tower: how Jumbo rebuilt architecture around teams and not titles!
this episode is offered to you by IcePanel: https://icepanel.io/lucaOnur is a staff engineer at Jumbo, the second largest supermarket chain in the Netherlands, where he has spent the last decade helping the company tear down two legacy monoliths, grow to 350-plus engineers, and rebuild its architecture around stream-aligned teams instead of a single gatekeeping architect.In this episode we go deep on how Jumbo used event storming and the core domain chart to expose Conway's Law in their own systems, why they chose a bottom-up transformation over a top-down mandate, and how they handle the friction that shows up when parts of the business, like their SAP teams, don't fit the new model cleanly. We also spend real time on how Onur's team is using agentic engineering in practice, including a pipeline of analyst, rubber duck, architect, and implementer agents built on internal skills, and why Onur still tells the business to hold its horses on AI more often than you'd expect.If you're an architect or engineer trying to figure out what your role looks like when the ivory tower comes down, this one gives you the trenches version, not the conference talk version.Chapters0:00 Welcome, and why Onur says the ivory tower is dead1:59 From two monoliths to 350 engineers4:44 Event storming exposes Conway's Law: five promotion microservices, zero communication5:56 The core domain chart, simplified for a real team8:05 Case study: cutting one team's microservices from 20 to 1010:10 Documentation that survives contact with reality: C4 and IcePanel13:52 Which C4 levels are actually worth maintaining16:17 Introducing team topologies into an existing landscape18:41 Why they chose bottom-up transformation over top-down23:39 The friction nobody talks about: SAP teams and finding the sweet spot29:56 The ivory tower is obsolete: what replaces the architect32:47 Handling cross-cutting concerns across domains37:47 Cutting through the AI noise39:38 Inside Jumbo's agentic engineering workshop44:44 How junior and senior engineers reacted differently to AI agents50:59 Merging deterministic tools with AI agents as fitness functions53:31 "Hold your horses": when the answer to AI is no54:57 Rolling out AI in layers: customer-facing, internal, developer experience57:48 Onur's closing advice: pick your battles, then fix your hiring1:01:21 Wrap up#SoftwareArchitecture #TeamTopologies #DomainDrivenDesign #AgenticEngineering #DearArchitects===================================Follow me for more tips!My gear: https://www.amazon.co.uk/shop/my50cents?ref_=cm_sw_r_cp_ud_aipsfshop_W744H9NEJG7C9T3JMFC2Spotify: https://open.spotify.com/show/0W5YEY5T3ApuYS8H9I3DzL?si=c279c2df086b4d8fTwitter: https://twitter.com/lucamezzaliraLinkedIn: https://www.linkedin.com/in/lucamezzaliraInstagram: https://instagram.com/mezzalabEdited in DaVinci Resolve: https://www.blackmagicdesign.com/products/davinciresolve
S1 · E7
August 11 · 1 hr
David Boyne on Event-Driven Architecture, Event Catalog, and Why Context Is King for AI
Try out IcePanel, your C4 model tool: https://icepanel.io/lucaIn this episode of Dear Architects I sit down with David Boyne, creator of Event Catalog and EDA Visuals, who has spent almost a decade working in the event-driven architecture world. We get into the practical realities of building async systems at scale, the mindset shift that trips up so many teams, and why treating your events with the same care you give your APIs changes everything.David shares hard-won lessons from production, including the trap of turning every single thing into an event, and we dig into how domain-driven design and EDA fit hand in hand. In the second half we move into AI, where David makes the case that documentation and context are becoming the real differentiator, how MCP changes the way we query our architecture, and why human interaction still sits at the centre of it all.If you are starting your event-driven journey, or you are already feeling the governance pain that comes with scale, there is a lot here to take away.Event Catalog: https://www.eventcatalog.devEDA Visuals: https://eda-visuals.boyney.ioChapters below.Subscribe for more conversations with the people shaping modern software architecture.#EventDrivenArchitecture #SoftwareArchitecture #EventCatalog #DomainDrivenDesign #AICHAPTERS00:00 Intro and David's background02:32 The one thing I wish I knew earlier: treat events like APIs03:59 Why teams find async architecture so intimidating07:59 Eventual consistency and the fear of debugging EDA09:59 Latency, business context, and asking the right questions16:59 The trap of turning everything into an event17:32 EDA Visuals: most popular pattern and anti-pattern19:57 How domain-driven design makes EDA click26:32 The origin story of Event Catalog40:49 Where Event Catalog is heading and the role of AI43:30 Where AI helps on the documentation side45:45 Why context will be king49:25 Living systems, mob programming, and shared understanding52:12 Can AI sit in on the mob and learn our decisions?55:44 First steps if you want to start with EDA
S1 · E6
July 8 · 1 hr 8 min
Microservices, AI and.... Chris Richardson
This episode is brought to you by IcePanel, a collaborative diagramming and modeling tool for architects. Model your system from business context down to components, keep diagrams in sync automatically, and connect your architecture to your favorite LLM via their MCP server. Try it free: icepanel.io/luca In this episode of Dear Architects, Luca sits down with Chris Richardson, author of Microservices Patterns and the creator of microservices.io, for a wide-ranging, no-hype conversation about where microservices actually stand in 2026, and what Gen AI does (and doesn't) change about how we design systems. Chris and Luca dig into why so many organizations still end up with a "distributed monolith," the real warning signs of bad service boundaries (hint: watch your services-to-developer ratio), and Chris's own framework for deciding what belongs together and what should be pulled apart — the Dark Energy and Dark Matter forces. They also get into the social-technical side of architecture: why team topologies, DevOps, and org structure matter as much as the diagrams, and why "the architecture is bad" is often just a symptom of deeper organizational issues.The second half turns to AI: the guardrails that actually make coding agents useful (tests, pre-commit hooks, code scanning), why brownfield modernization is nowhere near as simple as greenfield demos suggest, why Chris still prefers the Strangler Fig pattern over "big bang" AI rewrites, and a healthy dose of skepticism about the claims flooding your LinkedIn feed.If you're an architect, tech lead, or engineer trying to figure out what's signal and what's noise in the current AI moment — this one's for you. Chapters 00:00 Intro 01:36 Welcome, Chris Richardson 03:15 Chris's career: testing, Spring/Hibernate, the cloud, Cloud Foundry 06:01 State of microservices in 2026 07:30 "Living systems" — why boundaries need constant reassessment 09:47 Software serves two constituencies: users and the organization 10:19 Team topologies, DevOps, and the success triangle 12:53 Holistic engineering 13:36 The "red flag law" anti-pattern 14:51 Warning signs: the services-to-developer ratio 16:41 System releases and the distributed monolith trap 17:41 Service boundaries in practice 18:18 Default to monolith unless there's a clear problem to solve 19:03 Dark Energy & Dark Matter: the forces behind service boundaries 23:00 Dark Matter forces: runtime coupling, ACID vs. BASE 24:44 Collocating code isn't a weakness signalr 26:25 Ten forces, weighted by your own context 28:16 Architecture serves the organization, not just the customer 29:20 Latency-sensitive endpoints and selective distribution 31:31 AI hype: "we rebuilt it in 48 hours" 33:43 Best practices matter more, not less, in the Gen AI era 36:05 Multi-agent architectures and inter-service communication 37:33 The "agents for everything" trap 39:29 "SaaS is dead"? Big tech hype and bubble skepticism 40:26 Brownfield vs. greenfield: the AI modernization gap 42:02 Guardrails that work: tests, pre-commit hooks, code scanning 43:14 Legacy code without tests meets a probabilistic system 44:24 Human accountability for AI-generated code 45:22 Where architecture fits in the AI era 47:21 What AI-driven modernization gains — and loses 50:04 Strangler Fig over the "big bang" rewrite 53:36 Spec-driven development: waterfall in disguise? 54:16 Why well-documented systems are easier to AI-rewrite 56:02 "We are all juniors again" 57:55 Fundamentals over hype: modularity and loose coupling 59:47 AI burnout and the "slot machine" effect 1:01:26 Juniors, hiring, and whether Gen AI is even a profitable business 1:05:04 Final advice: the architectural mindset 1:07:21 Wrap-up and thanks
S1 · E5
May 29 · 1 hr 2 min
You don't need the Architect title to do architecture
subscribe to Dear Architects: https://deararchitects.xyzWhen companies grow through acquisition, architects inherit a mess: multiple teams, different engineering cultures, conflicting tools, and no shared map of the system. In this episode of Dear Architects, Luca sits down with Mahdi, tech leader at Fashion Cloud, a B2B wholesale platform connecting brands and retailers. Mahdi shares the in-the-trench story of how Fashion Cloud is rationalizing a federated socio-technical system after multiple acquisitions, starting bottom-up rather than top-down. They cover where to begin when you have fragmented teams under one CTO, how strategic Domain-Driven Design helps separate common platform capabilities from product-specific verticals, why the C4 model became their visualization backbone, how IcePanel replaced Miro for living architecture documentation, the role of ADRs and RFCs in capturing decisions, and how they handle cross-cutting concerns without killing team autonomy. Mahdi also shares how Fashion Cloud is experimenting with AI in their architecture practice, and the one piece of advice he wishes he'd given himself at the start of the transformation. If you're navigating a post-merger integration, modernizing a hybrid system, or just trying to build an ownership culture in your engineering org, this conversation gives you a practitioner's playbook.Chapters00:00 Intro and meet Mahdi from Fashion Cloud00:51 What is Fashion Cloud and the post-acquisition challenge06:40 Where do you start with multiple teams under one CTO13:39 The bottom-up approach: ownership without the architect title17:19 Strategic DDD: common platform vs product verticals21:43 Was it worth it? Reflecting on the transformation26:31 Visualizing systems: why the C4 model30:53 From Miro to IcePanel: choosing the right tool35:39 Architecture Decision Records and capturing the why44:19 Driving adoption: getting buy-in across the org45:19 Handling cross-cutting concerns in a federated model50:35 Building an ownership culture, not enforcing it51:39 AI in architecture practice: what actually works57:59 Advice to your past self58:55 Key takeaways and wrap-up
S1 · E4
April 21 · 1 hr 6 min
How to become an architect with James Eastham
What does it take to go from answering support calls in a small town in northern England to advising some of the largest companies on the planet at AWS and then becoming a developer advocate at Datadog? In this episode, I sit down with James Eastham to unpack a career built entirely in the trenches, without a traditional computer science background and without a straight path.We go deep on the real turning points: the crushing imposter syndrome of joining AWS ProServe, the "Magpie syndrome" trap of chasing shiny technology over context, and the moment every architect hits when they realise there is no right or wrong, only trade-offs.James shares a powerful reframe of imposter syndrome as a signal of growth, a practical habit for improving architectural decision-making, and a frank warning about what vibe coding and AI-assisted shipping will do to teams that skip the design thinking.We also get into the broader AI question: LLMs as amplifiers and why context, attitude, and fundamentals are the only things that truly compound over time.
S1 · E3
March 26 · 1 hr 7 min
Architecture for flow with Susanne Kaiser
Subscribe to the newsletter: https://deararchitects.xyz📚 RESOURCES MENTIONED📖 Architecture for Flow — Susanne Kaiser: https://amzn.to/4bMl0UR📖 Team Topologies — Matthew Skelton & Manuel Pais: https://amzn.to/3NIESA9📖 Wardley Mapping: https://www.wardleymaps.comIn the age of AI-accelerated development, most teams are shipping faster than ever but faster into the wrong direction. Investing time in software design, team alignment, and architectural thinking is not slowing you down. It is the only thing that will stop AI from amplifying your existing bottlenecks at scale.In this episode of Dear Architects, Susanne Kaiser, author of "Architecture for Flow," shows how to combine Wardley Mapping, Domain-Driven Design, and Team Topologies into a single coherent approach, in this way your architecture, your teams, and your business strategy finally move in the same direction.We get into what fast flow really means, why Conway's Law shapes your software whether you acknowledge it or not, how event storming becomes your most powerful tool in the AI era, and whether the "Architect" job title will even exist in the future.🕐 CHAPTERS0:00 Intro & meet Susanne Kaiser2:10 Why Susanne wrote Architecture for Flow5:10 What is fast flow (and why friction is a signal, not a problem)9:00 Conway's Law & the sociotechnical system12:40 Wardley Mapping explained15:00 Using Wardley Maps with leadership and the C-suite19:20 How Susanne approaches a new client engagement22:30 Domain-Driven Design: bounded contexts & subdomains24:20 Event Storming: where to start and how to run it31:10 Keeping event storming as a living document33:30 Team Topologies: the missing puzzle piece38:00 How team types map to bounded contexts41:00 Team interactions and how they evolve over time42:30 Systems are living — not just code43:30 The Architecture for Flow Canvas46:00 How long does the canvas process take?47:40 Evolving your North Star (not a big upfront design)50:30 AI accelerates your bottlenecks — not just your delivery54:00 Why DDD and event storming matter more in the AI era56:20 Architecture Decision Records and institutional memory58:30 Will the "Architect" job title disappear?1:01:20 The architect as coach: a federated future1:02:30 Where to start if you want to try this today1:04:00 Wrap up & where to find Susanne
S1 · E2
March 3 · 1 hr 2 min
Why AI is the Third Coming of Domain-Driven Design
subscribe to the newsletter: https://deararchitects.xyzBalancing Coupling in Software Design: https://amzn.to/4rotZlzLearning Domain-Driven Design: https://amzn.to/4tGQvb2Most architects have been thinking about coupling the wrong way for years. Not as something to understand and design deliberately but as something to eliminate. That misunderstanding is behind most of the distributed monolith disasters of the microservices era.In this episode, Vlad, author of Balancing Coupling in Software Design, shares what he learned after building a textbook distributed monolith while following best practices to the letter. We dig into why coupling is unavoidable, what the three dimensions of coupling actually are, and why strategic DDD consistently beats tactical DDD for large systems.But the conversation takes an unexpected turn: Vlad argues AI is the third coming of Domain-Driven Design. When you prompt an AI in natural language, ambiguous domain models don't just slow your team down — they get baked silently into generated code. The same discipline that makes systems evolvable turns out to be the foundation for working effectively with AI. 0:00 Intro & guest welcome1:00 Why modeling is the foundation of good software design2:45 Rethinking coupling — it's not what you think8:00 How microservices created the distributed monolith trap14:00 The real cost of splitting without fixing the design19:00 Why pain is your best architectural signal23:00 Domain-Driven Design has a reputation problem28:00 Strategic DDD vs tactical DDD — what actually matters33:00 How to approach a brownfield system37:00 Subdomains: the hardest part of DDD nobody talks about enough41:00 Bounded contexts and why less is more for startups46:00 AI is the third coming of Domain-Driven Design52:00 Teaching DDD to an LLM — what Vlad actually tried55:00 Working code is no longer the challenge. Evolvable code is.1:00:00 What Vlad would change in his book1:07:00 What's next
S1 · E1
February 17 · 1 hr 10 min
Architecture is BROKEN (It’s not the code but the communication)
subscribe to the newsletter: https://www.deararchitects.xyz ACED model: https://jacquiread.com/posts/better-software-design In this first episode of Dear Architects, Luca welcomes Jacqui Read, author of Communication Patterns, to explore why most software architecture problems aren’t technical, they’re communication failures.They dive deep into: • Why architecture must be iterative (and why big upfront design fails) • The dangerous return of waterfall thinking through AI and spec-driven development • Why LLMs require better communication, not less• The gap between business and technical teams — and how to fix it • The ACE model (Context, Design, Architecture, Engineering)• Living documentation, ADRs, and clear code vs “clean” code• Why most companies want automation — not AI • How architects should evolve in the AI eraIf you think architecture is just diagrams and tech decisions, this conversation will change your perspective. Because architecture isn’t about boxes and arrows.

Showing 1–8 of 8 episodes