Phase A: Architecture Vision
Start the cycle: set scope, identify stakeholders, create the Vision, and get approval to proceed.
About this phase
Phase A starts an iteration of the architecture development cycle. It is triggered by a Request for Architecture Work from the sponsoring organization. The phase sets the scope, constraints, and expectations for the project, validates the business context, and creates the Statement of Architecture Work.
The Architecture Vision itself is a high-level, aspirational view of the Target Architecture — an elevator pitch that sells the benefits of the proposed capability to decision-makers. It describes how the new capability will meet business goals and strategic objectives and address stakeholder concerns when implemented.
Two important techniques in this phase are business scenarios (to discover and document business requirements) and the Business Transformation Readiness Assessment (to evaluate the organization's readiness to undergo change). Securing formal approval of the Statement of Architecture Work closes the phase.
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.
Steps in this phase
0/11 · 0%Key inputs
- Request for Architecture Work
- Business principles, business goals, and business drivers
- Organizational Model for Enterprise Architecture
- Tailored Architecture Framework, including Architecture Principles
- Populated Architecture Repository (existing architecture documentation)
Key outputs
- Approved Statement of Architecture Work
- Architecture Vision — including refined key high-level stakeholder requirements
- Refined statements of business principles, goals, and drivers
- Capability Assessment
- Communications Plan
- Draft Architecture Definition Document (may include baseline/target Business, Data, Application, and Technology Architectures at a high level)
- Additional content populating the Architecture Repository
Worked example — Meridian Retail Group
Generated sample documents for a fictional company, showing what this phase consumes and produces. They are illustrative study aids, not templates from the standard.
Example inputs
example inputCatalogfrom PreliminaryA sample set of Architecture Principles in the standard four-part TOGAF template: Name, Statement, Rationale, Implications.
Meridian Retail Group — Architecture Principles v1.0
Approved by: Architecture Board, 14 March 2026 Owner: Lead Architect · Review cycle: annually, or when Phase H raises a change
Principles catalog (summary)
| # | Name | Domain | Derived from (business principle / driver) |
|---|---|---|---|
| 1 | Business Continuity | Business | Customer first |
| 2 | Data is an Asset, Shared, and Accessible | Data | One Meridian, not many |
| 3 | Buy Before Build | Application | Spend once |
| 4 | Interoperability | Technology | Spend once, integration cost driver |
| 5 | Compliance with Law and Regulation | Business | Regulatory pressure (GDPR, PCI-DSS) |
Principle 1: Business Continuity
Statement: Enterprise operations are maintained in spite of system interruptions.
Rationale: Store trading and online checkout are revenue-critical. As systems become more integrated under One Meridian, dependence on shared services increases and interruptions have wider impact.
Implications:
- Shared services must be designed for resilience and graceful degradation
- Recoverability and redundancy requirements must be defined at design time
- Applications must be assessed for criticality and assigned availability tiers
Principle 2: Data is an Asset, Shared, and Accessible
Statement: Data is a corporate asset with defined ownership; it is shared across functions and accessible to authorized users through common services.
Rationale: The single largest obstacle to the One Meridian strategy is fragmented customer, product, and inventory data held in silos.
Implications:
- Each key data entity is assigned a business data owner (trustee)
- Applications consume master data from designated authoritative sources
- Data sharing must comply with Data Governance Council privacy policies
Principle 3: Buy Before Build
Statement: Packaged and SaaS solutions are preferred over custom development unless a capability is a source of competitive differentiation.
Rationale: Meridian's differentiation is retail experience, not software engineering. Custom systems have driven maintenance cost and key-person risk.
Implications:
- Requirements should be adapted to standard product capability where possible
- A build decision requires an approved exception with business justification
- Vendor and integration standards must be defined and maintained
Principle 4: Interoperability
Statement: Software and hardware conform to defined standards that promote interoperability of data, applications, and technology.
Rationale: Integration cost across the current fragmented landscape is the largest single component of IT change spend.
Implications:
- An integration standard (APIs, events) is defined and governed
- Deviations are managed through a documented exceptions process
- Standards are reviewed periodically by the Architecture Board
Principle 5: Compliance with Law and Regulation
Statement: Architecture decisions comply with applicable law, regulation, and contractual obligations in every country where Meridian trades.
Rationale: Unifying customer data across channels increases GDPR exposure, and payment flows fall under PCI-DSS. A breach would undo the trust that One Meridian depends on.
Implications:
- Consent and lawful basis are designed into customer data flows, not added later
- PCI-DSS scope is kept as small as possible and documented for each solution
- The CISO and Data Protection Officer review designs that process personal data
Using these principles
- Every deliverable submitted to the Architecture Board states which principles it supports and any it departs from.
- A departure is handled as a time-bound dispensation (see the Architecture Governance Framework). A departure that should be permanent is raised as a Change Request against the principle itself.
- When principles conflict (for example Buy Before Build against Interoperability for a closed SaaS product), the Board records how it weighed them in the Governance Repository.
Example outputs
example outputDeliverableThe approved 'contract' for the architecture project — scope, plan, roles, and acceptance criteria for this ADM cycle.
Statement of Architecture Work
Project: One Meridian — Unified Customer Experience Architecture Reference: SAW-2026-001 (responds to RAW-2026-001) Status: Approved by Architecture Board, 30 April 2026
1. Architecture project description and scope
Develop Baseline and Target Architectures across all four domains (Business, Data, Application, Technology) for customer-facing commerce capabilities: customer identity and profile, ordering, inventory visibility, loyalty, and cross-channel fulfilment. Out of scope: finance/ERP, HR, franchise POS replacement (constrained until FY27 contract renewal).
- Breadth: Digital Commerce, Store Operations, Customer Care, Supply Chain (inventory visibility only)
- Depth: capability level for the enterprise; logical level for in-scope capabilities
- Time period: Target defined for FY28; Transition Architectures at 6-month intervals
2. Overview of the Architecture Vision
See Architecture Vision v1.0 (AV-2026-001): a shared Customer Profile Service and real-time inventory view enabling recognition and fulfilment in any channel.
3. Change of scope procedures
Scope changes are raised as Change Requests to the Architecture Board via the Requirements Management process.
4. Roles, responsibilities, and deliverables
| Role | Name/Group | Deliverables |
|---|---|---|
| Lead Architect | J. Okafor | Architecture Definition Document, Roadmap |
| Business Architect | T. Lindqvist | Business Architecture (Phase B) |
| Data + Application Architects | R. Mehta, S. Cho | Information Systems Architectures (Phase C) |
| Technology Architect | A. Duarte | Technology Architecture (Phase D) |
| Sponsor | COO | Approvals at phase boundaries |
5. Acceptance criteria and procedures
Deliverables accepted by the Architecture Board with sponsor sign-off; compliance with Architecture Principles v1.0 verified per deliverable.
6. Plan and schedule
- Phases B–D: May–August 2026
- Phases E–F: September–October 2026 (plan approved before peak freeze)
- Estimated architecture effort: 220 person-days
Study tips & key concepts
- The trigger for Phase A is the Request for Architecture Work; the key approval that ends it is the Statement of Architecture Work — think of it as the contract between the architecture organization and the sponsor.
- The Architecture Vision is the 'elevator pitch' — a first-cut, high-level description of Baseline and Target Architectures used to build consensus and secure funding.
- Stakeholder management: a Stakeholder Map classifies stakeholders (e.g., by power/interest) and records their concerns, and which viewpoints/views address them.
- Business scenarios are the recommended technique to discover and document business requirements; a good business scenario is SMART (Specific, Measurable, Actionable, Realistic, Time-bound).
- The Business Transformation Readiness Assessment evaluates factors such as vision, desire, need, funding, and governance — its findings become risks to manage.
- Risk management distinguishes initial risk (before mitigation) from residual risk (after mitigation).