中台的缺陷

建中台，组织架构一定要调整，但动组织架构就意味着在动“权力、金钱和人员”。不难看出，这个话题太敏感。

难以应对 Cross cutting concern

根据中台进行系统拆分和部门调整之后，还是会遇到 cross cutting concern，什么是 cross cutting concern：

The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.

有些需求难以避免地会影响整个流程中的所有系统：比如从技术范畴进行的一些改造(如为了完成 tracing，所有系统增加 trace id，并在 log 中默认携带)，比如从业务范畴进行的 i18n 改造。这些改造需求一般天生就是跨系统、跨组、跨部门的，事情一带上“跨”的字眼，就不好搞了。举一个典型的例子，某巨型互联网公司员工抱怨，在当前的微服务和中台架构前提下，做一个需求经常要改 20+ 个模块，苦不堪言，连上线顺序都不一定搞得清楚。当这 20+ 个模块又是跨部门的时候，就更难了。想要推动其它部门做一些短期看起来没啥收益的事，太难了。

稳定性和灵活性的矛盾

对于一个系统来说，追求稳定性，那么必然会在修改和升级上较为消极；追求灵活性，那在功能迭代上一定会较为激进。这两方面的矛盾本来就是难以调和的。追求其中之一，在一定程度上就得放弃另一方面。有很多中台系统被剥离之后，因为用户众多，一旦出现技术上的问题，影响面巨大。

中台的建设过程中节奏是最要命的。这其中有一个矛盾点，就是业务线在发展中是快速变化的，快速变化必然就会渴望得到各种资源支持。但是中台大部分是在缓慢建设与推进，两者之间会产生诉求与承接能力不匹配的问题。这块如何做好平衡，就涉及到先做什么、后做什么的问题。

一个被完全中台化的业务导致集团内部过分分工，任何前台业务都被认为是中台能力的线性组合。举个例子，有的公司会有接近或超过千人的供应链中台，搜索广告中台，内容中台等等，而多数业务前台少则几个人，多不过几十人。前台团队任何一个人哪怕是全职和一个中台域对接，也无法理解该域的全貌或者是跟得上这个中台的演变。这意味着前台业务完全无法在这些中台相关的领域做创新。本来的创新业务变成无从创新，当初的动力变成了中台的最大的诅咒。有说法说，一个业务靠拖拉拽就能编排出来了，这不是创新是什么？ 事实证明这种创新完全无用。没有任何一个投资人会把自己的钱投到一个可以被大公司拖拉拽出来的商业模式的。真正的创新不是现有能力的线性组合。

中台自身的场景往往缺乏前瞻设计，是对现有场景的抽象。而当某个创新在一个前线业务线孵化出来之后，中台团队会通过强制收编该能力来扩大自己的能力，同时强迫前台团队下线一个他们研发了很久的创新。这种行为往往造成精英人才的流失，使得本来就受到遏制的前台创新变得更为匮乏。

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

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

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

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

中台经常以最全的最复杂的实现来应对任何一个简单的应用场景。大量成熟行业和强监管环境下的需求被带入到了创新业务中。在带来了大量的运营复杂性的同时增加了用户（买家，卖家，本地运营）的学习难度。这就是我们常讲的膨胀软件(Bloatware): 巨大，复杂，缓慢，低效。

KPI

“这个业务中台的考核目标是什么？”

这块业务是做内容生态、创作者生态，但是当时只有创作、内容生产、内容审核、内容库等等从内容维度的奖励，没有内容的出口。面向 C 端的出口都在其他 BU，那这个中台业务如何进行考核？考核指标该如何制定？

要从规模、品质、活跃、消费、互动、收益这六个维度定义十几个指标吗？ 要从月 / 日均活跃账户数量、月 / 日均账户生产文章数量，再加上账号内容在端的月 / 日均播放量、阅读量等等维度进行考核吗？

无论从哪个角度来看，都感觉不太合适。这些指标都受到端的影响，没有一个指标仅仅跟中台业务本身相关联。比如有的人提到既然是围绕创作者的生态，那就只看创作者、内容生产就好了，但实际上每一部分都有成本，如果生产出来的内容在不同端效果很差，到底是用户画像的问题，还是算法的问题，还是内容质量的问题？各个业务都要承担 KPI，自然就会打架。

另外，以前各端的创作者奖励相当于成本，现在因为都归到中台来承担了，从财务角度只看到成本，那收益和利润该如何算呢？因为出口在各端，不同端的信息流中商业化收入会算到各端业务侧，在内容商业化探索上，也没有想象得那么容易。

阿里中台战略败点分析

中台应当分门别类，因地制宜，全局中台并不适合大集团

阿里集团业务繁杂度远高于超级细胞，中台范围应当细化，不适全局中台。治理小区和治理国家固然有一些类似的点和方法论，但是问题规模变大后，很多小规模下的方法也会变得不再适用，这是一个广泛被认可的观点。超级细胞的业务范围很专一，就是手游，所以它可以很容易就做成游戏工厂。放到阿里这样的大集团，业务种类繁杂，性质大相径庭，何必强融？像淘宝、一淘、天猫，这些其实换汤不换药，那么即便没有中台战略，架构师也知道很多业务逻辑可以复用，要说阿里架构师没有超级细胞的架构师懂？怎么可能。文献[7]中提到的第三阶段其实已经在考虑通过搭建业务平台来建设通用业务能力。而管理层想通过打造一个统一的万能中台来支撑所有集团业务前台（参考图 8），是未经深度思考的表现，从超级细胞小公司到阿里大集团，业务复杂度规模急剧增大，怎么能照搬模式呢。正如没有一个架构师可以在新问题上做出百分之一百与实际匹配的架构一样，也不会有一个统一的万能中台能在保证开闭原则的基础上适配所有业务。

总结来说，阿里集团业务繁杂，不能把 BU 当做前台来构建大中台，每个 BU 就是一个独立的公司，有着自己独立的业务，根本“小”不了。而为各个 BU 做的那些通用的东西也是具有局限性的，只能帮助上层 BU 节省部分研发成本。过度贪求高度复用，会陷入“强求陷进”——把不该抽象的东西硬是抽象到了一起，结果就是系统的复杂度并没有降低，而是从多个地方搬到了一个地方。因此，管理层想要的“全集团大中台、小前台”，是一种理想主义，注定难以实现。

全局中台带来的新问题——依赖单点和热点

按上文的理解，中台战略的实际意义更大的是在于提醒所有 BU，要尽量的增强能力复用，为 BU 业务创新营造一个高效低成本的环境。而如果我们把一家大集团的所有主要业务系统都放到一个事业部去管理，就会产生一个新的问题——单点甚至是热点现象。每个 BU 甚至业务线都各自有 KPI，如果某个 BU 发现中台无法支撑自己的场景（因为总会有没考虑的情况），那么势必要求中台团队做支撑，需求一多，还得排队，这和 BU 寻求自身的生存和发展势必是矛盾的。所以，复用能力涉及的业务范围越大，单点问题就越是严重，单点变热点的概率也就越大。即便中台事业部做的再大，哪怕为每个 BU 都搞一个小团队去支持，由于所背的 KPI 和汇报关系并不在所支撑的 BU，实践起来总是会存在信息断层。

合理的复用是不会产生热点的，因为正确的抽象聚焦是的领域内的业务，设计思路会无差别的对待所有用户，要么一个用户都没法用，要么所有用户都可以用（无故障的情况下）。就好比数据库一样，任何一款数据库都不会关注数据的业务属性，电商的数据能存，金融的数据必然也能存。引入数据库就是一种数据存取能力复用——数据库属于基础设施，复用性是必要的。