| Audience: | CIOs 🞄 CTOs 🞄 VP IT Operations |
| Primary Sectors: | Financial Services 🞄 Healthcare Systems 🞄 Government/Public Sector |
| Decision Horizon: | Next material application release, resilience investment decision, or service-contract renewal |
Executive Summary
A critical transaction can fail when a lower-priority service becomes unavailable. That failure establishes a technical dependency, but does not establish whether the business actually needs the service to complete the transaction.
Two different problems can produce the same result. An essential dependency may be incorrectly classified and inadequately protected. Alternatively, an unnecessary dependency may prevent a transaction that could otherwise continue safely. The first requires appropriate protection; the second requires architectural correction.
CIOs should mandate a business-necessity decision whenever a lower-priority service is found capable of stopping a critical transaction. That decision must precede permanent resilience upgrades or acceptance of the existing failure dependency. Temporary protection may be justified when immediate redesign is impractical, provided its costs, risks, and exit conditions are explicit.
Our Analysis
Service criticality, technical dependence, and business necessity are related but different concepts. Confusing them can leave critical transactions exposed while directing resilience expenditure toward preserving unnecessary architectural constraints.
The Narrative vs The Reality
Resilience management commonly classifies services by importance, establishes recovery objectives, and tests whether applications withstand dependency failures. Cloud platforms increasingly support automated testing against configured service-health and business-transaction criteria.1 The difficulty is determining what those results establish about the legitimacy of a dependency.
1. A technical dependency is not proof of business necessity. A transaction may fail because application code treats a downstream response as mandatory, even though the business outcome does not require it. Conversely, a service labelled noncritical may provide an indispensable function for a particular transaction.
Service classification alone cannot resolve either case. The question is whether the dependency supplies functionality essential to an authorized business outcome or whether the current implementation merely makes it appear essential.
2. Test success depends on the business criteria selected. AWS's October 2026 resilience-testing guidance recommends success criteria reflecting service health and customer experience. Its illustrative test blocks payment-gateway and notification services while application-health and end-to-end order-flow alarms remain normal.1
The example does not specify how payment status was validated. This is not an inherent limitation of AWS's testing capability, which can incorporate business-outcome measures. Rather, a passing result demonstrates that the configured criteria were met, not necessarily that every relevant business obligation was satisfied.
An order legitimately awaiting payment authorization is different from one incorrectly recorded as paid. Both might leave an application responding, but only the former may be an acceptable business outcome.
3. The same observed failure can require different remedies.
Uber's 2026 USENIX research identified 4,155 fail-close dependency violations through runtime and static analysis across different reliability classes. Its engineers used code-level isolation, service redesign, and promotion to higher reliability classes to address these problems. Approximately 200 previously lower-priority services were reclassified.2
These findings demonstrate different engineering remedies for unsafe cross-tier dependencies. They do not establish that every detected violation represented unnecessary business functionality or that every reclassified service was indispensable to a business transaction.
4. Architectural correctness and economic practicality are not always immediate companions. Removing an unnecessary failure dependency may require expensive redesign, complex testing, or a prolonged transition. Temporarily strengthening that dependency can therefore be reasonable. Uber's programme required substantial engineering resources and a phased rollout, illustrating that architectural remediation has costs and implementation risks of its own.2
The mistake is not necessarily funding interim protection. It is allowing that protection to become a permanent substitute for resolving whether the dependency should continue to exist.
The Signal in the Noise
A technically successful resilience programme can still protect more infrastructure than the business actually requires.
What Changes the Decision
When failure testing exposes a dependency affecting a critical transaction, the business process owner must establish the minimum acceptable outcome before the organization decides how to protect or redesign the dependency.
If its functionality is essential and no approved alternative exists, appropriate resilience protection is warranted. If the transaction can legitimately continue without it, failure isolation should be the default architectural response. The CIO may authorize temporary protection when immediate remediation is unjustified, but only through a costed exception with an explicit exit decision.
Why This Matters Now
AWS's October 2026 resilience-testing capability illustrates how automated dependency discovery and fault injection can make technical failure evidence easier to obtain.¹ However, that evidence cannot independently establish which business outcomes are acceptable. The distinction affects whether organizations strengthen, isolate, or redesign dependencies.
In financial services, unavailable payment authorization may require a transaction to remain pending rather than completed. In healthcare, clinical activity must not proceed as though essential patient information or safety checks were successfully obtained. In government, a valid citizen submission may continue without immediate notification, provided acceptance, recordkeeping, and receipt obligations remain satisfied.
What to Watch for Next
New synchronous dependencies introduced during modernization deserve scrutiny, especially when they connect critical transactions to lower-priority or external services. Resilience reports showing technical recovery without evidence of valid business outcomes should trigger a review of the acceptance criteria.
Recommended Actions
Do This
1. Require a business-necessity ruling when a dependency affects a critical transaction.Trigger this decision when a critical transaction fails during dependency isolation, a material release introduces a new cross-tier dependency, or additional resilience funding is proposed.
- Record whether the dependency is essential to valid completion, unnecessary but technically coupled, or unresolved. The business process owner defines acceptable normal and degraded outcomes; Enterprise Architecture determines the technical options; Risk or Compliance validates mandatory controls.
- Where necessity remains unresolved, existing protections must not be reduced. If available evidence indicates that those protections may be inadequate for the critical transaction, the CIO must authorize an interim disposition, temporary protection, an approved alternative operating mode, or restricted operation, pending the business-necessity ruling.
2. Make valid business outcomes part of resilience acceptance. Before releasing changes to critical transaction paths, test both explicit dependency errors and services that stop responding. Validate the resulting business state, including authorization, completeness, data integrity, permitted deferral, and any obligations that must be completed after service restoration.
- A service designated nonessential should not cause the transaction to breach its approved degraded-mode objective. The business process owner must approve the acceptance criteria, while Security, Risk, or Compliance confirms that mandatory controls remain effective. Any workaround that creates an unauthorized, misleading, or irrecoverably incomplete transaction must fail acceptance.
3. Separate permanent resilience investment from temporary architectural protection.At a proposed service-tier upgrade, material resilience investment, or relevant contract renewal, require a documented comparison of strengthening the dependency against isolating or removing it.
- Fund permanent protection where business necessity is established. Where unnecessary coupling remains, approve temporary protection only when the costs, timing, or risks of immediate redesign justify it.
- The exception must identify its incremental cost, accepted risk, accountable owner, remediation milestone, and expiry condition. At that milestone or the next relevant renewal, whichever occurs first, the CIO must authorize architectural correction, approve a newly justified time-limited exception, or restrict the affected transaction until an acceptable solution is available. Temporary protection must not renew automatically.
Avoid This
- Automatically elevating every service implicated in a critical transaction failure. Doing so may increase recovery obligations and recurring costs while retaining an avoidable failure path.
- Treating graceful degradation as permission to bypass mandatory controls. Authorization and other security controls must fail securely; financial integrity, clinical safety, and statutory requirements must also remain satisfied.3
- Using technical test success as final business acceptance. A healthy application can still produce an incomplete, invalid, or misleading transaction outcome, including when deferred obligations are silently lost.
Bottom Line
A critical transaction does not make every service it depends on critical. Establish which functions the business genuinely requires, then decide which dependencies to protect, which to isolate, and which merit temporary protection while the architecture is corrected.
Evidence and Sources
- Moran, Jennifer, and Imran Sadiq. 2026. “Recommended Resilience Testing in the Next Generation of AWS Resilience Hub.”AWS Architecture Blog, October 26.
- Bansal, Mayank, et al. 2026. “Uber's Failover Architecture: Reconciling Reliability and Efficiency in Hyperscale Microservice Infrastructure.”23rd USENIX Symposium on Networked Systems Design and Implementation, May 4–6.
- Waller, Daniel. n.d. “Fail Securely.”OWASP Foundation.