If you are looking for a single volume to explain software architecture, then I would recommend Software Architecture in Practice  by Bass, Clements, and Kazman. Software Architecture in Practice provides a comprehensive, superb, and highly readable overview of the software engineering practices termed “software architecture”, which include the design, analysis, documentation, and implementation of architectures along with related material on the business goals and quality attributes that influence architecture designs. What makes the work so informative, and so readable, is that the authors do an excellent job in weaving together descriptions and analysis of the many facets of software architecture with their own consulting experience. The result is a text that not only explains software architecture practice in-depth, but describes the application of the information from a variety of perspectives with examples of particular situations to make the descriptions of these software abstractions more concrete to the reader. For instructors, a complete set of Powerpoint slides that cover each chapter is available from Pearson Education.
Bass, Clements, and Kazman define software architecture as follows:
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
The set of structures that make up an architecture can be classified into three categories: static structures, such as modules and their decomposition; dynamic structures, such as how components of the system interact at run time; and finally mapping structures that relate software structures to organizational elements, development teams, or their execution environments.
What I particularly enjoyed about the book is its inclusion of several over-arching themes that are woven into the detailed descriptions within each chapter:
- The authors try very hard to be precise, defining their terminology with clear definitions, to avoid confusion, particularly if the reader is already somewhat familiar with the topic from the available literature.
- The authors make the point that software architecture is fundamentally about software quality: quality in terms of the software system being able to deliver support for the system’s security requirements, correctness requirements, performance requirements, availability requirements, extensibility requirements, and so on. Readers may be familiar with these issues as non-functional requirements and these are front-and-center in this volume, which the authors term Architecturally Significant Requirements (ASRs).
- The authors provide numerous examples of placing software architecture in a system development context. This context not only includes the determination of functional requirements from business analysts, but also includes additional constraints such as the development paradigm (e.g. waterfall or agile) being used.
- The authors go to great lengths to show that a software architecture is much, much more than a single diagram. An architecture will have multiple views of its various elements, some of which are static and some dynamic. These must be documented so that development teams understand where their specific development tasks fit within the system and so that the software architect can continuously monitor the development process to ensure that the project is continuing on the correct course, following the architecture as intended.
As an example, Chapter 15 describes the purpose of software in an agile development context. One might mistakenly believe that agile development should eschew significant planning tasks such as designing a software architecture, but the authors – correctly – point out that a software architecture provides a unifying force – perhaps the only unifying force – with which to combine separate development efforts into a cohesive whole. However, there are, as always, tradeoffs; the more complex the system, the greater the architectural effort required:
In summary, with Software Architecture in Practice the authors comprehensively document the design, analysis, and implementation of software architectures that are intended to deliver the following benefits (taken from Chapter 2):
- An architecture will inhibit or enable a system’s driving quality attributes.
- The decisions made in an architecture allow you to reason about and manage change as the system evolves.
- The analysis of an architecture enables early prediction of a system’s qualities.
- A documented architecture enhances communication among stakeholders.
- The architecture is a carrier of the earliest and hence most fundamental, hardest-to-change design decisions.
- An architecture defines a set of constraints on subsequent implementation.
- The architecture dictates the structure of an organization, or vice versa.
- An architecture can provide the basis for evolutionary prototyping.
- An architecture is the key artifact that allows the architect and project manager to reason about cost and schedule.
- An architecture can be created as a transferable, reusable model that form the heart of a product line.
- Architecture-based development focuses attention on the assembly of components, rather than simply on their creation.
- By restricting design alternatives, architecture channels the creativity of developers, reducing design and system complexity.
- An architecture can be the foundation for training a new team member.
I read this book cover-to-cover and I highly recommend it for any software developer. I am now reading a closely-related volume, Documenting Software Architectures: Views and Beyond, 2nd Edition, to better understand additional documentation techniques for describing software architectures to various sets of stakeholders.
 Len Bass, Paul Clements, and Rick Kazman (2013). Software Architecture in Practice, 3rd Edition. Addison-Wesley, Upper Saddle River, New Jersey. ISBN 978-0-321-81573-6.