Section 1: Phase A Overview
Phase A — Architecture Vision is the first lettered phase of the ADM cycle. It is triggered by a Request for Architecture Work and its central question is: "What do we need to achieve?" The phase establishes the scope, constraints, and high-level aspirational picture of the target state before any detailed architecture work begins in Phases B through D.
Architecture Vision is not a detailed design. It is a directional document — a high-level narrative that describes the business capabilities and value the architecture effort is intended to deliver. It provides the frame within which all subsequent phases operate, ensuring everyone is working toward the same end goal before large investments of time and money are made.
A high-level, aspirational view of the target architecture. It describes the business value and return on investment that the proposed architecture work will deliver. It is solution-concept-level — not a detailed blueprint. It gains sponsor approval before detailed architecture work commences. — TOGAF Standard
The Central Question
The single most important question Phase A answers is: "What do we need to achieve and why?" All other activities in Phase A exist to answer this question in sufficient depth that:
- Sponsors can approve the budget and timeline
- Stakeholders understand the direction and their role
- The architecture team has clear scope boundaries
- The organisation has a documented mandate to proceed
Inputs and Outputs of Phase A
- Request for Architecture Work
- Architecture Principles (from Preliminary)
- Organisational context and strategy
- Architecture Repository (current contents)
- Business Strategy, goals, drivers
- Relevant legislation and regulations
- Existing architecture frameworks and standards
- Prior architecture work (if any)
- Approved Statement of Architecture Work
- Architecture Vision document
- Refined statements of business goals
- Updated Architecture Principles
- Architecture Repository update
- Draft Architecture Definition Document
- Communications plan
- Stakeholder Map / Matrix
OGEA-103 Part 1 questions frequently ask: "What is the FIRST step when a Request for Architecture Work is received?" The answer is always Phase A — Architecture Vision. Do not confuse this with the Preliminary Phase, which established the architecture capability; Phase A is triggered by a specific request to do architecture work on a specific problem.
Section 2: Request for Architecture Work
The Request for Architecture Work (RfAW) is the document that formally triggers Phase A. Without it, Phase A should not begin. It is created by the Architecture Board (or, in organisations without a board, by the sponsoring executive or business leadership) and sent to the architecture team as a mandate to commence an architecture engagement.
A document (sometimes called a "Terms of Reference") that formally requests that the architecture team initiate an ADM cycle. It is typically created by the Architecture Board or the sponsoring organisation and is the trigger for Phase A. It is an input to Phase A — it does not emerge from it.
Contents of a Request for Architecture Work
A well-formed Request for Architecture Work should contain:
- Organisation sponsors — who is commissioning this work
- Business purpose — the business problem or opportunity being addressed
- Business objectives — specific, measurable outcomes expected
- Constraints — regulatory, financial, technical, or political boundaries
- Budget — indicative financial envelope for the architecture engagement
- Timeline — high-level milestones and deadlines
- Assumptions — what must hold true for success
- Risks — known risks at the point of commissioning
- Architecture repository reference — any existing architecture assets to leverage
Triggers for Architecture Work
Not all architecture work begins with a formal RfAW in practice, but the TOGAF standard identifies the following as typical triggers:
- A new business strategy or major strategic shift
- Merger, acquisition, or divestiture
- New regulatory or compliance requirements
- Technology refresh or platform migration
- A significant new IT investment decision
- Conclusion of a previous ADM cycle (iterative re-engagement)
- Output of Phase H (Architecture Change Management) identifying a need for a new cycle
Request for Architecture Work vs Statement of Architecture Work
| Attribute | Request for Architecture Work | Statement of Architecture Work |
|---|---|---|
| Who creates it | Architecture Board or sponsor | Architecture team (in Phase A) |
| When | Before Phase A begins | During Phase A; approved at its end |
| Purpose | Triggers the ADM cycle; sets broad intent | Defines scope, schedule, resources for the engagement |
| Status | Input to Phase A | Output of Phase A; quasi-legal contract |
| Approval | Signed by Architecture Board/sponsor | Signed by sponsor and architecture team lead |
| Level of detail | High-level intent and constraints | Detailed scope, deliverables, acceptance criteria |
The RfAW flows from the sponsor/board to the architecture team. The Statement of Architecture Work flows back from the architecture team to the sponsor for approval. Many candidates reverse these. Remember: Request = trigger = into Phase A. Statement = contract = out of Phase A.
Section 3: Stakeholder Management in Phase A
One of the most critical activities in Phase A is identifying and classifying stakeholders. Architecture work that fails to understand who has power, who has interest, and what each group cares about will produce outputs that are technically correct but politically rejected. TOGAF treats stakeholder management as a formal activity, not an afterthought.
The Power/Interest Grid
The power/interest grid (also called the stakeholder map) classifies stakeholders on two axes:
- Power — authority to make or block decisions
- Interest — the degree to which the outcome affects them
Stakeholder Matrix
Beyond the power/interest grid, TOGAF recommends a stakeholder matrix — a structured table that records, for each stakeholder group:
ISO 42010: Concerns, Viewpoints, and Views
TOGAF draws on ISO/IEC/IEEE 42010 (Systems and software engineering — Architecture description) for its approach to architecture views and viewpoints. Understanding the triangle of concerns, viewpoints, and views is essential for both Part 1 and Part 2 of OGEA-103.
| ISO 42010 Concept | TOGAF Meaning | Example |
|---|---|---|
| Concern | An interest that a stakeholder has in the system; something they need the architecture to address | "Will this system meet our 99.9% uptime SLA?" (Operations Manager concern) |
| Viewpoint | A template or pattern that specifies how to construct a view; defines what to include, what notation to use | The "Availability Viewpoint" specifies that uptime, failover, and RTO/RPO must be shown |
| View | A specific representation of the architecture from a particular viewpoint; the actual document/diagram produced | The Availability View for the Retail Banking Platform — shows actual redundancy topology |
A common Part 1 trap question: "A stakeholder says they want to see the system from a security perspective. What should the architect create?" The answer is: first define a Security Viewpoint (the template), then construct a Security View (the actual artefact) using that viewpoint. Never confuse the template (viewpoint) with the artefact (view).
Section 4: The Architecture Vision Document
The Architecture Vision document is the primary deliverable of Phase A. It is a concise, high-level description of the target state — written for business leadership, not technical teams. Its purpose is to achieve alignment and approval before detailed architecture work begins. Think of it as the "executive summary of the future state."
Contents of the Architecture Vision Document
- Problem description — the business context and what has triggered this architecture engagement
- Objectives and success criteria — how success will be measured
- Scope — what is in and out of scope (domains, business units, timeframes)
- Constraints — regulatory, financial, technical, time-based constraints
- Assumptions — what the architecture team is assuming to be true
- Risks — high-level risks identified at this early stage
- Stakeholder list — who is involved and their relationship to the work
- Architecture Principles — which principles govern this effort
- High-level solution concept — aspirational diagram of the target architecture
- Value chain analysis — how the proposed architecture supports business value creation
- Business capability assessment — gap between current and needed capabilities
High-Level Solution Concept Diagram
One of the most important elements of the Architecture Vision document is the solution concept diagram. This is deliberately high-level — boxes and arrows — showing how proposed capabilities relate to each other and to the business. It is not an architecture design; it is a conversation tool for alignment.
Value Chain Analysis
A value chain analysis within the Architecture Vision document maps how the proposed architecture supports value creation. It identifies primary activities (those that directly create value for the customer) and support activities (those that enable the primary activities). The architecture team should demonstrate which links in the value chain are being improved or transformed.
For the OGEA-103 exam, understand that value chain analysis in Phase A is done at a high level — it is not a detailed process model. Its purpose is to show business leaders that the architecture team understands the business before diving into technical detail.
Business Capability Assessment
A business capability assessment in Phase A identifies the capabilities the organisation has today versus the capabilities it needs to achieve its strategic goals. Gaps become the architecture's primary targets. Capabilities are described at business level — they do not specify how a capability will be implemented in technology.
The Architecture Vision document describes the target state at high level. The Architecture Definition Document (produced across Phases B–D) provides the detailed baseline and target descriptions. In Part 2 scenario questions, if the scenario asks what should happen first after receiving the RfAW, the answer involves producing the Architecture Vision — not the detailed architecture.
Section 5: Statement of Architecture Work
The Statement of Architecture Work (SoAW) is a quasi-legal contract between the architecture team and its sponsor. It is the key approval mechanism at the end of Phase A — the sponsor must sign off on the SoAW before Phases B through D can begin. Without this approval gate, there is no governance over what the architecture team is actually doing.
A document that defines the scope, approach, schedule, resource requirements, and acceptance criteria for an architecture engagement. It is agreed between the architecture team and the sponsor, and serves as the formal mandate for the detailed architecture work in Phases B–D. — TOGAF Standard
Contents of the Statement of Architecture Work
| Section | Contents |
|---|---|
| Title and scope | Name of the engagement; which parts of the enterprise are in scope; which ADM phases will be executed |
| Approach | How architecture work will be conducted; which frameworks, methods, or tailoring will be applied |
| Schedule | Timeline with milestones for each phase; review and approval gates |
| Resource requirements | People, budget, tools, access rights needed for the engagement |
| Deliverables | List of architecture artefacts to be produced; format and distribution |
| Acceptance criteria | How the architecture work will be judged complete and acceptable |
| Risks and issues | Known risks at this stage; mitigation approach |
| Sign-off section | Signatures of sponsor and lead architect; date of agreement |
Sign-Off Process
The sign-off process for the SoAW typically follows these steps:
- Architecture team drafts the SoAW based on Phase A analysis and the Architecture Vision document.
- Draft circulated to key stakeholders for comment and validation.
- Comments incorporated; revised SoAW issued for formal review.
- Architecture Board reviews the SoAW for governance compliance and strategic alignment.
- Business sponsor provides formal sign-off, authorising Phase B onwards.
- Signed SoAW stored in the Architecture Repository as a governance artefact.
Change Requests to the Statement of Architecture Work
Once signed, the SoAW is a governed document. Any change to scope, timeline, resources, or deliverables requires a formal change request. This is critically important: it means that if business requirements change mid-engagement, the architecture team should not simply absorb the change — they should raise a change request to the SoAW, have it reviewed by the Architecture Board, and obtain revised sponsor approval.
The TOGAF standard describes the SoAW as having the status of a "formal agreement." Part 2 scenario questions sometimes present a situation where scope creep is occurring. The correct TOGAF response is to raise a Change Request to the SoAW — not to accommodate the change informally, not to reject it outright, and not to wait until the end of the phase. Governing the scope through the SoAW is the architecture team's responsibility.
Section 6: Business Scenarios
Business Scenarios are a requirements elicitation and documentation technique used in TOGAF to capture, understand, and communicate the business context and requirements that an architecture effort must address. They are particularly useful in Phase A because they translate abstract business goals into concrete, testable architecture requirements.
A technique used to identify and understand the business requirements of architecture. A business scenario describes a real-world situation in enough detail to enable an architect to understand the architecture requirements that must be addressed. It connects business problems to architecture solutions.
The 6-Step Business Scenario Method
- Identify, document, and rank the problem — What is the business problem? Why does it matter? What is the business impact of not solving it?
- Identify the business and technical environment — What processes, systems, and actors are involved? What constraints exist?
- Identify and document objectives — What specific outcomes must the architecture achieve? Define success criteria.
- Identify the human actors — Who are the people (roles) participating in the scenario? What do they need?
- Identify computer actors — What systems, applications, or technology components are involved?
- Document, refine, and validate — Write the scenario; validate it with stakeholders; use it to derive architecture requirements.
How to Write a Good Business Scenario
A well-written business scenario has four key characteristics:
- Problem-oriented — it describes what is wrong or what opportunity exists, not how to fix it
- Business-language — written so a non-technical executive can understand and validate it
- Measurable — includes success criteria that can be objectively assessed
- Traceable — each requirement derived from it can be traced back to a business objective
Example: Digital Transformation Scenario
Problem: GlobalBank's retail customers cannot complete account opening digitally. Customers must visit a branch, creating operational cost pressure and a 23% abandonment rate during the sign-up process. Competitors offer fully digital onboarding in under 5 minutes.
Environment: 450 branches, legacy CRM on mainframe, no API layer, manual KYC process.
Objectives: Reduce account opening time to under 8 minutes; achieve 80% digital channel adoption within 18 months; reduce abandonment rate to below 5%.
Human actors: Retail Customer, Branch Teller, KYC Compliance Officer, IT Operations Team.
Computer actors: Legacy CRM, Identity Verification API (third-party), Mobile Banking App, Core Banking System, Document Management System.
Architecture requirements derived: API gateway capability, digital identity verification integration, event-driven data flow from digital channel to core banking, compliance audit trail for digital KYC.
OGEA-103 exams test whether candidates can distinguish Business Scenarios from Use Cases. Business Scenarios are architecture requirements tools that document the business problem and derive architecture requirements. Use Cases are software engineering tools that document system interactions. Business Scenarios operate at the enterprise/business capability level; use cases operate at the system/function level.
Section 7: Gap Analysis in Phase A
Gap analysis in Phase A is conducted at a high level — it is not the detailed gap analysis performed in Phases B, C, and D. Its purpose is to give the architecture team and sponsors a broad sense of the distance between where the organisation is now (Baseline) and where it needs to be (Target), which in turn informs the scope, timeline, and effort in the Statement of Architecture Work.
Baseline vs Target at High Level
Types of Gaps
OGEA-103 Part 2 questions sometimes present a scenario where an architect has produced a very detailed gap analysis in Phase A. This is usually a wrong answer. Phase A gap analysis is high-level — it feeds the scope and effort estimate in the SoAW. Detailed gap analysis happens in Phases B, C, and D, for each architecture domain. Producing too much detail in Phase A wastes effort and constrains the design space too early.
Section 8: Architecture Vision and the Part 2 Exam
Phase A appears frequently in OGEA-103 Part 2 scenario-based questions. The questions test whether candidates understand the purpose of Phase A activities and can select the most appropriate action given a realistic business situation. This section maps the key decision points and common question patterns.
Scenario-Based Question Patterns
| Scenario Situation | Correct TOGAF Response | Why |
|---|---|---|
| Business sponsor wants to skip Architecture Vision and go straight to technical design | Explain the value of Architecture Vision as an alignment tool; produce a concise Architecture Vision to gain approval first | Phase A creates the mandate and shared understanding that prevents wasted detailed design work |
| Scope expands mid-Phase A due to new stakeholder requirements | Assess the impact; if significant, raise a Change Request to the SoAW and obtain revised approval | SoAW governs scope; informal scope changes undermine governance |
| Two stakeholders have conflicting concerns about the architecture direction | Escalate to Architecture Board; use viewpoints and views to separately address each concern | Different viewpoints allow the same architecture to address different concerns simultaneously |
| Architecture team cannot identify a clear baseline because no prior architecture work exists | Document the lack of baseline; conduct a lightweight as-is assessment; proceed with a high-level baseline description | A missing baseline is itself an architectural fact; work cannot stop because documentation is absent |
| CEO asks for a detailed solution design at the Architecture Vision review meeting | Explain that Architecture Vision is intentionally high-level; commit to detailed design in Phases B–D after SoAW approval | Premature detail in Phase A constrains the architecture and wastes effort before scope is agreed |
Evaluating Answer Options in Part 2
OGEA-103 Part 2 questions present four options, typically ranked in descending appropriateness (A=best, B=acceptable, C=poor, D=worst). When evaluating options for Phase A questions, apply this thinking framework:
- Does the answer respect the governance model? — Options that bypass the Architecture Board or sign-off process are always penalised.
- Does the answer maintain the right level of detail? — Phase A is high-level. Options proposing detailed technical design in Phase A score poorly.
- Does the answer engage stakeholders appropriately? — Options that exclude or ignore stakeholders with power score lower than options that engage them.
- Does the answer produce the right deliverable? — Phase A produces Architecture Vision and SoAW. Options that produce Phase B/C/D deliverables in Phase A are incorrect.
- Does the answer follow TOGAF phase sequence? — TOGAF ADM phases must follow the prescribed sequence unless explicitly tailored. Skipping phases without a documented tailoring decision is wrong.
In Part 2, there is always one best answer. The other options are not necessarily wrong — they may be partially correct or appropriate in a different context. The best answer is the one that: (1) is most aligned with the TOGAF standard, (2) addresses the most important concern in the scenario, and (3) follows correct governance procedure. When stuck, eliminate answers that bypass governance or produce wrong-phase deliverables first.
Common Mistakes in Phase A
- Treating the Architecture Vision document as a detailed design — it is intentionally high-level and aspirational.
- Confusing the Request for Architecture Work (an input) with the Statement of Architecture Work (an output).
- Starting Phase B before the Statement of Architecture Work is formally approved by the sponsor.
- Confusing architecture viewpoints (templates) with architecture views (the actual artefacts produced).
- Performing detailed gap analysis in Phase A — this belongs in Phases B, C, and D.
- Ignoring the power/interest grid and treating all stakeholders identically in communications.
- Failing to document constraints and assumptions — these shape all downstream architecture decisions.
- Producing business scenarios that describe the solution (how) rather than the problem (what and why).
Revision Summary — Chapter 03: Architecture Vision (Phase A)
- Phase A is the first lettered ADM phase, triggered by a Request for Architecture Work; its central question is "What do we need to achieve?"
- The Request for Architecture Work is created by the Architecture Board or sponsor and is an input to Phase A — it does not come out of it.
- The Statement of Architecture Work is a quasi-legal contract produced during Phase A and must be signed by the sponsor before Phases B–D begin.
- Stakeholder management uses the power/interest grid and a stakeholder matrix to classify stakeholders and plan engagement.
- ISO 42010 defines: Concerns (what stakeholders need addressed) → Viewpoints (templates for views) → Views (the actual artefacts produced).
- The Architecture Vision document is high-level and aspirational — it includes a solution concept diagram, value chain, and business capability assessment.
- Business Scenarios are a 6-step technique to capture business problems and derive architecture requirements — they are not use cases.
- Phase A gap analysis is high-level only — it identifies broad people, process, technology, and data gaps to scope the SoAW; detailed gaps are found in Phases B–D.
- Part 2 exam answers that bypass governance, produce wrong-phase deliverables, or exclude key stakeholders are always ranked lower.
Practice Questions
A. Phase A (Architecture Vision) must be completed and the Statement of Architecture Work approved before Phase B commences, regardless of time pressure.
B. Phase A can be abbreviated but some elements should still be documented concurrently with Phase B.
C. If the Architecture Board has approved the programme, the architect may proceed directly to Phase B as the board approval substitutes for Phase A outputs.
D. Phase A should be completed but the Statement of Architecture Work can be signed retrospectively once Phase B is underway.
Explanation: Option A is correct. The TOGAF standard requires Phase A to be completed and the Statement of Architecture Work formally approved before Phase B begins. This is not a bureaucratic formality — the SoAW defines the scope, deliverables, and acceptance criteria that govern all subsequent phase work. Architecture Board approval of the programme is a trigger for Phase A (the Request for Architecture Work), not a substitute for Phase A outputs. Option B is wrong because running phases concurrently without the SoAW creates uncontrolled scope. Option C confuses the RfAW trigger with the Phase A outputs. Option D is wrong because retrospective sign-off defeats the governance purpose of the SoAW.
A. An Architecture Principle governing availability requirements.
B. An Architecture Viewpoint that documents the IT Operations Manager's concerns.
C. An Architecture Viewpoint that specifies how to represent availability concerns, and an Architecture View constructed from that viewpoint to present to the stakeholder.
D. An Architecture View that documents the stakeholder's concerns about availability.
Explanation: Option C is correct. ISO 42010 (adopted by TOGAF) distinguishes between a viewpoint (a template or specification that defines what to include in a view and how) and a view (the actual artefact produced for that stakeholder's concerns). The architect must first establish the viewpoint (the "how to represent") and then construct the view (the actual representation). Option A is wrong — Architecture Principles govern decisions but do not address concerns through representation. Option B confuses a viewpoint with a document about concerns. Option D confuses a view with a document about concerns — views show the architecture, not the concerns themselves.
A. Produce the detailed technical design immediately to satisfy the sponsor's procurement timeline, then document the Architecture Vision retrospectively.
B. Explain that Phase A produces a high-level Architecture Vision and solution concept; detailed designs will be produced in Phases B–D once the Statement of Architecture Work is approved, and that proceeding to procurement without this creates significant risk.
C. Produce both the Architecture Vision and the detailed technical design in parallel to meet the sponsor's request.
D. Escalate to the Architecture Board immediately to request special dispensation to skip to Phase C (Information Systems Architecture).
Explanation: Option B is correct. The Architecture Vision is deliberately high-level — it is not a detailed design. Producing detailed specifications in Phase A skips the alignment activities that prevent expensive rework later. The architect must diplomatically but firmly explain the risk of premature detailed design and the value of the ADM sequence. Option A is wrong — producing detailed designs before scope (SoAW) is agreed creates rework risk and governance failure. Option C wastes effort on detail before scope is confirmed. Option D is wrong — escalation to the board is not warranted for a common sponsor request; the architect should handle this through explanation and governance.
A. Raise a formal Change Request to the Statement of Architecture Work, have it reviewed by the Architecture Board, and obtain revised sponsor approval before continuing.
B. Continue absorbing the additional work informally and document the full scope once Phase D is complete.
C. Reject all additional scope requests and insist on strictly following the original SoAW.
D. Document the additional work as a new separate ADM cycle to avoid modifying the signed SoAW.
Explanation: Option A is correct. The Statement of Architecture Work is a governed document. Any change to scope requires a formal Change Request, Architecture Board review, and revised sponsor approval. Informal scope absorption undermines governance, distorts resource planning, and may invalidate the acceptance criteria originally agreed. Option B is wrong — informal changes to governed documents are a governance failure. Option C is wrong — rigid rejection of all changes is impractical and ignores legitimate business evolution. Option D is wrong — creating a new ADM cycle for scope that belongs to the current engagement creates duplication and confusion.
A. Business scenarios are preferred because they use more formal notation than use cases, making them easier to store in the Architecture Repository.
B. Use cases are acceptable — business scenarios and use cases are interchangeable in TOGAF.
C. Business scenarios operate at the business capability and enterprise level, capturing business problems and deriving architecture requirements. Use cases operate at the system and function level and are appropriate later in the development lifecycle, not as an enterprise architecture requirements technique.
D. Business scenarios are preferred because they are mandated by the TOGAF standard, whereas use cases are not mentioned anywhere in TOGAF.
Explanation: Option C is correct. Business Scenarios are specifically designed to capture business problems in business language and derive architecture requirements from them. They are enterprise-level tools. Use cases are system-level tools that describe how users interact with a specific system — they come much later in the lifecycle and do not capture the enterprise capability context that architecture requirements require. Option A is wrong — the preference is about purpose and level, not notation formality. Option B is wrong — they are not interchangeable. Option D is partially true that scenarios are preferred but wrong to say use cases are not mentioned in TOGAF — the issue is their appropriate level of abstraction.