3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition
Key Takeaways
Phase A has two objectives: develop a high-level aspirational vision of the capabilities and business value to be delivered, and obtain approval for a Statement of Architecture Work.
Phase A's eleven steps include assessing readiness for business transformation and identifying business transformation risks with their initial and residual levels.
The Request for Architecture Work comes from the sponsoring organization; it can also be an optional Preliminary output or be raised by Phase F or Phase H for a new cycle.
Scoping defines breadth, depth, time period, and architecture domains, plus partitioning characteristics and the repository assets to be reused.
The Statement of Architecture Work, Architecture Vision, and Communications Plan are the Phase A outputs needed to proceed with architecture development.
3.1 Phase A Objectives, Request for Architecture Work, and Scope Definition
Phase A (Architecture Vision) represents the formal inception of an Architecture Development Method (ADM) cycle. While the Preliminary Phase establishes the organizational architecture capability, governance structures, and enterprise-wide architecture principles, Phase A translates an executive business imperative into a bounded, actionable architecture project. Enterprise architects must understand how to ingest triggering business mandates, structure project boundaries, validate strategic drivers, and prevent fatal scope expansion before detailed architectural modeling begins.
The Strategic Mandate of Phase A: Architecture Vision
The fundamental purpose of Phase A is to articulate a compelling, high-level vision of the target enterprise capabilities and secure formal executive authorization to expend organizational resources on architecture development. Phase A does not attempt to produce comprehensive, low-level technical specifications; rather, it establishes the strategic perimeter and business rationale for all subsequent ADM activities (Phases B through H).
The TOGAF Standard, 10th Edition gives Phase A two objectives:
- 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.
It achieves them through eleven steps:
- Establish the architecture project
- Identify stakeholders, concerns, and business requirements
- Confirm and elaborate business goals, business drivers, and constraints
- Evaluate capabilities
- Assess readiness for business transformation (Section 8.5)
- Define scope
- Confirm and elaborate Architecture Principles, including business principles
- Develop the Architecture Vision
- Define the Target Architecture value propositions and KPIs
- Identify the business transformation risks and mitigation activities, assessing the initial and residual level of risk
- Develop the Statement of Architecture Work and secure approval
The Level 2 learning outcomes add a practitioner angle. You should know what information Phase A needs and how later iterations will add to it, and how much security-specific architecture design the engagement needs to be sufficient. You should also be able to produce the three outputs that let architecture development proceed: the Statement of Architecture Work, the Architecture Vision, and the Communications Plan.
Without a disciplined Phase A execution, architecture teams frequently descend into "analysis paralysis" or embark on broad technical redesigns that lack executive sponsorship, clear ownership, or measurable business value.
Deconstructing the Request for Architecture Work (RfAW)
An ADM cycle does not begin in a vacuum. It is triggered by a formal business communication known as the Request for Architecture Work (RfAW). The RfAW is produced by the sponsoring organization (a business executive, steering committee, or business unit leadership) seeking architecture work to address a strategic opportunity or problem. TOGAF also lists it as an optional output of the Preliminary Phase, and Phases F and H can raise a new RfAW to start another ADM cycle.
Essential Contents of an RfAW
A comprehensive Request for Architecture Work typically contains:
- Sponsoring Organization and Mandate: Identification of executive leadership holding budget authority and operational accountability.
- Business Mission and Strategic Drivers: Market imperatives, regulatory changes, customer experience initiatives, or cost-reduction mandates driving the request.
- Target Business Goals and KPIs: Quantifiable objectives, such as reducing loan origination cycle times by 40% or achieving compliance with revised data protection mandates.
- Strategic Constraints and Assumptions: Predetermined boundaries, such as mandatory integration with legacy core transactional ledgers, hard delivery deadlines, or target investment caps (e.g., maximum initial capital expenditure of $5M).
- Organizational Context and Change Triggers: Recent corporate mergers, strategic divestitures, or competitive disruptions prompting the engagement.
Architectural Evaluation of the RfAW
Enterprise architects do not accept an RfAW at face value. A critical practitioner responsibility during Phase A is conducting a rigorous architectural evaluation of the incoming request:
- Verify Executive Authority: Does the sender possess the organizational influence and budgetary backing required to sustain multi-phase transformation across business and technology domains?
- Check Principle Alignment: Does the requested direction violate overarching Enterprise Architecture Principles defined in the Preliminary Phase (e.g., "Buy vs. Build Commercial Solutions" or "Data as a Shared Asset")?
- Evaluate Feasibility and Completeness: Are the stated timeframes, budget envelopes, and business outcomes realistic, or does the request contain unstated, mutually contradictory assumptions?
If the RfAW is ambiguous, unrealistic, or unaligned with enterprise principles, the enterprise architect must collaborate with the sponsor to refine the request before committing the team to a Statement of Architecture Work.
Architecture Scoping: Breadth, Depth, Time Horizon, and Domains
One of the most consequential decisions made in Phase A is establishing the scope of the architecture activity. Scope determines the perimeter of investigation, the depth of architectural models, and the boundaries of governance authority. In the TOGAF Standard, architecture scope is defined across four main dimensions. Phase A's "Define scope" step also records the partitioning characteristics of the architecture and the architectural assets to be leveraged from the Architecture Repository:
1. Breadth (Horizontal Boundary)
Breadth defines the organizational and functional footprint encompassed by the architecture project. Does the engagement cover the entire enterprise, an entire business division (e.g., Consumer Lending), a specific cross-functional value stream (e.g., Order-to-Cash), or a single operational capability? Attempting to execute an enterprise-wide scope in a single, monolithic ADM cycle is a primary cause of project collapse.
2. Depth (Level of Granularity)
Depth dictates the level of detail required in the architectural artifacts:
- Strategic Architecture: High-level enterprise summary used for executive investment allocation and long-range planning.
- Segment Architecture: Operating-model level detailing business capabilities, data subject areas, and application portfolios for a specific business unit or value stream.
- Capability / Solution Architecture: Fine-grained technical and operational blueprints detailing service boundaries, integration patterns, and system components.
Phase A explicitly declares whether the current iteration will stop at segment-level abstractions or drive down to capability-level solution requirements.
3. Time Horizon (Planning Period)
The time horizon defines the temporal span between the Baseline ("As-Is") Architecture and the Target ("To-Be") Architecture. Common horizons include:
- Tactical Transition (0 to 12 months): Focused on immediate risk mitigation, regulatory compliance, or technical debt removal.
- Strategic Target (2 to 5 years): Focused on comprehensive capability transformation, cloud re-platforming, or digital business model enablement.
4. Architecture Domains Included
While TOGAF defines four core architecture domains (Business, Data, Application, and Technology—BDAT), not every ADM cycle addresses all four equally. A business restructuring project might focus deeply on Phase B (Business Architecture) with minimal changes to Phase D (Technology Architecture). Conversely, an infrastructure migration to public cloud platforms will focus heavily on Phases C and D, treating Phase B as fixed baseline constraints.
Translating Business Goals, Strategic Drivers, and KPIs into Architecture Drivers
Architectures deliver value only when technical structures directly support executive business outcomes. During Phase A, enterprise architects must translate abstract corporate strategy statements into concrete architecture drivers.
A business strategy statement such as "Expand rapidly into European retail financial services while cutting customer acquisition overhead" is too high-level for technical design. The architect methodically decomposes this strategic driver into architectural requirements:
| Business Strategic Driver | Target Business KPI | Derived Architecture Driver | Domain Impact |
|---|---|---|---|
| Rapid International Market Entry | Launch digital services in 3 new jurisdictions within 14 months | Multi-tenant regionalized platform supporting localization and independent regulatory hosting | Application & Technology |
| Regulatory & Sovereign Compliance | Zero statutory non-compliance audit findings | Cross-border data residency partitioning and automated GDPR/local privacy enforcement | Data & Business |
| Lower Customer Acquisition Cost | Reduce customer onboarding cost from $85 to under $20 per user | Straight-through digital identity verification via national identity provider APIs | Business & Application |
| High Availability & Brand Trust | 99.99% transaction processing availability during market peaks | Active-active geo-distributed ledger deployment with automatic failover | Technology & Data |
By establishing these explicit linkages in Phase A, the architect creates an auditable chain of traceability connecting every downstream database entity, microservice interface, and cloud infrastructure component directly back to an approved corporate business goal.
Practitioner Traps: Preventing Scope Creep and Misaligned Expectations
Experienced enterprise architects guard against predictable pitfalls during Phase A:
- Boiling the Ocean: Expanding the architecture scope to encompass every adjacent system, team, and legacy process. When scope expands uncontrollably, Phase A never finishes, no Statement of Architecture Work is approved, and executive sponsors lose faith in the enterprise architecture function.
- Confusing Solution Architecture with Enterprise Architecture: Diving into specific technology product evaluations, container orchestration scripts, or vendor negotiations during Phase A. Phase A defines what business capabilities are required and why, not the implementation code.
- Accepting Unfunded Mandates: Accepting an RfAW with immense strategic ambition but zero allocated capital, executive authority, or dedicated subject matter expert (SME) availability. If the executive sponsor cannot commit budget or staff time to the SoAW, the project is destined to fail.
- Unchallenged Assumptions: Assuming that legacy constraints stated in the RfAW are immutable. An executive might assert that "we must build our own custom billing engine," when industry COTS solutions exist that reduce delivery time by 70%. The architect must diplomatically challenge and validate constraints using objective architectural principles.
Comparative Analysis: Request for Architecture Work vs. Statement of Architecture Work
A frequent testing area on practitioner examinations is the structural and contractual distinction between the document that initiates Phase A and the document that concludes it:
| Dimension | Request for Architecture Work (RfAW) | Statement of Architecture Work (SoAW) |
|---|---|---|
| Origin / Source | Sponsoring organization (or an optional Preliminary output; Phases F and H can raise new ones) | Developed by the architecture team in Phase A, reviewed with the sponsor, and approved under the appropriate governance procedures |
| ADM Timing | Primary initiating input to Phase A | Foundational approved output and exit deliverable of Phase A |
| Governance Authority | Advisory request and business proposal; carries no binding project commitments | Contractually binding charter and governance baseline for ADM Phases B through H |
| Level of Detail | High-level business problem statement, target outcomes, and proposed budget | Detailed scope boundaries, work packages, milestones, deliverables, resource plan, and metrics |
| Primary Purpose | Triggers an investigation into the feasibility and desirability of an architecture project | Formally authorizes expenditure of budget, commits architecture resources, and locks project scope |
| Acceptance Criteria | General business expectations and desired performance indicators | Explicit, measurable, and auditable acceptance criteria for architecture deliverables |
Which of the following describes the fundamental distinction between the Request for Architecture Work (RfAW) and the Statement of Architecture Work (SoAW)?
The RfAW is the sponsor's request that triggers an architecture cycle, while the SoAW is the agreement developed in Phase A that governs the work.
The RfAW provides the final baseline architecture models for the engagement, while the SoAW defines only the initial problem statement.
The RfAW is created by the lead enterprise architect in the Preliminary Phase, whereas the SoAW is later authored by software solution architects in Phase G.
The RfAW names the implementation technology vendors, while the SoAW is limited to business strategy principles and stakeholder goals.
During Phase A scoping, an executive sponsor demands that the architecture team extend an active core banking modernization project to simultaneously encompass two newly acquired overseas retail branches, but specifies that the delivery date and the $2.5M budget must remain unchanged. How should the enterprise architect respond?
Accept the new scope immediately and lower the quality criteria for the architecture deliverables so that the existing deadline and fixed budget can still be met.
Assess the impact on breadth, depth, and resources, then present trade-off options: extend the time horizon, increase the budget, or defer the branches to a later ADM iteration.
Refuse the request outright, because once the Request for Architecture Work has been received Phase A does not allow changes to the business drivers or engagement scope.
Keep the original scope while recording the overseas branches in an appendix as out-of-scope technology, so the request is documented without being acted on.
According to the TOGAF Standard, which set of activities represents core objectives of Phase A (Architecture Vision)?
Selecting physical server hardware, installing the database software, and writing the first application code so the vision can be demonstrated early.
Conducting post-implementation audits of deployed systems and decommissioning obsolete legacy mainframes identified in the previous architecture cycle.
Validating business principles and goals, defining scope, identifying stakeholders, and obtaining approval for the Statement of Architecture Work.
Producing detailed class diagrams, database schemas, and network routing tables so that deployment teams can start building the target state.
Sections you finish are checked off in the contents.