A project team can't meet a mandatory architecture principle before its go-live deadline. Walk through how an exception/waiver process should handle this so the deviation doesn't just get lost.

## What a waiver is An **exception** (often called a **waiver**) is the formal mechanism by which an EA governance process lets a project deviate from a mandatory architecture principle without that deviation being either invisible or permanent. The reason this mechanism has to exist at all is that architecture principles are written as general rules for the common case, and real projects regularly hit situations where literal compliance is genuinely not achievable in the available time or budget: - a legacy dependency that can't be replaced before a hard regulatory deadline - a vendor product that doesn't support the mandated integration pattern - a cost constraint that rules out the approved but expensive database If governance offers no legitimate way to proceed anyway, teams don't stop; they deviate silently, and the organization loses visibility into exactly the risk the principle existed to control. A working waiver process is therefore a **release valve** that keeps deviations visible and bounded rather than eliminating them, which is not actually the goal - accepted, tracked risk is the goal. ## The five parts of a working process Mechanically, a solid process has five parts. 1. **First, a structured request**: the team names the specific principle being violated (not a vague 'we're not fully compliant'), states the business or technical driver, and describes the concrete risk introduced. 2. **Second, review by someone with genuine authority** to say no and make it stick, which for higher-risk waivers (security, data residency, regulatory) usually means a co-sign from a risk or security function, not the architecture lead alone. 3. **Third, a compensating control** where one is available - if you can't isolate PII in the mandated way, maybe you can add monitoring or encryption that partially offsets the gap. 4. **Fourth, and this is the part organizations most often skip, a mandatory expiry date and a named, accountable owner** - a waiver with no expiry is a permanent exception in disguise, and a waiver with no owner is nobody's job to ever fix. 5. **Fifth, central logging in a waiver register** that is queried, not filed away - the same register that feeds compliance scoring, portfolio risk reporting, and a periodic review of which principles are generating the most exceptions. ## The trade-off The trade-off here is **rigor versus delivery velocity**, playing out at two different points. - **Too strict** a waiver process - heavy paperwork, slow multi-party sign-off, no fast path for genuinely low-risk deviations - pushes exactly the deadline-pressured teams who need the waiver most toward skipping the process altogether, defeating its purpose. - **Too loose** a process - self-service approval, no expiry enforcement, no real review of the risk statement - turns the waiver register into a paper trail with no teeth, and 'temporary' exceptions become permanent because nobody is ever forced to revisit them. The healthiest designs tier this like ARB review itself: low-risk, well-understood exceptions get fast, lightweight approval, while high-risk or novel exceptions get full scrutiny and senior sign-off. ## Failure modes Failure modes are recognizable and common. - **'Waiver debt' is the most frequent**: exceptions accumulate because expiry dates aren't enforced, remediation is never prioritized against feature work, and eventually the organization is running significant production risk that nobody currently owns because the original accountable owner has moved teams. This surfaces during audits or incidents as 'we had a waiver for this from three years ago and it was never followed up.' - **A second failure mode is waivers used as a substitute for fixing a bad principle**: if the same rule generates dozens of exception requests across many unrelated teams, that's a strong signal the principle itself doesn't fit current technology or business reality and should be revised - but if the governance process treats every waiver as an isolated one-off rather than aggregating this pattern, the principle never gets fixed and teams keep paying the tax of requesting the same exception repeatedly. - **A third failure is inconsistent approval authority** - if any architect can grant any waiver informally over chat, the register becomes incomplete and unreliable, and compliance scoring built on top of it is meaningless. ## A concrete scenario A concrete scenario: a fintech project needs to launch before a regulatory deadline but its chosen payments vendor doesn't yet support the mandated tokenization pattern for card data. The team requests a waiver naming that specific gap, proposes a compensating control (network-level segmentation and enhanced monitoring until the vendor ships support), gets security co-sign given the sensitivity of card data, and is granted a waiver with a hard six-month expiry tied to the vendor's committed release date and a named product owner accountable for tracking it. The waiver is logged, appears in the next quarterly compliance report as an open exception, and if the vendor slips, the team must return to request a renewal with updated justification rather than the waiver silently persisting.