In this episode of Fundamentals of Software Engineering, Nate and I dig into the question the whole show is named after and the one our book only had a single chapter for: what software architecture actually is. We start where Neal Ford and Mark Richards start, with architecture as the things you cannot Google, and we work out why that definition holds up. By the time a decision reaches an architect, the easy answers are gone. Nobody escalates a variable name. What gets escalated is whether this should be a modular monolith, a set of microservices, or something event driven, and none of those have an answer that survives being lifted out of your context. From there we get into the part that makes architecture uncomfortable: it is trade-offs all the way down. We talk about quality attributes, the ilities that routinely conflict with each other, and why a manager asking for all of them at once is asking for something that does not exist. We cover architectural malpractice, the habit of picking a pattern because it is fashionable rather than because the problem demands it, and what happens when a whole platform gets rewritten around one team's favourite language. We also talk about legacy systems and why reimagining beats dragging, about evolutionary architecture and fitness functions, about the difference between design and architecture, and we close on what we would tell an engineer who wants to grow into the role. __________________________________________________ Key Highlights 🔎 Architecture is the things you can't Google: Neal Ford and Mark Richards coined it and it holds. The answer always depends on your constraints and the forces you are actually up against. 🏛️ No easy answers reach the architect: If a question had an obvious answer, it would have been solved further down. What lands on your desk is what is left. ⚖️ The ilities conflict with each other: Scalability, maintainability, simplicity and the rest pull in different directions. Prioritising them is the job, not a failure to deliver all of them. 🚨 Architectural malpractice: Reaching for microservices because they are in fashion, when the team shape and the actual demand say otherwise, is malpractice rather than ambition. 🐍 Don't replatform a whole team for one capability: If your people are strong on the JVM, moving the organisation to Python to reach one library is rarely the trade you think it is. 🔄 Reimagine legacy, do not drag it: Carrying every old defect and unfixed feature into the next system is a choice, and usually the wrong one. 🌱 How to grow into the role: Talk to the architects around you about how they got there, what they like, and what they do not. Ask what the path looks like before you try to walk it. __________________________________________________ Resources & Next Steps 📘 Fundamentals of Software Engineering, the book and the podcast 📚 Building Evolutionary Architectures by Neal Ford, Rebecca Parsons and Patrick Kua (second edition out now) 📖 Software architecture writing by Neal Ford and Mark Richards 🖥️ Fundamentals of Software Engineering on YouTube for the video version 🎤 Catch Dan and Nate at KCDC, Devnexus, Dev2Next and QCon San Francisco 🎧 Subscribe to Fundamentals of Software Engineering on Apple Podcasts __________________________________________________ YouTube Chapter Timestamps 00:00 Cold open: reading Carnegie is as useful as another framework 03:19 Conference season: what is coming up 06:53 Dev2Next and Venkat's conferences 07:36 QCon San Francisco and some good news 09:31 Today's topic, and where to find the book 10:28 Why one chapter on architecture was never going to be enough 11:36 Three shelves of architecture books and what they have in common 13:31 By the time the question reaches you, the easy answers are gone 14:30 Architecture is the things you can't Google 16:43 Knowing which questions to ask, and how to get answers 18:36 Does this problem actually require Kafka 20:34 Structure, teams and what architecture you can realistically run 23:21 Architectural malpractice, defined 24:43 Designing for scale you do not have yet 27:23 AI on the JVM, and not replatforming a team to chase a library 28:48 New leadership, rewrites, and the defects you carry across 31:34 Who should be an architect these days 34:45 Where design ends and architecture begins 42:29 Evolutionary architecture and fitness functions 46:23 The ilities, quality attributes and real trade-offs 55:46 Advice for engineers who want to grow into architecture
