E11 - What Is Software Architecture
Watch Episode
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
📚 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
__________________________________________________
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