SAF Phase 4 — Solutions Presentation and Decisioning

Overview

Solutions Presentation and Decisioning presents the Solutions Options identified in Phase 3, in an objectively determined order based on their fit assessments, to the key stakeholders identified in Phase 1. That ordering must reflect how well each option meets the Customer’s own stated needs — Vision, Mission, Goals, Scope, High-level Requirements, and Constraints — and the risk assessed for each in Phase 3, never the Solutions Architect’s personal preference. The phase’s work is not complete once options are presented — it continues through working with those stakeholders to achieve and finalize an actual decision.

Where governance review applies, every option presented here has already cleared it in Phase 3 — this phase presents already-viable options to the Customer for a decision among them, not options still pending a governance verdict.

This is the phase in which the SARB’s decision record, described in “The Solutions Architecture Reference Book (SARB)” earlier in this document, actually gets produced: every decision made, and by whom. That record extends beyond the Solutions Architecture team’s own Architecture Decision Records to include approvals from stakeholders who own any pre-existing constructs a decision affects.

That decision belongs to the Customer, not the Solutions Architect. The Customer is under no obligation to select the top-ranked recommendation, and the Solutions Architect’s role in this phase is to present every option with the data and analysis that supports it, not to steer the outcome toward a personally preferred architecture. This does not always produce the architecture the Solutions Architect would consider best — accepting that is part of practicing Solutions Architecture responsibly. In choosing a Solutions Option, the Customer is also choosing that option’s Transition Plan — a Customer may reasonably prefer an option with a less costly or less complex transition even when another option scores marginally higher on architecture fit alone.

Each option’s projected impact on the KPIs and metrics identified in Phase 1 is also part of what gets presented here, alongside its Transition Plan and risk assessment — giving the Customer a concrete basis for comparing how well each option is expected to actually move the outcomes that matter, not just how each one is architected.

Where the Customer is not a single voice but multiple internal stakeholders, they may not agree among themselves on which Solutions Option to choose. When that happens, the Solutions Architect’s role remains the same as it has been throughout this phase: present the same objective data to every disagreeing party, and escalate the decision to whichever stakeholder or body was identified in Phase 1 as holding final authority — not resolve the disagreement personally, even under pressure to do so.

Best Practice: Order Recommendations Objectively, Never by Personal Preference

Order Solutions Options for presentation strictly according to how well each one meets the Customer’s needs as established in Phase 1 — Vision, Mission, Goals, Scope, High-level Requirements, and Constraints — never according to the Solutions Architect’s own subjective preference. Where the ordering criteria are not obvious, document the specific Phase 1 factors that drove the ranking.

Benefit(s)

An objectively ordered set of recommendations protects the integrity of the decision: the Customer evaluates options on their actual fit to the engagement’s own stated needs, not on which option the Solutions Architect happens to favor — preserving the credibility this document has argued Solutions Architecture depends on throughout.

Best Practice: Present the Data and Accept That the Decision Belongs to the Customer

Present every Solutions Option with the data and analysis that supports it, and be prepared for the Customer not to select the top-ranked recommendation. The Solutions Architect’s role is to inform the decision, not make it — the final choice belongs to the Customer, who owns the engagement and its outcome, even when that choice does not produce what the Solutions Architect would consider the best possible architecture.

Benefit(s)

Accepting that the decision belongs to the Customer, not the Solutions Architect, is what makes Solutions Architecture a genuinely advisory-and-executing practice rather than an autocratic one — and it is consistent with the Customer’s ownership of the problem established throughout this document.

Anti-Pattern: The Solutions Architect Making the Final Decision Instead of the Customer

It is tempting for a confident Solutions Architect, especially one who has clearly identified a superior option, to simply tell the Customer what to choose rather than genuinely presenting alternatives for a decision. Doing so quietly puts the Solutions Architect in the Customer’s seat, deciding an outcome that was never theirs to decide — and the fact that the Solutions Architect may turn out to be right does not change whose problem, and whose call, it actually was.

Best Practice: Facilitate Escalation of Internal Customer Disagreement, Never Resolve It Personally

Where stakeholders within the Customer’s organization disagree on which Solutions Option to choose, present the same objective data to all parties and escalate the decision to whichever stakeholder or body Phase 1 identified as holding final authority. Do not break the tie personally, even if directly asked to — that authority was never the Solutions Architect’s to begin with.

Benefit(s)

Escalating internal disagreement rather than resolving it personally keeps the Solutions Architect’s role consistent throughout the engagement — informing the decision, never making it — and avoids the Solutions Architect being drawn into Customer-side politics that are not theirs to referee.

Best Practice: Capture Decisions and Their Approvers at the Time They Are Made

Record each decision, and who made or approved it, contemporaneously as it happens in this phase — not reconstructed afterward from memory. Where a decision affects a pre-existing construct not owned by the Solutions Architect, capture the specific approval from its owning stakeholder as part of the same record.

Benefit(s)

A contemporaneous decision record is more accurate and more defensible than one reconstructed after the fact, and it is what allows the SARB to function as a genuine governance artifact rather than a retrospective summary — distinct from the broader completeness benefit described in the SARB chapter itself.