SAF Phase 3 — Future State Solutions Options Determination and Vetting

Overview

Future State Solutions Options Determination and Vetting develops future-state permutations of all the data and information collected in Phase 2 — Roles & Responsibilities, Tools & Technologies, Data & Information, and the rest — into candidate Solutions Options. Each option is identified, vetted, and assessed, producing recommendations based on fit.

Each Solutions Option identified here may take different forms: a Custom-Built solution developed from scratch, an Acquired solution built on a vendor product, or a Composite solution combining both — the same terms already established for the Systems Development Lifecycle earlier in this document. Which form a given option takes shapes what its Transition Plan and risk assessment actually need to cover, not just its underlying architecture.

Acquired Solutions Options carry evaluation criteria beyond those built from scratch: vendor viability, licensing terms, and vendor concentration or lock-in risk all bear on whether the option is actually sound. These are not new categories invented for this phase — vendor viability and concentration risk are already governed through Application Portfolio Management and Technology Portfolio Management — a correlation covered in full in “Solutions Architecture and Portfolio Management (APM/TPM),” later in this document — and vendor-specific risk is simply one instance of the risk assessment already required for every option.

Each Solutions Option should also include a Transition Plan: an initial view of how the engagement would move from Current State to that specific option, typically covering a rough roadmap, required costs, required skills acquisition, and what actually changes along the way. Two options that reach similarly strong architectures can still differ sharply in how difficult, costly, or slow they are to get to, and the Customer needs to see that difference to choose well. These Transition Plans do not need to be perfected here — accuracy sufficient to give real directionality is enough. Improving the chosen plan in detail is the work of Phase 5, Solutions Realization Planning, if the Customer chooses to have that phase performed.

Each Solutions Option should also be assessed for risk: what could go wrong technically, in delivery, or organizationally, building on the risks first flagged during Vision Development in Phase 1. Risk is one more factor the Customer needs visibility into when choosing among options in Phase 4 — a technically superior option carrying substantially higher risk is not automatically the better choice.

Fit assessment in this phase evaluates more than raw functional capability. Non-Functional Requirements, established alongside functional requirements in Phase 1, are part of the same assessment, not a separate or secondary consideration set aside until later. So is each option’s projected impact on the KPIs and metrics identified and vetted with the Customer in Phase 1 — how convincingly, not just whether, an option is expected to move the numbers that actually define success for this problem.

This phase is where the future-state deconfliction and reuse mechanic described in “How Solutions Architecture and the EA Platform Reinforce Each Other” earlier in this document is put into practice: checking the EA Platform, including in-progress SARBs held in the Architecture Repository, for other already-in-play future-state work elsewhere in the enterprise that may influence, conflict with, or be leveraged by the options under consideration — rather than developing options in isolation.

Much of this work does not start from a blank page here. As established in “The Solutions Architecture Framework (SAF)” earlier in this document, ideas and possibilities for Future State Solutions Options often surface informally well before this phase formally begins — during Vision Development or Current State Collection, for example — and should be captured as they arise rather than set aside until this point in the engagement.

Where a Solutions Option is significant enough to warrant it, this is also the phase in which it should go before ARB, TRB, or whichever governance body applies — before any option reaches the Customer in Phase 4, not after. Covered in full in “Solutions Architecture and Governance Body (ARB/TRB) Review,” earlier in this document.

Best Practice: Develop a Transition Plan for Every Option, Not Just the Recommended One

Build an initial Transition Plan for each Solutions Option under consideration, not only the top-ranked one. Producing a Transition Plan for a single favored option while leaving the others undeveloped quietly biases the presentation in Phase 4, undermining the objective ordering this document requires.

Benefit(s)

Giving every option a comparably developed Transition Plan lets the Customer weigh architecture fit against real-world transition costs and effort on equal footing, rather than being steered toward whichever option happened to receive the most preparation.

Anti-Pattern: Presenting Only One Option Instead of a Genuine Set of Alternatives

Developing a single, well-considered recommendation can feel more efficient than fully working out multiple Solutions Options, especially under time pressure. But presenting only one option removes the Customer’s actual ability to choose, reducing Phase 4 to a rubber stamp rather than a genuine decision — and leaves no real evidence that the recommended option was actually the best available, rather than simply the only one considered.

Best Practice: Evaluate and Document Risk for Every Solutions Option, Not Just the Recommended One

Assess and document risk for each Solutions Option under consideration, not only the top-ranked one. Producing a risk assessment for a single favored option while leaving the others unassessed quietly biases the presentation in Phase 4, the same concern that applies to Transition Plans.

Benefit(s)

Assessing risk for every option, not just the favorite, means a serious risk surfaces during Phase 3’s vetting — where it can still change the outcome — rather than after the Customer has already committed to an option based on incomplete information.

Best Practice: Check for In-Play Future State Work Before Finalizing Options

Before finalizing the set of Solutions Options to bring forward, query the EA Platform and the Architecture Repository for other in-progress or recently completed engagements that touch the same or related parts of the enterprise. Incorporate what is found rather than discovering a conflict or a missed reuse opportunity later.

Benefit(s)

Checking for in-play work before finalizing options avoids wasted solutioning effort on this specific engagement — a distinct, engagement-level benefit from the enterprise-wide compounding value described in “How Solutions Architecture and the EA Platform Reinforce Each Other.”