022中台 ####### * 2015 阿里巴巴提出中台概念和战略 .. note:: 通常情况下我们说中台时所指的“需求”，还是指“业务需求”，即客户可以使用到的功能。 绝大部分谈中台的都是做中台的 没有完美的技术，没有放之四海皆好的技术，如果你只能看到一项技术的好处，而看不到坑，那实际上很可能就会掉到坑里去。 中台的价值 ========== 可以让各业务部门保持相对的独立和分权，保证对业务的敏感性和创新性；另一方面，用一个强大的平台来对这些部门进行总协调和支持，平衡集权与分权，并为新业务新部门提供生长的空间，从而大幅降低组织变革的成本。中台部门提炼各业务线的共性需求，最大限度地减少“重复造轮子”。 实际上的中台 ============ 1. 业务部门并不独立 ------------------- 基于中台的业务会被分为不同优先级:: 大业务对于中台的影响力远远大于小业务，核心业务对中台的影响力远远大于新业务。 形象点来说，中台抱大业务的大腿，小业务抱中台的大腿 因为中台也是有 KPI 的，大业务天然会有 KPI 数据上的优势。 这会导致什么问题呢？:: 大业务的创新不管是不是共性的，中台会鼎力支持， 毕竟判断是不是共性需求是中台判断的，而不是每次有个新业务的时候拉上所有业务方来评估和投票； 小业务就比较悲催了，中台要拒绝你，只需简单一句话“你这个业务不通用”，“你这个需求太特殊”。 基于中台的开发模式很可能会制约创新业务的快速发展， 除非这个创新业务一开始就有重量级人物挂帅，对中台能够有足够的影响力。 2. 中台并不总是能够提炼共性需求 ------------------------------- 提炼共性需求主要是中台从 0 到 1 的建设的时候:: 这个时候已经有多个业务需求的样本存在，哪些是共性哪些是个性是比较容易分析出来的， 但一旦建成后后续的业务发展和创新，中台和业务方天然存在对共性需求的不同诉求 业务与中台的矛盾:: 业务方总是期望将自己的需求划为共性需求，因为这样就能够让中台出人来实现需求； 中台总是期望先不要把需求划为共性需求，而是等到多个业务都有类似需求的时候再由中台来抽象提炼， 这样才能最大化复用，否则中台每个需求都认为是共性需求的话，中台会累死。 .. note:: 事实上几乎不太可能出现多个业务同时提出某个需求，除了国家颁布的法律法规相关的需求外，绝大部分业务需求都是由某个业务方先提出来的，这个时候中台是无法判断是否为共性需求的，只能又回到前面说的潜规则来操作：优先满足大业务，拒绝小业务。反正大业务的需求不管是不是共性的，做了后数据肯定好看，中台 KPI 有保证；小业务就算以后被证明是共性的，前期做了也没多少数据，中台很可能费力不讨好。 3. 中台的“轮子”会不断变化 ------------------------- .. note:: 很多朋友看到“避免重复造轮子”就以为中台把轮子造好了，业务方只管用就可以了，而实际情况是中台确实把轮子造好了，但是它每隔一段时间就会把轮子换一遍，例如中台的数据模型、接口、架构等其实都是需要根据业务发展不断变化的。 为了达到中台“复用”的目标，通常情况下中台在推出新轮子后，就不会再长期维护老轮子，否则如果中台同时维护 4~5 个相似的轮子，复用就无从谈起。这就要求基于中台的业务都必须在某个时间段内完成轮子的切换，相当于是业务方进行了一次被动架构演进。 有没有办法让中台的演进不影响业务呢:: 绝大部分情况下都不可能，这是由中台演进的本质决定的： 中台演进的绝大部分动力来源于业务，它的演进不可能做到反过来不影响业务。 这点和技术平台（存储、消息队列这类）不一样，技术平台演进的动力来源于技术更新，是可以做到不影响业务的。 4. 中台是某类业务的中台,不是所有业务的中台 ------------------------------------------ .. note:: 中台的本质是提炼共性需求复用，如果业务差异太大的话，复用度不高，提炼和维护中台花费的代价抵不上中台复用带来的价值。实际上应该叫“电商中台”、“支付中台”、“物流中台”、“出行中台”、“视频中台”、“保险中台”，而不应该是“阿里中台”、“腾讯中台”、“百度中台”、“滴滴中台”。 中台的效果 ========== 因为阿里巴巴的生态非常复杂，很多业务方本身也很年轻，要怎么去做，下层到底能提供什么样的支撑是不清楚的。当有大中台思路之后，第一，我们这个体系里有什么样的能力，可以让各业务很清楚地知道，也可以让前台业务方更快的理解、选择和使用中台能力。第二、我们提供了基础解决方案，业务方根据需要做定制开发满足自己的业务特性，对前台的业务来说会更快。 实际效果 ======== 1. 中台的体系有什么样的功能，业务方根本不是很清楚地知道，而是很清楚地不知道:: 几乎没有人能完整地知道中台里面各个域各个子系统的能力，更加谈不上业务方更快的理解、选择和使用了 线上运行的系统可能几百上千个，这么复杂的一个系统，怎么可能有人知道所有的功能和细节 .. note:: 说中台提供完整的解决方案，业务方只要定制一下就可以快速上线，说起来容易做起来难，除非业务方是准备复制一个和已有业务基本一样的业务，否则基本上是不可能实现的。 .. note:: 真正基于中台做过项目你就会发现，编码的时间确实少了，但是前期的沟通和后期的联调非常耗时间，随便做个什么项目，拉上 20~30 人算一般的，稍微大点的项目拉上 50~100 人也是很正常的。 2. 中台的所谓的“快”，并没有严谨的衡量:: 从实际的开发经验来看，业务方和中台的需求讲解和讨论，业务方和中台方案的设计讨论， 后期的业务系统和中台系统联调这些工作量并没有减少，反而还会有一定程度的增加， 因为中台在分析需求、设计方案、联调测试的时候需要考虑对其它业务的影响。 中台能够带来的效率提升主要体现在两方面:: 一是编码的工作量确实会少，毕竟还是有大量的代码可以重用的； 二是中台的人员都对已有的类似业务和技术很熟悉，需求的确认和方案的设计会更高效 全流程综合来看，很难判断效率到底高还是低。 .. note:: 中台并不适用于每家公司的每个阶段。在独立业务拓展期、突破期，“一定用独立团、独立师、独立旅建制来做”，否则就会变成瓶颈；但发展到一定阶段，出现太多山头时，就要“关停并转、要合并同类项。问管理要效率，取消重复性建设”。 思考 ==== 中台复用最大的问题就是边界问题，哪些能复用，哪些不能复用这个边界很难精确制定，因此需要大量的沟通讨论撕逼扯淡。 中小公司主要是没人啊，想成立组织都找不到合适的人，只能找外面的人。咨询公司一般都不会说问题只会吹中台多好，因为只有中小公司签了合同落地中台项目，咨询公司才能拿到钱；如果咨询公司说你们不适合落地中台，然后拿了几百万，中小公司又觉得太亏了 ：） 参考 ==== * 一文读懂「中台」的前世今生: https://mp.weixin.qq.com/s/ZdNEgn1gxyat9PeOeycHTg * 中台，我信了你的邪 | 深氪: https://mp.weixin.qq.com/s/9j3BnR3UqA-lnJDoM5Hrvg * 中台的问题，是技术的问题，还是人的问题: https://mp.weixin.qq.com/s/rHe1nf3jrGxoyZmWt-R25g * 中台翻车纪实：一年叫停，员工转岗被裁，资源全浪费: https://mp.weixin.qq.com/s/yfhaEkO1DG_ihJMhwtkWjA * 阿⾥巴巴中台架构19页ppt：中台是一把手工程: https://mp.weixin.qq.com/s/Flu6f7Ldhvi2V1qPwbhftg * [郭东白]关于中台的思考和尝试: https://mp.weixin.qq.com/s/qzvf4wZCDfHvATdz7KAgSg