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