记录软件架构决策对于保存设计选择背后的背景和理由非常重要，这对未来的自己和团队来说都是无价之宝：
在过去的两年里，我一直在从事一个有趣的应用程序现代化项目。它涉及将业务线从数十年历史的单体应用转移到更现代的 SaaS 应用程序。作为这一旅程的一部分，我们必须做出很多决定！我们需要这个特定功能吗？解决此功能可以通过多种方式完成，那么哪种方式是正确的？我知道，在这个过程中，人们会质疑我们为什么做出这个选择。
我在《纽约时报》担任设计工作的朋友有一个很棒的单页模板，用于推销创意或潜在项目。Olivia Cheng向我介绍了这个模板。这份单页模板概述了问题以及将创意转化为潜在项目的初步讨论。目标是引导团队、领导层和利益相关者。这份单页模板的元素包括：
- 问题是什么？在这里，您可以描述要解决的问题及其关键影响。
- 机会是什么？解决这个问题能给企业带来什么？
- 你的目标清单
- 成功指标。您如何衡量它？
- 挑战是什么？每个挑战的简要描述。
- 团队和利益相关者受到影响。
第一次记录决策
开始使用这个详细的模板来跟踪项目中的决策：
模式和模式语言告诉我，任何问题的解决方案总是有背景。因此，我修改了这个模板以包含以下元素。这是一个自由流动的文档，每个元素都有标题。
- 上下文：我以段落中的上下文作为开头。上下文描述了与我们必须解决的问题或困境相关的具体领域。
- 问题：我们具体要解决什么问题？我尽量在这里说得尽可能具体。由于人们已经阅读了上下文，他们现在可以更好地理解这些问题。
- 机会：在这里，我描述了为什么解决这个问题至关重要，以及它如何改善企业或用户的状况。
- 成功指标：我们如何衡量成功指标？我们可以衡量哪些指标？
- 受影响的团队：哪些人会受到此决定的影响？
- 已知的挑战和限制：我们是否知道做出此决定时需要解决的任何具体问题或事情？我会在此处记录所有重要问题。
- 未解决的问题：最初，在尝试解决问题并寻找解决方案时，可能会出现许多未解决的问题，我们需要找到答案。我在本部分中记录了这些问题。
- 建议的决定：经过审议和审查调查结果后，我将使用此部分来记录商定的决定。
- 附录：如果我在回答这个问题时有几个选项需要评估，我会将每个选项记录为附录，并附上它的优点和缺点。
但发现模板过于冗长，难以快速了解当前状态：
于是，从其他模板中汲取灵感，如 "one-pager pitch deck "和安德鲁-哈梅尔-劳（Andrew Harmel-Law）关于 "Scaling the Practice of Architecture, Conversationally "的建议，对这一方法进行了迭代。
改进后的决策记录模板的关键要素包括
- 状态（草案/建议/通过/过期），以便快速查看决策的当前状态
- 行动项目，作为下一步措施的清单
- 需要决定的明确问题及其相关背景
- 建议的决策、支持性论据和潜在后果/制约因素
- 考虑过的其他方案、受影响的利益相关者以及相关参考资料