团队授权：分散化的架构决策

跟黏菌学习：去中心化架构的隐喻

图片来源

多头黏菌（Physarum polycephalum），通常被称为黏菌，为软件架构师提供了一个意想不到的学习案例，因为它能够独立且无需中央决策者就能创建一个复杂而高效的网络。

科学家们通过将食物源放置在东京周边相对应的位置，并观察黏菌的反应，该实验揭示了这种单细胞生物惊人的决策能力。

黏菌会扩散开来，在局部探测营养物质和驱虫剂，针对寻找食物的方向做出局部决策。随着时间的推移，它们形成了一个营养输送管网络，在某些地方看起来与东京地铁系统惊人地相似，但效率更高。

这一自然现象挑战了传统方法，即架构决策通常需要集中化，有时甚至是从象牙塔中做出的。

那么问题就变成了：软件团队能否从黏菌那里学习，以创造更有效的架构决策过程呢？

上图显示了在 26 小时后，黏菌创建了一个与东京地铁相似的网络[图片来源]

我们的转型之旅

我们面向去中心化架构决策的转型始于 2020 年，当时我们正在努力解决一个熟悉的问题：一个拥有多条代码线、混合版本的.NET 以及分散在各处的不同库和包的遗留解决方案。涉及到 Windows 安装程序和文件复制的手动部署过程很容易出错，手动环境变更也是如此。这些错误导致了漫长的前置时间，即为期三到六个月的发布周期、用户验收测试（UAT）阶段和错误修复周期，向客户交付的价值也特别小。

组织设定了一个雄心勃勃的目标：将系统重新架构为云原生 SaaS 平台，同时采用现代化的工程实践。这一转型需要技术变革，以及在团队之间制定和实现架构决策的根本转变。

建立快速流动的团队

转型的第一步涉及根据 Matthew Skelton 和 Manuel Pais 所述的“Team Topologies”中的原则重组团队。公司建立了三个产品工程团队、一个由 SME 和专家组成的支持团队（以支持产品工程团队），以及一个最初专注于重新平台化的平台团队，但它后来演变成一个支持工程团队并减轻他们认知负担的团队。

根据 Nicole Forsgren 博士、Jez Humble 和 Gene Kim 以及DORA研究所所著的“Accelerate: The Science of Lean Software and DevOps”一书，有两项关键能力构成了这一转型的核心，即松耦合的架构和团队授权。为了支持团队之间的快速流动，组织需要一个可以跨团队分布的松耦合架构，同时授权这些团队以最佳方式解决问题。

建议流程：去中心化决策的基础

建议流程成为支持授权和对齐团队的核心。这一流程已进入 Thoughtworks Tech Radar 的试验象限，它规定任何团队都可以做出他们需要的任何决策，只要他们已经从所有受影响的方面和具有专业知识的人那里寻求了建议，并公开记录这些决策即可，如果有必要，应包含记录反对建议的理由，包括它的利弊。

这个简单而强大的框架将决策权转移到了团队，同时确保适当的咨询和记录。这种转变需要三个支持工具：指导决策的架构原则、记录决策的架构决策记录，以及分享和讨论决策的架构咨询论坛。

创建上下文图：定义边界和所有权

在团队能够做出独立决策之前，他们需要清晰的边界和所有权。产品工程团队继承了一个十五年历史的遗留平台，该平台主要使用旧技术编写，采用不同的架构风格，包括单租户桌面工具。为了使团队能够独立工作，同时提高快速流动，他们需要一种方法来理解整个系统，同时识别松耦合的业务领域。

通过应用领域驱动设计原则，我们创建了上下文图（context map），以识别松耦合、以业务为中心的领域，称为有界上下文。团队绘制了这些上下文之间的关系和契约，可视化了系统内的所有领域及其相互连接。然后，每个有界上下文被分配给一个特定的团队，使该团队负责该上下文中的所有重构、新功能开发和缺陷修复。

为具有复杂依赖关系和不同领域之间契约的遗留系统创建上下文图是很具有挑战性的。它的目标不仅仅是识别系统中的松耦合区域，还确保它们与业务流程对齐，使上下文图对公司中的每个人（包括工程师、QA、产品团队以及任何需要了解软件架构和团队所有权的人）都有用。

遗留平台上下文图的第一个视图，展示了其规模和复杂性。

上下文图的定义需要持续的审查和细化以保持适当的对齐。即使经过多次审查，灰色区域和共享上下文仍然存在。灰色区域是系统内没有明确归属的部分，无法被识别为独立的、有界限的上下文，或者是现有上下文的一部分。共享上下文是那些被不同团队或所有团队访问的上下文。这些区域可能成为挫败感的来源，特别是当在共享或灰色区域上下文情况下出现复杂、紧急的错误时，团队称之为“上下文图战争”。

尽管存在这些挑战，但是上下文图依然提供了显著的收益。通过定义不同有界上下文之间的复杂依赖关系，使团队能够充分意识到他们决策的影响。在他们的有界上下文中进行更改时，团队可以查看上下文图以了解将会受到影响的内容，哪些有界上下文将受到影响，以及他们需要与哪些团队协商或合作。这会形成更具协作性的决策过程，并激励团队考虑移除依赖关系，从而实现更具松耦合性的架构。

灰色区域和共享上下文为需要重新架构的组成部分提供了宝贵的见解。识别这些区域并将它们标记为技术债务以优先解决，可以让每个人的生活变得更轻松。上下文图建立了团队对分配上下文的所有权，使他们能够独立工作和规划。

架构原则：指导决策制定

架构原则作为核心思想，需要指导团队如何思考、行动和构建软件。公司原则是通过与业务中的各种专家和 SME 的协作会议制定的，从业务战略演示开始，并相应地塑造原则。在工程、QA 和架构之间共享理解的情况下，团队就能创建指导他们工作的原则。

这些原则就像虚线一样，围绕团队所构建的内容进行塑造，影响架构决策并指导决策。我们的组织从研讨会发展出了 16 个架构原则。每个原则都包括一个明确的声明，说明它的目标是什么，与商业战略的战略目标的联系，解释收益的基本原理，以及正面和负面的影响。

例如，“隔离租户数据库”原则清楚地说明了隔离租户的方法，与业务战略目标相关联，为快速消费和回溯提供了简洁的基本原理，并承认由于使用租户方法而增加的托管成本等影响。

架构原则有助于让团队与业务战略保持一致，创建跨团队的共识，因为它们是由团队自己形成的，成为了决策的基础。

架构决策记录：对选择进行文档化

决策构成了软件架构的核心，而实践软件架构就意味着与要与决策协作。软件开发本身代表了一个持续不断的决策流。在分散的决策过程中，从开发人员到架构师，每个人都为架构决策做出贡献。对于这种方法，确定一个决策在架构上是否重要，是否会影响现在或将来的系统，比谁做出这个决策或花了多长时间更重要。

记录架构决策捕捉了每个“什么”背后的“为什么”，为未来的学习和共享理解创造了宝贵的上下文。架构决策记录（ADR）是具有预定义格式的短文档，记录了单个架构决策，最重要的是，记录了它们背后的逻辑。

ADR 格式包括：

• 代表决策本身的唯一标识符和标题

• 编写 ADR 的作者，通常来自团队领导的团队

• 状态（新建、草稿、提议、采纳或取代）

• 决策部分包含一个简短的、自解释的描述，使用一到三句话即可。

• 指导决策的相关架构原则

• 描述触发决策需求的因素的上下文

• 考虑的替代方案，每个选项的优缺点以及为什么没有选择它们

• 决策的后果，包括正面和负面的影响

• 记录收到的建议，包括建议本身、给出建议的人和日期

ADR 支持记录架构决策，同时指导决策过程本身。当团队对即时决策缺乏信心时，起草 ADR 能够提供一个结构。上下文部分提醒人们为什么需要这个决策以及它解决了什么问题。选项部分列出了所有备选方案的优缺点，并使它们与架构原则保持一致。

当需要额外的调查时，团队可以提出探索性的问题。例如，在引入新技术时，如果它与架构的契合度存在不确定性，团队可以进行调查、分享学习成果，并为决策建立信心。一旦准备好，就会做出决定并将其结果记录下来。

寻求反馈或建议的时机取决于决策的性质。对于影响多个系统部件的重大决策，或者当缺乏业务或技术知识时，在决策过程中寻求建议会产生更好的结果。ADR 是不可变的文件；一旦标记为采用，就不能进行更改。如果一个决定需要修改，以前的 ADR 将被取代，并创建一个新的 ADR。

在将近五年的时间里，我们创建了 200 多个 ADR。这些文档都被集中和组织了起来，最初保存在 wiki 页面上，但后来为了更好的管理，转移到了工作项中。团队频道和电子邮件的通知系统会确保在 ADR 创建或更新时每个人都能得到通知。ADR 作为项目的活文档，通过模板，强制遵循定义好的格式。

架构咨询论坛：分享与协作

架构咨询论坛（Architectural Advisory Forum，AAF）代表了公司的周会，对所有团队、架构师、QA 和 SME 开放。论坛遵循一个固定的议程，首先讨论即将到来的冲刺，因为团队冲刺和未来决策之间存在相关性。分享即将到来的冲刺为所有团队提供了早期的可见性，从而在决策时提供更好的反馈。

论坛接着会讨论人们想要展示的即将形成的 ADR。虽然通知会提醒团队新的 ADR，但论坛提供了快速演示和提问的机会。额外的议程项目包括 DORA 指标和 Azure 支出，因为两者都与架构决策相关。每周监控允许团队观察决策的影响，这可能是资源变化所影响的成本和性能指标。服务水平目标（SLO）仪表板后来添加了进来，以提供额外的可见性。

第一个 ADR：经验教训

第一个做出独立架构决策、在 ADR 中记录它并在架构咨询论坛上分享的团队面临了独特的挑战和责任。该团队被分配了业务线上下文的所有权，这是遗留系统中一个复杂的领域，有许多依赖关系和与其他有界上下文的关系。

这个上下文面临了多个架构方面的挑战：一个单租户的单体桌面工具用于创建和管理业务线；质量问题；需要频繁开发干预的限制；缓慢的交付时间和不频繁的生产发布，以及性能瓶颈。该团队的解决方案为业务线引入了微服务，具有自己的数据存储和默认配置。

这个决策带来了重大的架构转型。为业务线引入微服务意味着要采用所有微服务的原则，包括每个微服务都有一个 Azure Cosmos DB。这一架构方式的引入代表从单一共享的 SQL 数据库向多个 Azure Cosmos DB 的转变，需要数据同步和双重写入来管理依赖关系，并与其他仍然依赖单一 SQL 数据库的有界上下文的契约。微服务将能够独立部署和扩展，缩减交付时间并实现更快的生产发布。

做出第一个决策的经历带来了复杂的情绪。与架构一起工作并做出架构决策是令人兴奋的，就像购物时看到所有东西都在打折，想要尝试每一种新技术和架构风格一样。然而，责任是重要的，我们意识到决策会影响团队，并且需要广泛的对话来理解和解决依赖关系。

从项目领导的角度来看，看着团队做出独立决策就像是使用自动驾驶功能的第一位特斯拉测试驾驶员，他们都希望避免撞车。避免做出决策需要有意识的努力，以避免破坏建议过程并回到替团队做出决策的老路上来。来自利益相关者的大量信息需要重新定向回 ADR 流程和 AAF，而不是非正式渠道。

在 AAF 上展示时，原本十分钟的演示延长到了一个多小时，因为有很多问题和动态需要讨论。变革的规模产生了不同的意见，导致 ADR 的建议部分收到了大量的反馈。与顾问的线下对话继续进行，以了解他们的观点并考虑他们的反馈。尽管一些方面强烈反对，支持者也有所担忧，但团队最终在没有更改的情况下采纳了决策。

对第一个 ADR 的反思揭示了需要改进的领域。决策没有与产品愿景建立更强烈的联系，因为它涉及架构和产品决策。并非所有参与建议过程的参与者都理解整体产品愿景，这限制了他们提供与产品方向一致的有效反馈的能力。这种理解的缺乏会影响在必要时创建与 ADR 相关联的产品决策记录。

根据现有的知识，我们倾向于采用一种更加迭代化的方法，通过多次 ADR 做出更小的决策，以实现更快的反馈和更大的灵活性。在决策过程中获取更多的建议，而不是等待 AAF 成为标准做法。在区分建议和意见的同时，尽早与受影响的团队和领域专家合作对有效决策至关重要。

决策演变

经历去中心化决策的团队会经历四个可预测的阶段。最初，团队没有意识到他们可以做出决策，因为他们习惯于从他人那里获得决策。他们寻求批准和盖章，但这些并没有出现，需要领导层坚定立场，打破集中式决策。

团队意识到他们具有自主权后，决策就会开始流动。他们兴奋和充满活力地探索新技术、框架、库、实践和模式。随着肉眼可见的势头，过程变得活跃起来。

第三阶段到来时，团队会感受到他们的决策的影响。大型、复杂的决策显示了它们的后果，团队会从好的和坏的选择中学习，这是所有架构师成长过程中必要的一部分。

最后，系统自我纠正并达到平衡。团队相互问责，质疑决策，提供反馈，并积极寻求意见。经过深思熟虑的 ADR 提交给 AAF，经验丰富的团队为新团队和加入组织的成员提供指导。

收益和输出

去中心化的架构决策提高了整个组织的信任和透明度。团队需要相信他们能够做出适当的决策，这些决策可能并不总是完美的，但承诺在给定的情况和约束下做出最佳选择。在分享决策和寻求建议时，保持透明度成为了流程的基础。

随着团队独立开展工作，他们之间实现了协调和对齐，同时为他们界定的上下文建立了所有权。架构原则指导团队遵循整体架构愿景，提醒他们正在同一款产品上工作，而不是在孤岛上，要做出针对他们特定上下文的决策，同时为整体做出贡献。

去中心化决策通过协作和分享产生了更强的架构决策。因为团队独立且更高效地工作，所以它支持快速流动。这种方法并没有消除对架构师的需求。团队仍然需要经验丰富的架构师的支持，他们可以促成事件风暴、威胁建模和风险风暴等研讨会。

架构师作为团队之间的桥梁，要发现单个团队可能错过的联系和影响。他们参与复杂、有趣的问题，从日常决策中解放出来，专注于需要他们专业知识的挑战。

结论

我们公司从集中式架构控制向去中心化决策的转变表明，团队就像黏菌一样，可以通过结构化框架内的地方自治创建高效、适应性强的系统。上下文映射、架构原则、ADR 和咨询论坛的结合为团队提供了必要的框架，使他们能够自信地做出决策，同时保持架构的连贯性。

五年多的时间和两百多个 ADR 之后，证据是明确的：通过强制性咨询和透明的文档，授权团队做出的决策比传统的审批层级更强大。

尽管这一旅程中涉及到可预测的挑战，从最初的不信任到最终的自我纠正，结果证明，投资是值得的。团队实现了更快的交付、更好的对齐和不断增强的所有权，而架构师专注于复杂问题和跨团队协调，而不是日常审批。

考虑采用这种方法的组织应该为所需的文化转变做好准备，但可以期待在技术决策质量和团队参与度方面能够取得显著改进。来自自然和我们经验的教训是令人信服的：适当支持的分布式智能胜过集中控制。

查看英文原文：Empowering Teams: Decentralizing Architectural Decision-Making