A tactic is a design decision which influences the achievement of a quality attribute response. It directly affects the system’s response to some stimulus. Architectural patterns can be considered bundles of tactics. For example, some of the tactics for recovering from faults are redundant spare, rollback, exception handling or retry.
This method, described in Software Architecture in Practice, 4th Edition, by Len Bass, Paul Clements, and Rick Kazman can be used by the architect to aid in reflection and introspection or it can be used to structure a question and answer session between an evaluator (or evaluation team) and the architect(s).
The tactics-based analysis focused on a single quality attribute at a time. The power of this method lays in the fact that it reveals a great deal about the risks in design decisions taken and those not taken in a relatively short amount of time (around one hour per quality attribute).
What is important with the tactics-based analysis is the tactics-based questionnaire which records:
– If the tactic is supported by the architecture.
– Weather there are any obvious risks in the use or non-use of the tactic.
– The specific design decisions made to implement the tactic.
– Any rationale or assumptions made in the implementation of this tactic.
Addressing the set of questions forces the architect to think about these tactics and consider the big picture.