LEARN. PRACTICE. GROW.Concept and mechanism
Phase A establishes an understandable direction and agreement on architecture work. The vision should explain the problem, intended outcome, boundaries, and principal constraints. It need not anticipate every implementation decision. Presenting a vendor choice too early can close options before important requirements are understood. Describe the intended state concretely enough to discuss value and feasibility. Relate it to the mandate, stakeholders, and success criteria. Authorization to develop architecture does not automatically authorize a production change. Those are decisions with different scopes and evidence needs.
Guided application
Consider a reconciliation platform with an 18:00 closing deadline. The vision may require processing within the window and reducing manual intervention while keeping data reconcilable during transition. Confirm how each outcome will be measured and which assumptions remain unproven. If the window depends on an external provider, include that dependency in feasibility analysis. Record what is outside scope and how that boundary can be reviewed. A prototype can reduce one technical uncertainty without validating complete operational capacity. When presenting the vision, seek decisions about objectives, constraints, and further studies, with owners and dates for resolving relevant uncertainties.
A prototype validates an interface; it does not independently demonstrate the complete daily close.
Common pitfalls
Vision as product list; implicit scope; design authorization treated as go-live.
Related topics: Context, mandate, and value · Stakeholders, conflicts, and views · Architectures and gap analysis
Obtain a verifiable agreement on the work and value.
Reference: Foundation versus Practitioner competencies · OGEA-102; TOGAF Standard, 10th Edition