Skip to content
Software Architecture Guide

Continuous Architecture Principles

Explanation

Section titled “Explanation”

The Continuous Architecture authors describe principles as capturing priorities and beliefs that guide a team’s reasoning. See Architecture Principle and Working with Principles for the general idea.

This article covers the four principles that the verified facts describe.

Principle 2: Focus on quality attributes. Quality attribute requirements, not functional ones, are the main drivers of the architecture. A quality attribute is a property such as speed or ease of change. See Quality Attribute.

Principle 3: Delay design decisions until they are needed. Teams decide based on facts, not guesses. That way they do not build capabilities nobody uses. See Last Responsible Moment.

Principle 4: Architect for change. This principle leverages the “power of small” elements. Big, monolithic, tightly coupled components are hard to change. So the principle favors small, loosely coupled services. See Loose Coupling and Coupling and Cohesion.

Principle 6: Model your teams after the system design. This follows Conway’s Law. The way teams are organized drives the architecture and design of the systems they work on. The authors say the law is now widely accepted.

The authors also recommend lightweight decision records (ADRs) to capture decisions. See Architectural Decision Record.

Example

Section titled “Example”

A team plans an online shop. Speed at peak sales and ease of change matter most to the business, so the team makes these qualities the main drivers of the design. It postpones choosing a recommendation feature until real usage shows it is needed. It builds the shop from small, loosely coupled services. It then organizes its teams to match those services. It records each decision in a short decision record.

Trade-offs

Section titled “Trade-offs”

The facts give rationale for the principles but do not describe their costs. Teams should still weigh them against their own context.

Checks

Section titled “Checks”
  • Quality attribute requirements, not only functional ones, are named as drivers of the architecture.
  • Decisions are based on facts rather than guesses, so unused capabilities are not built.
  • The design favors small, loosely coupled elements over big, tightly coupled components.
  • Team organization matches the system design.
  • Decisions are captured in lightweight decision records.
Section titled “Related”

Sources

Section titled “Sources”