Skip to content
Software Architecture Guide

Software Architecture Evaluation

Explanation

Section titled “Explanation”

Architecture evaluation means examining a software design to find problems and risks. The aim is to find them before development starts (see Software Architecture).

What it finds

Methods such as the Architecture Tradeoff Analysis Method (ATAM) expose risks that could keep an organization from reaching its business goals. ATAM also names sensitivity points and trade-off points. These show how quality goals, such as speed and security, pull against each other. See the articles on ATAM, Sensitivity Point and Trade-off Point.

Early and late evaluation

  • Early methods work from architecture descriptions and models.
  • Late methods look at the code. They search for rule violations and inconsistencies between modules.

Teams often start reviews too late. Then finding problems and refactoring gets harder.

Techniques

  • Experience-based evaluation is the technique most practiced in industry.
  • Scenario-based evaluation builds on scenarios. A scenario is a short description of how a stakeholder interacts with the system.
  • Math formalisms, such as Petri nets, and simulation can support performance estimates.

Qualitative and metrics-based assessment

Qualitative methods involve many stakeholders. They work breadth-first, which means they cover the key aspects of the architecture first. Metrics-based (quantitative) assessments cover only parts of a system. For example, a metrics tool can find dependency cycles. It cannot show how an architecture decision affects a quality attribute.

Cost and adoption

Full-scale methods, ATAM in particular, are heavyweight. They need a lot of effort and cost. Evaluation is beneficial, yet industry does not apply it widely. See Lightweight ATAM for a lighter option.

Example

Section titled “Example”

A team plans an online ticket shop. Before coding, they gather stakeholders and walk through scenarios, such as a sales rush for a popular event. They review the design against each scenario. They note risks and the places where two quality goals compete. They change the design on paper, which is cheaper than changing finished code.

Trade-offs

Section titled “Trade-offs”

Full-scale methods such as ATAM give thorough results but cost a lot of effort. This may explain why evaluation is not widely used in industry. Metrics are cheap to collect, but they cover only parts of a system and cannot show a decision’s effect on quality attributes. Waiting until late makes problems harder to detect and fix.

Checks

Section titled “Checks”
  • The document states when the architecture was evaluated and whether the evaluation worked from models or from code.
  • The evaluation records identified risks, sensitivity points and trade-off points.
  • The evaluation does not rely on metrics alone to judge whether quality goals are met.
Section titled “Related”

Sources

Section titled “Sources”