Sensitivity and Tradeoff Points
Sensitivity points and tradeoff points are two of the outputs of the Architecture Tradeoff Analysis Method (ATAM). They name the design decisions that a system’s quality attributes actually hinge on, so those decisions get measured and chosen deliberately instead of being set by default. The definitions below come from the Software Engineering Institute’s 2000 ATAM report by Kazman, Klein, and Clements.
Sensitivity point
The report defines a sensitivity point as “a property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response.” In other words, change this property and a specific quality — confidentiality, latency, maintenance effort — moves noticeably. The report’s examples include:
- the confidentiality of a virtual private network being sensitive to the number of bits of encryption;
- the latency of an important message being sensitive to the priority of the lowest-priority process involved in handling it;
- maintenance effort being sensitive to how well communication protocols and file formats are encapsulated.
A sensitivity point tells you where to look. It is something to measure: if a dashboard’s response time depends sharply on how data files are sized, then file size belongs in the evaluation, not in a footnote.
Tradeoff point
A tradeoff point is “a property that affects more than one attribute and is a sensitivity point for more than one attribute.” The report’s example is the level of encryption: raising it improves predicted security but requires more processing time, so where a confidential message also has a hard real-time latency requirement, the encryption level is a tradeoff point. The report calls tradeoff points the most critical decisions one can make in an architecture.
A tradeoff point is something to decide. Whichever way it is set, one attribute pays, and the decision should say which one and why.
Examples from a data platform
These are illustrations, not findings from the report:
| Property | Attributes it affects | Kind |
|---|---|---|
| How often a table is loaded | Freshness improves; small files accumulate, so query speed and maintenance cost can suffer | Tradeoff point |
| Whether workloads share one compute pool | Cost falls with sharing; isolation between workloads falls too | Tradeoff point |
| Result cache lifetime | Query latency and cost improve; data shown can be staler | Tradeoff point |
| Partition column chosen for a large table | Query latency for filters on that column | Sensitivity point |
From point to risk
In ATAM, every sensitivity and tradeoff point is a candidate risk, and by the end of the evaluation each is classified as a risk or a non-risk. A shared compute pool is a non-risk if the peak workloads never overlap and that assumption is written down; it becomes a risk the day a new workload lands in the same window. Recording the assumption is what lets someone notice when it stops holding. How this vocabulary helps compare platforms is worked through in Choosing a Data Platform: What to Compare When the Feature Lists Match.
References: Rick Kazman, Mark Klein, and Paul Clements, ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004.
Discover more from Insightful Data Lab
Subscribe to get the latest posts sent to your email.