两年 2500 万美元未构建出统一 API 系统，大公司的技术栈为何如此糟糕？

如今，其实有很多与敏捷开发相关的言论，谈论开发过程中保持敏捷的重要性。对于引入敏捷技术的易用性，以及哪些问题是由敏捷技术解决的，开发者做了太多假设。本文作者试图通过这篇文章提出与这些言论和假设不同的观点。

在过去的 20 年里，我是三家初创公司的技术联合创始人，其中两家公司发展到中等规模，然后卖掉了（我在所写的第一本书中简单谈过）。我在大中型公司做过一些咨询，我的意思是，那些只有几个办公室的公司，最多也就 3000 人。特别是在我 2009 年搬到纽约后，我做了一名救援人员，试图拯救那些落后于时代，但试图迎头赶上的老牌媒体公司。

现在我正在和我有史以来合作过的最大的公司合作。它拥有 11000 名员工，运营在 180 个国家里。这是一个你们大多数人都知道的著名公司，你们中的许多人都是它的客户。在本文中，我将该公司称为 SuperRentalCorp。

关于“初创公司是敏捷的，但大公司什么都做不了”这一主题，市面上已经有很多文章了。很多商业作家都写过一些有趣的书，讲述大公司如何进行重组，变得更敏捷一点儿。例如，Eric Ries 在他的书《The Startup Way》中提供了一些有趣的想法。

但是，为什么拯救一家大公司的技术状况如此困难呢?

SuperRentalCorp 就是其中一个很好的例子。

我最初是这样被告知他们需要帮助的。我的一个朋友已经和他们商量过了，他说：“嘿，这个公司需要有人帮忙建立一个 API。你知道如何建立起一套 API 吗？你能帮到他们吗？”

他告诉我，该公司试图构建一套 API 已经有两年了，但到目前都没有成功。

我对自己说：“花两年时间来构建一套 API！天啊，现在是 2019 年，有一百万个工具可以轻松地设置 API。他们怎么会认为这是很难的事呢？一个好的工程师可以在一天内完成这项工作。他们为什么在这上面挣扎？”

但我最初的想法是假设有一个数据库，你只是把 API 放在数据库和外部世界之间，这是我工作过的早期创业公司的常见场景。有了一个 greenfield Ruby On Rails 项目，你可以在一个小时内构建这种 API。

困扰大公司技术建设的两个大问题是：历史和信任。

这里的历史并不是指简单地处理遗留的应用程序，我还指要应对，随着公司调整适应每十年一次的思潮变革，不同的 CEO 在过去 30 年或 40 年里所做决策的后果。

SuperRentalCorp 成立于 100 多年前，当时世界上大部分地区由几个欧洲帝国统治，大多数公司在一些西方国家经营全球业务。但在 1948 年至 1980 年间，所有的旧帝国都分崩离析了，取而代之的是 100 多个新国家，每个国家都在保护自己新获得的独立性。因此，SuperRentalCorp 决定采用去中心化的结构。它在大多数国家设立子公司，子公司作为独立的公司经营。有时子公司的部分所有权被出售。这意味着，当上世纪 70 年代末第一批大型数据库出现时，这家公司没有中央数据库、中央 IT 部门，没有 CTO 或 CIO。

不久之后，由于局势比较安全，合并一些服务的好处变得显而易见，因此一些子公司合并，成立了区域公司。有一家区域公司负责中东和北非，一家负责欧洲，一家负责北美，一家负责亚洲，一家负责南美。伴随着这种结构，公司进入了 90 年代，这时公司开始认真地通过网络数据库管理所有服务。

面对上世纪 90 年代激烈的全球竞争，该公司决定通过收购其最大的竞争对手来实现增长。如果我把所有被收购的公司名称都告诉你，你会认出其中的大部分，而你可能会发现，现在所有这些公司都归一家公司所有。我很惊讶，因为有几家公司我认为是竞争对手，但现在，他们不再是了。

然后，大约在 2005 年，Web 2.0 时代到来，导致了敏捷的竞争对手爆炸式增长，他们利用互联网提供类似于 SuperRentalCorp 的服务，但采用了一些新的方式。同样，SuperRentalCorp 收购了几家这样的初创公司，通过吸收它们来打压竞争。其中许多初创企业只存在于一个国家或单一市场，比如欧盟市场。

最近，新首席执行官决定，最好是把公司团结起来。几家国际子公司被 100% 收购，目前正在进行重组，以使它们作为公司内部的部门来运作，而不是独立的公司。

基于上述背景，SuperRentalCorp 希望创建一套统一的 API，以使外界认为该公司拥有一个内部统一的技术架构。也就是说，SuperRentalCorp 希望创造一种幻像，即公司只有一个数据库，并且很容易与该数据库交互。

但现实如何呢？SuperRentalCorp 有 20 个主要数据库，由 20 个不同的团队在至少 10 个不同的国家里运行，这些团队中有许多都曾作为独立的公司运营。每个团队都想保护他们的数据，部分原因是出自于安全隐患的担忧，部分来自于当地法律关于用户隐私的担忧，以及国际用户数据转移的规定，而部分只是单单因为脾气倔。

与任何数据库操作一样，这里有两个关注点：读和写。读其实并不难。我们可以从 20 个不同的数据库中提取（必要的）数据，将数据存储在一个充当缓存的集中式数据库中，并在该数据库和世界其他部分之间放置一套 API。陈旧数据可能会有一些小问题，我们必须进行实验来确定哪些数据是高优先级的，需要在几秒钟内复制。不太重要的数据可以每 5 分钟复制一次，或者在更新时再通过触发器进行复制。

读并没有那么难 (不容易，但也不是不可能)。

而写却是另一回事。如果伦敦的客户想从一间伦敦的子公司租用数据资源，租用请求（数据库写）将发送到中央 API，但这是否意味着中央 API 必须得知道要写到内部哪个特定的数据库？同样的，在尼日利亚、德国和巴西发生的写请求也将进入不同的数据库。这就变成了一场噩梦。二十年前，这种思路导致了企业服务总线体系（ESB）结构的创建，但是 ESB 现在已经不受欢迎了，因为它过于复杂、僵硬和笨拙。

两年前，SuperRentalCorp 决定成为 MuleSoft 的客户，帮助创建他们的新 API。到目前为止，他们已经在涉及 MuleSoft 的项目上花费了大约 2500 万美元。MuleSoft 有一些用于构建 API 的工具，但这些工具对读操作的帮助远大于对写操作的帮助。也就是说，MuleSoft 有助于处理简单的事情，但对复杂的事情帮助不大。（话虽如此，我还要补充一点，在 SuperRentalCorp 有一些工程师喜欢 MuleSoft。）

在最佳集成架构方面，在我看来唯一的长期解决方案，是类似于 Jay Kreps 在 2013 年所写的统一日志架构。所有进来的写操作都需要放入一个集中的日志中，比如 Kafka，然后各个数据库就可以从中提取需要的东西，每个团队都可以从中心日志中决定需要什么。然而，SuperRentalCorp 有使用 POS 机（销售终端）系统的零售店，它们与特定的数据库直接对话，并且写路径（直接 POS 机到数据库）是硬编码的方式，这很难改动，所以它需要花费数年来建立单一的 write-point（写操作端点）。

目前，每个数据库团队需要接受来自多个源的写操作。但从长远来看，统一的日志是可行的。这对 20 个团队中的每一个来说都代表着一个巨大的过程变化。这也有助于解释为什么该公司花了两年时间和 2500 万美元试图构建一套 API，但到目前都没有成功。

这个问题一部分归咎于技术原因，一部分归咎于心理原因。每个团队都必须放弃一些权力，然后信任一条他们无法控制的流程。当公司有了新的 CEO 之后会发生什么呢？如果决定再次打散公司怎么办？团队能在多大程度上信任当前企业战略的持久性？他们是不是应该给自己留点余地，好让自己能够回到过去做事的方式？

到目前为止，我只讨论了来自内部数据库和内部流程的问题。从某种意义上说，与依赖外部服务供应商相比，这些都很容易，因为这些外部供应商都不受 SuperRentalCorp 的控制。从上世纪 90 年代开始，出现了一种管理理念，主张公司应该专注于“核心竞争力”，把其他一切都外包出去。如果你是一家报社，你不需要雇佣门卫来保持办公室的清洁，而是把清洁工作外包给一家专门从事办公室清洁的公司。专注于你擅长的事情，把其他的事情丢给别人。

如果什么事情都亲力亲为，那么你就犯了“非我发明综合症”（Not Invented Here Syndrome）。尽管我已经看到了它的缺点，但在这个论点中有很多我同意的地方。外包限制了灵活性，因为你最终与外部公司建立了长期的关系，而这些公司可能不会随着你的需求而发展。尽管解雇一项清洁服务公司并雇佣另一项清洁服务公司似乎很容易，但有一些种类的服务是很难替换的。

早在上世纪 90 年代，SuperRentalCorp 就决定将客户忠诚度计划的管理外包出去，因为这被视为一项财务职能，而 SuperRentalCorp 并不是一家财务公司。他们外包的公司也落后于时代，原始得令人吃惊——该公司没有为他们的服务提供公共 API。现在，当 SuperRentalCorp 想要忠诚度系统嵌入在各种 CRM（客户关系管理）和 POS 系统时，却做不了，因为它在公司里对管控忠诚度计划的技术决策没有控制权。是的，SuperRentalCorp 可以终止与这家公司的关系，并开发自己的技术来管理忠诚度计划，但他们已经在技术上浴血奋战多年。目前，与管理忠诚度计划的公司断绝关系并没有成为选项。

所有这些都有助于解释为什么在规模更大、历史更久的公司，技术改造很困难，因为需要不断与历史进行斗争。

最后一个问题是信任。数十亿美元的公司不断地与那些不守信用的内部和外部参与者打交道。这不是仅存在于理论中，这是现实。关于如何更敏捷的说法并没有多大帮助，因为他们面对的是关于公司结构、所有权和战略的实际问题。尽管我很喜欢初创企业社区，但我觉得硅谷的很多文章都想当然地认为，更大、更老的公司所面临的问题不会出现。特别是，许多文章都假设信任问题是愚蠢的，而不认为其是重要和真实存在的。一些肤浅的建议倾向于“假定善意”，似乎价值数十亿美元的公司就像维基百科（Wikipedia）一样。现实是，大公司不断面临着被公司内外的贪婪所毁灭的风险。创业公司更容易处理信任问题，因为当整个团队只有 5 个人的时候，你可以互相看着对方的眼睛，当你的同事表现失常的时候，你可以仔细检查他们。如果你在 180 个国家拥有 11000 名员工，那这就是不可能的了。在很大程度上，“敏捷”几乎等同于“相互信任”。如果你想知道为什么大公司在敏捷方面有困难，部分原因是 11000 人不可能像 5 个人那样相互信任。这就是现实。因此，创业社区给大公司提出应该更敏捷的建议是多么轻率。

原文链接： http://www.smashcompany.com/business/why-are-large-companies-so-difficult-to-rescue-regarding-bad-internal-technology