SAF Phase 5 — Solutions Realization Planning - Solutions Architecture Best Practices and Framework
SAF Phase 5 — Solutions Realization Planning
(Chapter 23 of Solutions Architecture Best Practices and Framework)
Executive Summary: Chapter Overview
IF4ITThe Bottom Line
Core Concepts
| Concept | Definition & Strategic Role |
|---|---|
| Phase 5 as optional | Solutions Realization Planning is often optional: the Customer may choose to leave it out of the engagement, defer it to a later time, or perform it with their own resources — a decision that is vetted as part of scope in Phase 1, not assumed by default. |
| Roadmaps and work planning | Development of the roadmap for realizing the chosen Solutions Option, and planning of the actual work — programs, projects, products, and services — needed to execute it. |
| Skills, funds, and communications planning | Analysis and acquisition planning for the skills the realization work requires, planning for the funds needed, and planning and execution of communications about the plan. |
| Customer handoff and close-out | The delivery of the SARB to the Customer and the formal close-out that ends the Solutions Architecture engagement — introduced here, and covered in full in “Post Solutions Architecture Engagement Best Practices,” the chapter that follows. |
| Course-correction | When detailed realization planning reveals that the chosen Solutions Option is no longer viable on the terms the Customer actually decided on — cost, risk, or feasibility having changed materially from what Phase 3 and Phase 4 presented — that is a course-correction, not a normal planning refinement, and belongs back with the Customer, not resolved unilaterally within this phase. |
Quick Q&A
Question: Does every Solutions Architecture engagement include Solutions Realization Planning?
Question: What does Solutions Realization Planning actually plan for?
Question: Does the Solutions Architecture engagement end the moment the plan is complete?
Question: What should the Solutions Architect do if realization planning reveals the chosen option isn't viable after all?
Read More Below
Overview
This phase is often optional. A Customer may choose to have the Solutions Architecture engagement conclude with the Transition Plan established in Phase 3 and confirmed in Phase 4, deferring detailed realization planning to a later time or performing it with their own resources rather than continuing with the Solutions Architect. Which phases, or parts of phases, the Solutions Architect is actually engaged to perform is something vetted as part of scope, established in Phase 1 — this phase is simply the one most commonly left out or deferred.

When performed, Solutions Realization Planning takes the rough Transition Plan chosen along with the Solutions Option in Phase 4 and develops it into a detailed, executable plan: roadmap development; work planning across programs, projects, products, and services; skills analysis and acquisition planning; funds planning; and communications planning and execution.
Detailed planning sometimes surfaces information that changes more than the plan’s specifics — a cost estimate that balloons well beyond what Phase 3 presented, a critical technical assumption that proves false, a skill the realization work depends on that turns out to be unavailable. As established in “The Solutions Architecture Framework (SAF)” earlier in this document, the SAF’s phases are loosely sequential, not rigidly linear — and this is that same principle applied to something more consequential than informal information flow: when what surfaces undermines the basis of the Customer’s Phase 4 decision itself, it belongs back with the Customer, not resolved unilaterally within this phase.
This phase, and the Solutions Architecture engagement itself, conclude with the Customer handoff — delivery of the SARB — and formal close-out. That close-out is introduced here as the natural conclusion of realization planning, and is covered in full, including what happens to the SARB and the engagement’s data afterward, in “Post Solutions Architecture Engagement Best Practices,” the chapter immediately following this one.
Best Practice: Bring Significant New Information Back to the Customer, Don’t Silently Adjust the Plan
Where realization planning surfaces information that materially changes the cost, risk, or feasibility the Customer’s Phase 4 decision was actually based on, stop and bring it back to the Customer before proceeding further — present what changed and why, and let the Customer decide whether to continue, adjust, or reopen Phase 4 entirely. Do not quietly absorb a material change into the plan and continue as though the original decision still holds.
Benefit(s)
Surfacing material changes immediately, rather than absorbing them silently, keeps the Customer’s decision authority genuine throughout realization, not just at the moment of Phase 4 — and avoids delivering a Solution Set the Customer never actually agreed to in its final, realized form.
Anti-Pattern: Silently Absorbing a Material Change Into the Plan Without Returning to the Customer
When detailed realization planning reveals that a cost, risk, or feasibility assumption behind the Customer’s Phase 4 decision no longer holds, it can be tempting to quietly adjust the plan and continue rather than reopening a conversation that feels already settled. Doing so means the Customer walks away believing they got what they decided on in Phase 4, when what actually got built quietly diverged from it somewhere along the way — a gap that tends to surface only once it is far more expensive to fix.
Best Practice: Treat the Customer Handoff as a Planned Step, Not an Afterthought
Include the Customer handoff and close-out explicitly in the realization plan itself, with its own timing and ownership, rather than treating it as something that happens automatically once the other realization planning work is finished.
Benefit(s)
Planning the handoff deliberately ensures a smooth, well-executed transition out of the engagement, rather than an abrupt or incomplete one — setting up the specific close-out practices covered in the chapter that follows.
How to cite this page
When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.
Example (informal web citation):
The International Foundation for Information Technology (IF4IT), LLC. SAF Phase 5 — Solutions Realization Planning | Solutions Architecture Best Practices and Framework. https://if4it.org/best-practices/solutions-architecture/saf-phase-5-solutions-realization-planning/ (accessed 2026-09-11).
See About Us for content governance and site-wide citation guidance.
Copyright for The International Foundation for Information Technology (IF4IT), LLC: 2008 - Present
Legal Disclaimers