Skip to content
Software Architecture Guide

Fitness for Purpose

Explanation

Section titled “Explanation”

Architecture is rarely good or bad in absolute terms. It is either fit or unfit for its purpose. So “Is this a good architecture?” is an incomplete question. Ask instead: “Fit for what?”

Where the purpose comes from

The purpose depends mainly on the context in which the system will live. Specific user requirements matter, but they are not the whole picture.

Guidance on choosing an architecture style (see Architecture Style) says to start from the problem. Then name the key business drivers and the matching quality needs, also called nonfunctional requirements (see Quality Attribute). Finally, rank them by priority.

Different priorities point to different choices:

  • If time to market is the driver, favor maintainability, testability and reliability.
  • If the budget is tight, favor simplicity.

Trade-offs and context

Every style has trade-offs. You should understand why a style was chosen. Sometimes relaxing one of its constraints is better than keeping the style pure.

Whether a style’s benefits outweigh its challenges must be judged for the specific context. The complexity of the architecture must also match the domain. If it is too simple for the domain, the result can become a Big Ball of Mud.

Fitness changes over time

Choosing a style is not a one-time task. It needs ongoing measurement, validation and refinement. Changing the style later is costly, so early checks pay off.

Example

Section titled “Example”

A team builds an internal tool that must reach users within weeks. Its stated drivers are time to market and a small budget. The team ranks maintainability, testability and simplicity first. It picks a simple structure and records why.

A different team builds a system for a complex domain. For that team, the same simple structure may be too simple. Its benefits and challenges must be weighed again for that context.

Trade-offs

Section titled “Trade-offs”

Judging fitness needs a stated purpose and ranked priorities. Without them, any opinion about an architecture is hard to check. Ranking also means accepting costs: favoring simplicity for a tight budget gives up something else. Relaxing a style’s constraint can serve the purpose better than purity, but the team must understand why it does so. Ongoing measurement and validation take effort, yet changing style late is costly.

Checks

Section titled “Checks”
  • The document names the business drivers and prioritized quality requirements that the chosen architecture style is meant to serve.
  • The document explains why the style was chosen and what trade-offs it accepts.
  • The document judges the style’s benefits against its challenges for the specific context.
  • The document describes how the fit will be measured and validated over time.
Section titled “Related”

Sources

Section titled “Sources”