3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
Key Takeaways
The Architecture Vision deliverable articulates the high-level baseline and target architecture summaries, value proposition, and solution concept.
The Communications Plan sets out where, how, and when the architects will communicate with each stakeholder group, using the classes from the Stakeholder Map.
The Statement of Architecture Work (SoAW) functions as the binding charter and formal governance contract between the architecture team and executive leadership for Phases B through H.
Formal sign-off on the SoAW by the Executive Sponsor is the mandatory Phase A governance gate required before committing enterprise resources to Phase B.
3.4 Architecture Vision, Communications Plan, and Statement of Architecture Work Approval
Phase A serves as the critical gating mechanism of the entire TOGAF Architecture Development Method (ADM). Up to this point, the enterprise architect has ingested the triggering business mandate, scoped project boundaries, analyzed stakeholders, and elicited authentic business requirements. The final activities of Phase A assemble these findings into three foundational deliverables: the Architecture Vision, the Communications Plan, and the Statement of Architecture Work (SoAW). Securing formal executive sponsor approval on the SoAW represents the non-negotiable governance exit gate of Phase A, authorizing the architecture team to commit capital, mobilize subject matter experts, and transition into detailed architectural modeling in Phase B.
Assembling the Architecture Vision Deliverable
The Architecture Vision is the primary public-facing deliverable of Phase A. It provides executive sponsors, operational leaders, and technical teams with a shared mental model of the future state enterprise. Rather than presenting low-level technical specifications, the Architecture Vision communicates strategic business intent and architectural direction in clear, compelling, executive-ready language.
Typical Contents of the Architecture Vision
The TOGAF Standard lists the typical contents of the Architecture Vision deliverable as:
- Problem description: the stakeholders and their concerns, and the issues or scenarios to be addressed.
- Objective of the Statement of Architecture Work.
- Summary views: the views needed for the Request for Architecture Work, plus first-cut (version 0.1) Business, Data, Application, and Technology Architectures.
- Business scenario (optional).
- Refined key high-level stakeholder requirements.
In practice architects also make the value proposition explicit. Phase A step 9 asks for the business case, value propositions for each stakeholder group, and KPIs, and these are incorporated into the Statement of Architecture Work so performance can be tracked. A common way to communicate the vision is a simple Solution Concept diagram: a high-level picture of the major components of the solution and how they benefit the enterprise, free of vendor or deployment detail so non-technical leaders can follow it.
Formulating and Tailoring the Communications Plan
Communication is not an ad-hoc, informal task; in the TOGAF Standard, it is a managed architectural discipline. The Communications Plan created in Phase A ensures that relevant, accurate, and consistent architectural information reaches the right stakeholders at the right time through appropriate channels.
The enterprise architect builds the Communications Plan by directly cross-referencing the Power/Interest Grid developed during stakeholder analysis:
┌────────────────────┬─────────────────────────────────┬───────────────────┬──────────────────────┐
│ Stakeholder Group │ Communication Content │ Delivery Channel │ Frequency & Cadence │
├────────────────────┼─────────────────────────────────┼───────────────────┼──────────────────────┤
│ Key Players │ Strategic decision papers, │ Face-to-face │ Bi-weekly sprint │
│ (Sponsor, CIO, BU) │ milestone reviews, risk logs, │ steering sessions,│ check-ins, monthly │
│ │ trade-off matrices, budget state│ executive decks │ governance reviews │
├────────────────────┼─────────────────────────────────┼───────────────────┼──────────────────────┤
│ Keep Satisfied │ Statutory compliance briefs, │ Formal executive │ Monthly audit notes, │
│ (CISO, CRO, Legal) │ security architecture summaries,│ memos, governance │ regulatory milestone │
│ │ data sovereignty audit proofs │ dashboards │ checkpoints │
├────────────────────┼─────────────────────────────────┼───────────────────┼──────────────────────┤
│ Keep Informed │ Solution roadmaps, operational │ Town halls, demos,│ Monthly release │
│ (Users, Ops, Devs) │ impact notes, brown-bag demos, │ video walkthroughs│ webinars, bi-weekly │
│ │ training schedules, API changes │ intranet portal │ team newsletters │
├────────────────────┼─────────────────────────────────┼───────────────────┼──────────────────────┤
│ Minimal Effort │ High-level project milestones, │ Enterprise-wide │ Quarterly digital │
│ (Peripheral Teams) │ strategic value realization │ newsletter, portal│ bulletin updates │
│ │ summaries, general announcements│ summary │ │
└────────────────────┴─────────────────────────────────┴───────────────────┴──────────────────────┘
The Communications Plan also establishes bi-directional feedback mechanisms. It provides formal grievance channels, architecture request-for-clarification portals, and operational feedback loops so that emergent concerns from front-line engineers or business analysts are surfaced and evaluated before designs are finalized.
Developing the Statement of Architecture Work (SoAW)
The most critical governance deliverable produced in Phase A is the Statement of Architecture Work (SoAW). While the Request for Architecture Work (RfAW) initiated the engagement with informal business aspirations, the SoAW transforms those aspirations into a formal, binding contract between the architecture team and executive leadership.
Typical Contents of the Statement of Architecture Work
The TOGAF Standard lists the typical contents of the Statement of Architecture Work as:
- Statement of Architecture Work title
- Architecture project request and background
- Architecture project description and scope
- Overview or outline of the Architecture Vision
- Managerial approach
- Change of scope procedures
- Roles, responsibilities, and deliverables
- Acceptance criteria and procedures
- Architecture project plan and schedule
- Approvals
Phase A step 11 explains what goes into it. The team decides which domains to develop, to what level of detail, and which views to build. It estimates resources, develops a roadmap and schedule for the ADM cycle, defines the performance metrics the EA team must meet, and develops the Communications Plan. The plans are then reviewed and agreed with the sponsors, formal approval of the Statement of Architecture Work is secured under the appropriate governance procedures, and the sponsor signs off to proceed. Explicit statements of what is excluded from scope are as useful as statements of what is included.
The Phase A Governance Gate: Sponsor Sign-Off and Phase Transition
The conclusion of Phase A is marked by a formal governance gate review. In TOGAF, transitioning from Phase A to Phase B is never automatic; it requires explicit, written approval.
The Review and Sign-Off Process
- Architecture Board Conformance Review: Prior to presenting the SoAW to the executive sponsor, the lead architect submits the draft Architecture Vision and SoAW to the enterprise Architecture Board. The Board verifies that the proposed scope complies with enterprise-wide architecture principles, avoids duplicating existing organizational initiatives, and leverages shared enterprise building blocks.
- Executive Sponsor Gate Review: The lead architect conducts a formal gate review meeting with the primary business executive sponsor. The architect presents the Architecture Vision, demonstrates alignment with the initiating RfAW, explains the trade-offs evaluated, walks through the resource and budget requirements, and reviews the explicit acceptance criteria.
- Formal Contractual Sign-Off: The Executive Sponsor signs the Statement of Architecture Work. This signature represents a binding organizational commitment: it secures the required project funding, authorizes the assignment of departmental subject matter experts, and empowers the architecture team with governance authority across subsequent ADM phases.
If the sponsor refuses to sign due to budget restrictions or scope disagreements, the architect does not proceed to Phase B. The architect iterates within Phase A, adjusting the scope boundaries, reducing the depth of models, or extending the time horizon until an acceptable SoAW is negotiated.
Common Practitioner Traps at the Phase A Gate
Enterprise architects must navigate treacherous failure modes during the final steps of Phase A:
- The "Gentleman's Agreement" Fallacy: Relying on verbal executive enthusiasm or informal email confirmations instead of a formally executed SoAW. When project schedules compress or budget cuts occur in Phase C, projects lacking a signed SoAW find their resources confiscated and their authority questioned.
- Premature Transition to Phase B Modeling: Commencing detailed Business Architecture process modeling or Application Architecture cataloging before the SoAW is signed. Architecture work performed without an approved SoAW represents unbudgeted, unauthorized effort that frequently must be scrapped when executive priorities shift.
- Vague or Subjective Acceptance Criteria: Writing acceptance criteria such as "Deliverables must be acceptable to business leadership." In Phase G compliance reviews, subjective criteria lead to bitter disputes. Acceptance criteria must be objective and measurable (e.g., "The Architecture Definition Document must contain approved catalogs for all core banking capabilities, data entity/business function matrices, and transition roadmaps signed off by the Chief Risk Officer").
- Treating the Vision as Immutable Dogma: Assuming that once approved, the Architecture Vision can never change. If a major macroeconomic shock, regulatory shift, or corporate merger occurs during Phase D or E, the architect must invoke the change management procedures defined in the SoAW and Phase H to adjust the Vision under formal governance control.
Midway through Phase A, an unexpected corporate merger alters the enterprise's strategic direction, rendering several baseline assumptions in the draft Architecture Vision obsolete. How should the enterprise architect proceed before finalizing the Statement of Architecture Work?
Leave the merger for Phase H, because changes to strategy that arise during Phase A must wait for formal architecture change management.
Revisit the drivers and goals with the sponsor, adjust the Architecture Vision and scope, and update the draft SoAW before seeking approval.
Approve the current SoAW at once to secure the funding, then raise the merger as a change request at the first Phase B checkpoint.
Hand architecture governance to the merged entity's development staff and let them update the documentation once integration plans settle.
Which deliverable is the formal agreement between the architecture team and the sponsor that defines the program of architecture work and is approved before Phase B proceeds?
The Communications Plan
The Architecture Repository Index
The Statement of Architecture Work (SoAW)
The Request for Architecture Work (RfAW)
What is the primary role of the High-Level Solution Concept Diagram within the Architecture Vision document?
To replace the detailed data entity-relationship models that would otherwise be produced in Phase C.
To provide the deployment scripts and configuration settings that cluster administrators need in Phase G.
To act as the binding bill of materials for hardware procurement once the SoAW is approved.
To give business and technical stakeholders a shared, easy-to-grasp picture of the proposed solution.
Sections you finish are checked off in the contents.