Applying the TOGAF Standard in Practice: Agile and Digital Contexts
Iteration, levels and just-enough architecture
The ADM is not a waterfall. TOGAF explicitly allows the method to be iterated and to be applied at different architecture levels - strategic (the whole enterprise), segment (a part of it) and capability (a capability increment) - and partitioned by level, segment or time to keep work tractable.
In agile delivery the useful translations are: keep the ADM but shorten it, running architecture work in sprints or increments slightly ahead of delivery; produce a minimum viable architecture - just enough vision, principles and target to unblock teams; maintain an architecture runway of intentional, planned capability the backlog can build on; map Phase E and F work packages to epics and features, and Phase G architecture contracts to definition-of-done and compliance checks; and let architecture emerge under Phase H change management rather than freezing it upfront. Governance becomes continuous and lightweight rather than a single gate.
In the digital context, TOGAF Series Guides extend the core for digital transformation, business capability, product-centric operating models and agile ways of working; they do not replace the ADM or its governance. Expect questions on how to handle continuous, high-tempo change (iterate the ADM and route change through Architecture Change Management) and on where principles and governance still sit (Preliminary/A, endorsed by the Architecture Board).
Traps: assuming ADM phase order dictates delivery order; assuming agile means no architecture; confusing a capability iteration of the ADM with capability-based planning, which is a technique.
Rule of thumb: just enough architecture, just in time, governed continuously - any option that says 'wait until the architecture is complete' is almost always wrong.