中台的末路 (转)

真相

中台能解决问题么？是能解决的。中台能解决所有问题么？那显然是不能的。

就像微服务架构一样，架构师吹牛的时候天花乱坠，你做起来却发现这条路上全都是坑。

中台给企业带来的收益, 首先是有效减少了重复造轮子、重复建系统的现象。有相对统一的业务收敛位置，并在公共服务上快速高效迭代出新的业务。

有了统一的用户、订单系统，就不会再有各种恶心的数据打通问题，不会有跨部门的数据墙。

有了统一的中台，也就有了统一的数据规范。

对于大数据相关的需求，可以从相对唯一的数据出口进行业务迭代，不需要为每一个部门进行定制开发，浪费人力。

公用业务下沉，这个理念其实很朴素。所有程序员都知道我们公用的逻辑要进行封装、抽象，变成 Library。中台的本质其实就是把这种朴素的思想进行了一定程度的推广。

稳定性和灵活性的矛盾

对于一个系统来说，追求稳定性，那么必然会在修改和升级上较为消极；追求灵活性，那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一，在一定程度上就得放弃另一方面。

就像网友经常讲的不作死就不会死，没有代码才是真正的稳定之道。Google 程序员在 GitHub 上发起的行为艺术项目：noCode，没有 code，就没有 Bug。可谓弃疗的典范。

有很多中台系统被剥离之后，因为用户众多，一旦出现技术上的问题，影响面巨大。从我的实际观察来看，中台部门的系统虽然初始立项的时候声势浩大，但基本也没什么人关注这些公共系统的代码质量或者测试质量。最终只不过是大家公用了一堆“垃圾”，“垃圾”在转过几手之后，后来的人基本就不太想对原来的代码进行修改了。

可能有人会讲你可以重构啊。嗯，重构的前提是系统有完善的测试用例和可以跑的测试。事实上一般都没有！在没有测试的情况下，我们可以根据过往的系统需求文档和 PRD（码农桃花源注：产品需求文档，Product Requirements Document）来还原当时的业务场景，并进行测试补充。

但你又发现，中台的性质（大多偏技术项目，基本没什么 PM 把关或者出文档）使其基本没有什么靠谱的、详尽的文档。写的复杂的中台，连业务流程都理不清楚，还想写测试，别做梦了哦。

中台与前台的模糊业务边界、距离

在实际实践时，中台与 FT 的边界往往划得不清不楚。比如用户服务、用户权益、用户在各种子系统中的状态，这些内容可能并不是用户服务本身关心的内容。但往往需求也会提给用户服务，这时候用户服务就只是进行字段存储，而状态机变化则完全在外部。

如果对系统内的个别数据不进行管理，那么有其它接入方接入时，就无法解释清楚字段的含义和使用场景。如果不接受这些不相干的数据接入，那么前台流程系统可能会在自己内部重新建立自己的数据系统，这部分系统又极有可能和中台有功能上的重叠。

如果想要把这些数据接管过来，那么中台又需要梳理所有业务场景。或者说明需要把所有对数据进行修改的逻辑全部收拢到中台内部，这往往又会产生与中台与前台业务边界的冲突。

难以给出有效的边界，就意味着无穷无尽的撕逼。这便是很多中台的两难：我接不是，不接也不是。

如果去问那些中台业务部门的系统开发负责人：某些业务要不要你们来做，连这些人自己都说不清楚。

人才方面

如果要做中台，那往往需要将业务部门的一部分系统进行下沉。下沉并不仅仅是一个技术问题。如果要把系统从一个部门变到另一个部门，这一定会带来人员的调动。从情感上来讲，人们都是讨厌这种部门变动的。因为“领导”会在部门调整中发生变化，同事也经常会随着部门调整而离职。只留自己在原地填坑给谁都不愿意。

也有些公司在调整中进行粗暴的系统交接，如果系统需要下沉，那我直接从原来的维护团队手里夺过来，交给中台部门来管理。这一样会引起双方的反感：

交接方：这是我们加班加点，辛辛苦苦开发出来的系统，凭什么交给别人？奋斗了半年难道就是为了给别人摘桃子？

被交接方：这个系统原来的维护团队水平极低，代码就是一堆“垃圾”，他们不想搞了就随便扔给我们？凭什么啊？我们又不是接盘侠。

即使贵司运气好，在系统交接过程中没有出现问题，那交接后也不好说。被交接的系统在交接后往往陷入消极维护状态，这时候前台业务接入中台会比以往更加困难，这种困难使前台业务的不满积累到一定程度之后，会再次催生前台部门重新造一套新的自己的中台，而部分或全部放弃原来的中台。这样，原来的中台部门便会陷入尴尬的境地。

生存空间被挤压，人也自然很难待得下去，各公司的中台部门，人跑的比香港记者都快。

跨部门沟通障碍、跨部门目标差异

进行部门划分之后，每个业务部门会有自己的一套目标体系。部门与部门的目标（KPI）一般是不相同的，如果相同的话，那也就没必要分多个部门了。

而部门与部门之间的目标在某种程度上甚至可能有冲突，例如 A 部门 Feature Team 较多，主要负责业务功能迭代，需要更强的灵活性。而 B 部门负责中台数据，主要关心系统稳定性，也就是前文提到的灵活性和稳定性的矛盾。若此时出现 cross cutting concern，两个部门需要在矛盾上取得一定程度的平衡，这种平衡在个别情况下是不可得的。

例如在一段时间内，中台部门的目标是提高某个商业指标，让公司更赚钱/省钱。这时候前台业务提来了新的需求，这种需求是能使流程开发更加灵活的，但与中台部门的 KPI 不在一个航道上。

中台部门显然要把需求排排优先级，把任务排排主次。前台部门又会觉得中台支持个需求怎么这么龟速又唧唧歪歪，不如自己实现了。

前台业务也有自己的理由：“自闭环”嘛，这词真是好用。

公司利益分配

毫无疑问，距离业务近的地方比距离业务远的地方能分到更多公司增长的成果。中台看起来是业务，但又是公共业务，既然是公共业务，那基本上没办法分享到任一单一业务成功的红利。纵使其成功的原因中，中台的强大、便捷是重要原因。

这会导致什么问题呢？没有人愿意接手中台项目，中台项目变成烫手的山芋。大佬无法在中台项目上获得红利，小弟们没法在中台项目上获得利益。中台功能确定以后，只有出事故的时候大家才想起你来。稳定运行是应该的，出事就是你的锅！

行业方面

中台建设一般要考虑公司的实际情况，这样建设出来的系统可以应对一段时间内的公司业务变化。然而公司的压力有时并不来自于自己的业务方向，可能来自于行业内其它公司的模式挑战。

理论上来说，只要一个公司的业务系统架构建设完成了，便已经完成了一种架构上的 固化。这时行业内如果有新的模式获得了成功，公司肯定要进行跟进。但是新的模式一定意味着对原有系统、架构的挑战。

试想，原来系统架构是针对线上交易设计的，突然有一天，O2O 模式被证明有利可图，大多数公司都开始转向线下。原有的流程、模式当然想要复用，但是这时候复用的成本很可能比重新开发还要高。眼睁睁看着竞争对手们甩掉包袱，轻装上阵，以更低的成本更短的时间攻城略地，挤压自己的生存空间。

这时候怎么办呢？大多数公司给出的方案是成立新的业务部门，在新趋势新阵地冲锋陷阵。新部门肯定也要用到原来公司的老服务，又碰到了我们的老问题：跨部门合作。新部门的成功并不会让老部门多得到多少好处，配合自然不会太积极。（码农桃花源注：公司内部做事都是利益驱动）

如果新部门的尝试获得了初步成功，得到了公司资源的倾斜，获得了有效的人力资源补充。之后又会带来新一轮重复造轮子，互相不合作，互相撕逼的腥风血雨。

简直是一个轮回。

结语

经常有小伙伴说，国内某公司中台非常好，大家都在学。嗯，我倒是想问问了，如果真的做的好，某公司旗下的金融公司和电商公司还会需要两套完全一样的基础架构，和好几朵云？

原文链接：https://blog.youkuaiyun.com/qcrao/article/details/101442702