支持采购同类最佳（best-of-breed）软件的论点一直都很有说服力。与其购买一个在所有方面都勉强凑合的单一平台，不如购买最好的 CRM、最好的 ERP、最好的库存系统、最好的 HR 工具。每一个都在其类别中处于领先地位。每一个都在由其全公司命脉皆系于该产品能否超越竞争对手的供应商不断改进。你避免了供应商锁定。你保留了灵活性。你得到了最好的。
然而，这个论点忘记考虑了一个系统。它通常在第三到第五个 SaaS 订阅之间被构建出来，通常是由一个本该做其他事情的开发者完成的。没人为它做预算。没人为它定范围。没人给它起名字。它没有产品经理，没有路线图，除了一份在2022年还算准确的 README 之外没有任何文档。
这就是那个没人主动要求的 SaaS 层，在许多组织中，它已经悄然成为他们运行的最关键的基础设施。
一切是如何开始的
触发点总是因为一份无法生成的报告。销售数据存在 CRM 中。收入存在会计软件中。库存存在仓库管理系统中。某位高管想要一个统一的视图——订单、成本、利润率、库存水平——而这三个系统中的任何一个都无法单独生成。
最初的反应是导出 CSV 并将它们合并到一个电子表格中。这确实有用。它有用到了这个电子表格变成了每周例行产物的地步。某个人的周五下午被永久保留用来运行它。当那个人离职时，究竟要提取哪些列以及按什么顺序提取的知识也随之而去。
最终有人用脚本代替了电子表格。该脚本按计划运行。它从 CRM API 提取数据，从会计 API 提取数据，从仓库 API 提取数据，将数据连接起来，然后写入每个人都能看到的地方。这是一个显著的改进。它同时也是——在没有任何人做出决定的情况下——该组织现在所依赖的数据集成平台的第一个组件。
它是如何生长的
该脚本解决了报告问题。但一旦它存在，它就成为了新需求的承接面。订单确认邮件应该包含仓库系统的库存状态。发票支付后 CRM 应该自动更新。当客户在 ERP 中被标记为高风险时，销售团队应该能在他们的 CRM 仪表板中看到该标记。
这些都是合理的要求。每一个都需要从一个系统读取并写入另一个系统。构建最初脚本的开发者添加了这些逻辑。然后添加了更多。脚本变成了一个服务。服务增加了配置。配置增加了复杂性。在某个时刻，它变成了需要花十五分钟以上才能向新工程师解释清楚的东西。
仔细追踪软件支出的组织通常会发现，这个内部层——没有预算、没有许可证、没有名字——正在执行的实际业务逻辑，比它连接的好几个 SaaS 产品还要多。客户生命周期规则。价格调整。履约触发器。合规性拦截。购买的软件负责存储和 UI。胶水层负责决策。
胶水层的问题
胶水代码有一个在数量不多时很容易被忽视的特性：它的承重能力与它所连接事物的数量成正比。两个系统之间的单一集成是一种便利。六个系统之间的五个集成就是基础设施。移除任何一个组件，多个业务流程就会停止。
基础设施需要被当作基础设施来对待。它需要正常运行时间监控。当某处悄然失效时它需要警报。它需要版本控制，以便当上游 API 发生改变时，你可以针对新版本进行测试而不会破坏生产环境。它需要文档，以便新工程师无需跟在构建它的人身后也能阅读并理解。当周日早上订单处理作业停滞且运营团队无法发货时，它需要有人为此负责。
大多数内部 SaaS 层都不具备这些东西，因为它们从未被打算成为基础设施。它们是意外长成这样的。并且由于它们从未被刻意设计过，它们承载了在最初那个周五下午的脚本之后十四个月的功能添加过程中所采取的每一条捷径。
供应商不告诉你的事
企业级 SaaS 供应商对与内部胶水层竞争的软件类别有一个术语：iPaaS，integration platform as a service。Zapier 是消费者版本。MuleSoft、Boomi 和 Workato 是企业版本。他们的推销说辞是，与其构建自己的集成层，不如购买一个托管的。
这解决了一部分基础设施问题。iPaaS 平台负责正常运行时间、版本控制和监控。但它们没有解决设计问题。构建在理解不足的数据模型（即同一个客户记录存在于三个系统中且具有三个不同的标识符）之上的 iPaaS 平台，将以与建立在相同基础上的自研脚本完全相同的方式失败。平台在工程上做得更好。但业务逻辑依然是错的。
供应商同样不会宣传 iPaaS 订阅的成本随着集成复杂度的增加而攀升的速度有多快。一个简单的触发器-动作工作流几乎不需要什么成本。而跨五个系统且带有条件逻辑、错误处理和自定义转换的双向同步，其成本则要高得多，通常超过它所连接的任何单一 SaaS 产品。到了那个时候，究竟是买还是建的问题又会重新变得真正有趣起来。
隐藏在采购决策背后的设计决策
采购同类最佳产品并没有错。确实存在这样的情况：正确的答案是在每个类别中购买最好的产品，并接受随之而来的集成工作。在单一领域有着特殊需求的组织——如专业的物流运营公司，有着特定数据要求的研究机构——通常找不到一个能很好地处理其核心领域的单一产品。同类最佳就是正确的选择。
但这是一个设计决策，需要被当作设计决策来对待。集成层不是采购决策之后产生的开销。它是一个作为采购决策后果而将要构建的系统，它需要像任何其他系统一样，以同样的严谨性进行预算规划、人员配备、确立所有权和设计。
处理得当的组织不会意外地发现他们的集成层。他们刻意地对其进行定义：这是我们要购买的系统，这是我们需要在它们之间移动的数据，这是负责移动数据的基础设施的团队，这是我们如何知晓它何时出故障。胶水代码变成了架构。
处理不当的组织最终会得到一个没人拥有所有权的关键系统，运行在没人监控的服务器上，执行着没人记录下来的业务逻辑。他们只有在它停止工作时才发现它的存在。
实际上，同类最佳加上偶然诞生的集成层，并不是真正的同类最佳。它是你评估过的部分中的同类最佳，加上在你忘记评估的部分里当时构建起来最便宜的东西。在做出采购决策之前明白这一点，就是深思熟虑的架构与昂贵的惊吓之间的区别。