Skip to content
Software Architecture Guide

Choosing and Applying Tactics

Explanation

Section titled “Explanation”

A tactic is a design decision that affects how well an architecture meets a particular quality attribute. A quality attribute is a property such as speed or availability. See Architectural Tactic and Quality Attribute.

Start from the requirements. Tactics are how you implement the quality requirements you already captured, for example in a utility tree. So write those requirements down first. Without them, there is nothing to choose a tactic for.

Pick tactics, then build patterns. Patterns are composed of tactics, which are the building blocks. Patterns and their variants can also be described by which tactics they use. So a different tactic choice can distinguish one pattern variant from another. See Relationship between Tactics and Architectural Styles/Patterns.

Expect side effects. Applying a tactic to improve one quality attribute almost always affects others. You must handle these interactions and document the trade-offs. See Tactic Trade-off Balancing.

Example

Section titled “Example”

A team has a captured requirement that a service must keep working when one part fails. They pick a tactic aimed at that availability goal. They then note that it may slow responses or raise cost. They record the side effect and the reasoning, so later readers see why the tactic was chosen and what it costs.

Trade-offs

Section titled “Trade-offs”

Every tactic helps one quality and may hurt another. Choosing means accepting some cost somewhere. If the side effects are not documented, later readers cannot tell whether a cost was intended or overlooked.

Checks

Section titled “Checks”
  • Each chosen tactic traces back to a documented quality requirement.
  • Side effects of each tactic on other quality attributes are documented along with the trade-offs accepted.
  • Where a pattern is used, the tactics it relies on are named.
Section titled “Related”

Sources

Section titled “Sources”