为什么说“大公司的技术顽疾根本挽救不了”

——我先谈谈历史。

当我提到“历史”这个词时，我指的不是简单地解决历史遗留应用程序的问题，而是处理过去30或40年间不同CEO所做决定的遗留后果，因为公司对过去每个十年时代的变化趋势都得适应。

SuperRentalCorp成立于100多年前，当时世界大部分地区由几个欧洲帝国统治，而大多数公司都是依托他们在西方国家内的公司来经营全球业务。但在1948年至1980年的那个时代，所有的旧帝国都解体了，取而代之的是一百多个新的国家，而这些新国家都保护着自己的独立性。因此，SuperRentalCorp决定采用分散结构。它在大多数国家中设立了子公司，并且子公司作为独立公司运营。有时子公司的部分所有权被出售给他人。这意味着，当上世纪70年代末第一批大型数据库来到时，这家公司没有中央数据库、中央IT部门、也没有首席技术官或首席信息官。

不久之后，由于政治形势似乎变得安全了一些，合并一些服务的好处变得显而易见，因此一些子公司被合并，组建了区域性公司。例如，中东和北非有一家，欧洲有一家，北美有一家，亚洲有一家，南美有一家。通过这种结构，这家公司进入了90年代，这时它开始认真考虑通过网络数据库来管理它所提供的所有服务。

20世纪90年代，面对激烈的全球竞争，这家公司决定通过收购最成功的竞争对手们来实现增长。如果我告诉这些被收购的所有的品牌名字，你会认出其中的大多数，但你可能会惊讶地发现他们现在都为一家公司所拥有。我也很惊讶，因为我也认为这些公司是竞争对手。但事实上他们不再是了。

然后，大约在2005年Web2.0时代的到来，导致竞争对手大量涌现，这些竞争对手提供类似于SuperRentalCorp的服务，但是他们通过使用互联网技术，以新的方式来提供这些服务。同样地，SuperRentalCorp收购了其中的几家初创公司，通过吸收竞争对手来赢得竞争的胜利。许多被收购的初创公司只在单一国家，或单一的市场（如欧盟）内运营。

就在最近，这家公司的新首席执行官决定最好把公司统一起来。一些国际子公司已被全资收购，目前正在进行重组，因此它们将作为公司内部的部门而非独立公司运营。

作为对公司统一的新的重点工作的一部分，SuperRentalCorp希望构建一个统一的API，以便外界认为该公司具有内部统一的技术架构。也就是说，SuperRentalCorp希望给外界一个这样的假象：即该公司只有一个统一的数据库，并且与该数据库的交互很容易。

然而，真实的情况是怎样呢？真实的情况是：SuperRentalCorp拥有20个主要数据库，由20个不同的团队在至少10个不同的国家/地区运行，其中许多拥有独立公司的运营历史，每个团队都保护自己的数据，部分出于安全担忧，部分出于对有关用户隐私的本地法律和对国际用户数据传输的监管的担忧，还有部分原因是纯粹的顽固。

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

所以，数据库读取不是那么困难，虽然不简单，但总是有办法做到。

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

两年前，SuperRentalCorp决定成为MuleSoft公司的客户，以便MuleSoft公司帮助他们构建新的API。到目前为止，他们已经投资了大约2500万美元在MuleSoft公司所做的相关工作上。MuleSoft公司有一些很好的工具来构建API，但是这些工具似乎对数据读取比对数据写入更有帮助。也就是说，MuleSoft公司的工具对简单的问题有帮助，但对困难的问题却没有效果。（既然说了这句话，我还想再补充一句，SuperRentalCorp里有一些，他们超爱MuleSoft。）

从最佳集成架构的角度而言，我认为唯一可以作为长期解决方案的是类似于Jay Kreps在2013年前后写的统一日志架构。这个架构中，所有的写入操作都需要进入一个集中的日志，例如Kafka，然后各个数据库就可以从那里提取他们需要的内容，每个团队都要自己决定从集中的日志提取的内容。

但是，SuperRentalCorp有一些零售店，配有直接与特定的数据库进行通信的POS系统，对这些零售店而言，数据写入的路径（直接从POS到数据库）是以难以更改的方式硬编码的，因此想要拥有一个单一的写入点，SuperRentalCorp还需要花费几年的时间。

目前，SuperRentalCorp的每个数据库团队都必须接受来自多个源的写入操作。但从长远来看，统一的日志是一条可行之路。这意味着这20个团队中的每一个团队都必须对他们的流程做出重大的改变。这就解释了为什么该公司花费了2年时间，投资了2500万美元试图构建一个API，最终却失败了的这一事实。

这个问题的发生部分是技术性的，部分是心理性的。每个团队必须放弃一些权力，然后信任一个超出他们控制的流程。当公司有一个新的首席执行官时会发生什么？如果他决定再次拆分公司呢？团队对当前公司战略的持久性有多信任？他们是不是应该给自己留点空间，回到过去做事的方式？…

到目前为止，我只讨论了由内部数据库和内部流程引起的问题。从某种意义上说，与依赖那些外部供应商提供的超出了SuperRentalCorp的控制的服务相比，内部机制导致的问题都是容易解决的。

从20世纪90年代开始，出现了一种管理理念，认为公司应该专注于其“核心竞争力”，并将其它一切外包出去。比如说，如果你是一家报纸，你不需要雇佣清洁工来保持办公室的清洁，而是应该把清洁工作外包给一家专门从事清洁公司办公室的公司。把精力集中在你擅长的事情上，把其它的一切交给别人去做。如果你试图自己做每件事，那么你就犯了“非自主发明综合症”。尽管我已经看到了不利的一面，但在这场争论中，有很多是我同意的。外包限制了你的灵活性，因为你最终与外部公司建立了长期关系，但这些公司可能并不会随着你的需求的变化而发展。虽然解雇一家清洁服务公司并雇佣另一家似乎很容易，但有些服务公司却很难更换。

早在20世纪90年代，SuperRentalCorp就决定将其客户忠诚度计划的管理外包，因为它被视为一项财务职能，而SuperRentalCorp不是一家财务公司。他们挑选的外包公司也非常原始落后，甚至不为其服务提供公共的API。因此，现在当SuperRentalCorp希望将其忠诚度管理系统集成到各种CRM（客户关系管理）系统和POS系统中时，它无法做到这一点，因为SuperRentalCorp对管理其忠诚度计划的外包公司的技术决策没有决定权。是的，SuperRentalCorp可以终止与这家外包公司的业务关系，开发自己的系统来管理忠诚度计划，但他们已经正在处理大量其它的技术难题。而目前，终止与管理其忠诚度计划的外包公司的业务关系还不能作为一种选项。

所有这些都有助于解释为什么一家大而老的公司的技术救援是如此困难，因为它不得不持续地和它的历史作斗争。

困扰着大公司技术救援的还有另外一个问题，那就是信任。拥有庞大资产的公司每天都要与内部和外部的不诚实的行为者打交道，这不是危言耸听，而是日常的现实。关于公司应该如何变得更敏捷的华而不实的肤浅言辞并不是很有帮助，因为公司需要面对的是公司结构、所有权和战略等真正的问题。尽管我很喜欢初创者社区，但是我觉得来自硅谷的太多文章描述的大公司和老公司所面临的问题只是简单的假设。特别是，大部分文章都认为信任问题是庸人自扰，而并认为是重要的和真实存在的。一些肤浅的建议倾向于“假定善意”，就好像数十亿美元的公司就像维基百科一样。

事实上，大公司一直面临着被公司内外的贪婪所摧毁的风险。而初创企业在处理信任问题上比较容易，因为当整个团队只有5个人时，你们都可以直视对方的眼睛，当他们表现异常时，你可以再次检查你的同事。而当你在180个国家拥有11000名员工时，这是不可能做到的。