TOGAF's ADM is often criticized as too heavyweight for fast-moving, agile-delivery organizations. As a principal architect, when would you deliberately NOT run the full ADM with all its phases and artifacts at full rigor, and what specifically do you lose by tailoring it down?

## The critique, in two halves The common critique that TOGAF's ADM is 'too heavyweight for agile teams' is half right and half a category error, and untangling which half is which is exactly the judgment a principal architect needs to exercise, because the ADM was designed from the start to be tailored rather than applied uniformly at full ceremony. ## Where the critique misfires The half that's a category error: TOGAF's own guidance is explicit that the ADM is a generic method meant to be adapted, not a fixed checklist every organization must run identically. The framework describes multiple 'iteration cycles' at different granularities, precisely so that an organization doesn't have to run the full heavyweight A-through-H sequence for every piece of work: | Iteration cycle | What it covers | |---|---| | **Architecture Capability** | setting up the Preliminary Phase's governance, done rarely | | **Architecture Development** | the classic B-C-D-E-F sweep, done per major initiative | | **Transition Planning** | focused on F-G, for organizations mid-migration | | **Architecture Governance** | focused on G-H, for organizations in steady-state operation | A team doing a narrow, well-understood infrastructure consolidation with no business-process change doesn't need a full Phase B business-architecture gap analysis with a formal matrix; a two-page statement that 'business architecture is unaffected by this engagement, confirmed by the process owner' can be a legitimate, deliberately tailored Phase B output. Critics who imagine TOGAF mandates a multi-month, every-artifact-in-full exercise for a two-sprint change are attacking a strawman the framework itself doesn't require. ## Where the critique lands The half that's a real critique: even with tailoring officially sanctioned, the ADM's default posture — sequential phases, formal sign-off gates, and governance boards — is genuinely in tension with fast, iterative delivery models where teams want to start building before every upstream architecture question is settled, and where the cost of a wrong early decision is cheap to reverse. In a genuinely agile context, waiting for a formal Phase A sign-off before any code gets written, or requiring an Architecture Contract before a two-week spike, can add process latency that's disproportionate to the risk being managed. The ADM's phase-and-gate structure was shaped by, and works best for, large, expensive-to-reverse, often regulated transformations — an insurer's core-policy-system replacement, a bank's payments-infrastructure overhaul — where the cost of under-governing genuinely exceeds the cost of the governance overhead itself. ## Naming the safeguard, artifact by artifact The principal-level skill is not 'always tailor down for agility' or 'always run it in full for rigor' — it's naming, artifact by artifact, exactly what safeguard each piece of ADM ceremony buys, and deciding per-engagement whether that safeguard's absence is tolerable. - **Skipping a formal Phase B gap analysis** costs you a documented, traceable business-impact record — tolerable for a narrow technical change, risky for anything touching customer-facing processes. - **Skipping Architecture Contracts in Phase G** costs you an enforceable compliance mechanism — tolerable for a single trusted team with a strong internal culture of following architectural intent informally, risky across a large program with many vendors and contractors who have no relationship-based incentive to comply. - **Skipping active Phase H environment-monitoring** costs you early warning that your architecture has gone stale — rarely tolerable for anything with a multi-year lifespan, because the cost of discovering staleness late compounds. ## Getting it wrong in either direction The failure modes run in both directions. - **Over-applying full ADM rigor** to small, low-risk, fast-moving work produces 'architecture paralysis' — teams waiting weeks for sign-offs on decisions that could have been made and revised cheaply, documentation debt nobody reads, and architects being quietly routed around by delivery teams who've learned that going through the formal process is slower than just building and asking forgiveness, which ironically destroys governance far more thoroughly than a deliberate tailoring decision would have. - **Under-applying rigor** to large, expensive-to-reverse, regulated work produces the opposite failure: architecture decisions made informally with no documented rationale, no gap analysis to justify why a work package was prioritized the way it was, and no Architecture Contract to point to when a delivery team's implementation quietly diverges from what was intended — discovered, typically, during an external audit or a production incident, at which point the absence of ADM rigor is far costlier than the process overhead would have been. ## Where it shows up A worked example of getting the calibration right: a large insurer running an EA capability might mandate full ADM rigor — formal gap analyses in B/C/D, Architecture Contracts, active Phase H monitoring — for any engagement touching policyholder data, regulatory reporting, or core underwriting systems, while explicitly tailoring down to a lightweight, single-page Statement of Architecture Work plus an informal technology-only gap check for internal tooling changes with no regulatory exposure and no cross-team dependency — applying the ADM's own tailoring guidance as a deliberate, documented policy rather than either a blanket mandate or an ad hoc, team-by-team improvisation.