关于中台的价值,你看到的是这样的:
可以让各业务部门保持相对的独立和分权,保证对业务的敏感性和创新性;另一方面,用一个强大的平台来对这些部门进行总协调和支持,平衡集权与分权,并为新业务新部门提供生长的空间,从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求,最大限度地减少“重复造轮子”。
实际上的中台是这样的:
1. 业务部门并不独立
基于中台的业务会被分为不同优先级,大业务对于中台的影响力远远大于小业务,核心业务对中台的影响力远远大于新业务。形象点来说,中台抱大业务的大腿,小业务抱中台的大腿,因为中台也是有KPI的,中台的KPI怎么来?当然是大部分了来源于支持的业务了,大业务天然会有KPI数据上的优势。
这会导致什么问题呢?大业务的创新不管是不是共性的,中台会鼎力支持,毕竟判断是不是共性需求是中台判断的,而不是每次有个新业务的时候拉上所有业务方来评估和投票;小业务就比较悲催了,中台要拒绝你,只需简单一句话“你这个业务不通用”,“你这个需求太特殊”。如果小业务不服气能怎么办?没什么办法,不会存在仲裁委员会之类的机构,就算有,你去仲裁的时间都够你自己把业务实现5遍了!
就算中台认为你的需求是共性需求,如果你是小业务,很可能也会以优先级的原因被排在很后面,这里的“很后面”可不是几天几周,很可能就是几个月半年了!而恰恰很多初创业务一开始规模肯定是比较小的,基于中台的开发模式很可能会制约创新业务的快速发展,除非这个创新业务一开始就有重量级人物挂帅,对中台能够有足够的影响力。
2. 中台并不总是能够提炼共性需求
注意这里的需求不是指电商中台里面“交易”这个粒度的需求,而是指“交易”系统里面一个个实际的功能点,你要是坚持说“交易”是共性需求,这实际上是一句正确的废话。事实上,提炼共性需求主要是中台从0到1的建设的时候,因为这个时候已经有多个业务需求的样本存在,哪些是共性哪些是个性是比较容易分析出来的,但一旦建成后后续的业务发展和创新,中台和业务方天然存在对共性需求的不同诉求。
业务方总是期望将自己的需求划为共性需求,因为这样就能够让中台出人来实现需求;中台总是期望先不要把需求划为共性需求,而是等到多个业务都有类似需求的时候再由中台来抽象提炼,这样才能最大化复用,否则中台每个需求都认为是共性需求的话,中台会累死。
而事实上几乎不太可能出现多个业务同时提出某个需求,除了国家颁布的法律法规相关的需求外,绝大部分业务需求都是由某个业务方先提出来的,这个时候中台是无法判断是否为共性需求的,只能又回到前面说的潜规则来操作:优先满足大业务,怠慢小业务。反正大业务的需求不管是不是共性的,做了后数据肯定好看,中台KPI有保证;小业务就算以后被证明是共性的,前期做了也没多少数据,中台很可能费力不讨好。
3. 中台的“轮子”会不断变化
很多朋友看到“避免重复造轮子”就以为中台把轮子造好了,业务方只管用就可以了,而实际情况是中台确实把轮子造好了,但是它每隔一段时间就会把轮子换一遍,例如中台的数据模型、接口、架构等其实都是需要根据业务发展不断变化的。
为了达到中台“复用”的目标,通常情况下中台在推出新轮子后,就不会再长期维护老轮子,否则如果中台同时维护4~5个相似的轮子,复用就无从谈起。这就要求基于中台的业务都必须在某个时间段内完成轮子的切换,相当于是业务方进行了一次被动架构演进。
当然,如果没有中台,业务方的架构肯定也要随着业务的发展而演进,那这和跟随中台被动演进有什么区别呢?最主要的区别是中台的架构演进频率会比独立的业务架构演进要快,道理很简单:中台融合了多个相似业务的发展!
举个简单例子:如果中台支持10个业务,其中有1个业务发展很快,中台就必须跟着演进,剩余的9个业务即使没有任何发展,也必须跟着被动演进!更何况如果这10个业务本身都在不断发展,那中台的演进会更快!
那是否存在某种牛逼的技术,让中台的演进不影响业务呢?绝大部分情况下都不可能,这是由中台演进的本质决定的:中台演进的绝大部分动力来源于业务,它的演进不可能做到反过来不影响业务。这点和技术平台(存储、消息队列这类)不一样,技术平台演进的动力来源于技术更新,是可以做到不影响业务的。
4. 中台是某类业务的中台,不是所有业务的中台
中台的本质是提炼共性需求复用,如果业务差异太大的话,复用度不高,提炼和维护中台花费的代价抵不上中台复用带来的价值。所以,实际上应该叫“电商中台”、“支付中台”、“物流中台”、“出行中台”、“视频中台”、“保险中台”,而不应该是“阿里中台”、“腾讯中台”、“百度中台”、“滴滴中台”。
当然,因为现在“中台”概念火爆,出现了原来很多做中间件和技术平台的团队,纷纷将自己负责的“XX平台”改为“技术中台”,从广义的角度来说也可以,因为这确实是“各业务线共性需求”,毕竟存储、缓存、消息队列这些肯定是各业务线的共性需求,但通常情况下我们说中台时所指的“需求”,还是指“业务需求”,即客户可以使用到的功能。
作者:李运华
点评:
说白了,中台适合有大量前端业务场景的公司去做。 前端业务场景单一中小规模企业,不适用。
很多企业本身业务虽然是一种“凑合”的状态,但至少能用。贸然上中台,必然会伴随着漫长而持久的不应期——渡过漫长而难受的不应期后才能磨合出一种适合自身的新组织方式。
而中台战略鼓吹者,只强调中台会带来的巨大提升,不说哪些企业不适合中台,更不说上中台对过往模式的巨大破坏以及破坏带来的漫长不应期。
个人看法,中台战略最大的问题,来自企业内部的“镀金者”。很多企业的技术部门的leader们多有来回跳来跳去的经历,他们才是中台最大的鼓吹者。这群技术leader最大的问题是从来不关注实际业务,只关心自身的项目经历有多丰富,身上有多少标签。
他们向上鼓吹“上中台”,自己却不关心中台是否真的对企业业务有意义。加班的是中下层员工,做不好也是中下层员工能力不行。最多自己拍拍屁股走人,简历上又能多了几笔——是XX企业中台化战略负责人,帮企业节省了XX成本,提升了XXX效益……
目前有 1 条留言 访客:0 条, 博主:0 条 ,引用: 1 条
外部的引用: 1 条
- 用vs2017编译zlib源码并完成编译批处理脚本 – 建标科技