任何大型软件工作，如大公司的软件产业，都需要大量人员，而只要有大量人员，就必须想办法把他们分成有效的团队。
组建以业务能力为中心的团队有助于软件工作对客户的需求做出响应，但所需的各种技能往往让这些团队不堪重负。
团队拓扑（Team Topologies）是马修-斯凯尔顿（Matthew Skelton）和曼努埃尔-派斯（Manuel Pais）开发的一种描述软件开发团队组织的模型。
它定义了四种团队形式和三种团队互动模式。
该模型鼓励健康的互动，使以业务能力为中心的团队能够蓬勃发展，稳定地提供有价值的软件。
该框架中的主要团队类型是流对齐团队，即以业务能力为中心的团队，负责为单一业务能力提供软件。这些团队是长期运作的团队，他们认为自己的工作是提供软件产品，以提高业务能力。
每个流对齐团队都是全栈和全生命周期的：负责前端、后端、数据库、业务分析、功能优先级排序、用户体验、测试、部署、监控--软件开发的全过程。
他们以结果为导向，专注于业务成果，而不是以活动为导向，专注于业务分析、测试或数据库等功能的团队。
但这些团队也不应过于庞大，理想的情况是每个团队都是两个披萨小组。
一个大型企业会有很多这样的团队，虽然他们有不同的业务能力需要支持，但他们有共同的需求，如数据存储、网络通信和可观察性。
像这样的小团队需要找到减少认知负荷的方法，这样他们就可以集中精力支持业务需求，而不是（例如）数据存储问题。
要做到这一点，很重要的一点就是要在一个平台上进行构建，以解决这些非重点关注的问题。
对于许多团队来说，平台可以是一个广泛可用的第三方平台，例如用于数据库支持的网络应用程序的 Ruby on Rails。
但对于许多产品来说，没有一个现成的平台可以使用，团队必须找到并整合多个平台。
在规模较大的企业中，他们必须使用一系列内部服务，并遵循企业标准。
当我谈论平台时，我在谈论什么？
到目前为止，这种模式并没有什么特别的创新。
将组织划分为业务团队和技术支持团队是一种与企业软件一样古老的方法。
近年来，很多作者都表达了让这些业务能力团队负责全栈和全生命周期的重要性。
对我来说，团队拓扑Team Topologies 的独到见解在于关注这样一个问题，即让业务能力强的团队负责全栈和全生命周期，意味着他们往往要面对过重的认知负荷，这有悖于建立小规模、反应迅速的团队的愿望。
平台的关键优势在于它能减轻这种认知负担。
如今，每个人都在构建一个 "平台"，以加快数字产品的大规模交付。但怎样才能成为有效的数字平台呢？一些组织在试图在现有共享服务的基础上进行构建时，没有首先解决组织结构和运营模式的问题，从而导致了失败。
这一见解影响深远。首先，它改变了平台团队对平台的思考方式。减少客户团队的认知负荷会导致不同的设计决策和产品路线图，而平台的主要目的是实现标准化或降低成本。除了平台之外，这种洞察力还促使 Team Topologies 进一步发展其模型，识别出另外两种类型的团队。
有些能力需要专家投入大量的时间和精力来掌握对许多流联盟团队都很重要的主题。
安全专家可能要花费更多的时间来研究安全问题，并与更广泛的安全社区进行互动，而这是作为一个团队成员不可能做到的。
这些人聚集在赋能团队中，其作用是在其他团队中培养相关技能，以便这些团队能够保持独立，并更好地拥有和发展自己的服务。
为了实现这一目标，扶持赋能型团队主要使用团队拓扑中的第三种也是最后一种互动模式、促进模式涉及辅导角色。
在这种模式下，赋能团队并不负责编写和确保符合标准，而是教育和辅导他们的同事，从而使流式对齐团队变得更加自主。
基于业务流对齐的团队负责为客户提供整个价值流，但偶尔我们也会发现流一致团队工作的某些方面要求很高，需要一个专门的小组来关注，这就产生了第四种也是最后一种类型的团队：复杂子系统团队。
复杂子系统团队的目标是减轻使用该复杂子系统的流式对齐团队的认知负担。即使该子系统只有一个客户团队，这也是一个有价值的分工。
大多数复杂子系统团队都会努力使用 x 即服务模式与客户互动，但也需要在短时间内使用协作模式。
团队拓扑结构 "在设计时明确认识到了康威定律的影响。它所鼓励的团队组织考虑到了人与软件组织之间的相互作用。团队拓扑结构的倡导者希望其团队结构能将软件架构的未来发展塑造成与业务需求相一致的响应式解耦组件。
乔治-博克斯（George Box）精辟地指出"所有模型都是错的，有些模型是有用的"。
因此，《团队拓扑结构》是错误的：复杂的组织不能简单地分解为四种团队和三种互动。
但是，正是这样的约束条件使得模型变得有用。
团队拓扑结构 "是一种工具，它促使人们将组织演变成一种更有效的运作方式，一种通过减轻认知负荷让流线型团队最大限度地流动起来的方式。