change-impact-analysis

Change Impact Analysis

Systematically analyze impacts of architectural changes to predict risk and plan safe rollout.

Context

You are analyzing impact of a major change. Trace affected systems, identify risks, plan mitigation. Read current dependency graph, deployment practices, system health metrics.

Domain Context

Based on change management and impact analysis frameworks:

• Direct Impact: System directly modified. Code changes, performance changes, behavior changes.
• Indirect Impact: Dependent systems affected. Database schema change affects clients. Service API change affects all callers. Message format change affects consumers.
• Risk Assessment: What could go wrong? Cascading failures? Data loss? Performance regression? Unavailability of critical path?
• Rollback Plan: If change goes wrong, can you revert quickly? What data consistency issues might occur?

Instructions

1. Trace Dependencies: What systems depend on the component you're changing? Use dependency graph tools (source analysis, API scanning). Interview teams.

2. Assess Direct Impact: For the component itself, what's changing? Behavior? Performance? Data model? How does change affect invariants, contracts, SLAs?

3. Assess Indirect Impact: For each dependent system, how does change affect it? Can they continue working with new interface? Will they need code changes? Testing?

4. Calculate Risk Score: How many systems affected? (x10 multiplier per additional system). How critical are those systems? (x5 for customer-facing, x2 for internal). Estimate blast radius.

5. Plan Mitigation: For high-risk changes, plan phased rollout (10% users, 50%, 100%). Parallel run (old and new simultaneously). Comprehensive testing and monitoring. Runbook for quick rollback.

Anti-Patterns

• Change Without Impact Analysis: Architect makes change unilaterally. Result: breaks production, cascading failures. Guard: Mandatory impact analysis before major changes; design review.
• Underestimating Blast Radius: Assume only 1-2 systems affected. Result: surprises. Guard: Systematic dependency tracing; interview teams; over-estimate.
• No Rollback Plan: Assume change succeeds. Result: stuck if it fails. Guard: Practice rollbacks; measure rollback time; have detailed procedure.
• Ignoring Monitoring: Make change, wait for problems to surface. Result: incidents. Guard: Comprehensive monitoring; metrics for correctness, performance, errors; alert on anomalies.

Further Reading

• The Phoenix Project by Gene Kim — change management and deployment discipline
• Release It! by Michael Nygard — failure modes and impact analysis
• Site Reliability Engineering by Google — safe change practices in production