在任何软件开发工作中，总有太多事情要做，而时间和资源却不够。软件架构的艺术在于决定哪些决策需要现在做出，哪些可以等待。

决策涉及回答关键问题，且某些问题需要按特定顺序回答。架构成功需要快速且廉价地拒绝错误假设/断言，即利用经验主义，快速找出错误且代价高的替代方案并选择更好的。最小可行产品（MVP）及其最小可行架构（MVA）方法有助于回答这些问题。

面对交付 MVP 且似乎不切实际的截止日期的挑战，团队需要按特定顺序回答几个关键问题：

1. 业务想法是否值得追求？
2. 需要多少性能和可扩展性？
3. 需要多少可维护性/模块化和可支持性？

答案决定了团队在设计 MVA 时需要做出的架构决策和权衡。

“业务想法是否值得追求”是最重要的问题，想法便宜，解决方案昂贵，MVP 测试提议解决方案的价值，且需测试业务想法批准时的假设，MVP 需收集数据。这与软件架构相关，不能为没人需要的产品创建架构，MVP 需能验证业务案例但不必回答所有关于可扩展性和性能的问题，同时要考虑成本。

“性能和可扩展性如何”是第二重要的问题，早期性能问题是未来扩展问题的领先指标，团队可在处理过程中进行权衡，如将耗时任务移至异步后台任务，同时要确定收集哪些指标来验证系统性能。“需要多少可扩展性”是相关问题，投资可扩展性成本高，团队常难准确预测需求，需在成本和可扩展性间做出权衡。

“需要多少可维护性/模块化和可支持性”是第三个重要问题，团队以模块化方式开发系统以方便开发、理解和维护，但要避免浪费努力，挑战在于预测最可能发生的变化并在代码中准备好应对。在开发 MVP 及其相关 MVA 时可能有 5 种结果，多数团队需处理部分成功的情况，应根据情况投资足够的可维护性等。可通过技术债务评估可支持性和可维护性，记录技术债务决策，利用经验主义测试，纳入“变更案例”等。

结论：如赫尔穆特·冯·毛奇所言，没有 MVP 能在与客户接触中幸存，这也影响 MVA。架构决策中，团队需先考虑业务想法是否值得追求，这会改变对 MVA 的决策，其次是性能和可扩展性，然后才是可维护性和可支持性，且架构决策需不断适应新情况，MVP 和 MVA 都需随时间和反馈而演变。