Dear Architects podcast

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

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

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.

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

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