Software Architecture in Practice, 4th Edition

The software development community is coming to grips with the fact that roughly 80 percent of a typical software system’s total cost occurs after initial deployment. Most systems that people work on are in this phase. Many programmers and software designers never get to work on new development—they work under the constraints of the existing archit... See more

The benefits of incremental development include a reduction of the potential risk in the project. If the architecture is for a family of related systems, the infrastructure can be reused across the family, lowering the per-system cost of each.

• If your system requires high performance, then you need to pay attention to managing the time-based behavior of elements, their use of shared resources, and the frequency and volume of their interelement communication.


• If modifiability is important, then you need to pay attention to assigning responsibilities to elements and limiting the interaction

... See more

This practice gained attention in the early 2000s through the ideas of Alistair Cockburn and his notion of a “walking skeleton.” More recently, it has been adopted by those employing MVP (minimum viable product) as a strategy for risk reduction.

Software architecture is a manifestation of the earliest design decisions about a system, and these early bindings carry enormous weight with respect to the system’s remaining development, its deployment, and its maintenance life. It is also the earliest point at which these important design decisions affecting the system can be scrutinized.

Every architecture, no matter what it is, partitions possible changes into three categories: local, nonlocal, and architectural.

• A local change can be accomplished by modifying a single element—for example, adding a new business rule to a pricing logic module.


• A nonlocal change requires multiple element modifications but leaves the underlying archite

... See more

once the architecture has been agreed upon, it becomes very costly—for managerial and business reasons—to significantly modify it. This is one argument (among many) for analyzing the software architecture for a large system before settling on a specific choice.

This point follows from the previous two: Architecture not only imbues systems with qualities, but does so in a predictable way.

A system’s ability to meet its desired (or required) quality attributes is substantially determined by its architecture. If you remember nothing else from this book, remember that.