Redgate是如何做出架构决策的？

架构决策“最简单”的解决方案是让拥有巨大大脑的人做出所有决定。这种“Megamind”方法当然有一些优势——一个人可以快速做出决定，并且有一个人负责；缺点使这些优点相形见绌。把责任推给一个人是有风险的——人并不完美（对不起！）。
让我们尝试改进一下：我们可以任命一个变革顾问委员会 (CAB)。CAB 是一个具有相关领域经验的小组，负责审查决策并提出改进建议。CAB 听起来像是一种改进；不同的群体做出更好的决策，相关领域的专业知识必然会让事情变得更好。不幸的是，研究表明拥有变更审批流程并不是一个好主意。
 
“……发现外部批准与提前期、部署频率和恢复时间呈负相关，与变更失败率无关。简而言之，外部机构（例如经理或 CAB）的批准根本无法提高生产系统的稳定性，以恢复服务的时间和更改失败率来衡量。但是，它肯定会减慢速度。事实上，这比根本没有变更审批流程更糟糕。” （加速：妮可福斯格伦）
 
我们在 Redgate 的核心信念是“我们相信制作软件的最佳方式是让拥有明确目标、行动自由和学习动力的团队参与进来。”。提交设计以供批准与行动自由的原则背道而驰。但是，我们也认识到，有时单个团队可能不具备整个环境，并且局部决策可能是局部最优。
我们如何解决这个问题？
圣达菲潜艇的船长大卫·马奎特已经给了我们答案。在被置于一个陌生的环境后，他形成了一种强调地方决策而不放弃控制的领导风格。基于意图的领导赋予团队决策权，但使用“意图检查”让其他人提供洞察力。
 
我们已经将这种方法体现在我们如何做出架构决策中。在开始工作之前，我们要求工程师记录他们的决定决策。把事情写下来改进了设计（毕竟，如果你不能把它写下来，你到底要如何实现它），但它也为那些有不同观点的人提供了一个意图检查。
我们的方法借鉴了两个既定流程，为 Redgate 构建了一些东西。

• RFC（征求意见）文件起源于 1969 年互联网的早期。这是一个正式的流程，公开工作以向每个人提供意见。RFC 过程今天仍然用于定义互联网的关键部分。例如，您可以查看有关 IPv6的完整讨论记录（引入是因为现在有数十亿台设备连接在一起）。
• ADR（架构决策记录）是另一端工程决策的轻量级记录。ADR 日志与源代码一起保存，让工程师可以很好地概览决策背后的历史背景。