Jeff Tyree 和 Art Akerman 的决策记录模板

这是 Capital One Financial 的 Jeff Tyree 和 Art Akerman 在《架构决策:揭开架构的神秘面纱》(Architecture Decisions: Demystifying Architecture)中发布的架构决策描述模板。

• 问题(Issue):描述你要解决的架构设计问题,不要让人对“为什么现在要解决这个问题”留有疑问。遵循极简主义的做法,只处理和记录在生命周期各个阶段确实需要解决的问题。

• 决策(Decision):清楚地陈述架构的方向,也就是你所选定的立场。

• 状态(Status):决策的状态,例如待定、已决定或已批准。

• 分组(Group):你可以使用简单的分组(例如集成、表现层、数据等)来帮助整理这组决策。你也可以使用更复杂的架构本体,例如 John Kyaruzi 和 Jan van Katwijk 提出的本体,其中包含事件、日历和地点等更抽象的类别。例如,使用该本体时,你会把涉及系统需要信息的各种事件的决策归入“事件”类别。

• 假设(Assumptions):清楚地描述你做出决策时所处环境中的基本假设,例如成本、进度、技术等。请注意,环境约束(例如公认的技术标准、企业架构、常用模式等)可能会限制你所考虑的备选方案。

• 约束(Constraints):记录所选备选方案(即该决策)可能给环境带来的任何额外约束。

• 立场(Positions):列出你考虑过的立场(可行的选项或备选方案)。这些往往需要冗长的解释,有时甚至需要模型和图表。这并不是一份详尽无遗的清单。不过,你不会希望在最终评审时听到“你有没有想过……?”这样的问题;这会导致失去信誉,并让人质疑其他架构决策。本节也有助于确保你听取了他人的意见;明确陈述其他意见有助于争取这些意见的支持者加入你的决策。

• 论证(Argument):概述你选择某个立场的原因,包括实施成本、总拥有成本、上市时间以及所需开发资源的可用性等事项。这可能与决策本身同样重要。

• 影响(Implications):正如 REMAP 元模型所指出的,一项决策会带来许多影响。例如,一项决策可能引入做出其他决策的需要、创建新需求或修改现有需求、给环境带来额外约束、要求与客户重新协商范围或进度,或者要求额外的员工培训。清楚地理解并陈述决策的影响,对于争取各方支持和制定架构执行路线图非常有效。

• 相关决策(Related decisions):显然,许多决策是相互关联的;你可以在此列出它们。不过,我们发现实践中追溯矩阵、决策树或元模型更有用。元模型适合以图示的方式展示复杂的关系(例如 Rose 模型)。

• 相关需求(Related requirements):决策应由业务驱动。为了体现问责,请明确地将你的决策映射到目标或需求。你可以在此枚举这些相关需求,但我们发现引用追溯矩阵更为方便。你可以评估每项架构决策对满足每项需求的贡献,然后评估所有决策合起来对每项需求的满足程度。如果一项决策对满足任何需求都没有贡献,就不要做出该决策。

• 相关制品(Related artifacts):列出该决策所影响的相关架构、设计或范围文档。

• 相关原则(Related principles):如果企业有一套公认的原则,请确保决策与其中一项或多项原则保持一致。这有助于确保各领域或各系统之间的一致性。

• 备注(Notes):由于决策过程可能耗时数周,我们发现记录团队在沟通推广过程中讨论的备注和问题很有用。