You don't need the Architect title to do architecture

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

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

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

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