Overview
Phase A, Architecture Vision, is where a specific architecture engagement begins. It is triggered by a Request for Architecture Work and builds on what the Preliminary Phase established: the organizational model for EA, the tailored framework, architecture principles and the repository. The phase defines scope, identifies stakeholders and their concerns, confirms business goals, drivers and constraints, assesses capabilities and readiness for transformation, and produces a high-level vision of the target.
This syllabus area has four outcomes. You must know what information is needed to begin, apply the phase to a situation, describe what a sufficient security-specific architecture design looks like at this stage, and identify the outputs needed to proceed. The key output is an approved Statement of Architecture Work, supported by the Architecture Vision, refined principles and goals, a Capability Assessment, a Communications Plan and initial content for the Architecture Definition Document and requirements.
How it's tested
A typical stem describes a new initiative, a sponsor and some constraints, then asks what the architect should do next or how to complete the phase. Best answers secure scope, stakeholders, goals and approval before detail. Distractors start building target models, skip readiness or ignore security and risk.
-
Scope before detail
Options differ in whether they set breadth, depth, time period and architecture domains first or rush into modelling. The scoped approach normally earns most points.
-
Readiness and risk
The organization shows signs of low change readiness. Strong answers include a Business Transformation Readiness Assessment and identify transformation risks and mitigations.
-
Approval as the gate
Questions ask what is needed to proceed. The Statement of Architecture Work, approved by the sponsor, is the key output that authorizes further work.
A hospital group's board requests an architecture for shared patient records, with a fixed budget and strict privacy law. One option starts detailed data models; another produces a vision without considering privacy. The best option confirms scope and constraints, identifies clinical, privacy and IT stakeholders, records regulatory and security requirements, assesses readiness, and drafts the Statement of Architecture Work for sponsor approval before any detailed design.
Learning outcomes 4
Official learning outcomes from the The Open Group outline, in outline order.
3.1 Apply the information needed to start the Architecture Vision phaseBloom level 3. Inputs that Phase A depends on.
- What it means
- Phase A starts from a Request for Architecture Work issued by a sponsor, plus outputs of the Preliminary Phase: the organizational model for EA, the tailored architecture framework, architecture principles, business principles, goals and drivers, and a populated Architecture Repository with existing architecture documentation.
- What to understand
- Missing inputs are a signal. If principles, a sponsor or a tailored framework do not exist, the architect may need to address the gap, sometimes by revisiting the Preliminary Phase, before a credible vision can be built. Existing baseline documentation in the repository reduces effort and avoids duplicate work.
- How it shows up
- Scenarios that start without a clear sponsor or Request for Architecture Work reward options that secure them first.
- Common confusion
- Treating the Architecture Vision itself as an input rather than an output of Phase A.
3.2 Apply Phase A: scope, stakeholders, goals and constraintsBloom level 3. Carrying out the steps of the Architecture Vision phase.
- What it means
- The phase establishes the architecture project, identifies stakeholders, concerns and business requirements, confirms business goals, drivers and constraints, evaluates capabilities, assesses readiness for business transformation, defines scope, confirms principles, develops the Architecture Vision, defines value propositions and KPIs, identifies transformation risks, and develops the Statement of Architecture Work.
- What to understand
- Scope covers breadth, depth, time period and the architecture domains involved. Business scenarios can help discover requirements and clarify the vision. The Business Transformation Readiness Assessment shows whether the organization can absorb the change. Constraints such as budget, regulation or deadlines shape every later decision and must be stated now.
- How it shows up
- The best option typically completes scoping, stakeholder and readiness work and confirms constraints before committing to solutions.
- Common confusion
- Thinking the Architecture Vision must be detailed; it is a high-level aspirational view used to gain agreement.
3.3 Describe a sufficient security-specific architecture design for Phase ABloom level 1. Security content needed at the vision stage.
- What it means
- At this stage security work is about framing, not detailed controls. It covers identifying security stakeholders and their concerns, applicable regulations and policies, the business's risk appetite, the assets that need protection, and security requirements and constraints that must appear in the vision and Statement of Architecture Work.
- What to understand
- A sufficient design is one that lets later phases make secure choices: security-relevant principles are confirmed, high-level threats and risks are recognised, and security scope is defined. Over-detailed control design here wastes effort; absence of any security framing risks expensive rework later.
- How it shows up
- Scenarios involving regulated data reward options that bring security and privacy stakeholders and constraints into Phase A.
- Common confusion
- Designing specific technical controls during Phase A instead of setting security scope and requirements.
3.4 Apply the outputs needed to proceed from Phase ABloom level 3. What must exist before architecture development starts.
- What it means
- Key outputs are an approved Statement of Architecture Work, refined business principles, goals and drivers, architecture principles, a Capability Assessment, a Tailored Architecture Framework, the Architecture Vision, a draft Architecture Definition Document and Architecture Requirements Specification, and a Communications Plan.
- What to understand
- The Statement of Architecture Work defines scope, approach, deliverables, schedule and acceptance criteria, and is signed off by the sponsor. It works as the contract for the architecture project. The Architecture Vision summarizes the target and its value. Without approval, Phases B to D should not proceed in earnest.
- How it shows up
- When asked how to conclude Phase A, look for sponsor approval of the Statement of Architecture Work.
- Common confusion
- Mixing up the Statement of Architecture Work with the Architecture Contract used later for implementation.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Request for Architecture Work
Document from the sponsor that triggers an ADM cycle.
- Remember
- It is an input to Phase A, not an output.
- Tested as
- Missing sponsor scenarios.
- Trap
- Confusing it with the Statement of Architecture Work.
-
Statement of Architecture Work
Defines scope, approach, deliverables, plan and acceptance criteria for the architecture project.
- Remember
- Approved by the sponsor at the end of Phase A.
- Tested as
- The gate to proceed.
- Trap
- Calling it the Architecture Contract.
-
Architecture Vision
High-level, aspirational description of the target and its business value.
- Remember
- Used to gain stakeholder buy-in, not as a design.
- Tested as
- Options that over-detail it score lower.
- Trap
- Treating it as the full target architecture.
-
Scope dimensions
Breadth, depth, time period and architecture domains.
- Remember
- Set in Phase A.
- Tested as
- Diagnosing vague scope.
- Trap
- Defining only breadth.
-
Business Transformation Readiness Assessment
Evaluates the organization's ability to undergo the change.
- Remember
- Started in Phase A, informs Phases E and F.
- Tested as
- Low-readiness scenarios.
- Trap
- Assuming readiness is only a project management issue.
-
Capability Assessment
Baseline and target capability levels of the business and of IT.
- Remember
- A Phase A output.
- Tested as
- Understanding the size of the change.
- Trap
- Skipping it for a quick vision.
-
Value propositions and KPIs
How the target delivers value and how success will be measured.
- Remember
- Defined in Phase A, used in Phase H for value realization.
- Tested as
- Weak business case scenarios.
- Trap
- Leaving measures until after implementation.
-
Transformation risks
Risks of the change effort identified with mitigations.
- Remember
- Initial and residual risk are both considered.
- Tested as
- Risk-aware options rank higher.
- Trap
- Listing risks without mitigation.
-
Security framing in Phase A
Security stakeholders, regulation, risk appetite, assets and security requirements.
- Remember
- Sufficient, not detailed.
- Tested as
- Outcome 3.3 and regulated scenarios.
- Trap
- Specifying technical controls too early.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Request for Architecture Work vs. Statement of Architecture Work vs. Architecture Contract
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Request for Architecture Work | Sponsor's request that starts an ADM cycle | Input to Phase A | Thinking the architect writes and approves it |
| Statement of Architecture Work | Agreed scope, approach and deliverables of the architecture project | Output of Phase A, approved by the sponsor | Treating it as optional paperwork |
| Architecture Contract | Agreement between architecture and implementation parties | Used mainly in Phase G | Using it to authorize Phase B |
Architecture Vision vs. Target Architecture
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Architecture Vision | High-level view of the target and its value | For agreement and buy-in | Over-detailing it |
| Target Architecture | Detailed description of the future state across domains | Developed in Phases B, C and D | Building it in Phase A |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Model first
- What candidates pick
- Begin detailed baseline modelling of all business processes.
- Why it looks right
- Detail feels like progress.
- Why it's wrong
- Without agreed scope and approval, detailed modelling may be wasted or misdirected.
Clue to watch for The engagement has just been requested and scope is unclear.
-
Vision without sponsor
- What candidates pick
- Publish the Architecture Vision to all staff to build momentum.
- Why it looks right
- Communication is good.
- Why it's wrong
- The vision and Statement of Architecture Work need sponsor approval and stakeholder validation first.
Clue to watch for The sponsor has not yet confirmed scope or budget.
-
Readiness ignored
- What candidates pick
- Proceed directly to Phase B because the board approved funding.
- Why it looks right
- Funding seems to confirm commitment.
- Why it's wrong
- Funding does not prove the organization can absorb change; readiness and transformation risks must be assessed.
Clue to watch for Prior failed initiatives, staff resistance or capacity limits.
-
Security later
- What candidates pick
- Record that security will be addressed in Phase D.
- Why it looks right
- Phase D deals with technology controls.
- Why it's wrong
- Phase A must frame security stakeholders, regulation and risk so later phases design securely.
Clue to watch for Personal data, regulators or audit findings.
-
Contract confusion
- What candidates pick
- Draft an Architecture Contract to authorize architecture development.
- Why it looks right
- It sounds formal and binding.
- Why it's wrong
- The Statement of Architecture Work authorizes the architecture project; Architecture Contracts govern implementation.
Clue to watch for The question asks what is needed to proceed to Phase B.
Answer framework
Use this order to judge options in a Phase A scenario.
- Confirm there is a sponsor and a Request for Architecture Work, plus principles and a tailored framework from the Preliminary Phase.
- Check that scope is set in all four dimensions and that business goals, drivers and constraints, including regulatory and security ones, are explicit; the four dimensions are breadth, depth, time period and architecture domains.
- Verify that stakeholders and concerns are identified and that readiness for transformation and key transformation risks have been assessed.
- Prefer options that develop a high-level Architecture Vision with value propositions and KPIs rather than detailed designs.
- Choose the option that secures sponsor approval of the Statement of Architecture Work before Phases B to D proceed.
Practice question
Want more like this? The TOGAF Practitioner practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start by reading Phase A in the ADM part of the Fundamental Content: objectives, inputs, steps and outputs. Write the steps on one page in order, because Practitioner options often differ by which step they skip.
Next, focus on four artifacts that dominate scenarios: the Request for Architecture Work, the Statement of Architecture Work, the Architecture Vision and the Communications Plan. For each, note who creates it, who approves it and what it contains. Compare them with the Architecture Contract so you never mix them up.
Third, study the Business Transformation Readiness Assessment and the treatment of transformation risks. Learn a few readiness factors such as vision clarity, sponsorship, need, funding and capacity to execute. Then read the security guidance for Phase A and summarize it as a short list: security stakeholders, regulation, risk appetite, assets, security requirements.
Finally, practise with scenarios that describe a fresh initiative. Before reading the options, write what Phase A still lacks in that organization. The best option usually fills that gap without overreaching into later phases, and the second-best option usually fills only part of it.
FAQ
How heavily is Phase A: The Starting Point weighted on OGEA-102?
No weight is published for Phase A: The Starting Point. It is one of eight syllabus areas covered by the exam's 8 scenario questions, and a single scenario may combine it with stakeholder or security topics.
What triggers Phase A?
A Request for Architecture Work from a sponsor, usually following strategic planning or a change in the business, and building on the Preliminary Phase outputs.
Who approves the Statement of Architecture Work?
The architecture sponsor approves it, sometimes with the Architecture Board depending on the governance model the organization has set up.
Is the Architecture Vision the same as the target architecture?
No. The vision is a high-level aspirational view to gain agreement; the detailed target is developed across Phases B, C and D.
How much security work belongs in Phase A?
Enough to frame later work: security stakeholders, regulation, risk appetite, assets to protect and security requirements. Detailed controls come later.
Can business scenarios be used in Phase A?
Yes. The business scenario technique is a common way to discover and document business requirements and to articulate the Architecture Vision.
Other Enterprise Architecture & IT Governance certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have studied Phase A inputs, steps, security framing and outputs. See whether you can pick the best way to start an engagement under gradient scoring.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the TOGAF Practitioner AI tutor Get any concept explained your way