江苏龙网

  1. 首页 > 人文 > >

数据中台乱象：不拆“烟囱”，在开始建设的时刻，就可能会失败


文|技术领导力
上周跟一位数据中台解决方案公司老板吃饭 ， 聊到后面 ， 他跟我吐苦水 ， 老有人说我们乙方公司割韭菜 ， 我觉得很冤啊 ， 我们不偷不抢、卖解决方案做正当生意 ， 客户有需求 ， 我提供解决方案 ， 我有错吗？
那位老板说到动情处 ， 开始抹鼻涕眼泪装惨 。
我急了 ， 就怼他 ， 你抹鼻涕就抹吧 ， 能不能别往我身上抹呀 。
老板平复了一下情绪 ， 接着说 ， 你是不知道客户的情况啊 ， 他也不懂中台 ， 觉得概念好 ， 有噱头 ， 就硬要上 ， 拦都拦不住 。
我心想 ， 你不是讨厌甲方 ， 你是讨厌没钱的甲方 。
话又说回来 ， 这位老板说的是实情 ， 我了解到的现状也是这样 ， 中台解决方案市场的乱象 ， 甲方公司要负一半的责任 。
数据中台乱象：不拆“烟囱”，在开始建设的时刻，就可能会失败
本文插图
建中台的过程 ， 就是拆“烟囱”的过程
京东的一位技术专家曾说过 ， “为什么要建中台？就是要拆掉‘烟囱’” 。 一句话就道破了中台建本质：建中台的过程 ， 就是拆“烟囱”的过程 。
做技术的都知道 ， 系统不是规划出来的 ， 而是根据业务的发展逐渐演化而成 。 就好像你养了一条鱼死了 ， 不想土葬 ， 只想火葬 ， 谁知道这玩意越烤越香 ， 然后你买了瓶啤酒 。 很多东西都不是你能预料的 ， 怎么规划 。
做系统 ， 一开始以快速交付为主 ， 就是一个个的单体应用 ， 代码往上堆 ， 不考虑什么高可用、架构分层 。
数据中台乱象：不拆“烟囱”，在开始建设的时刻，就可能会失败
本文插图
当系统大到一定的程度 ， 就开始拆分 ， 做服务化 ， 形成了一个个的微服务 ， 这个时候系统的高可用、服务稳定性有了很大提升 。
看起来已经是很好的架构了 ， 那么有什么问题呢？
从公司的层面看 ， 看到的就是一个个“烟囱” 。
“烟囱”怎么来的？
为什么会变成那么多“烟囱”呢？从四个维度来看：
第一 ， “产品烟囱” 。 不同产品线之间的功能、定位相同 。 比如商品模块 ， 商城系统有商品模块、自营系统也是商品模块、团购系统又有自己的商品模块 。 这些模块的功能和定位是相同的 。
第二 ， “系统烟囱” 。 做开发的都有一个特点 ， “自己写的代码 ， 用着才放心” ， 别人写的代码不愿意用 ， 所以就会造成重复开发 。 其实想想 ， 这又何必呢 ， 把自己累成狗 。 不对 ， 狗都没你这么累 。
第三 ， “数据烟囱” 。 虽然数据是会使用同一个库表 ， 但是数据的统计和定义 ， 每个系统之间又有所不同 。 比如“每日订单总数”这个指标 ， 有的按交易口径、有的按支付口径、有的按发货口径 ， 数据统计结果就会不一样 。

数据中台乱象：不拆“烟囱”，在开始建设的时刻，就可能会失败
本文插图
第四 ， “组织烟囱” 。 指的就是部门墙 ， 有部门划分就会有部门墙 ， 这很正常 ， 但是如果部门墙太厚 ， 扯皮的问题就会很严重 。 有时候想想 ， 扯什么劲呢？反正20年后都要一起去跳广场舞的 。
中台建设难 ， 难在哪里？
中台建设难 ， 并不是难在技术上 ， 主要难在两个方面：
第一 ， 组织 。 如上面的观点 ， 建中台的过程 ， 就是拆“烟囱”的过程 。 很多“烟囱”需要合并 ， 最简单的办法就是把这两个相同产品部门合并 ， 这就涉及到组织的变动了 ， 如果没有高层的支持 ， 就会很难 ， 因为你动到别人的“地盘”了 ， 别人会跟你拼命 。
第二 ， 思维 。 思维分成两个角度：服务提供方、服务调用方 。
服务提供方 ， 就需要把自己的工作范围扩大 ， 具备“中台思维” ， 也就是自己提供的服务不仅是给自己用的 ， 还要给其它团队用 ， 要兼顾所有调用方 ， 要做好能力的沉淀 ， 提供好支持 。


推荐阅读


上一篇：股价|中国联通：美国颁布了一项行政命令，估计将对公司股价产生影响

下一篇：公司|精艺股份：股东宏远创佳拟清仓减持不超14.68%股份