数据中台乱象：不拆“烟囱”，在开始建设的时刻，就可能会失败
上周跟一位数据中台解决方案公司老板吃饭，聊到后面，他跟我吐苦水，老有人说我们乙方公司割韭菜，我觉得很冤啊，我们不偷不抢、卖解决方案做正当生意，客户有需求，我提供解决方案，我有错吗？
那位老板说到动情处，开始抹鼻涕眼泪装惨。
我急了，就怼他，你抹鼻涕就抹吧，能不能别往我身上抹呀。
老板平复了一下情绪，接着说，你是不知道客户的情况啊，他也不懂中台，觉得概念好，有噱头，就硬要上，拦都拦不住。
我心想，你不是讨厌甲方，你是讨厌没钱的甲方。
话又说回来，这位老板说的是实情，我了解到的现状也是这样，中台解决方案市场的乱象，甲方公司要负一半的责任。
建中台的过程，就是拆“烟囱”的过程
京东的一位技术专家曾说过，“为什么要建中台？就是要拆掉‘烟囱’”。一句话就道破了中台建本质：建中台的过程，就是拆“烟囱”的过程。
做技术的都知道，系统不是规划出来的，而是根据业务的发展逐渐演化而成。就好像你养了一条鱼死了，不想土葬，只想火葬，谁知道这玩意越烤越香，然后你买了瓶啤酒。很多东西都不是你能预料的，怎么规划。
做系统，一开始以快速交付为主，就是一个个的单体应用，代码往上堆，不考虑什么高可用、架构分层。
当系统大到一定的程度，就开始拆分，做服务化，形成了一个个的微服务，这个时候系统的高可用、服务稳定性有了很大提升。
看起来已经是很好的架构了，那么有什么问题呢？
从公司的层面看，看到的就是一个个“烟囱”。
“烟囱”怎么来的？
为什么会变成那么多“烟囱”呢？从四个维度来看：
第一，“产品烟囱”。不同产品线之间的功能、定位相同。比如商品模块，商城系统有商品模块、自营系统也是商品模块、团购系统又有自己的商品模块。这些模块的功能和定位是相同的。
第二，“系统烟囱”。做开发的都有一个特点，“自己写的代码，用着才放心”，别人写的代码不愿意用，所以就会造成重复开发。其实想想，这又何必呢，把自己累成狗。不对，狗都没你这么累。
第三，“数据烟囱”。虽然数据是会使用同一个库表，但是数据的统计和定义，每个系统之间又有所不同。比如“每日订单总数”这个指标，有的按交易口径、有的按支付口径、有的按发货口径，数据统计结果就会不一样。
第四，“组织烟囱”。指的就是部门墙，有部门划分就会有部门墙，这很正常，但是如果部门墙太厚，扯皮的问题就会很严重。有时候想想，扯什么劲呢？反正20年后都要一起去跳广场舞的。
中台建设难，难在哪里？
中台建设难，并不是难在技术上，主要难在两个方面：
第一，组织。如上面的观点，建中台的过程，就是拆“烟囱”的过程。很多“烟囱”需要合并，最简单的办法就是把这两个相同产品部门合并，这就涉及到组织的变动了，如果没有高层的支持，就会很难，因为你动到别人的“地盘”了，别人会跟你拼命。
第二，思维。思维分成两个角度：服务提供方、服务调用方。
服务提供方，就需要把自己的工作范围扩大，具备“中台思维”，也就是自己提供的服务不仅是给自己用的，还要给其它团队用，要兼顾所有调用方，要做好能力的沉淀，提供好支持。
服务调用方，不能想要什么服务就自己建，要先考虑是不是已经有现成的服务可以调用，如果有就要去调用，如果不满足要求，就要去推动服务提供方完善服务，这点也是开发人员抵触的，害怕去推动，不愿去“麻烦”别人。
先有“中台思维”，才有“中台系统”
知道了问题所在，就可以针对性地寻找解决办法。
组织层面。要获得高层的支持，解决好合并组织带来的人员之间的矛盾，这些都要安排妥当。不要因为问题棘手，而选择故意躲避，问题始终存在，而且随时可能爆发。
思维层面。给技术人员宣导“中台思维”，即：服务调用方要考虑充分使用现有的服务，不要自己去写。服务提供方，要兼顾“小前台”们的需求，提供好中台服务。思维方面的支撑，建立中台系统才是事半功倍、水到渠成的事情。
写在末尾的话
总结一下：
1、建中台的过程，就是拆“烟囱”的过程。
2、“烟囱”分成：产品、系统、数据、组织四种。
3、中台建设难就难在，组织和思维两个方面，技术反而是好解决的。
4、建中台要先获得高层的支持，解决组织的问题。做好“中台思维”的全员宣贯，服务提供方和服务调用方都必须升级成“中台思维”，解决思维的问题。
5、总之就是一句话：拆系统“烟囱”容易，拆思维“烟囱”难。
立即沟通
