关于中台的思考和尝试
我们的讨论先从定义中台这个概念开始。
定义中台我认为可以有两个角度， 一个是从中台本身的价值和出发点来：中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合；另一个定义从中台的相对定位来：前台是面向终端用户的一组业务能力，业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。
我想特别强调这个定义是相对中性的， 我们能够通过这个定义区分什么东西是中台，什么不是中台。有的中台定义严格来说不是定义， 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略目标”、“中台就是一个革命性的设计”，似乎不做中台就成了反革命一样，就是落后生产力的代表。
其实中台本质上是一个对业务能力的抽象和共享的过程，一直存在，也谈不上革命。甚至业务中台这个概念也没有那么新：Oracle Fusion Middleware 早在 2006 年就发布了， 覆盖了包括企业智能、团队协作、内容等多个领域。
我想特别强调中台和前台的定义差别。前台服务单个业务，目标是就是这个业务的增长；前台必须紧贴业务做好差异化；前台的定位要考虑到竞争环境、目标客群、业务成长阶段、运营人员能力、人才供给、监管环境等因素；前台要有自己的技术内容、定制流程、流程对接和个性化数据应用。中台服务整个集团，目标往往是降低成本、加强管控，或者是扩大规模优势；中台的定位在以集团利益最大化的前提下最大化服务前台业务的需求；中台有自己的技术实现、研发流程和数据标准。而后台是不具备任何业务语义的基础计算能力。下图就是对这种定位的一个示意：
当前对中台的看法主要有两种极端，一种是认为中台是一个完全错误的方向，要紧急刹车；另一种是认为中台就是技术终局，是业务增长的不二法门。我们先分别讨论一下这两种观点。
我开始考虑 QCon 演讲话题的时候，中台只是多个备选话题之一， 但是当我意识到大家对待这个话题非常极端的时候， 我才觉得有必要把这个话题讲通讲透。最终选择以中台做为架构师独立思考的能力的一个案例。这是题外话。
先说中台是否是个完全错误的方向？想思考清楚这个方向是否错误， 我们可以先看中台最初的动力来自哪里。不论是甲骨文还是后来的阿里， 其实本质动因是一个大公司内部的大业务呈军阀割据现象，导致多条业务线重复造轮子。由此而衍生出其他的问题， 比如说团队之间内耗严重；小业务无资源， 增长乏力；整个公司数字资产不统一， 损失机会成本；业务线也不能对核心系统做打磨，业务线不稳定。因为这些原因， 所以阿里的高管们就以美国海军陆战队和 Supercell 的组织形式为启发， 做了“大 (业务) 中台， 小 (业务) 前台”的策略。这里先不谈中台是否能解决这些问题， 或者是说战略启发是否正确， 但是毫无疑问的是， 中台想解决的问题既没有过时， 也依然正在不同的公司里发生， 所以这些问题还是必须解决。也就是说从问题定义角度来说， 中台是个完全正确的方向。
那么中台是否是这些问题的完美解决方案？中台是不是万能药？我们已经知道答案是否定了。现在看来中台的解决方案至少有以下几个缺陷：
对创新的遏制：一个被完全中台化的业务导致集团内部过分分工， 任何前台业务都被认为是中台能力的线性组合。举个例子， 有的公司会有接近或超过千人的供应链中台、搜索广告中台、内容中台等等， 而多数业务前台少则几个人，多不过几十人。前台团队任何一个人哪怕是全职和一个中台域对接， 也无法理解该域的全貌或者跟上这个中台的演变。这意味着前台业务完全无法在这些中台相关的领域做创新。本来的创新业务变成无从创新， 当初的动力变成了中台最大的诅咒。有说法说，一个业务靠拖拉拽就能编排出来了， 这不是创新是什么？事实证明这种创新完全无用。没有任何一个投资人会把自己的钱投到一个可以被大公司拖拉拽出来的商业模式。真正的创新不是现有能力的线性组合。
反人性：中台自身的场景往往缺乏前瞻设计 ，是对现有场景的抽象。而当某个创新在一个前线业务线孵化出来之后，中台团队会通过强制收编该能力来扩大自己的能力， 同时强迫前台团队下线一个他们研发了很久的创新。这种行为往往造成精英人才的流失， 使得本来就受到遏制的前台创新变得更为匮乏。
过度设计：中台经常以最全的最复杂的实现来应对任何一个简单的应用场景。大量成熟行业和强监管环境下的需求被带入到了创新业务中。在带来大量运营复杂性的同时增加了用户（买家、卖家、本地运营）的学习难度。这就是我们常讲的膨胀软件（Bloatware）：巨大、复杂、缓慢、低效。
丧失对客户心智的追求：中台团队的产品和研发的核心技能在于抽象和降本。前台业务的核心能力在于对商业机会的捕捉和新商业机会的创造。这是两种完全不同的技能，往往对应着完全不同类型的人才。一个长期在多个业务中间找共性来降本的人是不会专注在最大化前台业务增长的。
之前做中台的公司往往被以上一个或者多个问题所困扰。也就是说中台事实上不是完美的。为什么呢？
我们先思考一下中台的本质。中台本质是把一些分散的重复的开发工作集中起来， 通过共享同一个研发团队来提升不同业务线之间的共性， 也就是通过抽象和统一来获取增量价值。具体的增量可以分成以下几类：
以零成本研发加速上线：对完全可以复用的标准化功能集中开发，未来以低研发成本上线，比如说一些无状态的计算能力，类似 SDK。
提升业务稳定性：对产品差异不大的领域，通过集中研发运维而获取更高的业务稳定性。这样一个团队开发的底层服务能够同时服务多个业务场景， 聚合所有的流量来加速积累。同时研发同学也通过更多的场景来加速打磨设计。常见的领域是会员、营销、交易、资金等服务。
加速技术和业务能力扩散：把整个集团的能力尽量跨 BU 复制。这包括两种类型，一种是类似 SaaS 服务的场景，比如说 Chatbot、直播、内容等领域；另一种是类似 ISV 的场景，由一个中央的团队同时提供研发，对内服务和运营，比如说安全、风控、财务、人力资源等。
统一数据资产：在集团内部统一数据标准，最大化数据复用， 把一个场景积累的数据优势应用到其他的业务场景中去，逐渐建设企业的数据壁垒。
集团层次的资源高效利用：把部分资源中央化，变成全集团资源， 比如说商品中台不但包括商品库，也包括商品质量控制体系、背后的货源、相关货源的价格以及服务竞争力。而商家中台，不仅仅是包含商家的信息，还包括商家的合作意愿和对集团品牌的信任，从而使得商家更愿意和一个新孵化的初创业务合作。集团真正想跨 BU 复用的是从一个大业务孵化而来的竞争力，而不是信息本身。
从研发和管理难度来说从１到５逐渐变难，而带来的增量价值也依次变得更大。
从这个本质来看， 那么中台似乎就是完美的， 那么之前提到的不完美又从哪里来的呢？我们有必要更深度的思考一下。
首先我们思考一下上面的要求， 我们把这些要求归类成六类， 其中第一种场景细分成低成本上线和加速上线两个类别，那么这些类别有以下共同特征：
0.低成本上线：同一个功能模块在多个场景中被使用， 要求该能力的接口确定性高。
1.加速上线：同一个基础能力不需修改或者简单修改即可上线， 也就是模块化支持，要求高 API 确定性和好的功能通用性。
2.提升稳定性：同一个业务能力持续打磨， 要求需求同时具备高的接口稳定性和好的跨业务线通用性。
3.加速能力扩散：基础业务能力可以跨业务线模式， 要求该能力具备比较好的通用性，可以在多个业务线之间共享。
4.统一数据资产：数据模型可以在多个业务线之间统一， 对功能的通用性要求高， 且业务需求相对稳定。
5.集团资源高效利用：业务能力共享， 不仅仅是技术资源， 其实是业务能力有高通用性且需求稳定。
下图把这几个特征分别放在一个四象限图里面。这四个象限的横轴代表技术演化稳定性，竖轴代表功能的通用性。中台的优势领域在第三象限，这个象限技术具有高确定性，业务功能通用。第二象限属于比较稳定但是不通用的小众行业。第四象限属于普遍流行但是高速变化的领域，比如说内容和服饰或者端上的交互。而第一象限属于创新业务，不但定制化程度高且快速演化，比如说面向垂直行业或者初创技术。也就是说：中台的使用范围是有限的，仅仅限于技术演化相对慢且功能通用性高的场景中。这是我们得出的第一个结论。过往中台的失败案例也往往集中在把中台强推到创新业务中的情况。
那么为什么即便是在相对优势的领域，中台也没有取得类似 Supercell 那样的效率呢？他们不过是 100~200 人便撑起一个独角兽， 甚至是跨多个大洲的超级独角兽。值得一提的类似 Supercell 的中台并非个案， 仅仅百万人口的小国爱沙尼亚就有 4 个独角兽， 他们的中台团队也不过是百人左右。那么国内的中台为啥动辄就是成百上千人的研发团队呢？
我有幸深度接触过芬兰和爱沙尼亚的几家独角兽， 我觉得导致这个巨大差异的根源在于研发文化和资源环境。这两个国家由于历史和文化传统，造就了崇尚简约、尊重原创和组织扁平的研发文化。而我们国家的高科技从业人口全球第一， 过去的十年间每年又有大量的新从业者。这些新从业者又普遍有大厂情节， 期望为一个技术品牌相对比较高且收入稳定的公司工作。也就是说大厂同时具备了孵化中台的条件且有源源不断的对成长没有太多诉求的劳动力。这其实是不断重复造轮子的必要条件。
当前几乎所有的大厂都有同样的晋升和薪酬激励机制，就是一个人管理的研发越多， 层级越高， 收入也越高。这种机制有个巨大的弊端， 一个奖励组织膨胀的机制必然会带来组织膨胀。而组织膨胀最终因为康威定理的作用也必然导致膨胀的系统， 也就是前面提到的膨胀软件（Bloatware）。这个就是不断重复造轮子的充分条件。
大量的劳动力供给和鼓励膨胀的机制合在一起， 结果就是团队上下不断加速重复造破轮子。下图就是对这个过程示意。某个研发经理从状态 1 开始， 带领一个小团队。这个时候他对应的层级是 2， 收入是 3。某一天， 他启动一个大项目， 给这个项目一个冠冕堂皇的名字， 比如说“拿破仑项目”。他的团队急速膨胀到 4。项目上线时间一到， 不论完成与否质量如何， 他立即对外发战报、做宣讲：我们取得了“滑铁卢大捷！”。紧接着他的上级内举不避亲， 把他从层级 2 提拔到 5， 收入也相应的从 3 调整到 6。然后周而复始， 他再启动“拿破仑二世项目”继续开发膨胀软件。很快他的“成功”也被疯狂复制。公司变得臃肿迟缓。
这个现象当然不局限于中台， 整个公司都在膨胀。但是这种膨胀对中台而言却是灾难性的。一个膨胀的业务线伤害到自己， 但一个膨胀的中台放缓的是整个集团。
所以我们有了第二条重要结论： 中台的建设要有与之匹配的组织文化机制。
那么什么样的机制才是一个合理的组织文化机制呢？很遗憾我自己也不知道正确答案。但是我们或多或少可以从过去的失败中寻求教训，从历史中寻找启发。
先来思考一下过去的失败。我归纳下来大致有这么几个根因：
对哪个团队做中台或者哪个人来设计中台的决策是个自顶而下的中央决策过程。做中台的人没有所必须的抽象能力和业务理解，类似过去封建王朝的分封的过程。受封的仅仅是生在帝王家， 有没有治理和决策能力不重要。
中台的推行机制往往是个掠夺的过程。对业务线的创新直接复制， 不尊重发明者的知识产权和劳动。中台所到处，寸草不生。
中台能力一旦发布， 独家专供， 哪怕功能不完善， 设计不合理也不允许业务团队复制或分支。
中台为了做规模强制向业务线推行，业务线被迫削足适履，消耗严重。每次中台升级，小的 BU 更是叫苦不迭，故障频发。
其实这几个问题并非中台所独有。上面的四个问题其实和封建社会的分封机制类似，本来应该有市场选择、良性竞争和创新来完成的事情变成了强权。其实这个问题是有解决方案的。
伴随工业革命带来的人类劳动力巨大释放（具体见 Berkley 大学 De Long 教授对人类文明史的人均 GDP 分析）背后也有完整的机制，这些机制就是我们可以借鉴的出路：
机会配置由市场决定。
尊重知识产权和创新， 保护参与者的创新意愿。
通过自由准入维持市场活力。
最终由规模效应形成统一的事实标准。
虽然我还不能确定这是不是完整且合理的中台机制， 但是我们的思想实验至少给了我们避免过去的失败的一些希望：
谁来做中台、谁的设计才是真正合理的中台设计，由市场决定。
尊重原创，通过溯源和产权机制保护创新。
自由准入， 不做独家专供。
不强制推行， 设计统一是演化的结果， 而不是行政命令。
不过哪怕有这个机制， 我们还是要认识到中台天然的局限性。中台不是万能的， 它仅仅合适在高确定性和高通用性场景下创造增量价值。没有合理的期望设定，其实还会让迭代过程漫长而艰苦。在一个竞争环境下， 错误的目标设定不但会带来大量的资本和时间消耗，而且对员工士气打击也很大， 甚至会最终毁掉一家公司。
从公司层面来看， 中台要降低成本， 但是抽象带来的增值是有天花板的。抽象的终局是个零和游戏， 不过就是把前台的事情交割给中台去做。没有价值创造，只有权力转移。另外，中台要加速业务迭代也有逐渐减少的边际收入。 一个健康的行业中需求是永远进化的，不存在超前的完美设计为未来不断创造价值。中台在业务起初产生最大的价值，其后逐渐衰减。
从一个团队或者是 BU 角度来看，小 BU 期望通过中台带来业务增长，但事实上大 BU 的需求总是优先， 会占用几乎所有的中台资源。小 BU 的需求永远排在第二位，会饿死在等待的途中。另外中台靠合理的设计创造价值， 我们期望中台的设计是最优的， 但是真正有能力的架构师不一定在你所依赖的中台团队。你接触的中台边界不一定合理。如果中台很复杂， 跨团队的沟通也会变得更艰难。中台创造的增量价值就越小了。
从个人来看，每个人都期望能力提升， 但是擅于发现机会也擅于抽象的人不一定在中台团队。每个人都期望职业高速发展， 但是高增长的团队往往是高风险的前台团队，而高稳定的中台团队往往变化缓慢。所以没有不论中台还是前台团队， 人才的配置不一定是最优的。
知道了这些局限性， 我们才能对中台设定合理的期望。有了合理的期望， 我们还需要建设合理的迭代机制。这里我们还是可以借鉴其他领域的成功路径。我认为对中台机制探索应该向任何科学探索一样， 是个从假设到实验， 到结果分析， 到修正，最终到正确结论的过程。 我们从相对合理的中台诉求出发， 做合理的机制设计， 通过实施，到效果验证，然后对机制不断修正， 来最终得出逼近真理的一个机制。
在分享车好多的中台实现机制之前， 我想先讲一下我为什么要分享车好多的机制。每一个机制的设计和迭代都是一个漫长的过程。虽然我们刚刚开始， 但是我把我们中台的机制完整的分享出来，也欢迎大家采用， 甚至是加入到我们的建设中来。我也想听到反馈， 尤其是你们已经发现机制漏洞的地方，那么我们就能够共同进步。
首先，考虑在车好多做中台的原因和之前提到的几个原因类似：加速技术能力和业务能力扩散，整合数据资产，最大化公司资源利用。
那么具体什么时间启动有这么几个考虑，第一和下图有关， 就是中台启动之后的复杂度的变化情况。随着时间变化，首先中台服务的调用频次逐渐上升，甚至往往呈指数上涨， 其次是 BU 数目逐渐上升， 最后是变更频次逐渐变少。太早上线其实价值不大， 因为极端情况就是一两条业务线之间做复用， 中台带来的合力还抵不上增加的重构成本、沟通成本和人力开销。这一点上车好多有 8 条不同的业务线， 有了足够的场景复杂度和中台增值空间， 但是也不至于像某些公司有成百条业务线，建设难度非常大。 另外车好多的业务天生是低频业务， QPS 低于传统电商３～４个数量级， 所以做中台有绝对优势。最后车好多的主流业务和新兴业务都在不同层次的迭代当中，所以我们的变更频次比较高， 对做中台也是利好。
以上三个因素，是决定中台的研发复杂度的核心指标，我们可以大致建模为：中台变更复杂度 =（QPS*Count(BU)/ 变更频次)。任何一个服务，QPS 越低，依赖这个服务的 BU 数越少，迭代的越频繁， 那么变更的难度越小， 变更带来的风险越小。
如下图所示。在中台建设期间， 由于自动化测试能力还不够，接口设计不完善， 团队同学的运维和沟通能力也还在成长中， 那么风险上升就会相对比较快。等到中台建设相对完善了，风险的增长和迭代难度就相对变缓。
车好多的优势是 QPS 增长不快，原因是汽车交易本来就是个低频事件， 全年全国不过是千万量级，和传统电商完全没办法比， 而车好多自生的业务迭代速度非常快， 变更频繁， BU 数增长很慢， 也就是车好多的中台变更复杂度随着时间的变化非常慢， 留给车好多的中台建设时间相对就比较充裕。另外车好多最大的两个板块新车和二手车有很大的相似性， 所以建设中台可以从这两个板块的最相似业务线出手来打造能力， 这也是优势。
但是车好多的中台也有自己的挑战：首先三大板块新车、二手车和车后的差异大，而且业务所处的阶段不一样， 有的在做增长，有的在做转型，有的在做赛道探索。所以同样有前面第二节里提到的中台适用范围的挑战。另外整个产业互联网行业还不同于传统互联网，我们的产品技术还在从生产工具到核心生产力的过渡过程中。也就是说，技术的投入是有限的，技术带来的增量价值也待验证，所以研发投入不能过度超前。最后一个挑战是这几大板块对应着数万亿的线下市场，所以车好多的业务与线下高度结合， 流程往往以天计算， 因此变革要和行业的适配能力和期望相符。
在定位上，车好多中台要解决的问题集中在集团高确定性和高通用性领域的技术和数据共享，我们不对创新业务探索加速。车好多中台是技术产业链的规模化之后的分工， 它的核心是对研发成本的优化和某些计算和运营资源的集中化管控和共享。
在组织保障层面上， 我们以加速业务迭代为目标， 通过市场机制加速中台的进化，通过内部开源且允许分支的方式加速进化和保障自由准入。我们鼓励原创，以物质、奖金、股票和晋升激励和固定人员投入来放大团队原创的动力。
在文化保障上，技术上我们关注设计, 崇尚简约，鼓励创新。对中台保持一个客观的态度， 中台回报不一定为正，也要迭代进化甚至消亡。中台既不是管理方式，也不是价值观。我们尊重学术自由， 中台设计没有权威， 逻辑面前人人平等。
下图是车好多的中台构成， 所有的业务线共享数据、计算、研发效能和企业效能中台， 业务线对业务中台形成部分依赖， 算法能力我们还没有中台化， 更多是个共享的组织， 而不是共享的技术能力， 所以用虚线表示。 每个中台域的研发范围如图所示。业务线则按需定制， 我们通过控制业务线的研发人数防止膨胀软件。
以前各家公司开发中台， 很少对中台软件做出系统性要求。中台团队想交付什么就交付什么。这些软件的质量参差不齐， 往往是项目的时间节点一到， 中台团队就三呼完美，那时候就有什么算什么， 业务团队如果稍有抱怨， 未来的需求就免不了受打压。为了避免这种情况， 我们对中台的软件做了一个定性要求。这些定性要求又可以大致分成两类， 一类是必要条件， 一类是充分条件。
先说必要条件：
中台软件必须具有可解释性， 也就是中台能力可以被分解成一组可以被完整描述的行为。这里特别要强调完整描述， 有些团队做中台， 先不说自己能做什么， 而是先占领一个关键词之后问你想要什么？你想要什么我们就可以做什么。 这个就是典型的圈地心态。对做什么功能，解决什么问题完全没有任何前瞻思考， 结果就是越做越无序， 前台团队跟着变得越来越低效。
中台必须具备可验证性，也就是说中台和计算的结果可以验证， 中台的交付的功能可以确定性的被证伪或者被证真。这是独立测试和边界稳定需求，很多中台是从业务线里划分出来的。因为需求繁忙， 往往对自己的边界也不做清晰定义， 也没有完备的自动化功能测试，更别说场景集成测试了。哪怕有边界，也经常变动， 没有兼容能力。这个要求就是对能力的验证和兼容性做限制， 避免中台堕入深不可测状态。
再说充分条件：
中台软件必须具备可隔离性，中台能力应该由多个相对独立的模块构成， 每个模块对相关实体的状态改变必须隔离在模块内部。这个要求是确保前台对中台可以做到最小化。而且对中台的依赖可以局限在前台的个别业务模块中， 这样对某个中台的依赖不会带来整个系统的稳定性降低。这个要求可以防止中台过度侵入到前台，无序扩张。
中台的模块必须可以被局部替代，中台的各模块加载独立，且个别模块所封装能力可以被等价接口所替代而不影响剩余的模块功能。这个要求和前面可解释性 / 可验证性一起就可以允许业务线对中台形成部分依赖， 而不是只要依赖某个中台的一个功能， 就必须所有功能全依赖，永远全家桶。
中台能力可以被第三方扩展和传播。也就是说中台的某个模块可以被前台团队重写后发布给全集团使用。这样可以避免中台能力仅仅独家定制，创新被遏制在远离前台的后台团队。
为什么说前面两个要求是必要条件呢？因为他们合在一起就是要解决中台提供能力的可封装性和可用性， 也就是说一个前台团队根据能力的描述可以决定是否使用一个中台功能。而后面三个是充分条件， 就是中台提供的能力前台业务线也可以选择不用， 或者部分使用那些有价值的模块。 这样中台既可用、亦可弃， 才满足了中台做为一个通用能力加速业务线迭代的充分必要条件。
中台设计和使用上我们有如下原则：
业务优先。多数时候由业务线同学决定架构选型， 而不是中央决策。
反膨胀软件。对中台 API 稳定性和数据模型兼容性做强制要求， 避免中台膨胀过快。避免复杂依赖。
整个中台要求扁平化微服务化设计，降低依赖深度，加速功能发现。
模块化开发。各模块有明确边界，独立文档，可独立设计 / 发布 / 被替代 / 升级。 模块尽量以原子服务模式向往透出，模块间依赖主要是服务依赖。
中台的具体边界和抽象深度是个非常有挑战的问题，往往是个平衡，没有对错。对此我们做了设计追求的建议，就是期望各中台团队在交付压力允许的情况下最大化的做到以下两点：
边界合理：寻找中台的正确边界，平衡研发成本和业务迭代速度。中台的边界应当使得 API 最简化。
中台对多个业务的抽象逼近最优， 模型在信息量最大的情况下能够保持相对稳定。
下面两张图就是个具体的例子， 前一个模型简单， 相对稳定， 但是在这个模型下能够提供的服务粒度粗。第二个模型更复杂， 这个模型下能够提供相对更细粒度的服务。后者能够适用多个车好多业务线的现有模式， 且信息容量更大，所以在当前的业务矩阵之下是个更好的模型。
车好多之前没有中台，怎么孵化出中台来也是个挑战。
孵化中台有多个方式：
自由竞争制：个人或者团队自主入场， 自主投入。代码开源，去中心化研发， 通过统一发现机制对外露出。
中央授权制：由公司做顶层决策，不做团队调整， 做项目强制统一多个技术分支。
集中孵化制：由公司做顶层决策， 对团队先做整合， 之后由该团队孵化中台。
重点扶持制：不对称的做研发人员补贴，对特定领域做引导，加速该领域的中台建设。
视情况不同， 我们这几种组织和孵化机制都有采用。
中台的孵化具体有如下几个平行的方向：
逐步建设市场机制：由前台业务线研发做选型决策，保障业务优先。同时通过 HC 管理引导最优决策，靠市场和预算驱动最经济的决策， 防止中台和前台的膨胀软件。在考核指标上前台考核业务增长；中台则考核前台接入成本、前台新需求延迟、前台定制成本和接口高稳定性。
建设自由准入能力，同时鼓励经营和创新。除了前面提到的内部开源且允许分支，我们会逐步建设去中心化研发体系，加速分布式创新。同时为了鼓励中台经营， 通过控制业务线分支权利来说防止重复造轮子。
人才流转策略：中台和前台必须有统一的研发体系和统一的人才流转机制，保持双方的活力。对有基本的能力、偏好和专业度差异的研发人才做定向培养， 支持转岗。
保障业务连续性和人员稳定性：对中台我们会保留一定程度的顶层设计，避免大范围技术和组织重构。
最后讲讲人才。不论设计多么完美的机制， 最终还是要靠人来实现。合理的机制仅仅能够避免引人误入歧途， 但是价值创造还是要靠优秀的人才。
车好多对人才的画像可以总结成两句话：做学问要包容求真， 做人要有良知和勇气。 第一点是期望我们的人才能够保持开阔的视野， 对新事物和不同观点的包容，和不断探索寻求真正有价值洞察的欲望， 从而发现别人不能发现的机会。第二点是希望我们的人才能够为公司做正确的决策， 不断让正确的事情发生。同时他也要有勇气，愿意站出来阻止错误的事情发生。我们当下虽然有一些这样的人才，但也渴望更多的这样的人才加入。
中台不是万能的， 但是可以在高确定性和高通用性场景下能创造增量价值。中台应该有合理的应用场景和时间窗口， 需要用一些设计原则来约束， 也需要相应的组织机制支持。中台有自己的生命周期， 要做阶段性的重构和重定位。这就是我对中台的大致理解。
车好多的中台实践不是标准答案，甚至不一定正确。我的分享是仅仅是为了带动高质量的思想碰撞， 也希望得到大家的帮助和反馈。谢谢大家。
今日荐文
点击下方图片即可阅读
华为海选开发者状元？还送14件豪礼？
PPT | 硅谷的数据中台实践
1219大数据技术沙龙-数据成本治理、数据仓库、数据湖、增长黑客、ABtest、实时平台.PPT
Apache Atlas | 元数据管理框架的独舞
快手大数据-数据治理、数据模型、数据质量、元数据管理、指标体系、OneService平台化