主页

索引

模块索引

搜索页面

022中台

  • 2015 阿里巴巴提出中台概念和战略

备注

通常情况下我们说中台时所指的“需求”，还是指“业务需求”，即客户可以使用到的功能。

绝大部分谈中台的都是做中台的

没有完美的技术，没有放之四海皆好的技术，如果你只能看到一项技术的好处，而看不到坑，那实际上很可能就会掉到坑里去。

中台的价值

可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求，最大限度地减少“重复造轮子”。

实际上的中台

1. 业务部门并不独立

基于中台的业务会被分为不同优先级:

大业务对于中台的影响力远远大于小业务，核心业务对中台的影响力远远大于新业务。
形象点来说，中台抱大业务的大腿，小业务抱中台的大腿
因为中台也是有 KPI 的，大业务天然会有 KPI 数据上的优势。

这会导致什么问题呢？:

大业务的创新不管是不是共性的，中台会鼎力支持，
  毕竟判断是不是共性需求是中台判断的，而不是每次有个新业务的时候拉上所有业务方来评估和投票；
小业务就比较悲催了，中台要拒绝你，只需简单一句话“你这个业务不通用”，“你这个需求太特殊”。

基于中台的开发模式很可能会制约创新业务的快速发展，
  除非这个创新业务一开始就有重量级人物挂帅，对中台能够有足够的影响力。

2. 中台并不总是能够提炼共性需求

提炼共性需求主要是中台从 0 到 1 的建设的时候:

这个时候已经有多个业务需求的样本存在，哪些是共性哪些是个性是比较容易分析出来的，
但一旦建成后后续的业务发展和创新，中台和业务方天然存在对共性需求的不同诉求

业务与中台的矛盾:

业务方总是期望将自己的需求划为共性需求，因为这样就能够让中台出人来实现需求；
中台总是期望先不要把需求划为共性需求，而是等到多个业务都有类似需求的时候再由中台来抽象提炼，
  这样才能最大化复用，否则中台每个需求都认为是共性需求的话，中台会累死。

备注

事实上几乎不太可能出现多个业务同时提出某个需求，除了国家颁布的法律法规相关的需求外，绝大部分业务需求都是由某个业务方先提出来的，这个时候中台是无法判断是否为共性需求的，只能又回到前面说的潜规则来操作：优先满足大业务，拒绝小业务。反正大业务的需求不管是不是共性的，做了后数据肯定好看，中台 KPI 有保证；小业务就算以后被证明是共性的，前期做了也没多少数据，中台很可能费力不讨好。

3. 中台的“轮子”会不断变化

备注

很多朋友看到“避免重复造轮子”就以为中台把轮子造好了，业务方只管用就可以了，而实际情况是中台确实把轮子造好了，但是它每隔一段时间就会把轮子换一遍，例如中台的数据模型、接口、架构等其实都是需要根据业务发展不断变化的。

为了达到中台“复用”的目标，通常情况下中台在推出新轮子后，就不会再长期维护老轮子，否则如果中台同时维护 4~5 个相似的轮子，复用就无从谈起。这就要求基于中台的业务都必须在某个时间段内完成轮子的切换，相当于是业务方进行了一次被动架构演进。

有没有办法让中台的演进不影响业务呢:

绝大部分情况下都不可能，这是由中台演进的本质决定的：
  中台演进的绝大部分动力来源于业务，它的演进不可能做到反过来不影响业务。
这点和技术平台（存储、消息队列这类）不一样，技术平台演进的动力来源于技术更新，是可以做到不影响业务的。

4. 中台是某类业务的中台,不是所有业务的中台

备注

中台的本质是提炼共性需求复用，如果业务差异太大的话，复用度不高，提炼和维护中台花费的代价抵不上中台复用带来的价值。实际上应该叫“电商中台”、“支付中台”、“物流中台”、“出行中台”、“视频中台”、“保险中台”，而不应该是“阿里中台”、“腾讯中台”、“百度中台”、“滴滴中台”。

中台的效果

因为阿里巴巴的生态非常复杂，很多业务方本身也很年轻，要怎么去做，下层到底能提供什么样的支撑是不清楚的。当有大中台思路之后，第一，我们这个体系里有什么样的能力，可以让各业务很清楚地知道，也可以让前台业务方更快的理解、选择和使用中台能力。第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。

实际效果

  1. 中台的体系有什么样的功能，业务方根本不是很清楚地知道，而是很清楚地不知道:

    几乎没有人能完整地知道中台里面各个域各个子系统的能力，更加谈不上业务方更快的理解、选择和使用了
线上运行的系统可能几百上千个，这么复杂的一个系统，怎么可能有人知道所有的功能和细节

备注

说中台提供完整的解决方案，业务方只要定制一下就可以快速上线，说起来容易做起来难，除非业务方是准备复制一个和已有业务基本一样的业务，否则基本上是不可能实现的。

备注

真正基于中台做过项目你就会发现，编码的时间确实少了，但是前期的沟通和后期的联调非常耗时间，随便做个什么项目，拉上 20~30 人算一般的，稍微大点的项目拉上 50~100 人也是很正常的。

  1. 中台的所谓的“快”，并没有严谨的衡量:

    从实际的开发经验来看，业务方和中台的需求讲解和讨论，业务方和中台方案的设计讨论，
  后期的业务系统和中台系统联调这些工作量并没有减少，反而还会有一定程度的增加，
  因为中台在分析需求、设计方案、联调测试的时候需要考虑对其它业务的影响。

中台能够带来的效率提升主要体现在两方面:

一是编码的工作量确实会少，毕竟还是有大量的代码可以重用的；
二是中台的人员都对已有的类似业务和技术很熟悉，需求的确认和方案的设计会更高效
全流程综合来看，很难判断效率到底高还是低。

备注

中台并不适用于每家公司的每个阶段。在独立业务拓展期、突破期，“一定用独立团、独立师、独立旅建制来做”，否则就会变成瓶颈；但发展到一定阶段，出现太多山头时，就要“关停并转、要合并同类项。问管理要效率，取消重复性建设”。

思考

中台复用最大的问题就是边界问题，哪些能复用，哪些不能复用这个边界很难精确制定，因此需要大量的沟通讨论撕逼扯淡。

中小公司主要是没人啊，想成立组织都找不到合适的人，只能找外面的人。咨询公司一般都不会说问题只会吹中台多好，因为只有中小公司签了合同落地中台项目，咨询公司才能拿到钱；如果咨询公司说你们不适合落地中台，然后拿了几百万，中小公司又觉得太亏了 ：）

参考

主页

索引

模块索引

搜索页面