How should EA governance checkpoints be placed across the SDLC and tied into project portfolio management (PPM) funding gates, and what goes wrong when the gate is placed too early or too late?

## Why the gate is where the power is Linking EA governance to the SDLC and to **project portfolio management (PPM)** is what converts architecture principles from aspirational guidance into something with actual enforcement power. Both already have gates of their own: | Process | The gates it already has | |---|---| | **PPM** - the discipline of managing a portfolio of projects as investments, deciding what gets funded, sequenced, and continued - naturally has **stage gates** | business case approval, funding release, phase transitions, go/no-go decisions | | **The SDLC** has its own **phase gates** | requirements/design complete, code complete, pre-production, go-live | The core governance design decision is which of these gates an architecture review outcome gets attached to, because a review with no gate attached is advisory, and advisory reviews get skipped under deadline pressure. Attaching review to a gate means the gate literally cannot be passed without a recorded governance outcome, which is what gives the process real teeth. ## Where the touchpoints sit The mechanism for placement typically follows a **two-touchpoint pattern**, because a single gate can't serve both purposes well. 1. **An early touchpoint** sits at or near business case / funding approval, before detailed design exists - its job is directional: is this initiative broadly aligned with the target-state architecture, does it duplicate an existing capability, is it choosing a fundamentally disallowed technology. This check has to stay lightweight because there's little concrete design to evaluate yet; asking hard implementation-level questions here just produces speculative answers. 2. **A second, fuller touchpoint** sits later, typically at design-complete or before major build-phase funding is released - by this point there's an actual solution design, integration approach, and data model to check against principles and reference architectures in real detail, and this is where most of the substantive review work happens. 3. **A third, continuous layer**: increasingly, mature organizations add automated 'fitness functions' or policy-as-code checks embedded in CI/CD that catch drift between the scheduled gates, so governance isn't purely a point-in-time event. ## The trade-off in placement The trade-off in gate placement is fundamentally about when architectural cost commitment happens versus when governance has enough information to give a meaningful answer. - **Too early** - placing the primary review before any real design exists - forces teams to produce a design document purely to satisfy the review, often written after the fact to describe decisions the team was going to make anyway; this produces **paper compliance**, where the artifact reviewed doesn't reflect what actually gets built. - **Too late** - placing the primary review say, immediately before go-live - is the more damaging failure, because by then the truly expensive architectural decisions are already implemented, tested, and often contractually or operationally locked in. A finding at that point has only two realistic outcomes: an expensive, schedule-threatening rework, or - far more commonly - a waiver, because nobody wants to blow the go-live date over an architecture finding discovered too late to act on cheaply. Late-gate governance therefore quietly converts into a **waiver-generation machine** rather than a design-quality mechanism, and it earns architecture governance a reputation as a rubber stamp exercised right before launch. ## Failure modes Failure modes cluster around gate placement and timing. - **'Gate too late'** shows up as go-live reviews with a spike in waiver requests clustered right at the end of delivery, because that's the only point at which governance actually looks - teams have had no earlier forcing function to build compliantly, so violations accumulate silently until the one moment someone checks. - **'Gate too early'** shows up as architecture documents that read as generic and templated, because they were written to satisfy a review rather than to actually describe an implementable design - the real design decisions get made later, off the record, once engineering starts. - **A third failure, 'gate disconnected from funding,'** happens when the SDLC has an architecture review step on paper but the PMO doesn't actually condition funding release or phase transition on its outcome - the review happens, generates a report, and the project proceeds regardless, because no one owns enforcing the linkage between the two processes. ## A concrete example A concrete example: a retailer's governance model requires a lightweight architecture screening at business-case approval (a one-page target-state alignment check, gating whether the initiative even gets funded for detailed design), a full design review before the PMO releases build-phase funding (gating the large majority of the budget), and continuous automated policy checks in the CI pipeline flagging drift for remediation before each production deployment - so the expensive commitment point (build funding) is exactly where the fullest scrutiny sits, and go-live is a low-drama confirmation that automated checks have stayed green rather than the first time anyone looks.