TOGAF Phase A: Architecture Vision Outputs & Deliverables (2026)

Phase A at a Glance

Item	Detail
Phase name	Architecture Vision
Position in ADM	First phase after Preliminary
Primary question	What are we trying to achieve and who cares?
Key inputs	Request for Architecture Work, business strategy, architecture principles
Key outputs	Architecture Vision document, Statement of Architecture Work
Who approves?	Architecture Board / executive sponsor
Exam fact	Statement of Architecture Work is the formal mandate to proceed — without it, the project has no authority

---

What is TOGAF Phase A?

TOGAF Phase A — Architecture Vision — is the project initiation phase of the ADM. It identifies stakeholders and their concerns, defines the scope and constraints of the architecture engagement, produces the Architecture Vision document, and culminates in a signed Statement of Architecture Work that formally authorises the project to proceed. Phase A is where architecture projects succeed or fail based on the quality of stakeholder engagement and scope definition.

---

The Purpose of Phase A

Phase A serves as the project initiation for an architecture development engagement. It mirrors what a project charter does in traditional project management, but goes deeper by establishing the architectural context and ensuring senior business commitment.

The two primary outputs of Phase A are:

• The Architecture Vision document, describing the high-level target state of the architecture
• The Statement of Architecture Work, formally authorizing the project to proceed

Without these two documents, the architecture team has no mandate. Phase A is what gives the subsequent ADM phases their authority and legitimacy.

---

The Key Objectives of Phase A

TOGAF defines the following objectives for this phase:

1. Ensure the architecture development project has the support of executive management
2. Identify and mobilize the corporate sponsors and business owners for the work
3. Define the scope, constraints, and expectations of the architecture development effort
4. Identify the stakeholders and their key concerns and requirements
5. Identify the business requirements and architecture requirements the project must satisfy
6. Confirm and elaborate the business goals, business drivers, and constraints
7. Evaluate capabilities against the current business goals and drivers
8. Assess the readiness for business transformation
9. Create the Architecture Vision
10. Define the Target Architecture Vision, including KPIs
11. Identify transformation risks and mitigation approaches
12. Develop a Statement of Architecture Work, gaining approval to proceed

---

What Triggers Phase A?

Phase A begins when a Request for Architecture Work is received. This request typically comes from one of three sources:

• Organizational initiative: A strategic decision, such as a merger, digital transformation programme, or regulatory change that requires architectural support
• Architecture board decision: The governance body identifies a gap or opportunity that requires an architecture project
• Business leadership request: An executive sponsor commissions architecture work to support a business goal

When the request arrives, Phase A begins by examining it and determining whether the proposed architecture project is appropriate, well-scoped, and sponsored at the right level.

---

Stakeholder Identification and Management

One of the most important activities in Phase A is identifying and understanding the stakeholders. In TOGAF, a stakeholder is any individual, team, or organization that has an interest in the outcome of the architecture.

Stakeholders are not only technical people. They include:

• Business executives: who care about cost, risk, and strategic outcomes
• Business process owners: who care about how the architecture affects their day-to-day operations
• IT teams: who care about technical feasibility, integration, and operational impact
• Regulators and auditors: who care about compliance and data governance
• End users: who care about usability and the impact on their work
• External partners: who care about integration and shared service impacts

For each stakeholder, Phase A documents their concerns. A concern is a specific requirement, risk, or question that the architecture must address.

The TOGAF technique used here is the Stakeholder Map, which organizes stakeholders by their level of influence and interest, helping architects decide where to focus engagement effort.

---

Defining the Scope

A key decision in Phase A is defining the scope of the architecture project. Scope has four dimensions in TOGAF:

• Breadth: Which parts of the enterprise are included? Is this a full enterprise architecture or a segment architecture covering one business unit?
• Depth: How deeply will the architecture be defined? A strategic architecture operates at a high level. A capability architecture goes into technical detail.
• Time period: What is the time horizon? Is this about the next year, three years, or longer?
• Architecture domains: Will all four domains (Business, Data, Application, Technology) be developed, or is this focused on one or two?

Getting scope wrong in Phase A causes one of two problems. If the scope is too narrow, the architecture misses important interdependencies. If it is too broad, the project becomes unmanageable and never delivers.

---

Business Transformation Readiness Assessment

Phase A also assesses the organization's readiness for the change that the target architecture will require. This is called a Business Transformation Readiness Assessment.

The assessment looks at a set of readiness factors:

• Vision: Is there a clear and shared vision of what needs to change?
• Desire, willingness, and resolve: Does the organization genuinely want to make this change?
• Need: Is there a compelling reason to change, strong enough to overcome inertia?
• Business case: Is the case for change financially and strategically justified?
• Funding: Are resources available to make the change happen?
• Sponsorship: Do senior leaders visibly support the change?
• Champion: Is there an individual or team actively driving the change?
• Governance: Are there processes to oversee, make decisions, and correct course?
• Accountability: Are people held responsible for delivering the change?
• Ability and capacity: Does the organization have the skills and capacity to execute the change?

If this assessment reveals serious readiness gaps, Phase A may recommend addressing those gaps before architecture development continues. A technically perfect architecture cannot be implemented in an organization that is not ready to change.

---

Creating the Architecture Vision

The Architecture Vision is the headline output of Phase A. It is a high-level description of the Target Architecture, written to be understandable by business sponsors and non-technical stakeholders.

The Architecture Vision typically includes:

• A summary of the business context and the drivers for this architecture project
• The business goals and objectives the architecture will support
• The scope and constraints that apply
• A high-level description of the target state: what the business will look like once the architecture is implemented
• Key risks and dependencies the project must manage
• The key stakeholders and their primary concerns
• A description of how the architecture will address those concerns

The Architecture Vision is deliberately high-level. It does not go into the detailed design of systems or processes. That is the work of Phases B through D. The Vision just needs to give everyone enough shared understanding to agree that proceeding with detailed development is the right thing to do.

---

The Statement of Architecture Work

The Statement of Architecture Work is the formal agreement between the architecture team and their sponsors that authorizes the work to continue. It is the governance document that makes Phase A official.

A Statement of Architecture Work typically covers:

• The project title and scope
• The business context and sponsorship
• What will be produced (deliverables)
• The approach and method to be used
• The criteria for success and acceptance
• Risks and mitigations
• Resource requirements
• A high-level schedule
• Signatures from the architecture team lead and the sponsoring executive

The signed Statement of Architecture Work is what gives Phase B through H their mandate. Without it, the architecture team is working without explicit organizational approval.

---

The Role of the Architecture Board in Phase A

The Architecture Board reviews and approves the Statement of Architecture Work before the project proceeds. This board review serves several purposes:

• It confirms the project is in scope for the architecture practice
• It checks that the proposed approach is consistent with existing architecture principles and standards
• It identifies any conflicts with other active architecture projects
• It provides governance oversight from the outset of the project

If the Architecture Board has concerns, they may direct the team to refine the scope, address readiness issues, or reconsider the approach before giving final approval.

---

Practical Example: Digital Banking Platform

A bank's executive team sponsors a project to migrate their retail banking platform to the cloud. Phase A for this project would proceed as follows:

1. The CIO issues a Request for Architecture Work to the Enterprise Architecture team
2. Stakeholders are identified: the CTO, CFO, Head of Retail Banking, Chief Risk Officer, and end-customer experience team
3. Key concerns are documented: the CTO wants flexibility and reduced vendor lock-in, the CFO wants cost predictability, the CRO wants data sovereignty and compliance, and customers want no service disruption during transition
4. Scope is defined as covering Business and Technology Architecture across the retail banking segment for a five-year horizon
5. A Business Transformation Readiness Assessment reveals strong executive sponsorship but limited cloud skills in the IT team, which is flagged as a risk with a training plan as the mitigation
6. The Architecture Vision is drafted and presented to the executive sponsors in a one-page summary and a visual future-state diagram
7. The Statement of Architecture Work is signed by the CIO and the enterprise architecture lead, authorizing Phase B to begin

---

Summary

Phase A is where architecture development projects are defined, scoped, and formally authorized. It produces two critical outputs: the Architecture Vision and the Statement of Architecture Work.

Success in Phase A requires:

• Thorough stakeholder identification and concern mapping
• Careful scoping across breadth, depth, time, and domain dimensions
• An honest assessment of organizational readiness for change
• An Architecture Vision written for business decision-makers
• A signed Statement of Architecture Work that formally authorizes the project

In the next post, we begin the detailed architectural development with Phase B: Business Architecture, where the current and target states of the organization's business capabilities, processes, and structure are defined in detail.

This post is part of the ongoing TOGAF 9.2 Masterclass series. We recommend starting with the Preliminary Phase post to understand the governance context before diving into Phase A.

For the official TOGAF ADM specification, refer to the TOGAF standard published by The Open Group. For exam preparation covering Phase A topics, see our TOGAF Foundation Mock Exam and TOGAF Foundation Study Guide.

Frequently Asked Questions

Q: What is the main output of TOGAF Phase A and why is it important?

The primary output of Phase A is the Architecture Vision document, which provides a high-level summary of the changes to the enterprise that will result from the architecture engagement. It includes the problem statement, objectives, key stakeholder concerns, and a high-level view of the Baseline and Target architectures. The Architecture Vision is important because it is the first formally approved deliverable — it aligns stakeholders before significant architecture work begins, preventing wasted effort on detailed design work that stakeholders later reject.

Q: What is a Statement of Architecture Work?

The Statement of Architecture Work is a formal agreement produced in Phase A that defines the scope, approach, schedule, and resources for the architecture engagement. It is the architecture equivalent of a project charter. It sets boundaries on what will and will not be addressed in this ADM cycle, establishes the deliverables to be produced, and is formally agreed and signed off by the sponsoring organisation. The Statement of Architecture Work is a critical governance document — it holds the architect accountable to a defined scope and protects against scope creep.

Q: How does stakeholder management work in Phase A?

Phase A requires identifying all stakeholders — individuals or groups with an interest in the outcome of the architecture engagement — and understanding their concerns, requirements, and level of influence. A Stakeholder Map is produced classifying stakeholders by power and interest. The Architecture Vision then demonstrates how the proposed architecture addresses key stakeholder concerns. This upfront engagement prevents a common failure mode: producing technically excellent architecture work that fails to gain approval because it did not address the concerns of the people who control budget and authorisation.

---

Part of the TOGAF 9.2 Masterclass. See the TOGAF & Enterprise Architecture Learning Hub for the complete index.