The outcome of the architectural characteristics and logical component analysis we've been undertaking over the last few chapters is for an architect to choose an appropriate architecture style most suitable for the problem and capabilities we must build to be successful. Thus, this chapter starts a deep-dive on the most popular generic architecture styles that architects should be aware of. This chapter separates the concept of style versus pattern and describe how we'll tackle each fundamental style. 

For the past few chapters/episodes, we've been delving into the analysis and definition of architectural characteristics, one of the two key structural design activities for software architects. In this chapter, we cover the other aspect of structural design in defining logical components, the building blocks of most software architectures. These define the behavior of the system, and we talk about some techniques and challenges in understanding the problem domain and translating it to software structure.

In this episode, we cover one of the key indicators for architects to answer one of the first questions they must consider--should they choose a monolithic or distributed architecture? Understanding and applying the scope of architectural characteristics is one of the keys to properly choosing most applicable solution. As usual, we cover details and background from the chapter and answer questions from the recording audience.

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 chapter, and answer some live questions.

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 and how they apply to the remainder of the book.

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.