TOGAF Phase A: Architecture Vision Explained

Every architecture development project starts with a clear answer to one question: what are we actually trying to achieve here? Phase A of the TOGAF ADM is where that question gets answered.

Architecture Vision is not just a document. It is the scoping and commitment phase. It identifies who cares about this project, what they need from it, and what success actually looks like. Before any detailed architecture work begins, Phase A ensures the entire team, including business sponsors and technology leaders, agrees on the destination.

Getting Phase A right is the difference between an architecture project that delivers real organizational value and one that produces technically excellent documents that nobody reads.

---

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.