架构中的强力和弱力
良好的技术设计决策高度依赖于上下文。经常一起为共同目标工作的团队能够定期沟通并快速协商变更。这些团队表现出强力的协同性，并且可以做出利用这种强力的技术和设计决策。当我们在更大的组织中放大时，在独立工作且协作频率较低的团队和部门之间存在越来越弱力。认识到这些强力和弱力的差异，使我们能够做出更好的决策并为每个级别提供更好的指导，从而实现更赋能的团队，这些团队可以更快地行动。
2021 年 11 月 10 日
Evan 是一位经验丰富的架构师和技术领导者，致力于帮助组织更成功地交付和维护技术。他将时间花在穿越规模化组织的沟通和决策路径上，并帮助人们管理复杂性。
Evan 以前是 Thoughtworks 的技术总监，现在是位于澳大利亚的业务管理平台 MYOB 的架构主管。
技术治理和“良好架构”的定义通常采用“一刀切”的方式。许多组织试图在所有级别应用相同的严格治理 - 限制技术选择，并削弱团队的权力。其他组织则允许团队在所有级别完全自主，这意味着团队可以自由选择，没有任何约束。这两种方法都不理想。
以一个具体的例子来说，我们长期以来看到集成架构师在架构的所有级别都努力追求“唯一正确”的集成方法。他们引用“最佳实践”，强制执行极其松散的耦合、向后兼容的接口以及对所有级别所有系统交互进行仔细的封装。这种普遍的方法在许多情况下造成了不必要的复杂性和延迟 - 但是如何确定在哪里可以更快地行动并放松这些要求呢？
MYOB 团队
在 MYOB，我们根据现代数字产品组织的成熟原则对团队进行了组织。团队与我们的产品能力和业务能力保持一致，并负责其软件和基础设施的规划、交付、维护和支持的所有方面。
团队被分组到域中，这些域汇集了相关的功能，一些领导和赋能角色在域级别工作。域进一步分组到称为垂直的更大的组织单元中。垂直代表我们客户群的主要部分。
当然，还有更多内容，包括支持功能和内部平台，这些平台为整个组织有效交付提供了支架。但是，这个简化的模型对于推理技术治理很有用。
在本文中，我想解释这种结构如何影响我们的技术选择和设计决策，以及根据决策范围（或“爆炸半径”）可能适合不同的方法。我喜欢使用的概念模型是组织不同部分之间的吸引力。
域内 = 强力
在一个域内，我们有多个团队，每个团队负责域内的一些功能和底层系统。有时这完全一致，每个团队都是一组整齐界定的系统的管理者。在现实中，这种情况往往并不完美，一些系统的管理权在团队之间共享 - 通常是出于遗留原因。对于域内的团队来说，存在非常强的协同力。
域结构旨在将功能上内聚的系统整合在一起 - 它们密切相关，处理相同的概念，依赖于共同的域专业知识，并且经常同时发生变化以满足客户需求。
单个团队的成员通常会跨越相同的系统工作，因此需要一种非常清晰且一致的工作方式、标准、技术选择和设计方向。这是最强的协同力。
在同一个域内的团队之间，协同力仍然非常强。知识共享很容易且流畅。协商系统交互（例如模式）相对容易。当需要交付跨越域内系统的功能时，通常相同的人员会实施每个集成点的“两端”。
这意味着域内系统之间的“私有”交互 - API 调用、事件、数据文件 - 可以具有更紧密的耦合，而不会产生太大的成本。通过允许一些更紧密的耦合，我们可以减少用于版本控制和向后兼容性以及避免共享依赖项的工作量。域级别系统之间的耦合并不总是必须不惜一切代价消除的邪恶怪物，事实上，这种范围内的耦合可能是一件好事。
垂直内 = 弱力
在中间地带，我们有垂直结构，包含多个域。一个域中的人员与另一个域中的人员之间的社交距离正在拉大。这使得协商和达成一致变得更加紧张和缓慢，因此必然会影响我们的技术选择和方法。
整个组织 = 弱力
当我们放大到整个组织时 - 垂直之间的协同力非常弱。几乎不可能在整个环境中原子地进行更改 - 主要是因为每个垂直的工作优先级是故意独立的。协调此级别的工作必然会更慢且更有限。这意味着我们的设计决策和方法需要相应地调整。
我们如何应用这个模型？
让我们通过探索一些可能根据其范围而有所不同的技术决策领域来使这个模型更加具体。以下列表并非详尽无遗 - 只是几个值得考虑的有趣示例。
技术选择
垂直（弱力）
在垂直级别，将有一组略大的商定技术选择，以满足多个域的不同需求。
垂直能够将人员更靠近高优先级工作是有益的，因此保持技术一致在这里很重要。
更正式地共享解决方案选项和提案可以有效地保持选择一致。
整个组织（弱力）
在整个组织级别，协调和管理技术选择的力最弱。
MYOB 技术雷达在首选技术方面设定了方向。
解决方案选项和提案鼓励对话并提高一致性。
共享代码和基础设施
域（强力）
在一个域内，即使跨越 3-5 个团队，我们也应该拥有高带宽的通信和通往赋能领导层的短距离。
这意味着当需要对共享代码或基础设施进行更改时，我们可以快速通知并为更改做好准备。
共享代码和基础设施带来的耦合影响较小，并且优势通常大于成本。
垂直（弱力）
共享代码、工件和基础设施通常可以在垂直级别进行管理 - 但应仔细监控引入的阻力。
整个组织（弱力）
在整个组织级别共享代码仅限于高度稳定、高度有用的内容。这些内容通常仅限于可以分发和版本控制的库，并且可以谨慎地进行更改。
共享基础设施类似 - 在组织范围级别，共享基础设施必须具有非常高的价值，并且必须很好地封装（“作为服务”，自助服务）。它应该很少需要响应单个团队的需求而进行核心更改。
代码贡献模型
域（强力）
在一个域内 - 在实践和技术方面具有高度一致性 - 团队可以合理地在团队边界之间贡献代码，集体代码所有权扩展到整个域。
每个系统的管理权应仍然清晰明了，通常最好由一个团队保留。
垂直（弱力）
在一个垂直结构中，代码贡献通常发生在系统之间，例如源代码控制中的拉取请求 - 仅需要少量延迟和返工。
整个组织（弱力）
在整个组织级别，有效地管理跨越垂直的贡献通常很困难（有时甚至有害）。
这在系统本质上很复杂、在准确性、性能、隐私和合规性方面高度关键或敏感的情况下尤其如此。
当建立全新的系统功能时，跨越垂直进行协作甚至一起进行结对编程可能效果很好。但是，随着功能的建立以及其他垂直对更改的需求不断增加，需要投入资金来使这些系统能够安全地扩展和配置。这些更改通常是架构性的 - 将“核心”和复杂子系统分离，并引入模块化以使扩展更容易管理。
集成模式
域（强力）
在单个域内拥有的系统可以相对容易地以紧密协调的方式进行更改。例如，这意味着在维护接口的向后兼容性方面需要花费的精力（略微）减少。
即使是“禁止”的方法，例如数据库级集成，在单个域内的系统中也会产生较小的影响。虽然我们不应该故意以这种方式构建系统，但如果它存在，那么我们可以将影响限制在单个域内。
垂直（弱力）
必须跨越垂直结构内的多个域进行协调的更改应该很少见，但在绝对必要时可以进行管理。 扩展-收缩 API 合同的更改 在影响限制在垂直结构内的情况下非常有效。
整个组织（弱力）
发布到整个 MYOB 的 API 和接口（例如事件）必须高度关注已发布的模式、版本控制、向后兼容性、合同和弃用策略。
高度耦合的集成（例如 ETL、数据库集成）的影响非常大，应绝对避免。
结论
在任何规模不小的组织中，每天都会做出数十个技术决策。多年来，我们一直努力使团队能够做出更接近工作的决策，而无需对每个决策进行严格的集中治理。实现“协调的自主权”并非易事，需要不断平衡和调整。简单的模型可以帮助团队了解如何在上下文中做出良好的决策。在本文中，我描述了 MYOB 如何将我们的技术治理方法与我们的组织结构和动态保持一致。了解我们组织内的这些协同力，使我们能够理解哪些事情容易做，哪些事情难以做，并因此做出更好的技术选择。
致谢
这篇文章最初是 MYOB 内部的一篇博客文章，它引发了一些精彩的对话，帮助我完善了这个想法。感谢 MYOB 同事 Heaton Cai 和 Thoughtworks 的 Rebecca Parsons、Birgitta Böckeler、Mark Taylor 和 Peter Gillard-Moss 对草稿提供的深刻反馈。
重大修订
2021 年 11 月 10 日：发布