Iteration, scope, and partitioning | TOGAF Enterprise Architecture Foundation: from vision to operations

Concept and mechanism

Applying the ADM requires scope and detail appropriate to the work. A single-application initiative and transformation of an entire business line do not need identical depth everywhere. Iteration incorporates learning within architecture work and across related decisions. An earlier approval establishes a reference but does not make new evidence irrelevant. If discovering a dependency invalidates data design, identify what is affected, who decides, and which models or requirements need revision. There is no need to assume the whole program must restart or that one team may change shared interfaces without coordination.

Guided application

Partitioning work helps manage complexity. Two teams can develop different segments while sharing identity and reference data. Define boundaries, contracts, integration points, and responsibilities for common decisions. Useful autonomy depends on clear interfaces rather than absence of relationships. In an agile setting, the backlog may contain architecture work and validation findings; cross-team requirements and decisions still need maintenance. Increase detail where risk and the decision justify it. Documentation can evolve with delivery, provided state and validity remain clear to implementers and operators.

IN PRACTICE

Two teams can progress in parallel if they agree on the identity contract both use.

Common pitfalls

Iteration without history; irreversible phases; partitioning as total isolation; agility as absence of governance.

Related topics: Govern implementation and exceptions · Content, views, and traceability

Take this idea with you

Tailor the path while keeping shared dependencies and decisions visible.

Create account

Reference: Foundation competency mapping · OGEA-101, TOGAF Enterprise Architecture Foundation; body of knowledge drawn from TOGAF Standard, 10th Edition