TL;DR
Phase A is where we frame the engagement and secure permission to continue. The practical flow is: set up the project, align stakeholders and scope, shape the vision and business case, document risks and value, then sign off the Statement of Architecture Work.
For exam prep
This page is a detailed companion to Overview.
- Foundation usually focuses on Phase A purpose, objectives, and outputs
- step-level execution is typically more Practitioner-oriented
- the short request-to-approval flow is summarized in Approach
Step-by-step flow (practical)
flowchart TD S1["Establish project"] --> S2["Identify stakeholders and concerns"] S2 --> S3["Confirm principles, goals, drivers, constraints"] S3 --> S4["Evaluate capabilities"] S4 --> S5["Assess transformation readiness"] S5 --> S6["Define scope"] S6 --> S7["Confirm principles"] S7 --> S8["Develop Architecture Vision"] S8 --> S9["Define value, KPIs, business case"] S9 --> S10["Identify risks and mitigations"] S10 --> S11["Produce and approve Statement of Architecture Work"]
1) Establish the architecture project
Formally initiate the architecture engagement so it has visibility, ownership, and backing.
Typical checks:
- confirm project governance route and approvals in your organization
- confirm EA team capacity and skills for this engagement
- confirm sponsor, accountability, and engagement model
2) Identify stakeholders, concerns, and business requirements
Build a stakeholder map and capture what each group needs from the architecture.
Typical outcomes:
- stakeholder map with involvement level and key concerns
- initial communication and engagement plan
- initial in-scope requirements list
- initial measurable requirements for the architecture
To structure this properly, create a Communication Plan from the stakeholder map.
Requirements handling:
- this step helps extract business requirements directly from stakeholders
- in-scope requirements go into the Requirements Specification
- out-of-scope requirements are documented in the Architecture Requirements Repository
- Requirements Management keeps new and changed requirements controlled across the ADM cycle
3) Confirm business principles, goals, drivers, and constraints
Validate strategic intent before designing architecture direction.
Focus on:
- business principles and ways of working
- current business goals and strategic drivers
- enterprise-wide constraints
- project-specific constraints (timeline, budget, resource limits)
These items provide the Business Context for the architecture project.
If principles, goals, or drivers are unclear, go back to the originators of the Statement of Architecture Work, clarify them, and secure endorsement before continuing.
4) Evaluate capabilities (EA capability + business capability needs)
Evaluate capabilities through one or more Capability Assessments.
Check two things early:
- whether your architecture capability can deliver this engagement
- which business capabilities are needed to support strategic priorities
Assessments may focus on enterprise capability, business capability, IT capability, architecture maturity, or gaps between baseline and target capability levels.
If capability gaps are material, address them before proceeding.
5) Assess readiness for business transformation
Assess how ready the organization is for change using a Transformation Readiness assessment.
Use the result to:
- shape scope realistically
- plan change-enablement activities
- identify transformation risk areas early
This is one type of capability-related assessment. It identifies readiness factors, ratings, risks, and mitigation actions for later migration planning and implementation governance.
6) Define scope
Set clear boundaries for baseline and target work using TOGAF scoping dimensions:
- breadth
- depth
- architecture domains
- time period
Also define what is out of scope and what reusable architecture assets will be used.
7) Confirm and elaborate architecture principles
Select the principles relevant to this engagement scope and ensure they are actionable.
Keeps early decisions aligned with enterprise direction and governance.
8) Develop the Architecture Vision
Create the Vision Deliverable: a concise, high-level picture of baseline-to-target direction across domains in scope.
Common technique:
- use Business Scenarios and simple concept diagrams to communicate value and direction quickly
Typical content includes the problem description, stakeholders and concerns, objectives from the Statement of Architecture Work, summary views, mapped requirements, and a reference to a draft Architecture Definition Document.
9) Define value proposition, KPIs, and business case direction
Translate vision into decision-ready value.
Typical outputs:
- stakeholder-specific value propositions
- initial KPIs/measures
- business case framing and procurement considerations
10) Identify transformation risks and mitigations
Capture key delivery and change risks, assess impact/likelihood, and define mitigations.
Surfacing risks early helps avoid unrealistic commitments down the line.
11) Produce and approve the Statement of Architecture Work
Document the Phase A agreements in the Statement of Architecture Work and secure sign-off.
This is the formal green-light to continue architecture development with agreed scope, value, constraints, and governance.
Typical content includes approvals, change-of-scope procedures, project request and background, scope, plan and schedule, acceptance criteria, roles, responsibilities, deliverables, and an overview of the Architecture Vision.
Sponsor signature represents approval to continue into detailed target architecture work.
Common pitfalls
- unclear scope boundaries
- weak stakeholder mapping
- mixing vision with low-level solution design too early
- missing explicit risk/value discussion before sign-off
Exam note
- Phase A is where engagement framing and approval happen.
- Architecture Vision and Statement of Architecture Work are central outputs.
- Scope, stakeholders, principles, value, and risk are all addressed before moving forward.