架构师之殇：一个反对“平台团队”的案例

运营多个专注于各自技术业务领域的平台比运营一个平台团队更好。平台思维是关于促进演进的，而不是关于重用的，而专注于重用会破坏这种机会。将平台思维灌输到所有团队中，给自主领域和平台出现的机会，而不应强加于事。

超过一定规模的大多数技术公司都开始考虑创建一个内部平台团队来构建 / 管理供多个团队 / 产品使用的系统。这是一个杠杆率非常高的团队，因为他们可以同时对许多产品产生有益的影响，并为能给组织带来巨大的动力。但是，今天，我想提出一些内部平台团队无法顺利工作的情况，至少我遇到过这样的情况。

TL;DR——运营多个专注于各自技术业务领域的平台比运营一个平台团队更好。平台思维是关于促进演进的，而不是关于重用的，而专注于重用会破坏这种机会。将平台思维灌输到所有团队中，给自主领域和平台出现的机会，而不应强加于事。

1这个团队是做什么的?

拥有一个独立的平台团队通常意味着所有水平关注点都会被推到他们身上。最终，这个团队将无法识别它的客户，只能以支持许多有用但互不关联的系统而告终。很难为这样的一家公司设定目标和“北极星”，因为它们“从定义上”就是与最终用户脱钩的。这样团队的唯一目的是在不考虑这些系统的目的和运行这些系统所需的专业知识的情况下，最大限度地重用组织内的这些系统。

更糟糕的情况是，其他团队会毫无顾虑地构建可重用的组件。但是，当涉及到在生产中支持重用、尊重其他团队的 SLO 和 SLA 时，人们会立即开始寻找平台团队来进行操作。其结果是，一个操作繁重的中央小组一直忙于灭火，因为他们对自己所拥有的东西缺乏了解。

随着公司共享用例数量的增加，平台团队将会变成各种无连接的组件的存储库，这些组件的业务用途与这些组件是分离的。最终，我们得到了一个“团队”，但这个团队的成员根本不知道其他人在做什么，因为每个成员最终都只专注于各自的某个部分。我们有技术专家，但他不是对业务影响最大的领域专家。如果业务开始陷入困境，平台团队及其工作通常是第一个被砍掉的。这是因为很难向业务方解释这批“准专家”是如何帮助他们赚钱。

2开发人员淘金热

从根本上讲，对于一个组织的技术栈，采用流行的二维视图是不合理的。它会使我们产生偏见，认为底层的事物在本质上更基础或更复杂。当然，底层比上层支持更大的“规模”。所有这些都会导致开发人员急于加入刚刚孵化出来的内部平台团队。在某种程度上，这项工作被视为是对组织来说更具声望或更为核心的。事实上，在本质上讲，它充其量是更技术性的，这样开发人员就不必处理现实世界的混乱，不必面向客户的产品了。

这在很多方面对组织构成了挑战。一个是管理谁来做什么，以及哪些角色被认为很酷（为什么非平台角色不被视为“业务特性”，而是“出色的工程”）。另一部分是管理最终形成团队的期望值，创建团队很容易，但是要让他们保持以业务 / 客户为中心比预期的要困难。许多平台团队都深陷到了一种混合状态中，即技术傲慢且与客户脱离，这使得他们的实力远远低于他们的能力。

3其他团队就不是平台团队?

如果有一个平台团队，那么是否意味着其他团队就不是平台团队了？有了一个“无所不能”的团队，其他团队开始放弃平台思维，开始在产品孤岛中思考。

如果平台化是有价值的，那么它应该是所有团队的心态和策略，而不是单个团队的领域。由于所有业务问题都是 由领域和组织环境所组成的，因此有理由认为，所有团队都应该生产和运营平台化组件。这些平台可以在其他团队所拥有的平台之上生成。平台或通用产品的目的不仅仅是重用，而且要为集中组织专业知识的领域边界进行建模。平台团队不能在任何出现水平组件的地方都继续使用它们，因为那样他们必须是业务各个方面的专家。拥有底层可重用事物的平台团队的典型定义与组织的工作方式并不兼容。

这导致我们……

4所有权范围

一个公司的技术栈可以通过顶层的高阶系统抽象和底层的低阶系统抽象进行可视化。这意味着，操作架构的技能集可以随着你的深入而发生很大的变化。这就证明了较低层与较高层的“不同”，应该以不同的方式进行管理。

当我们看技术栈时，所有权范围应该如何运行？它们应该沿着具有类似抽象级别的组件水平运行，还是应该垂直运行，将系统分组以生成端到端的业务价值？

如果你正在运行一个自主的、跨职能的团队（许多公司都声称要这样做），那么技术栈的深度是否重要？这个团队的基本前提是能够在技术栈的所有级别上工作，并且在每个级别上与其他团队都能保持松散的一致性。在这种情况下，建立一个具有固定水平章程的平台团队的想法是毫无意义的。每个团队都会创建自己需要的平台层，并根据需要与其他团队共享。这样可以保持低开销的对齐流程的运行，因为创建组件不仅仅是为了重用，它首先是为了使用而创建的，然后才是在需要时再进行重用。

这种所有权还解决了孤立组件的问题，每个人都非常依赖这些孤立组件，但又没有一个团队对其进行维护。开源对于编写代码来说是个好主意，但对于操作来说却是个糟糕的主意。软件必须有一个可操作的所有者——一个负责确保软件按预期运行并达到预期基准的团队。自主团队操作他们构建的东西，如果我们可以教会他们如何构建平台，那么我们就不需要明确地创建平台团队了。

话虽如此，但反对自主团队的一大论点是，他们往往最终不得不做一堆重复的工作。这显然是次优的，那么我们如何才能将其最小化呢。

5解决重用问题

这个问题可以通过以平台化的方式解决所有问题来最小化，这样，一旦被创建出来，所有团队都可以从出现的系统中获益。在调整发布日期等方面可能存在短期问题，但从长远来看，某个特定功能或实体的所有用例开始集中在一个地方。

然而，这并不意味着构建这个平台的团队不再拥有它。重用并不意味着将所有权与创建分离。一个设计良好的平台旨在将平台团队排除在客户的决策周期之外（外部可编程性），因此，如果一个通知平台是由营销团队构建的，并且它被其他许多人所采用了，那么营销团队可以继续拥有并运营它，这没什么错。

一旦一个可重用的东西找到了 3 个以上的客户（Atwood 定律），那么可能是时候考虑一下这是一个横向的责任，并把它转移到一个单独的团队。我并不是说把它转移到一个通用平台团队，而是转移到一个特定的团队，这个团队可以专攻组件建模领域，并致力于将其发展以使其所有客户都受益。例如， 一个通知系统可以完全启动一个全新的商业领域，它本身就是小一点的 Twilio。或者，它可能只是一种共享的技术能力，如托管 Elasticsearch，可以由存储平台团队 /ES 平台团队中的存储 /Elasticsearch 专家团队来处理。

上面的例子表明，如果团队最初拥有其工作中的所有抽象级别（也就是全栈团队），那么新的团队和领域可以从每个团队的工作中派生出来，这些团队和领域可以在相同的抽象级别上产生。从某种意义上说，新领域是一个全新的可重用组件。我们通过对组件进行分层来垂直扩展组织，并且这些层是在彼此之上创建可重用组件的。我们还通过添加需要解决的全新问题空间来水平扩展组织，而每一个问题空间反过来又会带来新的深化机会。

这种有机的过程与固定的、共同定位的平台宪章的理念背道而驰。“平台团队”的概念混淆了所有权和重用的概念，正如它混淆了技术栈中平台的“深度”与领域知识的概念一样。我认为最好是从特定领域的团队角度来考虑，每个团队都开发自己的平台，并在发现冗余或重用时跨团队转移并合并。

在我看来，今天唯一的平台团队是基础设施团队（管理硬件设备），也许还有身份验证 / 授权团队，甚至我认为这些都是业务 / 技术能力，而不是重用 / 技术栈深度驱动的团队。所有其他平台都应该来自产品团队内部。想想细胞分裂而不是神之手。