# arc42 section 11: Risks and Technical Debts

Checks for section 11 (Risks and Technical Debts) of an arc42 document.

Known risks and technical debt

- A target stack per area is defined, with justified exceptions. → [Application Landscape Evolution Drivers](https://arc.fuet.ch/concepts/enterprise-architecture/patterns-for-the-evolution-of-application-landscapes.md)
- Each application appears as one bar on a shared timeline with a labeled planned end date. → [Application Lifecycle Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-lifecycle-diagram.md)
- Applications nearing end of life without a planned successor are identified. → [Application Lifecycle Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-lifecycle-diagram.md)
- The meaning of each color is explicit, and the underlying scores are available. → [Capability Heat Map](https://arc.fuet.ch/concepts/enterprise-architecture/capability-heat-map.md)
- Prioritization does not give mature and embryonic practices the same emphasis. → [Gartner Hype Cycle for Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/gartner-hype-cycle-for-enterprise-architecture.md)
- Component end dates are compared with the end dates of the applications that rely on them. → [IT Component Catalogue](https://arc.fuet.ch/concepts/enterprise-architecture/it-component-catalogue.md)
- The number of point-to-point interfaces between systems is known and kept under control. → [Warning Signs of Poor Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/warning-signs-of-poor-enterprise-architecture.md)
- For a legacy system, the architecture was recovered before the analysis, and the documentation was not simply trusted. → [ATAM Application Phases](https://arc.fuet.ch/concepts/evaluation/atam-application-phases.md)
- Team roles are assigned: evaluation leader, scribes, timekeeper and questioners. → [ATAM Evaluation Team and Stakeholder Selection](https://arc.fuet.ch/concepts/evaluation/atam-evaluation-team-and-stakeholder-selection.md)
- Individual risks are grouped into risk themes, and each theme names the business driver it threatens. → [ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points](https://arc.fuet.ch/concepts/evaluation/atam-findings-risks-non-risks-sensitivity-points-and-trade-offs.md)
- The evaluation report lists non-risks next to risks, sensitivity points and trade-off points, organized by quality attribute. → [ATAM Non-Risk](https://arc.fuet.ch/concepts/evaluation/atam-non-risk.md)
- The review team, the project team and stakeholder representatives all take part. → [ATAM Phase 1 and 2 Activities](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-and-2-activities.md)
- The evaluation plan states that the evaluation leader describes the evaluation method to all participants at the start. → [ATAM Phase 1: Architecture-centric Analysis](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-architecture-centric-analysis.md)
- The plan allows for about three to four days in total for the evaluation. → [ATAM Phase 1: Architecture-centric Analysis](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-architecture-centric-analysis.md)
- The results record risks, sensitivity points and tradeoff points found during approach analysis. → [ATAM Results](https://arc.fuet.ch/concepts/evaluation/atam-results.md)
- The decision-makers taking part have authority to mandate architectural changes. → [ATAM Roles](https://arc.fuet.ch/concepts/evaluation/atam-roles.md)
- The team considered reusing recorded scenarios or a lighter method to reduce evaluation cost. → [Advantages and Drawbacks of ATAM](https://arc.fuet.ch/concepts/evaluation/advantages-and-drawbacks-of-atam.md)
- Each record lists all consequences, including negative ones. → [Architectural Decision Records as Evaluation Prerequisite](https://arc.fuet.ch/concepts/evaluation/architectural-decision-records-as-evaluation-prerequisite.md)
- The documented evaluation lists the architectural risks found and states which business goals they could threaten. → [Architecture Tradeoff Analysis Method (ATAM)](https://arc.fuet.ch/concepts/evaluation/architecture-tradeoff-analysis-method-atam.md)
- Each risk in the evaluation is stated as an architectural decision that may lead to undesirable consequences. → [Battlefield Control System ATAM Case Study](https://arc.fuet.ch/concepts/evaluation/battlefield-control-system-atam-case-study.md)
- Each trade-off point names the quality attributes in tension, such as reliability and performance. → [Battlefield Control System ATAM Case Study](https://arc.fuet.ch/concepts/evaluation/battlefield-control-system-atam-case-study.md)
- The documentation names how code smells are detected, for example through static analysis tools that report complexity metrics. → [Code Smell](https://arc.fuet.ch/concepts/evaluation/code-smell.md)
- Known smells such as overly long methods or large classes are tracked, with refactoring planned for them. → [Code Smell](https://arc.fuet.ch/concepts/evaluation/code-smell.md)
- Internal-quality problems found through smells are recorded as technical debt. → [Code Smell](https://arc.fuet.ch/concepts/evaluation/code-smell.md)
- Each sensitivity point names the decision and the quality attribute that reacts strongly to a small change. → [Insufficient ATAM Application](https://arc.fuet.ch/concepts/evaluation/insufficient-atam-application.md)
- The document records who ran the lightweight review: external parties, the team, or both. → [Lightweight ATAM](https://arc.fuet.ch/concepts/evaluation/lightweight-atam.md)
- The review names the most significant risks against those objectives. → [Lightweight Approach for Software Reviews (LASR)](https://arc.fuet.ch/concepts/evaluation/lightweight-approach-for-software-reviews-lasr.md)
- Section 11 is titled as an ATAM evaluation, and its subsections separate risks, sensitivity points and trade-off points. → [Placing ATAM Evaluation in arc42](https://arc.fuet.ch/concepts/evaluation/placing-atam-evaluation-in-arc42.md)
- Each risk finding is tied to a business driver or quality goal, for example through a risk theme. → [Placing ATAM Evaluation in arc42](https://arc.fuet.ch/concepts/evaluation/placing-atam-evaluation-in-arc42.md)
- Findings name the stakeholders who were involved in identifying them. → [Placing ATAM Evaluation in arc42](https://arc.fuet.ch/concepts/evaluation/placing-atam-evaluation-in-arc42.md)
- Each identified risk has a probability and an impact rating, on a low/medium/high or numeric scale. → [Risk Storming](https://arc.fuet.ch/concepts/evaluation/risk-storming.md)
- The risk list is ordered by priority. → [Risk Storming](https://arc.fuet.ch/concepts/evaluation/risk-storming.md)
- Each high-priority risk has a mitigation measure, with tasks assigned and scheduled. → [Risk Storming](https://arc.fuet.ch/concepts/evaluation/risk-storming.md)
- Properties that affect more than one quality attribute are identified as trade-off points. → [Sensitivity Point](https://arc.fuet.ch/concepts/evaluation/sensitivity-point.md)
- Scenarios are prioritized, for example by likelihood and criticality. → [Software Architecture Analysis Method (SAAM)](https://arc.fuet.ch/concepts/evaluation/software-architecture-analysis-method-saam.md)
- The document states when the architecture was evaluated and whether the evaluation worked from models or from code. → [Software Architecture Evaluation](https://arc.fuet.ch/concepts/evaluation/software-architecture-evaluation.md)
- Known technical debts are listed in the risks and technical debts section, ordered by priority. → [Technical Debt](https://arc.fuet.ch/concepts/evaluation/technical-debt.md)
- Each deliberate debt is marked as knowingly accepted, with a plan to repay it (for example by refactoring). → [Technical Debt](https://arc.fuet.ch/concepts/evaluation/technical-debt.md)
- Debt in architecture and design is covered, not only code-level debt. → [Technical Debt](https://arc.fuet.ch/concepts/evaluation/technical-debt.md)
- The recorded consequences list negative effects as well as positive ones. → [Trade-off Point](https://arc.fuet.ch/concepts/evaluation/trade-off-point.md)
- Alternatives listed in an ADR are real options, not filler added to satisfy a template. → [Architectural Decision Management](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-practices.md)
- Hard-to-reverse decisions, such as the integration style, are explicitly identified as significant. → [Architecturally Significant Decision](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-decision.md)
- Ideas and approaches are documented after they proved useful. → [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)
- Dependencies between architectural items are made visible, not assumed away. → [INVEST Applied to Architectural Work](https://arc.fuet.ch/concepts/functional-requirements/invest-applied-to-architectural-work.md)
- The customer representatives are named, and the document states whether they represent the wider customer side. → [Requirements Difficulty and Customer Engagement](https://arc.fuet.ch/concepts/functional-requirements/requirements-difficulty-and-customer-engagement.md)
- The document describes how the structure is protected against erosion from quick fixes and piecemeal growth. → [Accidental Architecture](https://arc.fuet.ch/concepts/fundamentals/unsystematic-accidental-architecture.md)
- The document shows some deliberate design effort rather than only ad-hoc tactical decisions. → [Agile Architecture](https://arc.fuet.ch/concepts/fundamentals/agile-architecture.md)
- The document states how divergence between the intended and implemented architecture is detected, for example through conformance checking. → [Architecture Decay](https://arc.fuet.ch/concepts/fundamentals/architecture-decay.md)
- The document names refactoring as the way the team counters structural decay. → [Architecture Decay](https://arc.fuet.ch/concepts/fundamentals/architecture-decay.md)
- Throwaway code is either removed or deliberately kept and documented, not left in the system by accident. → [Big Ball of Mud](https://arc.fuet.ch/concepts/fundamentals/big-ball-of-mud.md)
- Blighted areas of code are identified and cordoned off. → [Big Ball of Mud](https://arc.fuet.ch/concepts/fundamentals/big-ball-of-mud.md)
- The document states the intended architecture, so it can be compared with the implemented one. → [Implicit Architecture](https://arc.fuet.ch/concepts/fundamentals/architecture-facts-and-challenges.md)
- There is a process or tool to keep the architecture description in step with code changes. → [Implicit Architecture](https://arc.fuet.ch/concepts/fundamentals/architecture-facts-and-challenges.md)
- Refactoring and consolidation are planned as ongoing work, not left for later. → [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md)
- Changes that break the running system are rejected immediately, for example through regular builds. → [Keep It Working](https://arc.fuet.ch/concepts/fundamentals/keep-it-working.md)
- Refactoring is done continuously to prevent design decay. → [Refactoring](https://arc.fuet.ch/concepts/fundamentals/refactoring.md)
- Boundaries around the messy code start where coupling is lowest. → [Sweeping It Under the Rug](https://arc.fuet.ch/concepts/fundamentals/sweeping-it-under-the-rug.md)
- The DLQ retention period is longer than the source queue's retention period. → [Dead Letter Channel](https://arc.fuet.ch/concepts/integration/dead-letter-channel.md)
- Rejected messages carry error metadata such as a reason and description. → [Invalid Message Channel](https://arc.fuet.ch/concepts/integration/invalid-message-channel.md)
- If transactions span widely distributed systems, the document discusses the performance cost. → [Transactional Client](https://arc.fuet.ch/concepts/integration/transactional-client.md)
- Prototypes, if used, are labeled as learning tools and not treated as final designs. → [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md)
- Components in the zone of pain (low I and low A) are named, and their position is explained or accepted. → [Main Sequence (Balance of Abstractness and Instability)](https://arc.fuet.ch/concepts/principles/main-sequence.md)
- An as-is process model exists and was reviewed for improvement opportunities. → [Process Automation Magnifies Efficiency](https://arc.fuet.ch/concepts/principles/process-automation-magnifies-efficiency.md)
- The document names how faults are detected, for example through monitoring and alerting. → [Fault](https://arc.fuet.ch/concepts/quality-attributes/fault.md)
- The design addresses alarm flood during upsets. → [Hazard Warning](https://arc.fuet.ch/concepts/quality-attributes/hazard-warning.md)
- Operational constraint is described separately from fail safe, hazard warning, risk identification and safe integration. → [Operational Constraint](https://arc.fuet.ch/concepts/quality-attributes/operational-constraint.md)
- The document says how equivalence of a replacement candidate will be established, for example by running an evaluation suite, rather than assuming it from interface compatibility. → [Replaceability](https://arc.fuet.ch/concepts/quality-attributes/replaceability.md)
- Access is authenticated, authorized, and minimized by privilege, scope, and time. → [Resistance](https://arc.fuet.ch/concepts/quality-attributes/resistance.md)
- Safety expectations are stated for both the integration moment and the system after integration. → [Risk Identification and Safe Integration](https://arc.fuet.ch/concepts/quality-attributes/risk-identification.md)