首先，我得声明一下。本篇文章不针对阿里这家公司，可能是个普遍现象。我只是站在一个开发者或者用户的角度，把个人经历和看到这些问题的一些思考总结下来。当然我从事的数据开发这个方向，我们着重说一下数据方向。

　　说的不对也请阿里的大佬们轻点喷。

　　首先我们说一下中台这个概念。

　　中台这个概念不是互联网首先创造的，也不是阿里首先创造的。

　　在大型企业里，如果有一项职能是共有的，被多个部门依赖。那么这种共有的职能就可以独立出来作为服务平台。在很多大型企业例如苹果、三星等这种公司早早就诞生了类似的部门。

　　那么好，数据部门就是一个非常典型而且非常适合做「统一服务平台」的部门，数据平台的周边能力加上业务特性就诞生了各种各样的「中台」部门。比如，营销数据中台、供应链数据中台等等。

　　「统一服务平台」有什么好处呢？

　　好处异常的多。

　　首先，资源集中可以集中力量办大事。 在一个成熟的大型企业里，有多少预算可以干多大的业务，出多大的成绩，多多少少是成正比的。有了这样的统一服务平台，有人，有钱，支持自身业务的同时，可以去研究很多长远的事情，现在可能没什么用处，但是未来有帮助的。

　　我们举个例子，数据血缘这个能力，在10年前你听过这个概念吗？直到现在还有很多小公司的数据血缘还是手动记录在系统中，或者直接就记录在一个Excel中呢？大家别笑，我的读者中就有很多这样做的。不同的业务都有了这样的诉求，就可以把这样的能力需求提出来，集中公司的开发能力进行攻关，然后快速开发迭代，并且应用于业务中。

　　其次，避免重复建设。我们拿营销数据中台举个例子，所有业务都有红包、优惠券这些数据需求，那么中台就可以把这些底层能力做好，业务很方便的在这些基础上开发等等就可以了，既避免了重复建设又可以快速统一升级迭代。

　　再次，成功的经验可以被其他部门复制。 在大企业中，部门之前的墙是非常深的，甚至像有些公司只是名义上的一家公司，公司内部非常像「联邦制」，各自业务比较独立，例如网易。一些成功的经验如果在一个部门成功可以通过中台快速复制到其他部门。

　　但是凡事都有对立面，中台也有自己的弊端。

　　中台最大的弊端就是反应慢。 这个反应慢，叠加阿里独特的考核机制和职级制度让中台更慢，甚至成了业务的绊脚石。大家都知道阿里有独特的361考核制度，这个考核制度在公司发展受阻进入平台期的时候导致了同公司不同部门、同部门不同组、同组的同事高度对立。中台作为独立的部门，在强361结果导向下，没法根据业务的个性需求进行快速调整，因为你的需求让我拿不到好绩效，你的需求在和其他业务方PK的过程中不占优势。例如一些非常影响用户体验的产品设计，阿里的产品经常被人诟病用户体验差，却非常难以推动解决。不敢说都把锅都甩给中台部门，但是有一部分中台绝对脱不了干系。

　　其次，中台本来应该作为基础建设和服务的角色，有过大的话语权和博弈能力。 在公司处在顺风发展期还好，一旦业务进入平台期或者面对激烈的竞争环境，过大的话语权和博弈能力导致前台业务居然陷入被动。这里不得不提一下阿里P系列的职级体系，阿里的职级体系在我看来堪比印度的种姓制度。曾经在某一个时刻集中爆发，阿里内部的高低P对立情况非常严重，中台和业务部门博弈的过程中双方大老板的职级会直接被摆在台面上来被比较，并且背后往往有更大的老板在撑腰。顺风抢活干，逆风乱甩锅的现象比比皆是，在受制于361的考核制度，没有人真正去为业务着想，如果有，也只是想想，什么也做不了。

　　那么为什么中台被拆分也就很清晰了。在当前，阿里几乎所有的业务都在充分竞争的环境中，所有反应慢、太遥远的事情都会被拆掉，到离业务更近的地方去。

　　那回过头来，跟中台或者平台相关的能力它并没有消失，反而变的更为重要，而且离业务更近了。每一个业务在保证平台能力共用的情况下可以结合自身业务量身定制更加敏捷和符合业务本身的中台能力，参与到业务敏捷的过程中来。

　　回到开头所说，数据部门的基础能力高度统一，并且非常适合业务进行定制化二次开发。那么现在这些公司要做的是，把原来公司级别能力拿到离业务更近的地方，并且为业务量身定制，这些能力未来会在不同公司、不同业务类型中出现比较大的差异，并且具备业务特性。这些内容是非常适合体现在简历中的，未来面试也会给对方面试官惊喜。