arc42 section 11: Risks and Technical Debts

Known risks and technical debt

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