Solution Options & Trade-offs

## What a solution option set is 'Solution options' in architecture work means deliberately producing a small set of **distinct, viable** ways to satisfy the same requirement -- typically two to four -- before committing to one. Each option in the set should be developed to comparable depth: - a rough component or integration diagram - the key technology choices - an effort/cost estimate - the risks it carries A common shape for the set is three options: | Option | Character | |---|---| | **'tactical'** or low-risk | minimal change, fastest to ship, often accepting some technical debt | | **'recommended'** | the architect's best balance of cost, risk, and value | | **'bold'** or **'ideal'** | the strongest long-term fit, usually at higher upfront cost or risk | This structure isn't mandatory, but it's a useful default because it forces you to think across a spread of risk appetites rather than anchoring on the first workable idea. ## Why the practice exists The reason this exists as a practice, rather than architects simply presenting their best judgment, is that a single option cannot be evaluated -- it can only be accepted or rejected wholesale, and rejecting it puts the burden of generating an alternative back on people less equipped to do so than the architect. Architects, like anyone, carry biases: - familiarity with a particular technology - resume-driven interest in something new - anchoring on how a similar problem was solved at a previous job - simple sunk cost from work already started An explicit option set converts what would otherwise be an implicit, unexaminable judgment call into something **inspectable**: stakeholders can see what was considered, what was ruled out, and why, and can contest the reasoning rather than just the conclusion. It also matters because many 'technical' decisions are really **business trade-offs in disguise** -- cost versus time-to-market, or build velocity versus long-term maintainability -- and those are judgment calls that non-technical stakeholders have a legitimate stake in, but only if the trade-off is made visible to them rather than buried inside a single technical recommendation. ## The cost, and where it earns its keep The cost of this practice is real and sits on the other side of the trade-off: producing two to four properly-sized options costs meaningfully more time than developing one, since each option needs enough depth to be genuinely comparable rather than hand-waved. - For a small, easily-reversible decision -- what Amazon calls a **'two-way door,'** like choosing between two internal helper libraries -- that cost isn't justified, and a single reasoned choice with a short rationale is the proportionate response. - The practice earns its keep specifically for **'one-way door'** decisions: expensive to reverse, affecting multiple teams, or committing the organization for years, such as choosing a primary datastore, an authentication provider other teams will integrate against, or the platform for a customer-facing product. ## How it fails In practice, this technique fails in a few predictable ways. 1. **Straw-manning** is the most common: presenting two or three options where only one was ever seriously considered, and the others are included as a formality, under-researched and clearly inferior, so the 'real' decision was made before the document existed. This is usually visible to careful reviewers because the preferred option has a diagram, sizing, and named risks, while the alternatives get a sentence each -- an imbalance that itself signals the comparison wasn't genuine. 2. **Option overload** is a second failure mode: presenting six or eight options that no reviewer can hold in their head at once, which usually means several are minor variations of each other rather than architecturally distinct, and signals the requirement itself may be underspecified. 3. **Analysis paralysis** is a third, where the org spends so long generating and re-generating options that the decision never actually gets made, and the market or the business moves on regardless. ## A worked scenario A concrete worked scenario: a product team needs to add search to an application. - **Option A** is to extend the existing Postgres database with trigram indexes for fuzzy text matching -- cheap, ships in days, but has a low ceiling on relevance ranking and scale. - **Option B** is standing up a dedicated Elasticsearch cluster -- the best relevance and scale characteristics, but adds a new piece of infrastructure to operate, a learning curve for the team, and ongoing cost. - **Option C** is a managed search-as-a-service product like Algolia -- fast to integrate with excellent out-of-the-box relevance, but recurring vendor cost and a new external dependency with data residency implications. Presenting all three, with their trade-offs made explicit, lets the team pick based on its actual constraints -- e.g., a small team with no dedicated infrastructure staff and moderate near-term scale might reasonably choose Option A now, with an explicit note that Option C becomes the fallback if relevance quality becomes a customer complaint, rather than silently locking in a choice nobody outside the original author can evaluate.