SAF Phase 1 — Vision Development and Understanding

Overview

Vision Development and Understanding is where an engagement begins. Its work consists of documenting and understanding the key stakeholders; the perceived problem or problems; the vision, mission, objectives, and scope of the engagement; and the high-level capabilities and requirements involved. This becomes the problem statement portion of the SARB, covered earlier in this document.

This phase captures what is perceived, not yet what is validated. The perceived problem, as understood at the outset, is the starting point — it is Phase 2, Current State Collection and Analysis, that validates what actually exists against this initial understanding.

Scope and the high-level requirements captured in this phase are closely related, but distinct: scope sets the boundaries of what the engagement will and will not address, and high-level requirements are defined within those boundaries — getting scope right is what keeps requirements properly bounded rather than open-ended. Both matter well beyond this phase: they give Phase 2 a lens for judging what in the current state is and is not working, and they give Phase 3 the boundary conditions against which future-state options are actually evaluated for fit.

High-level requirements captured here include both functional requirements — what the solution must do — and Non-Functional Requirements (NFRs), such as performance, scalability, availability, reliability, maintainability, usability, interoperability, and recoverability. Both kinds are requirements in the same sense used throughout this document; NFRs are simply the requirements that describe how well the solution must do what it does, not what it does.

Constraints — such as budget limits, timelines, regulatory requirements, or mandated technologies — should also be collected in this phase. They further hone scope: where scope defines what the engagement will address and requirements define what must be achieved within it, constraints define the conditions and limits within which those requirements must actually be met. Initial risk identification also begins here — early flags about what could go wrong, feeding a Risk Register that gets refined and weighed more fully once Future State Options are compared in Phase 3. Phase 3, Future State Solutions Options Determination and Vetting, evaluates every Solutions Option against these constraints and risks, alongside vision and requirements, when assessing fit.

The KPIs, metrics, and measures relevant to the problem being solved should also be identified here, and vetted with the Customer — what success concretely looks like for this specific problem, not a generic notion of a good outcome. These are metrics about the problem domain itself, not process metrics about how the engagement was run; a retail availability problem might track stockout rate, a claims-processing problem might track cycle time. Identifying them here gives Phase 3 and Phase 4 something concrete to assess Solutions Options against — how well each option is projected to move the metrics that actually matter to the Customer.

Scope also extends to the engagement itself, not just the problem: which of the five SAF phases, or which parts of them, the Solutions Architect is actually engaged to perform is something to vet here, at the outset, rather than assume. Solutions Realization Planning, for example, is often optional — a Customer may choose to leave it out of the engagement, defer it to a later time, or perform it with their own resources — and confirming this in scope avoids ambiguity later about what the Solutions Architect is, and is not, accountable for delivering.

Whether Solutions Options are likely to need governance review — from ARB, TRB, or another applicable body — is also worth identifying here, alongside scope. Significant options warrant that review before being presented to the Customer in Phase 4, covered in full in “Solutions Architecture and Governance Body (ARB/TRB) Review,” earlier in this document.

The stakeholders met here are also the first opportunity to keep Enterprise Architecture visible and engaged, and to pick up forward-looking signal worth feeding back later — see “How Solutions Architecture Turns Stakeholder Access Into Enterprise Architectural Value” for how.

Best Practice: Confirm the Vision and Problem Statement With Stakeholders Before Proceeding

Do not treat Phase 1’s outputs as final once drafted. Circle back to the key stakeholders identified and confirm that the documented vision, mission, objectives, scope, high-level requirements, constraints, and problem statement genuinely reflect their understanding before moving into Current State work — with particular attention to scope, since it sets the boundaries within which the requirements must fit, to constraints, since they further hone that scope into what is actually achievable, and to which phases, or parts of phases, the Solutions Architect is actually engaged to perform. Where the Customer is multiple stakeholders rather than one voice — Business and IT together, or multiple business units, for example — also identify who holds final authority to break a tie if they cannot reach consensus, before Phase 4 decisioning is underway. This is the first application of the continuous stakeholder communication established for the SAF as a whole.

Benefit(s)

Confirming the vision and problem statement early prevents scope drift and wasted work later in the engagement — a poorly understood or unconfirmed starting point is one of the most common sources of rework in problem-solving of any kind. Clear scope, requirements, and constraints at this stage also give Phase 2 and Phase 3 something concrete to evaluate against, rather than vague or shifting criteria discovered partway through the engagement, and confirming which phases the Solutions Architect is accountable for prevents disputes later about what was, and was not, included in the engagement.

Anti-Pattern: Skipping Stakeholder Validation of the Vision and Problem Statement

Treating Phase 1’s outputs as finished once drafted, without circling back to confirm them with the stakeholders who actually own the problem, is an easy step to skip when the vision seems obviously correct. But skipping this step means the engagement proceeds on an assumption no one actually verified — and if that assumption turns out to be wrong, every subsequent phase inherits an error that traces all the way back to a conversation that was never actually had.

Best Practice: Identify and Vet Problem-Domain KPIs and Metrics With the Customer Before Proceeding

During Vision Development, identify the specific KPIs, metrics, and measures relevant to the problem being solved, and vet them directly with the Customer — do not assume a generic notion of success or leave this implicit. These are metrics about the problem domain itself, not about how the engagement or the Solutions Architecture practice performed.

Benefit(s)

Vetted, problem-specific metrics give the Customer and the Solutions Architect a shared, concrete definition of success from the outset, and give Phase 3 and Phase 4 something real to assess Solutions Options against — rather than deciding among options on architectural elegance alone.