In this post, you will find the list of thirteen and the notes for each item.


  1. An architecture will inhibit or enable a system’s driving quality attributes.
  2. The decisions made in an architecture allow you to reason about and manage change as the system evolves.
  3. The analysis of an architecture enables early prediction of a system’s qualities.
  4. A documented architecture enhances communication among stakeholders.
  5. The architecture is a carrier of the earliest and hence most fundamental, hardest-to-change design decisions.
  6. An architecture defines a set of constraints on subsequent implementation.
  7. The architecture dictates the structure of an organization, or vice versa.
  8. An architecture can provide the basis for evolutionary prototyping.
  9. An architecture is the key artifact that allows the architect and project manager to reason about cost and schedule.
  10. An architecture can be created as a transferable, reusable model that forms the heart of a product line.
  11. Architecture-based development focuses attention on the assembly of components, rather than simply on their creation.
  12. By restricting design alternatives, architecture channels the creativity of developers, reducing design and system complexity.
  13. An architecture can be the foundation for training a new team member.


2.1. Inhibiting or Enabling a System’s Quality Attributes

  • A good architecture is necessary, but not sufficient, to ensure quality.
  • Achieving quality attributes must be considered throughout:
    • Design
    • Implementation
    • Deployment

2.2. Reasoning About and Managing Change

  • Every architecture partitions possible changes into three categories: local, nonlocal, and architectural.
    • A local change can be accomplished by modifying a single element.
    • A nonlocal change requires multiple element modifications but leaves the underlying architectural approach intact.
    • An architectural change affects the fundamental ways in which the elements interact with each other and will probably require changes all over the system.
  • Local changes are the most desirable, and so an effective architecture is one in which the most common changes are local, and hence easy to make.

2.3. Predicting System Qualities

  • It is possible to make quality predictions about a system based solely on an evaluation of its architecture.

2.4. Enhancing Communication among Stakeholders

  • The architecture is sufficiently abstract that most nontechnical people can understand it adequately.
  • The abstraction can be refined into sufficiently rich technical specifications to guide:
    • Implementation
    • Integration
    • Test
    • Deployment

2.5. Carrying Early Design Decisions

  • An architecture design can also be viewed as a set of decisions.
  • The early design decisions constrain the decisions that follow, and changing these decisions has enormous ramifications.

2.6. Defining Constraints on an Implementation

  • An implementation exhibits an architecture if it conforms to the design decisions prescribed by the architecture.
    • The implementation must be implemented as the set of prescribed elements.
    • These elements must interact with each other in the prescribed fashion
    • Each element must fulfill its responsibility to the other elements as dictated by the architecture.
  • Each of these prescriptions is a constraint on the implementer.

2.7. Influencing the Organizational Structure

  • The architecture includes the broadest decomposition of the system, it is typically used as the basis for the work-breakdown structure.
  • The work-breakdown structure in turn dictates:
    • Units of
      • Planning
      • Scheduling
      • Budget
    • Interteam communication channels
    • Configuration control and file-system organization
    • Integration and test plans and procedures
  • A side effect of establishing the work-breakdown structure is to freeze some aspects of the software architecture.
  • A group that is responsible for one of the subsystems will resist having its responsibilities distributed across other groups.
  • If these responsibilities have been formalized in a contractual relationship, changing responsibilities could become expensive or even litigious.

2.8. Enabling Evolutionary Prototyping

  • Once an architecture has been defined, it can be analyzed and prototyped as a skeletal system.
  • Build a little infrastructure to support a little end-to-end functionality; repeat until done.
  • Systems built as plug-in architectures are skeletal systems.

2.9. Improving Cost and Schedule Estimates

  • One of the duties of an architect is to help the project manager create cost and schedule estimates early in the project life cycle.
    • Top-down estimates are useful for setting goals and apportioning budgets.
    • Cost estimations that are based on a bottom-up understanding of the system’s pieces are typically more accurate.
  • The best cost and schedule estimates will typically emerge from a consensus between:
    • The top-down estimates (created by the architect and project manager)
    • The bottom-up estimates (created by the developers)

2.10. Supplying a Transferable, Reusable Model

  • Reuse of architectures provides tremendous leverage for systems with similar requirements.
  • Not only can code be reused, but so can
    • Requirements
    • Experience
    • Infrastructure

    be reused.

  • When architectural decisions can be reused across multiple systems, the early-decision consequences are transferred.
  • A software product line or family is a set of software systems that are all built using the same set of reusable assets.
  • The architecture (for product lines) defines what is fixed for all members of the product line and what is variable.

2.11. Allowing Incorporation of Independently Developed Components

  • Architecture-based development often focuses on composing or assembling elements that are likely to have been developed separately, even independently, from each other.
  • The architecture constrains possible replacements (or additions) according to
    • How they interact with their environment
    • How they receive and relinquish control
    • What data they consume and produce
    • How they access data
    • What protocols they use for communication and resource sharing

2.12. Restricting the Vocabulary of Design Alternatives

  • Engineering is about discipline, and discipline comes in part by restricting the vocabulary of alternatives to proven solutions.
  • Architectural patterns guide the architect and focus the architect on the quality attributes of interest in large part by restricting the vocabulary of design alternatives to a relatively small number.
  • Properties of software design follow from the choice of an architectural pattern.

2.13. Providing a Basis for Training

  • The important uses of software architecture is to support and encourage communication among the various stakeholders.
  • The architecture is a common reference point.


Reference Book: Software Architecture in Practice (3rd Edition)