Alternative Enumeration
Requires the model to surface multiple viable approaches before committing to one, preventing premature convergence.

Problem
The model quickly converges on the first plausible answer, hiding other viable approaches and locking framing too early.
Solution
Require multiple alternatives before any selection. Structural obligation forces distribution across distinct solution regions instead of single-path collapse.
Example
One worked example. The book has 2–4 per technique.
List four alternative approaches to migrating our monolithic order-management system to microservices. For each, give a one-paragraph description.
1. **Strangler Fig** — Incrementally replace monolith components by routing traffic to new services one capability at a time. The old code is retired as each service proves stable. Low risk but slow. 2. **Domain-Driven Decomposition** — Identify bounded contexts in the domain model and extract each as an independent service. Requires upfront domain analysis but produces services aligned with business capabilities. 3. **Branch by Abstraction** — Introduce an abstraction layer inside the monolith that allows swapping implementations. Build services behind the abstraction, then remove the monolith implementation once each service is ready. 4. **Modular Monolith First** — Restructure the monolith into well-defined internal modules with clear boundaries before extracting any services. This reduces coupling risk and may show that some modules should remain internal.
Techniques
Concrete ways to implement Alternative Enumeration. Each technique fits a different situation.
- 01
Breadth Enumeration
Ask for multiple alternatives without specifying how they should differ so the model decides which dimensions of variation to explore.
- 02
Dimensional Enumeration
Constrain the enumeration to a named dimension (cost, complexity, risk, time) so alternatives are directly comparable on the axis that matters.
