今儿个这篇随笔没有核心思想内容随意表达，想到哪里写到那些。
昨儿个一个好久不联系的朋友忽然微信“ 你的公众号一段时间不更新了 ”， 我回复“这不是在码字，做总结吗” ，不拉不拉一通。
一个好的公众号还是要经常的维护与更新的， 我自己的公众号本来属于自己的随笔，基本输出的都是自己原创的内容，都是别人来要求开白名单转发，我为什么也不花费点心思呢。
有一件搞笑的事情，大概是在周三吧。一个蛮好朋友问我相机的型号与建议， 我忽然来了一句 “你国庆节要出去吗 ？”，过一会来了一句 “ 你是老年痴呆了吗！！！已经告诉你多次了，我老爸过来了 ” ，” 我就 .....@#￥%……&* “ 。”本来想说，可以带家人一起出去啊 “，想了下 或许是自己每天到很晚搞的太累，把很多事情都给忽略了 ，内心有点奔腾 ” 。
昨天一个不认的学医将要毕业小朋友互加了微信 ，来问Spss 的一些问题 ，聊天中忽然也来了一句 ”你每天这么晚睡觉不秃头吗 ？“，”我还在逆生长呢 “。
我不禁感叹，时间过的好快啊。
自从上周”中台的讲座“ 直播完毕，再次回归到了往日的平静，稍微总了下直播的一些内容发现还欠听众一些内容与问题 ，我后面会逐渐的补上。上次直播准备的内容有四个中台案例，结果只讲了一个案例，剩下的三个案例因为时间的要求也没有讲，还有最后的数据中台这个方向的也只分享了一点点。后续会再继续安排一场分享的，在等小编的安排。
在直播中最开始感觉还是一本正经的，没多久就还是回到自己在不同高校、对外分享特点上来，自己当时为什么会做这个决定，死板的样子不是自己本来的样子，还是喜欢活出本来的样子来。在分享的过程中有一个网友调侃的问题彻底把我搞笑了，”中台是不是中国特色社会主义名词？“ 第一次看到这个提问差不多在8点半，我忍住没有笑场，但是在最后再看这个问题没有在忍住，到今天再次回想起来感觉蛮形象的。
”中台“ 这个词已经进入到下半场，从之前的互联网的引爆 到欢呼 到质疑 再到现在下半场的传统企业去开始尝试进一步理解与进一步的欢呼。怎么讲呢，互联网公司引爆的这个词，给大家安利了一波，就像是互联网公司在革传统软件公司命一样，然后分成了不同的声音，现在呢传统IT、软件公司又起了另外一个套路 “用企业架构” 的角度去做中台化探索，反正是生态的演进必然是有牺牲为代价的，希望”中台“这个”生态“ 能将演进的更好与更加落地。
现在对于中台的很多弊端也在逐渐凸显，比如给中台提需求半个月没动静，无奈只能自己搞上线后，结果中台来告状说重复造轮子浪费人力信不过中台。一些中小业务线想去做个创新也够难的，说体量小不支持或不优先支持，那就晾一遍吧。还有就一些中小业务线赖以生存一些有价值的东西都被中台抢走了，既然抢走就好好支持，结果还不好好做。以前中台是集中集中炮火，结果这个炮弹全部落到前台自己阵地上了。有些公司允许厮杀，前后台、中台与中台之间不是沉下心来去做应该做的，而是在抢来抢去的或许有一天中台又是变成一种烟筒般的存在然后在出一个新词”全台“的概念去解决。不管怎么样我自己对于中台这种方法论还是非常期待的，真金不怕火炼，期待我们的探索越来越完美。
关于双中台，自己认为就是一个严重的伪命题，即使是双中台，其中的数据方面的是打着中台的旗号在实施数据平台，这个暂时不在这里讨论更多，因为更多的内容都写在自己的书中了。
如果把数据平台的发展比作第三代数据处理体系，那现在所谓的数据中台顶多是3.5代平台，现在很多把数据中台当做一个大盒子什么东西都往里装，当然或许企业、用户很愿意买单。
上次还在开玩笑的说加入有这样的中台我也是希望能跪求一下，或许描述了一个美好终极目标。
（这个图是来自于某个文章的，左侧的内容与右侧图没有什么关系，是关于中台一些问题的）
因为现在的数据中台的实施，不管是第三方 还是企业自建还是都在用数据平台的各种方法去实施。可能有人会反对数据中台通过API对外提供数据复用、服务。早在数据平台年代因为业务的需要已经就这样去规划与落地了，数据服务、总线、推送、订阅类的早都存在了。剩下的算法、标签、画像这些内容因为业务的需要很多时候一直在数据平台去实施的。或许是我自己没有吃透数据中台统一模型的概念吧， 里面的指标统一、维度统一、编码统一、指标落地统一拆解构建统一只不过换了一个视角数据平台实施罢了。
数据本身其具备的天然特性，一次采集广泛使用，也就是自身就带着共享与服务的特点恰恰又踩到了”中台”词的 复用、服务的特点，希望早日一天能探索出 “数据中台”更加完美形态。
下图是自己在分享中台时第四小节中用到一个小案例，其中前两个图 因为企业一般企业从创立到成长、扩展基本上是 3-5 年为一个周期，如果恰好某个热点引爆的飞起的风头公司发展会更加剧烈， 其业务规模、系统会指数级的翻倍， 所以带来的数据量也是翻倍递增。企业的业务 BU 会变的更多，企业在业务数据化或数字化转型，不可避免的会涉及到业务与管理的转型。
企业的成长与扩张，不可避免的广度上需要有巨大的变化，业务线、子公司的分分成立必然带来比以往更宽的产品线， 客户群体的增加也促使企业提供形式不同的、内容更丰富的服务模式。
因此，在向客户提供更多的服务同时意味着必须以客户为中心的各种组合、定制化、服务化的产品需要更多。必然所带来 BU 与 BU，子公司与子公司之间的各自为战的 IT 建设，久而久之就形成了 “烟筒“与流程过多、打架、效率低下等等通病。
自然 子公司A 是老牌的业务线，子公司B是新兴的业务线，自然合并之后是A业务的数据平台为基础，B业务人员资源往A团队合并，最后形成C图。
当然了，这个合并只是一种形式，组织结构、资源做的事情一种合并，不代表这所有的数据中台的可能。虽说自己经历过几个数据中台但是毕竟是个人不能代表一切，以上仅代表个人观点。
本文分享自微信公众号 - songzi2016（data_pm_bi）。
如有侵权，请联系 [email protected] 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。