Architecture assessment: what would justify a rewrite?

Name the decision the assessment must change

Suppose an order service becomes slow while large customer exports run. A product launch is approaching, and the team proposes replacing the service. The sponsor has to decide whether to fund that replacement, isolate the export workload, or investigate a narrower repair. This is a hypothetical assessment scenario, with no customer measurements behind it.

Bound the investigation to a decision: can order processing and exports meet their agreed service objectives within the current design and an acceptable operating cost? Name the workload, the deadline, and who can accept the tradeoffs. A general request to review the architecture leaves too much room for findings that do not change the investment.

Find the unknown that separates the options

The Software Engineering Institute's Architecture Tradeoff Analysis Method connects business drivers to scenarios and architectural decisions, then identifies risks and tradeoffs. That relationship is useful even when the engagement is smaller than a full ATAM evaluation: the scenario should explain why the sponsor needs a decision.

In the order-service example, both operations might compete for database capacity. They might instead wait for the same application connection pool. A new service that retains the limiting shared resource could inherit the delay. The investigation needs to locate the constraint before comparing implementation technologies.

Write a condition beside each option. Retain the design if evidence supports the agreed workload and operating limits. Fund a bounded repair if a specific intervention satisfies the objectives without introducing an unacceptable constraint elsewhere. Consider replacement when the evidence identifies a limitation that the evaluated repairs cannot meet, and the proposed replacement has a credible way to address it.

A failed repair experiment excludes the repair that was tested under those conditions. It does not establish that every repair is impossible. Record unexplored alternatives and why investigating them would or would not be worth the additional time.

Commission a test that can distinguish causes

Agree on the experiment before implementing the preferred solution. For this scenario, exercise orders alone, exports alone, and their overlap in an environment whose relevant limits are documented. Use representative synthetic or sanitized data. AWS's load-testing guidance recommends realistic workloads, a production-like environment, and comparison with predefined objectives.

Observe where requests spend their time: waiting for admission, waiting for a connection, executing database work, or doing application work. Preserve the workload's request mix and data distribution when comparing runs. A quiet database with a small uniform dataset may remove the contention the investigation needs to explain.

Try a bounded intervention against the proposed cause, such as limiting concurrent exports, while keeping the other test conditions comparable. Measure order completion and latency alongside export completion, backlog, and resource use. Faster orders obtained by indefinitely delaying exports would fail a contract that requires both to complete.

Retain the baseline and intervention results with their configuration and source revision. Repeat observations enough to distinguish a reproducible effect from an isolated run, and state what remains uncertain. This article proposes an experiment; it supplies no test result or universal workload threshold.

Let missing access limit the conclusion

A diagram can identify a shared database. It cannot establish how long requests wait inside it. If the assessment lacks the relevant traces, workload data, or a representative test environment, the conclusion should identify the missing observation and the decision it prevents.

Separate an observed finding from its explanation. An overlap between exports and slow orders is an observation; a shared connection limit is a hypothesis until evidence supports it. The recommendation can then be conditional: authorize the measurement or a bounded validation phase before committing to a replacement.

Time-box the investigation around that uncertainty. If the result would leave the same decision and scope unchanged, explain why the test is still needed. Some checks establish required integrity or recovery behavior; others may add detail without affecting the next commitment.

Compare the cost of operating the transition

A replacement proposal should include how existing clients continue working, which component owns writes during coexistence, and how the team will verify the replacement before cutover. These obligations belong in the comparison even when the new implementation is smaller or easier to maintain.

A local repair has operating consequences too. Export throttling can change completion deadlines. More database capacity can change cost. A separate read path can introduce freshness requirements. Test the consequence that matters to the agreed workload instead of treating the initial fix as the end of the decision.

Preserve the accepted reasoning in a decision record. Google Cloud's architecture-decision guidance recommends recording context, requirements, alternatives, and the decision. Add the evidence and the condition that would reopen the choice so a later team can tell whether the original assumptions still apply.

Make the next commitment reviewable

The assessment should leave the sponsor with a bounded recommendation, supporting evidence, unresolved assumptions, and acceptance conditions for the next phase. Another engineering team should be able to inspect why a repair was selected or what justified a replacement.

In this scenario, the immediate purchase could be a short contention experiment, implementation of a demonstrated repair, or validation of a replacement boundary. The report should identify which one the evidence supports and which new finding would change that recommendation.