好的技术设计决策严重依赖于上下文！定期为共同目标而合作的团队能够定期沟通并快速协商变更。这些团队表现出强大的一致性，并且可以利用这种强大的力量做出技术和设计决策；而独立工作且协作频率较低的团队和部门之间存在越来越弱的力量。
技术治理和所谓的“良好架构”大多采用“一刀切”的方法来考虑。许多组织试图在各个级别应用相同的严格治理：限制技术选择，并剥夺团队的权力；而有一部分其他人（banq注：所谓平台团队）则允许团队在所有级别上完全自治，这意味着团队可以不受任何限制地做出自己的选择。这两种方法都不是理想的。
举一个具体的例子，我们早就看到集成架构师在架构的所有级别上都在努力寻求“一个真正的”集成方法。他们引用了“最佳实践”，强制要求极其松散的耦合、向后兼容的接口以及对所有级别的每个系统交互进行仔细封装。在许多情况下，这种通用方法造成了许多不必要的复杂性和延迟 - 但是您如何确定可以更快地移动并减轻这些要求的地方？
MYOB 团队
在MYOB，我们根据现代数字产品组织的行之有效的原则来安排我们的团队。团队与我们的产品能力和业务能力保持一致，并负责其软件和基础设施的规划、交付、维护和支持的所有方面。
团队被分组到领域中，这些域汇集了相关的功能，在域级别工作的一些领导和支持角色。域被进一步分组为称为“垂直Verticals”，一种更大的组织单位，垂直代表了我们客户群的主要部分。
在本文中，我想解释这种结构如何为我们的技术选择和设计决策提供信息，根据决策的范围（或“爆炸半径”），可能适用不同的方法。我喜欢的概念模型是组织不同部分之间的吸引力。
在一个领域内 = 强大的力量
在一个域内，我们有多个团队，每个团队负责域内的某些功能和底层系统。有时这是完全一致的，每个团队都是一组整齐划一的系统的保管人。在现实中，这通常是不完美的，因为某些系统的托管是跨团队共享的——通常是出于遗留原因。但对于一个领域内的团队来说，有很强的一致性。
领域结构旨在将在功能上具有凝聚力的系统结合在一起——它们密切相关，处理相同的概念，依赖于共同的领域专业知识，并且经常同时发生变化以满足客户需求.
单个团队的成员通常在相同的系统中工作，因此需要非常清晰且一致的工作方式、标准、技术选择和设计方向。这是最强大的对齐力量。
同域战队之间，阵营力量还是很强的。知识的共享既简单又流畅。就系统交互（例如模式）进行协商相对来说非常容易。当需要交付跨越域中系统的功能时，通常同一个人将实现每个集成点的“双方”。
这意味着域内系统之间的“私有”交互——API 调用、事件、数据文件——可以具有更紧密的耦合，而不会产生如此严重的成本。通过允许一些更紧密的耦合，我们可以减少版本控制和向后兼容性以及避免共享依赖项的工作量。域级别的系统之间的耦合并不总是必须不惜一切代价战胜的邪恶怪物，实际上在这个范围内耦合可能是一件有用的事情。
在垂直范围内 = 减弱的力量
在中间地带，我们有我们的垂直结构，存在有多个领域（banq：筒仓）。一个领域的人们与另一个领域的人们之间的社会距离正在拉大。这使得谈判和达成一致更加紧张和缓慢，因此必然会影响我们的技术选择和方法。
整个组织=弱力量
当我们俯瞰整个组织时 ： 垂直之间的对齐力量确实非常弱。在整个景观中原子地进行更改非常困难 ：主要是因为每个垂直领域的工作优先级是故意独立的。在这个层面上的协调工作必然要慢得多且有限。这意味着我们的设计决策和方法需要相应地进行调整。
如何改进？
让我们通过探索一些可能因范围而异的技术决策领域来使这个模型更加具体。下面的列表并不是详尽无遗的——只是一些值得考虑的有趣例子。
- 我们如何管理技术选择的生命周期？
- 领域（强力）：在一个单一的领域内，应该有一小组技术选择达成一致。通常， 对于所需的每一类技术，这都遵循Default Trial Retire。通过技术领导的非正式治理通常非常有效
- 垂直（弱力）：在垂直层面上，将有一组稍大的商定技术选择，以满足多个领域的不同需求。垂直行业能够让人们更接近高优先级的工作是有益的，因此在技术上保持一致很重要。解决方案选项和建议的更正式共享使选择有效地保持一致。
- 整个组织（弱力）：调整和管理技术选择的最弱力量是在整个组织层面。MYOB 技术雷达在首选技术方面设定了方向。解决方案选项和建议鼓励对话并改善一致性。
- 共享代码和基础设施
- 领域（强力）：在单个域内，即使是跨 3-5 个团队，我们也应该拥有高带宽通信和近距离获得授权的领导。这意味着当需要对共享代码或基础架构进行更改时，我们可以快速通知并为更改做好准备。共享代码和基础设施引入的耦合影响较小。
- 垂直（弱力）：共享代码、人工制品和基础设施通常可以在垂直级别进行管理 - 但应仔细监控引入的阻力。
- 整个组织（弱力）：整个组织级别的共享代码仅限于高度稳定、高度有用的东西。大多数情况下，这些东西仅限于可以分发和版本化并仔细更改的库。共享基础设施是类似的——在组织范围内，共享基础设施必须具有很高的价值，并且被很好地封装（“即服务”，自助服务）。它应该很少需要针对单个团队的需求进行核心更改。
- 代码贡献模型
- 领域（强力）：在单个领域内——在实践和技术方面高度一致——团队跨团队边界贡献代码是非常合理的，一种集体代码所有权扩展到整个领域。每个系统的监管仍然应该清楚地理解，通常最好保持在一个团队内。
- 垂直（弱力）：在垂直领域内，跨系统发生代码贡献是很常见的，例如源代码控制中的拉取请求——只需要少量的延迟和返工。
- 整个组织（弱力）：在整个组织层面，有效管理跨垂直领域的贡献通常非常困难（有时是有害的）。当系统本质上很复杂、在准确性、性能、隐私和合规性方面非常关键或敏感时，尤其如此。当建立全新的系统功能时，它可以很好地跨垂直协作，甚至一起进行结对编程。然而，随着功能的建立和对其他垂直领域变化的需求增加，需要投资以确保这些系统可以安全地扩展和配置。这些变化本质上通常是架构性的——将“核心”和复杂的子系统分开，并引入模块化以使扩展更易于管理。
- 集成模式
- 领域（强力）：在单个域内拥有的系统相对容易以密切协调的方式进行更改。例如，这意味着（稍微）减少维护接口向后兼容性所需的努力。甚至像数据库级集成这样的“禁止”方法在单个域中的系统内的影响也较小。虽然我们不应该故意以这种方式构建一个系统，但如果它存在，那么我们可以将影响控制在单个域中。
- 垂直（弱力）：必须在一个垂直领域内跨多个域协调的更改应该很少见，但可以在绝对必要时进行管理。 API 合同的扩展合同更改在影响包含在垂直范围内的情况下非常有效。
- 整个组织（弱力）：发布到整个 MYOB 的 API 和接口（例如事件）必须高度关注发布的模式、版本控制、向后兼容性、契约和弃用策略。高耦合集成（例如 ETL、数据库集成）的影响非常大，应该绝对避免。
结论
在任何规模不小的组织中，每天都会做出许多技术决策。多年来，我们一直努力使团队能够做出更贴近工作的决策，而无需对每一个决策进行严格的集中治理。实现“统一自治”并非易事，需要不断平衡和调整。简单的模型可以帮助团队了解如何在上下文中做出正确的决策。在本文中，我描述了 MYOB 如何将我们的技术治理方法与我们的组织结构和动态保持一致。意识到我们组织内的这些一致性力量使我们能够了解什么是容易的，什么是困难的，并因此做出更好的技术选择。