Architects have an important responsibility to question assumptions and axioms left over from previous eras. Many of the books about software architecture were written in an era that only barely resembles the current world. In fact, the authors believe that we must question fundamental axioms on a regular basis, in light of improved engineering practices, operational ecosystems, software development processes—​everything that makes up the messy, dynamic equilibrium where architects and developers work each day.

Careful observers of software architecture over time witnessed an evolution of capabilities. Starting with the engineering practices of Extreme Programming, continuing with continuous delivery, the DevOps revolution, microservices, containerization, and now cloud-based resources, all of these innovations led to new capabilities and trade-offs. As capabilities changed, so did architects’ perspectives on the industry. For many years, the tongue-in-cheek definition of software architecture was “the stuff that’s hard to change later.” Later, the microservices architecture style appeared, where change is a first-class design consideration.

Each new era requires new practices, tools, measurements, patterns, and a host of other changes. This book looks at software architecture in a modern light, taking into account all the innovations from the last decade, along with some new metrics and measures suited to today’s new structures and perspectives.

The subtitle of our book is “A Modern Engineering Approach.” Developers have long wished to change software development from a craft, where skilled artisans can create one-off works, to an engineering discipline, which implies repeatability, rigor, and effective analysis. While software engineering still lags behind other types of engineering disciplines by many orders of magnitude (to be fair, software is a very young discipline compared to most other types of engineering), architects have made huge improvements, which we’ll discuss. In particular, modern Agile engineering practices have allowed great strides in the types of systems that architects design.

We also address the critically important issue of trade-off analysis. As a software developer, it’s easy to become enamored with a particular technology or approach. But architects must always soberly assess the good, bad, and ugly of every choice, and virtually nothing in the real world offers convenient binary choices—​everything is a trade-off. Given this pragmatic perspective, we strive to eliminate value judgments about technology and instead focus on analyzing trade-offs to equip our readers with an analytic eye toward technology choices.

This book won’t make someone a software architect overnight—​it’s a nuanced field with many facets. We want to provide existing and burgeoning architects a good modern overview of software architecture and its many aspects, from structure to soft skills. While this book covers well-known patterns, we take a new approach, leaning on lessons learned, tools, engineering practices, and other input. We take many existing axioms in software architecture and rethink them in light of the current ecosystem, and design architectures, taking the modern landscape into account.

What's new in the second edition:

When we set out to write the second edition of Fundamentals of Software Architecture, we had a few ideas of things we wanted to flesh out and improve from the first edition, but like a lot of software projects, it kept growing.

One of our met goals was to make the styles sections more consistent, making them more useful for comparisons. We also made some changes to our star ratings to add sections and a few new categories, and added new sections on cloud considerations, data topologies, team topologies, and governance for each architectural style. Along the way we made major additions to a number of chapters on popular topics, such as Chapters 15 and 18, and added a new chapter (Chapter 11) on the modular monolith architectural style.

We also added several entirely new chapters covering architectural patterns in Chapter 20, the intersections of architecture in Chapter 26, and revisiting our laws of software architecture (of which there is a new corollary and a new law) in Chapter 27.