Skip to content

Risk Analysis and Quality Attributes

Summary

This chapter extends the ATAM methodology to cover risk analysis and the full spectrum of quality attributes used to evaluate trust architectures. Students will learn to identify architecture risks, organize them into risk themes, develop mitigation strategies, and evaluate systems against security, performance, availability, reliability, modifiability, and maintainability attributes. These skills enable structured comparison of blockchain vs. traditional approaches.

Concepts Covered

This chapter covers the following 12 concepts from the learning graph:

  1. Architecture Risk
  2. Risk Identification
  3. Risk Theme
  4. Risk Mitigation
  5. Stakeholder Analysis
  6. Non-Functional Requirement
  7. Security Attribute
  8. Availability Attribute
  9. Reliability
  10. Modifiability
  11. Maintainability
  12. Stakeholder Buy-In

Prerequisites

This chapter builds on concepts from:

Rex Says: Trust, but Verify!

Rex welcomes you Welcome back, fellow analysts! In the last chapter, we learned to compare architectures using quality attributes and utility trees. Now we add the critical complement: risk analysis. Every architecture carries risks — the question is whether you discover them during evaluation or during production. Trust, but verify — and identify the risks first!

Learning Objectives

After completing this chapter, you will be able to:

  • Define architecture risk and distinguish it from project risk and operational risk
  • Apply systematic risk identification techniques to trust technology architectures
  • Organize identified risks into risk themes that reveal systemic architecture weaknesses
  • Develop risk mitigation strategies appropriate to the severity and likelihood of each risk
  • Conduct stakeholder analysis to identify all parties affected by architecture decisions
  • Explain why non-functional requirements drive architecture decisions more than functional requirements
  • Evaluate trust architectures against security, availability, reliability, modifiability, and maintainability attributes
  • Build stakeholder buy-in for evidence-based architecture recommendations

Architecture Risk

An architecture risk is a potential problem inherent in an architecture decision that could prevent the system from meeting its quality attribute requirements. Architecture risks differ from project risks (schedule overruns, budget shortfalls) and operational risks (hardware failures, human errors) because they are embedded in the fundamental design choices and cannot be fixed without changing the architecture itself.

In trust technology evaluations, architecture risks are particularly consequential because the choice between centralized and distributed architectures is difficult and expensive to reverse. Discovering that a blockchain architecture cannot meet performance requirements after 18 months of development is not a bug to be fixed — it is an architecture risk that should have been identified during evaluation.

Architecture risks have two dimensions:

  • Likelihood — the probability that the risk will materialize, given realistic operating conditions
  • Impact — the severity of the consequence if the risk materializes

The expected risk exposure is the product of these two dimensions:

\[E[\text{risk}] = P(\text{occurrence}) \times C(\text{impact})\]

A risk with 20% probability and \(500,000 impact has the same expected exposure (\)100,000) as a risk with 80% probability and $125,000 impact. However, the risk management strategies for these two cases differ substantially — the first calls for contingency planning, the second for active mitigation.

Risk Level Likelihood Impact Response Strategy
Critical High High Mitigate immediately or reject architecture
Major High Medium, or Medium/High Develop mitigation plan with timeline
Moderate Medium Medium Monitor and prepare contingency
Minor Low Low-Medium Accept and document

Risk Identification

Risk identification is the systematic process of discovering architecture risks before they manifest as system failures. For trust technology evaluations, risk identification should examine risks specific to the candidate architecture type (blockchain-specific, centralized-specific) and risks common to both approaches.

Effective risk identification techniques include:

Scenario-based risk identification leverages the quality attribute scenarios from the ATAM utility tree. For each (H,H) and (H,M) scenario, ask: "What could prevent this architecture from meeting this scenario's response measure?" The answers are architecture risks.

Checklist-based identification uses a catalog of known blockchain architecture risks:

  • Smart contract vulnerabilities (reentrancy, integer overflow, front-running)
  • Consensus mechanism failures (51% attacks, nothing-at-stake, long-range attacks)
  • Key management failures (lost keys, stolen keys, inadequate key rotation)
  • Oracle dependencies (external data feed manipulation, oracle downtime)
  • Governance deadlocks (inability to agree on protocol upgrades)
  • Regulatory risks (changing classification of tokens, privacy regulation conflicts)
  • Platform risks (underlying blockchain platform abandoned, forked, or compromised)

Analogy-based identification examines failures in similar deployments. The history of blockchain projects provides abundant case studies:

  • The DAO hack (2016) — $60M lost to a reentrancy vulnerability in a smart contract
  • The Parity wallet freeze (2017) — $150M in ETH permanently locked due to a library contract bug
  • Numerous DeFi exploits — flash loan attacks, oracle manipulation, bridge hacks

Each historical failure suggests a category of architecture risk that should be evaluated for any new deployment.

Key Insight

Rex is thinking Risk identification is not about proving that blockchain is risky — every architecture has risks. The point is to ensure that blockchain-specific risks receive the same rigorous analysis as the risks in traditional architectures. A fair evaluation identifies risks in all candidate architectures and compares them against the same criteria.

Assumption-based identification challenges the assumptions underlying each candidate architecture:

  • "Consortium members will honestly participate in consensus" — what if one becomes an adversary?
  • "Gas prices will remain stable enough for our budget" — what if they spike 10x?
  • "The blockchain platform will continue to be maintained" — what if the core development team dissolves?
  • "Our smart contracts are bug-free" — what if they are not, and the bugs are exploited?

For the traditional centralized alternative, equivalent questions apply:

  • "The database administrator will not be compromised" — what if they are?
  • "The hosting provider will maintain uptime" — what if they have a catastrophic failure?
  • "The regulatory environment will not require decentralization" — what if it does?

Risk Themes

A risk theme is a pattern that emerges when multiple individual risks share a common underlying cause or affect a common quality attribute. Organizing risks into themes reveals systemic weaknesses in an architecture that might not be apparent from examining individual risks in isolation.

For blockchain architectures, common risk themes include:

Theme: Immutability as liability Individual risks in this theme include: inability to correct data entry errors, inability to comply with GDPR "right to be forgotten," inability to roll back fraudulent transactions, inability to upgrade data schemas without forking. The theme reveals that immutability — often presented as blockchain's greatest strength — creates a cluster of risks for systems that must handle real-world messiness.

Theme: Governance fragility Individual risks include: inability to agree on protocol upgrades, inability to resolve disputes between consortium members, inability to respond quickly to security incidents, inability to enforce participation commitments. The theme reveals that decentralized governance introduces coordination risks that scale with the number of participants.

Theme: Expertise concentration Individual risks include: difficulty hiring blockchain developers, dependency on specific team members' smart contract knowledge, inability to find auditors for the chosen platform, vendor support limitations. The theme reveals that emerging technology stacks create human capital risks that mature technology stacks do not.

For centralized architectures, common risk themes include:

Theme: Single point of compromise Individual risks include: database administrator misconduct, hosting provider failure, DDoS attack on central infrastructure, insider threat. The theme reveals that centralized authority creates concentrated failure modes.

Theme: Opacity and audit resistance Individual risks include: difficulty proving data has not been tampered with, log manipulation by administrators, lack of independent verification, audit trail gaps. The theme reveals that centralized systems make independent verification harder.

Documenting risk themes alongside individual risks provides decision-makers with both the detailed view (specific risks to mitigate) and the strategic view (systemic weaknesses to consider in architecture selection).

Risk Mitigation

Risk mitigation is the set of strategies for reducing the likelihood or impact of identified architecture risks. For trust technology evaluations, mitigation strategies must be costed and incorporated into the TCO model from Chapter 12, since mitigation is not free.

The four standard risk mitigation strategies, applied to blockchain architecture risks:

Avoidance — eliminate the risk by choosing a different architecture or design approach.

  • Example: Avoid smart contract reentrancy risk by using a platform that does not support recursive calls
  • Example: Avoid gas price volatility by choosing a private blockchain with fixed transaction costs
  • Cost: May require choosing a less capable platform

Reduction — decrease the likelihood or impact of the risk.

  • Example: Reduce smart contract vulnerability risk through formal verification and multiple independent audits
  • Example: Reduce key management risk through hardware security modules and multi-signature schemes
  • Cost: Audit and formal verification costs (\(50K-\)200K per contract); HSM costs (\(10K-\)50K per node)

Transfer — shift the risk to another party.

  • Example: Purchase smart contract insurance (available through protocols like Nexus Mutual)
  • Example: Use a managed blockchain service where the provider assumes infrastructure risk
  • Cost: Insurance premiums (typically 2-5% of insured value annually); BaaS subscription fees

Acceptance — acknowledge the risk and prepare contingency plans.

  • Example: Accept that consortium governance will occasionally be slow, and build buffer time into critical processes
  • Example: Accept that the blockchain platform may require migration in 5 years, and budget for switching costs
  • Cost: Contingency budget allocation (typically 10-20% of project budget)
Risk Strategy Mitigation Action Estimated Cost Residual Risk
Smart contract vulnerability Reduce 3 independent audits + formal verification $300K Low
Consensus failure Reduce Byzantine fault tolerance + monitoring $50K/year Low
Key management failure Reduce HSMs + multi-sig + key ceremony $100K setup Medium
Gas price spike Transfer Fixed-price BaaS or private chain $80K/year premium Low
Governance deadlock Accept Escalation procedures + exit clause $20K legal Medium
Platform abandonment Avoid Choose platform with largest developer ecosystem $0 (selection criterion) Medium

Stakeholder Analysis

Stakeholder analysis identifies all parties who are affected by or can influence the architecture decision, and maps their interests, concerns, and level of influence. In trust technology decisions, the stakeholder landscape is typically broader than for conventional IT projects because blockchain implementations often span organizational boundaries.

Key stakeholder categories for a trust technology evaluation:

  • Business sponsors — executives who authorize funding and expect business value. They care about ROI, risk, and strategic alignment.
  • Technical architects — engineers who must design and implement the chosen architecture. They care about feasibility, maintainability, and technology maturity.
  • Operations teams — staff who must run the system day-to-day. They care about monitoring, incident response, and operational simplicity.
  • Compliance and legal — teams ensuring regulatory adherence. They care about data privacy, auditability, jurisdictional issues, and liability.
  • End users — individuals or systems that interact with the solution. They care about performance, usability, and reliability.
  • Consortium partners (for multi-party solutions) — external organizations that must participate. They care about cost sharing, governance, data ownership, and competitive implications.
  • Regulators — government or industry bodies that oversee the domain. They care about transparency, consumer protection, and systemic risk.

A stakeholder power-interest matrix helps prioritize engagement:

Low Interest High Interest
High Power Keep satisfied (Legal, Regulators) Manage closely (Business sponsors, Consortium partners)
Low Power Monitor (End users of partner systems) Keep informed (Operations, Development team)

Bias Alert

Rex warns you Stakeholder analysis often reveals that the loudest voices in a technology decision are not the most affected parties. A CTO excited about blockchain may have strong influence but bears none of the operational burden. An operations team that must run the blockchain nodes has high interest but low decision-making power. Ensure the evaluation gives appropriate weight to stakeholders who must live with the consequences, not just those who make the announcement.

Non-Functional Requirements

Non-functional requirements (NFRs) specify the quality constraints under which a system must operate, as distinct from functional requirements that specify what the system must do. In ATAM terminology, non-functional requirements map directly to quality attribute scenarios — they are testable statements about how well the system must perform along quality dimensions.

The term "non-functional" is misleading because these requirements are deeply functional in practice. A system that records transactions correctly (functional requirement) but takes 30 minutes per transaction (failing a performance NFR) is useless. A system with perfect availability but no access control (failing a security NFR) is dangerous.

For trust technology evaluations, NFRs serve as the primary discriminator between candidate architectures. Two architectures that satisfy identical functional requirements may differ dramatically in their ability to meet NFRs:

Non-Functional Requirement Public Blockchain Private Blockchain Centralized Database
Transaction latency < 2 sec Difficult (block confirmation) Achievable (configurable) Easy (milliseconds)
99.99% availability Achievable (redundancy) Challenging (consensus dependency) Achievable (standard HA)
Tamper-evident audit trail Native capability Native capability Requires additional design
GDPR data deletion Extremely difficult Difficult (requires design) Straightforward
Schema evolution without downtime Very difficult (immutable contracts) Difficult (chaincode upgrade) Standard practice
< $0.01 per transaction Uncertain (gas volatility) Achievable (fixed costs) Achievable (amortized)

This table demonstrates why NFR analysis is the most powerful tool for trust technology evaluation. The functional requirement "record supply chain transactions" says nothing about which architecture to choose. The NFRs determine which architectures are even viable.

Security Attribute

The security attribute measures a system's ability to resist unauthorized access, data manipulation, and service disruption while maintaining confidentiality, integrity, and availability for authorized parties. Security is often cited as blockchain's strongest quality attribute — and in some respects, this claim is justified. In others, it is misleading.

Blockchain security strengths:

  • Cryptographic integrity — hash chains make undetected data modification computationally infeasible
  • Distributed redundancy — no single point of compromise can destroy or alter the entire dataset
  • Transparent verification — any participant can independently verify the chain's integrity
  • Immutable history — confirmed transactions cannot be retroactively altered (with sufficient confirmations)

Blockchain security weaknesses:

  • Smart contract vulnerabilities — application-layer code can contain bugs that are exploitable and, once deployed, difficult to patch
  • Key management burden — the entire security model depends on private key secrecy; lost or stolen keys have irreversible consequences
  • 51% attacks — on smaller proof-of-work networks, a majority hashrate attack is economically feasible
  • Bridge and oracle risks — interactions between the blockchain and external systems introduce trust assumptions that negate on-chain guarantees
  • Social engineering — blockchain cannot protect against users being tricked into signing malicious transactions

A security quality attribute scenario for comparison:

An external attacker (source) exploits a vulnerability in the transaction validation logic (stimulus) in the trust system (artifact) during normal operation (environment). The system detects the exploit and halts affected processing within 60 seconds (response), with zero unauthorized state changes committed to the permanent record (response measure).

Against this scenario:

  • Public blockchain: Detection may occur, but halting processing requires community consensus (slow). However, on-chain state changes require block confirmation, providing a detection window.
  • Private blockchain: Network operators can halt processing quickly but must coordinate across organizations.
  • Centralized database: Can halt immediately and roll back. But if the attacker is the database administrator, detection depends on external monitoring.

No architecture is universally "more secure." Security must be evaluated scenario by scenario.

Availability Attribute

The availability attribute measures the proportion of time that a system is operational and accessible to authorized users. Availability is typically expressed as a percentage of uptime over a given period, with common targets expressed in "nines":

Availability Annual Downtime Classification
99% (two nines) 3.65 days Basic
99.9% (three nines) 8.76 hours Standard
99.99% (four nines) 52.6 minutes High availability
99.999% (five nines) 5.26 minutes Mission-critical

Public blockchain networks like Bitcoin and Ethereum have remarkably high availability — the Bitcoin network has operated continuously since January 2009 with no complete outages. However, this headline availability figure masks important nuances:

  • Network availability versus application availability — the blockchain network may be up, but if gas prices are prohibitively high, the application is effectively unavailable to cost-constrained users
  • Confirmation availability — the network may accept transactions but take unpredictably long to confirm them during congestion
  • Smart contract availability — a paused or buggy smart contract is unavailable even if the underlying network is operational
  • Node availability — individual node failures may not affect network availability but do affect specific users or organizations

For private and consortium blockchains, availability depends on:

  • The consensus mechanism's fault tolerance (typically tolerates \(f\) failures out of \(n = 3f + 1\) nodes for BFT consensus)
  • The hosting infrastructure's reliability
  • The ability to detect and replace failed nodes quickly

Key Insight

Rex is thinking When comparing availability between blockchain and centralized architectures, ensure you are comparing like with like. A centralized database's availability depends on its hosting and replication setup. A blockchain's availability depends on its node count and consensus mechanism. A well-designed centralized system with active-active replication may achieve higher effective availability than a poorly designed blockchain consortium with insufficient node diversity.

Reliability

Reliability measures the probability that a system performs its intended function without failure over a specified period under specified conditions. While availability measures whether the system is "up," reliability measures whether it produces correct results when it is up.

For trust systems, reliability has specific dimensions:

  • Transaction reliability — the probability that a submitted transaction is correctly processed and permanently recorded
  • Ordering reliability — the guarantee that transactions are processed in a consistent, deterministic order
  • Finality reliability — the assurance that a confirmed transaction will not be reversed

Blockchain protocols provide strong ordering and finality reliability through consensus mechanisms, but transaction reliability varies:

  • On public blockchains, transactions may fail due to insufficient gas, nonce errors, or reverted smart contract execution — and the user still pays for the failed attempt
  • On private blockchains, transaction failures are typically due to validation rule violations and are handled more gracefully
  • On centralized databases, transaction failures trigger standard rollback mechanisms with clear error handling

The mean time between failures (MTBF) for the transaction processing function can be compared across architectures:

\[\text{Reliability} = \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}}\]

where MTTR is the mean time to repair. Blockchain systems tend to have long MTBF (failures are rare) but also long MTTR (recovering from consensus failures or smart contract bugs is complex and slow). Centralized systems may have shorter MTBF for some failure modes but much shorter MTTR due to simpler recovery procedures.

Modifiability

Modifiability measures the cost and effort required to change a system after deployment. In trust technology evaluation, modifiability is often the quality attribute where blockchain architectures are weakest — and where this weakness is most frequently underestimated during initial evaluation.

Blockchain modifiability challenges include:

  • Immutable smart contracts — once deployed on most public blockchains, smart contract code cannot be changed. Upgradable proxy patterns exist but add complexity and introduce their own risks.
  • Schema rigidity — adding new fields to on-chain data structures often requires deploying new contracts and migrating data references.
  • Protocol dependency — changes to the underlying blockchain protocol can break applications. Hard forks may require choosing sides.
  • Multi-party coordination — in consortium networks, any change requires agreement from all (or a majority of) participants, introducing governance delay.
  • Audit cost of changes — every smart contract modification requires re-auditing, adding \(50K-\)200K per significant change.

By contrast, centralized database systems offer:

  • Standard schema migration tools (ALTER TABLE, data migration scripts)
  • Rolling deployment with zero-downtime updates
  • Single-party decision authority for changes
  • Mature version control and rollback procedures

A modifiability quality attribute scenario:

The product team (source) needs to add a new compliance data field to all transaction records (stimulus) in the smart contract / database schema (artifact) during a planned maintenance window (environment). The team implements, tests, and deploys the change (response) within 5 business days at a cost of under $15,000 (response measure).

Comparative evaluation:

  • Public blockchain: Likely requires new contract deployment, data migration strategy, front-end updates, and security audit. Timeline: 2-8 weeks. Cost: \(50K-\)150K.
  • Private blockchain: Chaincode upgrade with channel approval. Timeline: 1-3 weeks. Cost: \(15K-\)50K.
  • Centralized database: Schema migration, API update, deployment. Timeline: 1-5 days. Cost: \(2K-\)10K.

This comparison reveals modifiability as a major tradeoff point: the immutability that makes blockchain valuable for data integrity makes it expensive for system evolution.

Maintainability

Maintainability measures the ease and cost of keeping a system operational over its full lifecycle, including bug fixes, performance tuning, infrastructure updates, and knowledge transfer between team members. Maintainability differs from modifiability in that it focuses on sustaining current functionality rather than adding new capabilities.

Maintainability concerns for blockchain architectures include:

  • Node software updates — keeping blockchain node software current across all participants in a consortium
  • Monitoring complexity — monitoring a distributed network is inherently more complex than monitoring a single server or cluster
  • Incident response — diagnosing and resolving issues in a distributed system requires expertise that is scarce and expensive
  • Documentation and knowledge management — smart contract code, deployment configurations, and consensus parameters must be documented for operational continuity
  • Team turnover — replacing team members with blockchain-specific expertise is harder and more expensive than replacing team members with traditional database skills

The maintainability cost differential between blockchain and traditional architectures tends to widen over time. In year one, when the development team is intact and the technology is fresh, maintainability costs may be comparable. By year three, as team members leave, the technology landscape shifts, and accumulated technical debt compounds, blockchain systems often require significantly higher maintenance investment.

A useful maintainability metric is the maintenance cost ratio — the annual maintenance cost as a percentage of initial development cost:

Architecture Typical Maintenance Cost Ratio Notes
Centralized database 15-20% annually Mature tooling, large talent pool
Private blockchain 25-40% annually Specialized skills, audit requirements
Public blockchain integration 20-35% annually Platform changes may force updates
Consortium blockchain 30-50% annually Governance overhead adds to maintenance

Stakeholder Buy-In

Stakeholder buy-in is the degree to which all affected parties accept, support, and commit to an architecture decision. In trust technology evaluations, buy-in is particularly challenging because the decision often spans organizational boundaries and affects parties with conflicting interests.

Achieving stakeholder buy-in for an evidence-based architecture recommendation requires:

Transparent methodology — stakeholders who understand the ATAM process and participated in utility tree construction are more likely to accept the results, even if the recommended architecture differs from their initial preference. The methodology provides a shared language and a documented rationale.

Acknowledging tradeoffs — presenting the recommended architecture as "better in all respects" destroys credibility. Every architecture has weaknesses. Explicitly documenting the tradeoffs in the recommended architecture — and explaining why the prioritized quality attributes justify those tradeoffs — builds trust in the analysis.

Addressing emotional investment — stakeholders who have publicly advocated for blockchain (or against it) may resist evidence that contradicts their position. The ATAM output should be framed as "here is what the analysis shows" rather than "here is why you were wrong." Preserving face enables changed minds.

Phased commitment — rather than demanding an all-or-nothing architecture decision, propose a phased approach: proof of concept with clear success criteria, followed by pilot with defined metrics, followed by production rollout with exit criteria. This reduces the perceived risk of the decision and gives skeptics a structured way to validate (or challenge) the recommendation.

A stakeholder buy-in checklist:

  • All identified stakeholders participated in or reviewed the utility tree
  • Risk analysis was conducted for all candidate architectures, not just the recommended one
  • The cost analysis includes all architectures with equivalent rigor
  • Tradeoff points are documented with explicit rationale for the chosen priority
  • The recommendation includes a phased implementation plan with go/no-go criteria
  • Exit criteria are defined in case the chosen architecture fails to meet expectations

Rex's Tip

Rex shares a tip The most common reason architecture recommendations fail is not technical — it is political. A technically superior recommendation that key stakeholders do not support will be undermined, starved of resources, or overridden. Invest as much effort in stakeholder engagement as in technical analysis. The best architecture decision is one that is both evidence-based and organizationally viable.

Diagram: Risk Theme Heat Map

Interactive Risk Theme Heat Map for Trust Architecture Comparison

Type: MicroSim sim-id: risk-theme-heatmap
Library: p5.js
Status: Specified

Learning objective: Analyze (L4) — Compare risk profiles across blockchain and traditional architectures by mapping identified risks to risk themes and visualizing their severity in a heat map format.

Description: An interactive heat map with risk themes as rows (Immutability as Liability, Governance Fragility, Expertise Concentration, Single Point of Compromise, Opacity and Audit Resistance, Regulatory Uncertainty) and candidate architectures as columns (Public Blockchain, Private Blockchain, Consortium Blockchain, Centralized Database). Each cell is color-coded from green (low risk) to yellow (medium) to red (high risk). Clicking a cell reveals a panel listing the specific individual risks that contribute to that theme-architecture combination, along with recommended mitigation strategies. A summary row at the bottom shows an overall risk score for each architecture. Students can adjust individual cell ratings to explore how different risk assessments change the overall comparison.

Canvas: Responsive width, 550px height. Background: aliceblue.

Controls:

  • Click any cell to see detailed risk breakdown
  • Select dropdown: "Weight by Likelihood" or "Weight by Impact" or "Weight by Expected Value"
  • Button: "Reset to Defaults"
  • Checkbox: "Show Mitigation Costs"

Visual elements:

  • Heat map grid with color-coded cells (green/yellow/orange/red)
  • Row and column headers with clear labels
  • Detail panel showing individual risks and mitigations
  • Summary row with weighted risk scores
  • Legend showing color-to-risk-level mapping

Implementation: p5.js with responsive canvas, grid rendering, click-to-reveal panels

Diagram: Quality Attribute Radar Chart

Quality Attribute Comparison Radar Chart

Type: Diagram sim-id: quality-attribute-radar
Library: p5.js
Status: Specified

Learning objective: Evaluate (L5) — Visually compare how different trust architectures perform across multiple quality attributes simultaneously, identifying where each architecture excels and where it falls short.

Description: A radar (spider) chart with 7 axes representing quality attributes: Security, Availability, Reliability, Performance, Modifiability, Maintainability, and Cost Efficiency. Three overlaid polygons represent three candidate architectures: Public Blockchain (blue), Consortium Blockchain (orange), and Centralized Database (green). Each polygon's vertices show the architecture's rating (1-5) on each attribute. Checkboxes allow toggling each architecture's polygon on/off for cleaner comparison. Hovering over a vertex shows a tooltip with the specific rating rationale. A "Customize" mode allows students to adjust ratings based on their own analysis and see how the polygons change.

Canvas: Responsive width, 550px height. Background: aliceblue.

Controls:

  • Checkbox: Show/hide each architecture polygon
  • Button: "Customize Ratings" to enter edit mode
  • Sliders (in edit mode): adjust each attribute rating (1-5) per architecture
  • Button: "Reset to Defaults"

Visual elements:

  • Radar chart with 7 labeled axes
  • Three color-coded polygons with semi-transparent fill
  • Axis labels at each spoke endpoint
  • Tooltips on vertex hover
  • Legend identifying each architecture
  • Rating values displayed at each vertex

Implementation: p5.js with responsive canvas, polar coordinate rendering, hover detection

Key Takeaways

This chapter extended ATAM with risk analysis and deep quality attribute evaluation:

  • Architecture risks are embedded in design decisions and cannot be fixed without changing the architecture — they must be identified before commitment
  • Risk identification should use multiple techniques (scenario-based, checklist-based, analogy-based, assumption-based) to achieve comprehensive coverage
  • Risk themes reveal systemic architecture weaknesses by grouping related individual risks — blockchain themes include immutability-as-liability, governance fragility, and expertise concentration
  • Risk mitigation strategies (avoidance, reduction, transfer, acceptance) must be costed and included in the TCO model
  • Stakeholder analysis maps the interests, concerns, and influence of all parties affected by the architecture decision
  • Non-functional requirements are the primary discriminators between candidate trust architectures — systems with identical functionality can require fundamentally different architectures based on NFRs
  • Security in blockchain is strong for integrity and transparency but has specific weaknesses in smart contracts, key management, and cross-system interactions
  • Availability and reliability require nuanced comparison — headline network uptime figures can mask application-level availability problems
  • Modifiability is typically blockchain's weakest quality attribute, with change costs 5-15x higher than centralized alternatives
  • Maintainability costs for blockchain architectures tend to escalate over time due to specialized skill requirements and governance overhead
  • Stakeholder buy-in requires transparent methodology, acknowledged tradeoffs, and phased commitment — technical correctness alone is insufficient

Exceptional Progress!

Rex celebrates You now have the complete analytical toolkit: cost analysis, architecture tradeoff evaluation, risk assessment, and quality attribute comparison. But even the best analytical tools can be undermined by the biases in the analysts' own thinking. In the next chapter, we examine the cognitive biases that systematically distort technology decisions — and how to defend against them. Stay sharp, fellow analyst!