4.5 Phase A: Architecture Vision
Key Takeaways
- Phase A objectives are to develop a high-level aspirational vision of the capabilities and business value to be delivered and to obtain approval for a Statement of Architecture Work.
- The Request for Architecture Work is an input that triggers the cycle, while the approved Statement of Architecture Work is a Phase A output.
- TOGAF defines the Architecture Vision as a succinct description of the Target Architecture that serves as an aspirational vision and a boundary for detailed architecture development.
- Phase A steps include evaluating capabilities, assessing readiness for business transformation, and identifying business transformation risks and mitigation activities.
- Phase A outputs include the Architecture Vision, Capability Assessment, Communications Plan, Architecture Principles, and a draft Architecture Definition Document.
4.5 Phase A: Architecture Vision
Phase A is the initial phase of an architecture development cycle. The Foundation syllabus asks you to briefly explain its purpose and describe its objectives. Phase A defines the scope of the initiative, identifies stakeholders, creates the Architecture Vision, and obtains approval to proceed.
Purpose and Objectives
Phase A starts with receipt of a Request for Architecture Work from the sponsoring organization. Its two objectives are:
- Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture
- Obtain approval for a Statement of Architecture Work that defines a program of works to develop and deploy the architecture outlined in the Architecture Vision
The glossary defines the Architecture Vision as "a succinct description of the Target Architecture that describes its business value and the changes to the enterprise that will result from its successful deployment. It serves as an aspirational vision and a boundary for detailed architecture development."
The Steps of Phase A
- Establish the Architecture Project — conduct the project within the enterprise's project management frameworks
- Identify Stakeholders, Concerns, and Business Requirements
- Confirm and Elaborate Business Goals, Business Drivers, and Constraints
- Evaluate Capabilities — understand the capabilities in the enterprise and document them in a Capability Assessment
- Assess Readiness for Business Transformation — using the Business Transformation Readiness Assessment technique
- Define Scope — breadth, depth, time period, domains, and assets to re-use
- Confirm and Elaborate Architecture Principles, including Business Principles
- Develop Architecture Vision
- Define the Target Architecture Value Propositions and KPIs
- Identify the Business Transformation Risks and Mitigation Activities
- Develop Statement of Architecture Work; Secure Approval
Request Versus Statement of Architecture Work
| Characteristic | Request for Architecture Work | Statement of Architecture Work |
|---|---|---|
| Origin | Sent from the sponsoring organization to the architecture organization; may also be produced by the Preliminary Phase, result from approved change requests, or come from migration planning | Developed by the architecture team in Phase A |
| Role | Input that triggers the start of an architecture development cycle | Output that defines the scope and approach for the architecture project |
| Typical content | Sponsors, mission statement, business goals, strategic plans, time limits, changes in the business environment, constraints, budget, current business and architecture descriptions, resources available | Title, request and background, description and scope, outline of the Architecture Vision, change-of-scope procedures, roles, responsibilities and deliverables, acceptance criteria and procedures, project plan and schedule, approvals |
| Status | A request | Approved at the end of Phase A; typically the document against which successful execution of the architecture project is measured |
Creating the Architecture Vision
The Architecture Vision provides a first-cut, high-level description of the Baseline and Target Architectures across the domains. It is an aspirational vision and a boundary for later detailed work, so it must be understood and agreed by sponsors and stakeholders.
The business scenarios technique (Section 8.2) is a key tool here: it helps discover and document business requirements and articulate the vision in terms stakeholders recognize. Business scenarios may also be used in later phases.
Stakeholders and Communication
Phase A identifies stakeholders, their concerns, and their business requirements, and produces a Communications Plan so the right stakeholders receive the right information at the right time. The stakeholder management technique (Section 12.1) classifies stakeholders and determines how to engage them.
Capability Assessment and Readiness
Before detailed definition, Phase A records a Capability Assessment, which can include business capability, IT capability, architecture maturity, and business transformation readiness. The Business Transformation Readiness Assessment (Section 9.2) identifies factors that could help or hinder change, and Phase A identifies business transformation risks and mitigation activities early.
Scope
Phase A applies the scoping dimensions from Section 4.3 — breadth, depth, time period, and architecture domains — so the Statement of Architecture Work describes a realistic, bounded effort.
Inputs and Outputs of Phase A
| Inputs | Outputs |
|---|---|
| Request for Architecture Work | Approved Statement of Architecture Work |
| Business principles, business goals, and business drivers | Refined statements of business principles, business goals, and business drivers |
| Organizational Model for Enterprise Architecture | Architecture Principles |
| Tailored Architecture Framework | Capability Assessment |
| Populated Architecture Repository and architecture reference materials | Tailored Architecture Framework |
| Architecture Vision — problem description, objective of the Statement of Architecture Work, summary views, optional business scenario, refined key high-level stakeholder requirements | |
| Draft Architecture Definition Document — high-level baseline and target views across the domains | |
| Communications Plan | |
| Additional content populating the Architecture Repository |
Scenario: Airport Passenger Experience
An airport authority's board issues a Request for Architecture Work to "cut average passenger processing time by 30%." In Phase A the architecture team identifies stakeholders (airlines, border agency, security contractor, retail tenants), confirms goals and constraints, and assesses capabilities and readiness — discovering that the border agency's systems team has little capacity for change in the next year. They scope the effort to check-in, security, and boarding over a three-year horizon, draft an Architecture Vision built around biometric passenger flow, define KPIs, record transformation risks with mitigations, and secure sponsor approval of the Statement of Architecture Work before detailed Phase B work starts.
Common Exam Pitfalls
- Swapping the Request and the Statement. The Request is an input from the sponsor; the Statement is the approved Phase A output.
- Doing detailed modeling in Phase A. Phase A produces high-level vision and a draft ADD; detailed domain work is Phases B–D.
- Forgetting the second objective. Phase A must obtain approval for the Statement of Architecture Work.
- Leaving readiness and risk until later. Phase A includes assessing readiness for business transformation and identifying transformation risks and mitigation activities.
Which of the following is an objective of Phase A: Architecture Vision?
What is the relationship between the Request for Architecture Work and the Statement of Architecture Work?
How does the TOGAF glossary describe the Architecture Vision?
During Phase A, an architect evaluates whether the organization has the leadership, funding, and capacity to undergo the proposed change. Which Phase A step is being performed?