FreightTrack: Evaluation Before a Rewrite-or-Evolve Decision
FreightTrack is an eight-year-old logistics platform with 4.2 million lines of code, 310 services and batch jobs, and a deployment pipeline that takes nine hours with manual approval gates. Production incidents rose 40% year over year, and 11% of defects escape to production. Two of the four engineers who understand the route-optimization module are retiring within six months. The underlying application server reaches vendor end-of-support in 14 months. A rewrite is estimated at 18 months and €8 million; incremental evolution at €2 million over the same period. Business volume is growing 20% annually and the peak season is in nine months. The CIO has requested an architecture evaluation before committing funds. There is no current architecture description, but there are 60 microservice README files of varying quality and a 2019 deployment diagram.
1. Design an architecture evaluation for FreightTrack. State the method, stakeholders, scenarios, evidence, and outputs, and explain how you would avoid a decision driven only by cost.
Read the worked answer
Method
Use a structured scenario-based evaluation in the ATAM tradition, run over three to five workshops. Establish business drivers, elicit quality-attribute scenarios, present the architecture, build a utility tree, and identify risks, non-risks, sensitivity points, and trade-off points. The evaluation is not an audit of documents; it is a structured interrogation of decisions.
Stakeholders
Include dispatch operations, finance, security, platform operations, the route-optimization maintainers, and the CIO. Add the vendor support owner for the end-of-support application server.
Scenarios
Cover peak-season throughput, deployment lead time, recovery from a route-optimization failure, onboarding a new maintainer, vendor end-of-support migration, and auditability of route changes. Prioritize by business impact and difficulty.
Evidence
Use incident data, defect escape rate, deployment logs, static analysis, dependency graphs, vendor notices, interviews, and the existing READMEs as weak evidence to be verified. Do not treat the 2019 diagram as current.
Avoid cost-only reasoning
Weight scenarios by business impact and risk exposure, not just estimated cost. Include the cost of inaction: continued incidents, lost peak-season volume, and vendor unsupported risk. Include option value and reversibility. Present a risk-adjusted comparison, not a single number.
Outputs
A risk register, a sensitivity and trade-off list, a recommendation with conditions, and a roadmap. The CIO should see which risks are reduced by each option and what evidence would change the decision.
2. Define measurable maintainability and operability criteria that would let you compare rewrite and evolution. Explain how each would be collected.
Read the worked answer
Maintainability criteria
- Change lead time for representative changes, collected from ticketing and version control.
- Defect escape rate and escaped-defect severity, collected from production incident records.
- Cyclomatic complexity and duplication hotspots in route optimization and integration code, collected through static analysis.
- Coupling and fan-out of the 310 services, collected through dependency extraction.
- Test coverage on critical paths and the time to run the regression suite, collected from CI.
- Bus factor and onboarding time, collected through interviews and skills matrices.
Operability criteria
- Deployment frequency and deployment lead time, collected from the pipeline.
- Change failure rate and mean time to restore, collected from incident and deployment data.
- Batch window adherence and peak throughput headroom, collected from monitoring.
- Mean time to diagnose a failed route calculation, collected through incident walkthroughs.
- Percentage of services with current runbooks and owners, collected through a documentation audit.
Comparison rules
Baseline the current system before choosing. Set target thresholds for each option and state how long after cutover they will be measured. Distinguish leading indicators, such as test runtime and dependency fan-out, from lagging indicators, such as incident rate.
Avoid
Do not use lines of code or number of services as quality measures. They describe size, not maintainability. A smaller rewrite can still be hard to change if ownership and tests are weak.
3. Given the evidence, what decision framework and risk mitigations would you recommend to the CIO?
Read the worked answer
Hard constraints first
The vendor end-of-support is 14 months away and peak season is in nine months. An 18-month rewrite cannot satisfy either deadline without a parallel run and a risky cutover. The bus factor of two retiring engineers is an immediate risk regardless of option.
Decision framework
Score both options against time to regulatory and vendor compliance, peak-season readiness, risk-adjusted cost, maintainability improvement, and reversibility. Evolution costs €2 million but may not remove the core problem; rewrite costs €8 million and carries delivery risk. Include the cost of inaction and the probability of slippage.
Recommendation
Recommend evolution with funded modernization: replace the unsupported application server, use a strangler approach for route optimization, and retire the highest-risk components first. This meets the vendor deadline and protects peak season. Start a small rewrite spike only for a bounded capability if it can prove value within the peak-season window.
Mitigations
- Knowledge capture: pair the retiring engineers with successors, record decision rationale, and run joint incident drills.
- Contract tests and feature flags to allow staged cutover.
- Parallel run for route optimization with reconciliation checks.
- Monthly risk review against thresholds; if change failure rate or defect escape does not improve, revisit the strategy.
Decision rule
Do not choose a rewrite because the code is old. Choose it only if evidence shows evolution cannot meet the hard deadlines or the risk thresholds. Record the decision and the conditions that would trigger a revisit.