本文介绍了如何利用架构决策矩阵和 ADR 优化团队技术架构决策流程的方法，从而避免架构混乱、信息缺失等风险。原文：The Hidden Burden of Architectural Decision Fatigue (And How to Fix It)

作为技术架构师，我们理应做出决策，并且是有关架构的决策。这些决策通常规模宏大、意义重大、复杂且影响深远，具有长期影响力，并且跨越多个组织范围。

然而，在经过一次又一次决策之后，常常会质疑自己的选择以及他人的选择，总觉得哪里不对劲，感觉什么地方偏离了正轨，有一种不安的感觉，觉得遗漏了某些东西，没有将这个或那个因素考虑进去。

“为何选择将事件流技术应用于那个客户订单系统呢？这样做真的有意义吗？为何选择那个特定的商业应用？供应商是否真能如我们所期望的那样提供服务？”

没人明确知道所有细节，没有审计记录，没有关于这些决定的记录，没人能回忆起决策过程以及与之相关的讨论内容。

我曾参与过这样一个项目，当时我担任架构师，那是一个规模非常大的机构，拥有数百名各类架构师 —— 包括解决方案架构师、软件架构师以及企业架构师等各类“架构师”角色。

我原本打算接手一个尚处于起步阶段的应用，不过这个应用的架构设计工作是由另一位离职的架构师完成的。

有一些初步的文件资料留存了下来，但内容并不详尽，不过已经预先做出了不少重大决策。该应用是一款 SaaS 产品，年销售额高达数百万美元。某些地方使用了云环境，但并非在所有地方都用，还有数据库、数据湖以及与其他系统的集成，似乎有些古怪且格格不入。

这就是我在构建产品其余部分以及确定其架构和设计时所依据的基础。

基于已经做出的种种决定，我需要做出很多抉择。然而，却没有明确的框架或指导来帮助我进行这些抉择。

这还不够，我还得为我所做的决策以及之前其他人所做的决策进行解释和辩护，所有这些内容都必须在架构审查委员会面前进行陈述和论证。

这个决策制定流程简直让人精疲力竭，通过与其他架构师的交流，我意识到并非只有我一人有这种感受。

我想要弄明白原因。

为什么在一个看起来拥有庞大架构和技术力量的组织中，架构决策过程却如此耗费精力呢？

我意识到，这是因为根本就没有形成架构决策流程。

尽管有架构审查委员会、企业架构师的参与以及充足的预算，但对于 IT 架构师而言，在着手做出架构决策时却没有一套可遵循的流程。

尽管无法独自为整个公司建立起那样的流程，但或许至少可以为我的项目以及直属团队做些事情，即便最终结果可能并不完美，但这些努力仍可能具有一定价值。

然后我开始思考，到底缺失了什么东西？换句话说，正确的架构决策流程应包含哪些要素？

文档资料

首先，没有任何文件记录。什么都没有被记录下来，技术决策及其背后逻辑都没有被记录下来，甚至连那些每年让公司损失数百万美元的重大决策也没有记录在案。

我认为这会是个不错的起点，于是开始记录实际决策过程。起初只是简单的将相关信息以文本格式记录在 Confluence 系统中。

随后，结构变得更加严谨，最终采用一种简单却有效的格式来记录此类技术决策过程。

我将这种结构称为 技术/架构决策矩阵，目的是突出每个技术方案的不同方面。我们并不一定需要传达对每个方案进行研究时所涉及的所有详细技术信息，这些信息可以留给其他类型的文档来处理，其作用在于集中收集每个方案中最重要的方面，从而使每个方案的决策过程变得清晰明了、一目了然。

下面就是矩阵的结构，每个选项需要列出以下内容：

• 选项名称：用于标识该选项的简单标识符。

• 描述：对选项所包含内容的清晰但简短的说明。

• 优点：该选项带来的好处。

• 缺点：该选项的不足之处。

• 风险：实施该选项所涉及的风险。

• 影响：实施该选项的总体影响（正面或负面）。

还可以添加诸如 成本 或 不实施该选项的风险 等内容。

以这种方式记录技术决策所带来的首要作用是，能帮助我们对所有相关信息进行组织和整理。这样一来，就能够做出明智且正确的决策。

如果没有这份文件，决策过程就会变得随意且不透明，很难追踪理解为何会做出某些决策以及决策的具体过程，也很容易忘记和遗漏重要信息。

有人可能会说，这只会让其他人更清楚的理解决策过程，但并不能真正帮助到当时正在执行决策过程的那个人。但事实并非如此，即使作为决策者，也能够帮助我们在脑海中更好的整理思路，并以客观、清晰、明智的方式对每个选项进行分析。此外，还能帮助决策者向他人传达这些选项，并从他们那里获得有价值的反馈。

这对我的工作帮助极大，一旦开始记录技术方案，不仅有助于进行架构设计，还有助于与利益相关者就各种方案进行沟通和协商。

但是，仅仅列出各种选择是不够的，这是个很棒且重要的开始，但远远不够。

架构决策记录（Architectural Decision Records）

上述矩阵中的记录有助于我们以清晰、透明的方式确定应采用哪一选项。然而，这发生在做出决策之前，简而言之，这就是我们做出特定决策的过程。

一旦做出该决定，结果也必须如实记录下来。

这就是 架构决策记录（Architecture Decision Records，简称 ADR）发挥作用的地方。

简而言之，这些架构决策记录对于追踪决策以及为过往决策建立审计记录至关重要。

回到开头的例子，我们有多少次不得不去审视别人的决策，却无法理解他们为何会做出那样的决定？这种情况相当常见，原因在于，一旦做出决策，没人会去记录相关技术或架构方面的细节。

按照 ADR 的简单格式来操作，对于提高技术决策的可见性和透明度大有帮助。无论用 Confluence、Notion 还是 Markdown，记录这些决策都能消除我们试图理解为何选择这一方式而非另一方式时所存在的猜测成分。

此外，还能降低因长期遗忘最初制定该决策的初衷而导致重要决策被重新修改的风险。

因此，ADR 是一种简单却极具效力的工具，能够简化并助力架构决策过程。

现在，你可能会说这一切都很好。但问题在于，究竟如何将这些内容纳入到团队或组织的运作流程中呢？尤其是对于一家大型企业而言？如何将改进措施融入到所在组织的实际决策流程中呢？而且，如果不具备大规模改革组织流程的权限，又该如何实现这一点呢？

以下是我在担任软件开发人员、技术负责人以及架构师期间多次采用的一种方法，这些职位并不允许我直接决定和影响工作的具体执行方式。

关键在于建立清晰、透明、高效且强大的架构及技术决策流程，并逐步让利益相关者认识其价值。当然，这说起来容易做起来难。不过，如果运用一些创造力、坚持不懈的精神以及创新思维，是完全可以做到的。

每当我们考虑架构方案时，都会经历一个评估过程。但问题是，在许多组织中，这种评估往往是隐性的。并非以有意识和审慎的方式进行，也没有形成书面记录，因此无法重复，也缺乏透明度。

要在大型组织内部建立起更有效的决策流程，应从小处着手，逐步获得利益相关者或团队的逐步支持。

第 1 步：树立榜样

软件架构师和开发人员往往认为，对于超出其职责范围、所有权或管理权限的事项，他们无法做出改变。当然，这种观点有一定道理，但事实上，你们所拥有的影响力和权力远超自认为的那样。

关键在于，你不能简单命令组织去实施你所提议的变革，而是需要去说服这个组织。

可以从某个具体案例开始，以此为例来展示所做之事的价值。

首先找到某个存在架构问题的情况，即你或他人曾需从多个选项中做出选择。这个问题可能是过去发生过的，也可能是当前正在处理的。

使用上述技术决策矩阵记录正在考虑的各种选项。不必过于复杂，只需能清晰传达已做出或正在做出的决策要点即可。

然后，如果过去已经根据这些选项做出了决定，就记录一个简单的 ADR。

第 2 步：获得有限支持

一旦记录了一些选项，并且手头有了具体的东西，是时候让别人注意到这一点了。

找几位团队成员或利益相关者，他们和我们一样，也受到缺乏明确架构决策流程这一问题的影响。这些人可以是其他架构师、开发人员、经理、产品负责人等等。

展示所记录的内容，并说明此类记录资料在简化流程以及缓解当前难题方面（至少在一定程度上）能起到怎样的作用。

这有助于构建某种展示，可以列出这种流程的优点以及不实施该流程所存在的风险。

后半部分至关重要，表明了不采纳所提议方案的后果。

一旦获得部分利益相关者的支持，并且已经获得了一定的实际支持，那么就可以进入下一步了。

第 3 步：向更广泛的群体进行宣传并获得支持

在此阶段，需要向团队或相关利益相关者介绍所经历的这一过程及其带来的好处。可以通过演示、研讨会或就该主题所举办的一系列演讲来实现。

向利益相关者展示第 2 步已经获得的支持情况，据此来阐述你的观点。

目标是让团队相信这一过程是有价值的，并促使他们认同并采纳这一架构决策流程，将其融入日常工作中。

为了促进转变，并使团队操作起来更加便捷，可以提议进行一次“试运行”。在此期间，团队可以先试行该流程一段时间，然后重新评估并验证该流程是有助于解决问题还是反而使情况变得更复杂。

关键在于要逐步小幅度实施变革，而不要要求对团队的工作方式进行大规模调整。如果采取后者的方式，很可能会引发更多抵触和反对情绪，阻碍新流程的推行。

团队成员可以开始做的事情其实非常简单，大致就是：

1. 下次需要就某个解决方案、系统、应用程序或其他具有足够重要技术或架构影响的事项做出架构决策时，可以记录基本的决策矩阵。

2. 用该矩阵来向团队成员介绍和讨论解决方案以及各种选项。

3. 将最终做出的决策记录为 ADR。

为了流程更加顺畅，我们甚至可以主动承担引导基于决策矩阵进行架构讨论的任务。这可以在架构审查委员会会议期间进行，也可以是单独的会议。

还需要向团队保证，我们会提供指导和支持，这点对于确保新流程的成功实施（这是团队运营模式的一部分）至关重要。

总结

在许多组织中，存在着一项重要需求，即简化技术及架构方面的决策流程。通常情况下，这类决策并没有相应流程可依循。若缺乏此类流程或者流程效果不佳，就会导致混乱、信息遗漏并增加风险。

此外，还会导致软件工程师、架构师以及其他技术和非技术方面的利益相关者产生决策疲劳，而他们必须做出这些决策，或者依赖这些决策来行事。

如果没有清晰、有效且可重复的框架，决策过程就会变得令人疲惫且效率低下。技术决策者们不再能够推动发展，反而陷入了反复争论、不确定性以及不断增加的运营风险之中。

那些未能解决这一问题的组织将会付出代价，包括时间的浪费、不必要的复杂性、以及灵活性的降低，并且很有可能会遗漏一些重要的架构考量因素，从而在未来引发严重的组织问题。因此，建立高效、透明的决策流程对于组织的成功至关重要。

这个过程有几个关键点：

1. 通过编制“架构决策矩阵”使技术决策过程变得清晰且有条理，该矩阵侧重于每个选项的关键方面。

2. 利用矩阵推动架构讨论，通过架构审查委员会或其他类似会议来进行。

3. 做出决策后，将决策记录为“架构决策记录”。

本文提供了简单且易于实施的方法，可实现此类流程的实施，同时又不需要对组织进行大规模变革。只需要为需要进行架构决策的特定领域创建矩阵，然后向团队推广，建议采用“试运行”方式来实施，这样工作量最小。

这种方法具有以下优点：

✅ 减少抵触情绪 —— 小的改变更容易被接受

✅ 展现阶段性成果 —— 能保持势头持续下去

✅ 建立信任 —— 人们开始相信这个过程

你好，我是俞凡，在 Motorola 做过研发，现在在 Mavenir 做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！