Skip to content
Software Architecture Guide

Reasons for Architectural Tactics

Explanation

Section titled “Explanation”

An architectural tactic is a design decision that affects how a system addresses one quality attribute, such as availability or performance. (See Architectural Tactic and Quality Attribute.) Tactics adjust the parameters of quality attribute models.

Tactics are smaller than patterns. A tactic is like an atom and a pattern is like a molecule. So a pattern can be seen as composed of tactics. The SEI report on modifiability tactics follows this idea. It describes standard architectural patterns and their variants in terms of tactics.

Why use tactics next to patterns?

  • Patterns need adapting. A pattern taken from a catalog must still be adapted to the specific problem and design context. Tactics are the smaller pieces an architect can use for that adaptation.
  • Top-down reasoning. Tactics give a way of thinking about design that starts from a quality attribute objective. The architect asks which decisions would serve that goal.

For more on how the two relate, see Relationship between Tactics and Architectural Styles/Patterns.

Example

Section titled “Example”

A team picks a catalog pattern for its system. The context differs from what the pattern assumes. The team states its main quality goal, for example availability. It then looks at tactics for that goal and adds or changes decisions in the pattern until it fits the situation.

Trade-offs

Section titled “Trade-offs”

The verified facts cover only the reasons for using tactics. They do not describe side effects of individual tactics. For balancing quality attributes, see Tactic Trade-off Balancing.

Checks

Section titled “Checks”
  • When a catalog pattern is used, the document shows how it was adapted to the specific problem and design context.
  • Design decisions are tied to a stated quality attribute objective.
Section titled “Related”

Sources

Section titled “Sources”