下半场的“中台”：别再打着架构创新的口号了，谈谈我的偏见
”中台“ 这个词已经进入到下半场，从之前的互联网的引爆 到欢呼 到质疑 再到现在下半场的传统企业去开始尝试进一步理解与进一步的欢呼。
怎么讲呢，互联网公司引爆的这个词，就像是互联网公司在革传统软件公司命一样，然后分成了不同的声音，现在呢传统IT、软件公司又起了另外一个套路 “用企业架构” 的角度去做中台化探索。
反正是生态的演进必然是有牺牲为代价的，希望”中台“这个”生态“ 能将演进的更好与更加落地。
现在对于中台的很多弊端也在逐渐凸显，比如给中台提需求半个月没动静，无奈只能自己搞上线后，结果中台来告状说重复造轮子浪费人力信不过中台。
一些中小业务线想去做个创新也够难的，说体量小不支持或不优先支持，那就晾一遍吧。还有就一些中小业务线赖以生存一些有价值的东西都被中台抢走了，既然抢走就好好支持，结果还不好好做。
以前中台是集中集中炮火，结果这个炮弹全部落到前台自己阵地上了。有些公司允许厮杀，前后台、中台与中台之间不是沉下心来去做应该做的，而是在抢来抢去的.
或许有一天中台又是变成一种烟筒般的存在然后再出一个新词”全台“的概念去解决。不管怎么样我自己对于中台这种方法论还是非常期待的，真金不怕火炼，期待我们的探索越来越完美。
关于双中台，自己认为就是一个严重的伪命题，即使是双中台，其中的数据方面的是打着中台的旗号在实施数据平台，这个暂时不在这里讨论更多。
如果把数据平台的发展比作第三代数据处理体系，那现在所谓的数据中台顶多是3.5代平台，现在很多把数据中台当做一个大盒子什么东西都往里装，当然或许企业、用户很愿意买单。
上次还在开玩笑的说加入有这样的中台我也是希望能跪求一下，或许描述了一个美好终极目标。
因为现在的数据中台的实施，不管是第三方还是企业自建还是都在用数据平台的各种方法去实施。可能有人会反对数据中台通过API对外提供数据复用、服务。
早在数据平台年代因为业务的需要已经就这样去规划与落地了，数据服务、总线、推送、订阅类的早都存在了。
剩下的算法、标签、画像这些内容因为业务的需要很多时候一直在数据平台去实施的。或许是我自己没有吃透数据中台统一模型的概念吧， 里面的指标统一、维度统一、编码统一、指标落地统一拆解构建统一只不过换了一个视角数据平台实施罢了。
数据本身其具备的天然特性，一次采集广泛使用，也就是自身就带着共享与服务的特点恰恰又踩到了复用、服务的特点，希望早日一天能探索出 “数据中台”更加完美形态。
下图是自己在分享中台时第四小节中用到一个小案例，其中前两个图因为企业一般企业从创立到成长、扩展基本上是 3-5 年为一个周期，如果恰好某个热点引爆的飞起的风头公司发展会更加剧烈，其业务规模、系统会指数级的翻倍，所以带来的数据量也是翻倍递增。
企业的业务 BU 会变的更多，企业在业务数据化或数字化转型，不可避免的会涉及到业务与管理的转型。
企业的成长与扩张，不可避免的广度上需要有巨大的变化，业务线、子公司的分分成立必然带来比以往更宽的产品线， 客户群体的增加也促使企业提供形式不同的、内容更丰富的服务模式。
因此，在向客户提供更多的服务同时意味着必须以客户为中心的各种组合、定制化、服务化的产品需要更多。必然所带来 BU 与 BU，子公司与子公司之间的各自为战的 IT 建设，久而久之就形成了 “烟筒“与流程过多、打架、效率低下等等通病。
自然子公司A是老牌的业务线，子公司B是新兴的业务线，自然合并之后是A业务的数据平台为基础，B业务人员资源往A团队合并，最后形成C图。
当然了，这个合并只是一种形式，组织结构、资源做的事情一种合并，不代表这所有的数据中台的可能。虽说自己经历过几个数据中台但是毕竟是个人不能代表一切，以上仅代表个人观点。
立即沟通
