Claim OwnershipSoftware Architecture Book Club
Subscribed: 17Played: 129
Subscribe
© 2025 Software Architecture Book Club
Description
This podcast goes chapter-by-chapter through books about software architecture, by the authors of those books, starting with Head First Software Architecture.
18 Episodes
Reverse
In this episode, we cover the critical topic of how architects can govern the architectural characteristics they identified. Architects are responsible for both identifying architectural characteristics, but should also ensure that they check on them to make sure the aspirational goal is manifesting. For example, if the team has a goal of 50ms First Contentful Paint for responsiveness, how can you determine if you've achieved that goal? As always, we cover some details and background from the...
In this episode, we cover the Software Architecture Fundamentals 2nd Edition chapter on identifying architectural characteristics, an important skill for all software architects. Many think this type of analysis is only useful at project inception, but it turns out to be useful even for existing systems. As always, we cover the basics of the chapter and answer a number of questions from the live audience.
Architects can split structural design into two analyses: architectural characteristics and logical component analysis. This episode introduces what we mean by architectural characteristics (and why we don't care for alternative terms such as non-functional requirements, cross-cutting requirements, etc.). We discuss our definition and how it impacts architecture decisions.
A key concept for structural design in software architecture is modularity, which this episode dives into. We define the difference between modularity and granularity, and focus on some of the concrete measurements architects have to understand the macro structure of component-based systems. As usual, we also answer some great questions from our live audience.
In this episode of the podcast, we sync up with chapter two of Software Architecture Fundamentals 2nd Edition, Architectural Thinking, including topics like architecture versus design, the distinction and importance of technical depth versus breadth, the primacy of analyzing trade-offs, understanding business drivers, and balancing role expectations like coding versus non-coding activities.
In this episode, we start our chapter-by-chapter exploration of Software Architecture Fundamentals 2nd Edition. We discuss our (updated) definition of software architecture. While we were writing the first edition, we kept our eyes open for things that seems universally true; we hoped to find about 10, but we ended up with two in the first edition. For the second edition, we added a third law after some insights in the intervening years. In this episode of the podcast, we cover all three laws...
What's it like to author a technical book? Especially one as stylized at Head First Software Architecture? We take a brief departure from our normal pattern of covering one book chapter per episode as we're between books and thought this might be a good time to go meta. We provide some insight in writing "regular" technical books, along with the special constraints and challenges inherent in writing for a series like Head First.
Head First books by their nature cannot cover as much material as conventional books, especially for such a broad topic as software architecture. Thus, the "Leftovers" chapter was born--several important topics that we just didn't have room to cover in the book. In this episode of the podcast, we cover the Head First Software Architecture "Leftovers" and sum up our last thoughts on the book.
Everyone's favorite popular architecture of the moment, our next architecture style goes fully into distributed architectures with microservices, discussing how it differs from monolithic architectures and other distributed ones. Regardless of what people say, this isn't the only architecture anyone should use; we discuss the good and bad for this style, along with its superpowers and kryptonite.
Our third monolithic (sometimes) architecture style is the micro-kernel architecture. We delve into how this is different than an architecture that just supports plug-ins, and talk about some of the great uses and dangers to watch out for. As with all our style chapters, we end with a discussion of the super powers and kryptonite of this style.
In our second architecture styles chapter, we delve into the Domain-driven Design inspired cousin of the Layered architecture (our previous episode)--the Modular Monolith. We describe what sets these two monolithic architectures apart, what the superpowers (and kryptonite) for this style, and when you would use it rather than a layered architecture. And, as always, we answer the voluminous questions from our audience at the recording.
The main part of the Head First Software Architecture book is a catalog of architecture styles; this is the first of several chapters delving in the structure, communication, and all the other characteristics of named architectural styles, in this case, the Layered Architecture. We start with the traditional layered architecture as it is so common, and it has an easy to understand structure. We discuss its uses, how layered related to the domain, and limitations. For each architectural style,...
As architects, we often talk about patterns--contextualized solutions to problems. But we must also choose between architectural styles: named topologies that include component organization, logical (and sometimes physical) deployment, communication,and a host of other characteristics. In this episode, we distinguish between patterns and styles and answer some common questions.
Structural design in software architecture entails both architectural characteristics analysis and deriving logical component from the problem domain. This episode of the podcast delves into logical component analysis, some traps to avoid, and some different analysis techniques. And, as always, answer lots of questions that came up during the discussion.
Chapter Three of Head First Software Architecture covers our Two Laws of software architecture: 1) Everything in software architecture is a trade-off 2) Understanding why is more important than understanding how In this episode, we discuss the origin of these two laws, why we consider them universal, and the (sometimes deep) implications of them for architects making trade-off decisions.
In this episode, we cover the first of the core four dimensions that make up software architecture: architectural characteristics. We discuss what they are and answer questions about derivation, composition, and a host of other factors required to understand this building block of structural design.
Covering the first chapter of Head First Software Architecture, this episode dives into the spectrum of differences between architecture and design. We also cover the four dimensions of software architecture, which forms the narrative scaffolding for the next few chapters: architectural characteristics, architectural decisions, logical components, and architectural styles.
Continuing our exploration of distributed architectures, our next architecture style is event-driven architecture, one of the few styles that can also double as a communication pattern. We discuss what makes an architecture event-driven versus microservices, and discuss why architects might choose this style for certain classes of problems ill suited to other styles. And, as always, we cover both the super powers and kryptonite for this style.
Download from Google Play
Download from App Store
United States
Yeah man, totally get where you're coming from. I used to do all the code checking manually too and it was a pain. Then I switched to Structural Analysis Software, SDC Verifier https://sdcverifier.com and it made a massive difference. It’s a plug-in for FEA tools like ANSYS, Femap, and Simcenter 3D, and it automates all the code checks for standards like Eurocode, AISC, API, you name it. You can even create your own custom checks if you’ve got non-standard requirements. What I love most is how visual and intuitive the reporting is—it makes documentation way easier too. Definitely give it a try if you’re looking to save time and stay compliant.
Hey everyone, I’ve recently started working as a structural engineer, mostly dealing with offshore and steel construction projects. I'm pretty comfortable with general FEA tools like ANSYS, but I feel like I’m spending way too much time manually checking design codes and standards. Is there any structural analysis software that automates these checks or streamlines that process? Bonus points if it can handle custom standards too. Would love some recommendations!