In TOGAF's ADM, what's the difference in purpose between the Preliminary Phase and Phase A (Architecture Vision), and why does TOGAF treat them as two separate phases rather than merging 'set up the framework' and 'define this engagement's scope' into one step?

## Two phases, two altitudes The Preliminary Phase and Phase A are easy to conflate because both happen 'before the real architecture work,' but they operate at different altitudes and on different cadences, and TOGAF separates them precisely so an organization doesn't have to redo organization-wide setup work every time it starts a new architecture engagement. ## The Preliminary Phase — building the capability The Preliminary Phase is about building the capability to do architecture at all. Its outputs are organizational, not project-specific: - an **Architecture Principles** set (the ground rules — e.g., 'buy before build,' 'data is a shared asset,' 'security is non-negotiable' — that every future architecture decision must be consistent with); - a decision on how the **ADM itself will be tailored** for this organization (which phases will be run in full, which abbreviated, what artifacts are mandatory, how the method integrates with existing frameworks like ITIL or a PMO's project methodology); - the **Architecture Governance framework** (who sits on the architecture review board, what the escalation path is for exceptions); - the **tooling/repository decisions** (where architecture artifacts live, what modeling notation is used). Crucially, the Preliminary Phase is typically done once when an organization stands up an EA capability, and then only revisited occasionally — when the governance model itself needs to change, or when tailoring needs adjustment — not at the start of every new architecture project. ## Phase A — scoping one engagement Phase A, Architecture Vision, is where the actual per-engagement work starts, and it runs every time the organization enters the ADM cycle for a new scope of work. Its job is to answer 'what are we architecting, for whom, and why, this time.' Concretely: - **identify the stakeholders and their concerns** (a CFO cares about cost and risk; a plant manager cares about operational continuity; these concerns shape what the architecture must demonstrably address); - **define the scope and constraints** of this particular effort; - **articulate a high-level Architecture Vision** — a sketch of the target state good enough to get organizational buy-in, not the detailed target architecture itself (that's Phases B-D's job); - **produce a Statement of Architecture Work**, a document that gets formal sign-off before deeper, more expensive analysis begins in Phase B onward. ## Why they stay separate The reason TOGAF keeps these as two phases rather than one 'setup' step is a reuse and cost argument. Architecture Principles, governance structure, and ADM tailoring are expensive to get right and expensive to change — they should be stable enough that dozens of individual architecture engagements can run against them without re-deriving them each time. If Preliminary-Phase content were re-done inside every Phase A, two costs would follow: 1. **First, duplicated effort** — every project team re-debating principles that should already be settled. 2. **Second, and worse, principle drift** — different engagements silently adopting slightly different ground rules because each one improvised its own 'preliminary' step, undermining the whole point of having enterprise-wide architecture governance. Separating the phases also lets the artifacts have different owners and different change cadences: | Artifact | Who owns it | How often it changes | |---|---|---| | **Architecture Principles** | usually owned and versioned by an Architecture Review Board or Chief Architect's office | change rarely | | **Statement of Architecture Work** | owned by the engagement's lead architect | produced fresh for every project | ## The trade-off The trade-off is that this separation only pays off if the Preliminary Phase is actually done well and durably — a shallow, box-ticking Preliminary Phase means every subsequent Phase A engagement inherits a weak foundation and ends up quietly re-deriving ground rules anyway, defeating the reuse benefit while still paying the overhead of having two named phases. ## What goes wrong in practice A common failure mode in practice: an organization runs the Preliminary Phase once at EA-program kickoff, produces a principles document, and then never revisits or enforces it. Individual Phase A engagements each write their own Architecture Vision without checking consistency against the unenforced principles, so two years later the organization discovers it has three incompatible integration patterns in production, each locally justified by a Phase A vision document that nobody cross-checked against Preliminary-Phase principles. ## Where it shows up A worked example: a multinational insurer stands up an EA capability with a single Preliminary Phase — one set of architecture principles, one governance board, one ADM tailoring (skip Phase C's detailed data architecture for small engagements, mandate it for anything touching policyholder PII). Every subsequent Phase A — a claims-system modernization here, a new regional market entry there — reuses that same Preliminary-Phase foundation, so each Statement of Architecture Work only has to state scope and stakeholders for that engagement, not re-litigate what 'architecture principle' or 'governance sign-off' means from scratch.