Dear Architects podcast

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.

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

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

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.