Software Systems Architecture

About the Book

Who the Book is For

We wrote this book primarily for people like us: software architecture practitioners who need to get to grips with the development of practical architectures for their information systems that meet the needs of those they are intended to serve. We also hope the book will be of interest to people studying software architecture at university, and others involved in the software lifecycle, such as development managers, testers, software developers and technical specialists.

The knowledge that you will gain by reading of the book includes:

  • An understanding of what software architecture is, and why your role is vitally important to successful project delivery.
  • How to determine who is interested in your architecture (your stakeholders), understand what is important to them (their concerns), and design an architecture that reflects and balances their different needs.
  • How to communicate your architecture to your stakeholders in an understandable way that demonstrates that you have met their concerns (the architectural description).
  • How to focus on what is architecturally significant, safely leaving other aspects of the design to your designers, without neglecting issues like performance, resilience, and location.
  • What important activities you most need to undertake as an architect, such as identifying and engaging stakeholders, using scenarios, creating models, and documenting and validating your architecture.

Key Concepts

In order to help to organise the material in the book, we have identified three key architectural concepts that we use as themes throughout the text.

  • Stakeholders are the people for whom we build systems. A key part of your role as an architect is knowing how to work with stakeholders in order to create an architecture that meets their complex, overlapping, and often conflicting needs.
  • Viewpoints (and views) are an approach to structuring the architecture definition process and the architectural description, based on the principle of separation of concerns. Viewpoints contain proven architectural knowledge to guide the creation of an architecture, described in a particular set of views (each view being the result of applying the guidance in a particular viewpoint).
  • Perspectives are a complementary concept to viewpoints that we introduce in this book. Perspectives contain proven architectural knowledge and help structure the architecture definition process by separating concerns but focusing on cross-structural quality properties rather than architectural structures.


The book is divided into five sections as follows.

  • Part I provides an introduction to and review of the basic concepts we use throughout the book (e.g., stakeholder, architectural description, viewpoint, view, and perspective) and describes the role of the software architect.
  • Part II describes the most important activities you need to undertake as an architect, such as agreeing on a project’s scope, identifying and engaging stakeholders, using scenarios and patterns, creating models, and documenting and validating your architecture.
  • Part III is a catalog of the seven most important viewpoints you will need when creating your architectural description: the Context, Functional, Information, Concurrency, Development, Deployment, and Operational viewpoints.
  • Part IV is a catalog of the most important perspectives for information systems, including Security, Performance and Scalability, Availability and Resilience, Evolution, Location, Development Resource, Internationalization, and a number of others.
  • Part V pulls these concepts together and explains how you can start to put our ideas into practice.

What’s New in Edition 2

The most important changes in this edition are as follows.

  • We have introduced a new viewpoint, which we call the Context viewpoint. This describes the relationships, dependencies, and interactions between the system and its environment (the people, systems, and external enti- ties with which it interacts). It extends, formalizes, and standardizes the relatively brief discussion of scope and context that used to be in Chapter 8.
  • We have expanded the discussion of different aspects of the role of architecture in Part II.
  • We have revised most of the viewpoint and perspective definitions, particularly the Functional and Concurrency views and the Performance and Scalability perspective.
  • We have revised and extended the Bibliography and the Further Reading sections in most chapters.
  • We have updated the book to align with the concepts and terminology in the new international architecture standard ISO 42010 (which derives from IEEE Standard 1471).
  • We have updated our UML modeling advice and examples to reflect the changes introduced in version 2 of UML.