关于中台的深度思考和中台实战

01

中台的定义

我们的讨论先从定义中台这个概念开始。

定义中台我认为可以有两个角度, 一个是从中台本身的价值和出发点来:中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合;另一个定义从中台的相对定位来:前台是面向终端用户的一组业务能力,业务中台是对前台应用的抽象,提供多个前台业务之间共享的业务逻辑、数据和计算能力。

我想特别强调这个定义是相对中性的, 我们能够通过这个定义区分什么东西是中台,什么不是中台。有的中台定义严格来说不是定义, 比如说“中台是提升效率和加速业务增长的一种工具”、“中台是我们的战略目标”、“中台就是一个革命性的设计”,似乎不做中台就成了反革命一样,就是落后生产力的代表。

其实中台本质上是一个对业务能力的抽象和共享的过程,一直存在,也谈不上革命。甚至业务中台这个概念也没有那么新:Oracle Fusion Middleware 早在 2006 年就发布了, 覆盖了包括企业智能、团队协作、内容等多个领域。

我想特别强调中台和前台的定义差别。前台服务单个业务,目标是就是这个业务的增长;前台必须紧贴业务做好差异化;前台的定位要考虑到竞争环境、目标客群、业务成长阶段、运营人员能力、人才供给、监管环境等因素;前台要有自己的技术内容、定制流程、流程对接和个性化数据应用。中台服务整个集团,目标往往是降低成本、加强管控,或者是扩大规模优势;中台的定位在以集团利益最大化的前提下最大化服务前台业务的需求;中台有自己的技术实现、研发流程和数据标准。而后台是不具备任何业务语义的基础计算能力。下图就是对这种定位的一个示意:

06

中台的组织机制

那么为什么即便是在相对优势的领域,中台也没有取得类似 Supercell 那样的效率呢们不过是 100~200 人便撑起一个独角兽, 甚至是跨多个大洲的超级独角兽。值得一提的类似 Supercell 的中台并非个案, 仅仅百万人口的小国爱沙尼亚就有 4 个独角兽, 他们的中台团队也不过是百人左右。那么国内的中台为啥动辄就是成百上千人的研发团队呢br>

当前几乎所有的大厂都有同样的晋升和薪酬激励机制,就是一个人管理的研发越多, 层级越高, 收入也越高。这种机制有个巨大的弊端, 一个奖励组织膨胀的机制必然会带来组织膨胀。而组织膨胀最终因为康威定理的作用也必然导致膨胀的系统, 也就是前面提到的膨胀软件(Bloatware)。这个就是不断重复造轮子的充分条件。

大量的劳动力供给和鼓励膨胀的机制合在一起, 结果就是团队上下不断加速重复造破轮子。下图就是对这个过程示意。某个研发经理从状态 1 开始, 带领一个小团队。这个时候他对应的层级是 2, 收入是 3。某一天, 他启动一个大项目, 给这个项目一个冠冕堂皇的名字, 比如说“拿破仑项目”。他的团队急速膨胀到 4。项目上线时间一到, 不论完成与否质量如何, 他立即对外发战 、做宣讲:我们取得了“滑铁卢大捷!”。紧接着他的上级内举不避亲, 把他从层级 2 提拔到 5, 收入也相应的从 3 调整到 6。然后周而复始, 他再启动“拿破仑二世项目”继续开发膨胀软件。很快他的“成功”也被疯狂复制。公司变得臃肿迟缓。

以上三个因素,是决定中台的研发复杂度的核心指标,我们可以大致建模为:中台变更复杂度 =(QPS*Count(BU)/ 变更频次)。任何一个服务,QPS 越低,依赖这个服务的 BU 数越少,迭代的越频繁, 那么变更的难度越小, 变更带来的风险越小。

如下图所示。在中台建设期间, 由于自动化测试能力还不够,接口设计不完善, 团队同学的运维和沟通能力也还在成长中, 那么风险上升就会相对比较快。等到中台建设相对完善了,风险的增长和迭代难度就相对变缓。

车好多的优势是 QPS 增长不快,原因是汽车交易本来就是个低频事件, 全年全国不过是千万量级,和传统电商完全没办法比, 而车好多自生的业务迭代速度非常快, 变更频繁, BU 数增长很慢, 也就是车好多的中台变更复杂度随着时间的变化非常慢, 留给车好多的中台建设时间相对就比较充裕。另外车好多最大的两个板块新车和二手车有很大的相似性, 所以建设中台可以从这两个板块的最相似业务线出手来打造能力, 这也是优势。

对中台软件的要求

以前各家公司开发中台, 很少对中台软件做出系统性要求。中台团队想交付什么就交付什么。这些软件的质量参差不齐, 往往是项目的时间节点一到, 中台团队就三呼完美,那时候就有什么算什么, 业务团队如果稍有抱怨, 未来的需求就免不了受打压。为了避免这种情况, 我们对中台的软件做了一个定性要求。这些定性要求又可以大致分成两类, 一类是必要条件, 一类是充分条件。

先说必要条件:

  1. 中台软件必须具有可解释性, 也就是中台能力可以被分解成一组可以被完整描述的行为。这里特别要强调完整描述, 有些团队做中台, 先不说自己能做什么, 而是先占领一个关键词之后问你想要什么想要什么我们就可以做什么。 这个就是典型的圈地心态。对做什么功能,解决什么问题完全没有任何前瞻思考, 结果就是越做越无序, 前台团队跟着变得越来越低效。

  2. 中台必须具备可验证性,也就是说中台和计算的结果可以验证, 中台的交付的功能可以确定性的被证伪或者被证真。这是独立测试和边界稳定需求,很多中台是从业务线里划分出来的。因为需求繁忙, 往往对自己的边界也不做清晰定义, 也没有完备的自动化功能测试,更别说场景集成测试了。哪怕有边界,也经常变动, 没有兼容能力。这个要求就是对能力的验证和兼容性做限制, 避免中台堕入深不可测状态。

再说充分条件:

  1. 中台软件必须具备可隔离性,中台能力应该由多个相对独立的模块构成, 每个模块对相关实体的状态改变必须隔离在模块内部。这个要求是确保前台对中台可以做到最小化。而且对中台的依赖可以局限在前台的个别业务模块中, 这样对某个中台的依赖不会带来整个系统的稳定性降低。这个要求可以防止中台过度侵入到前台,无序扩张。

  2. 中台的模块必须可以被局部替代,中台的各模块加载独立,且个别模块所封装能力可以被等价接口所替代而不影响剩余的模块功能。这个要求和前面可解释性 / 可验证性一起就可以允许业务线对中台形成部分依赖, 而不是只要依赖某个中台的一个功能, 就必须所有功能全依赖,永远全家桶。

  3. 中台能力可以被第三方扩展和传播。也就是说中台的某个模块可以被前台团队重写后发布给全集团使用。这样可以避免中台能力仅仅独家定制,创新被遏制在远离前台的后台团队。

为什么说前面两个要求是必要条件呢为他们合在一起就是要解决中台提供能力的可封装性和可用性, 也就是说一个前台团队根据能力的描述可以决定是否使用一个中台功能。而后面三个是充分条件, 就是中台提供的能力前台业务线也可以选择不用, 或者部分使用那些有价值的模块。 这样中台既可用、亦可弃, 才满足了中台做为一个通用能力加速业务线迭代的充分必要条件。

车好多中台的设计原则

中台设计和使用上我们有如下原则:

  1. 业务优先。多数时候由业务线同学决定架构选型, 而不是中央决策。

  2. 反膨胀软件。对中台 API 稳定性和数据模型兼容性做强制要求, 避免中台膨胀过快。避免复杂依赖。

  3. 整个中台要求扁平化微服务化设计,降低依赖深度,加速功能发现。

  4. 模块化开发。各模块有明确边界,独立文档,可独立设计 / 发布 / 被替代 / 升级。 模块尽量以原子服务模式向往透出,模块间依赖主要是服务依赖。

中台的具体边界和抽象深度是个非常有挑战的问题,往往是个平衡,没有对错。对此我们做了设计追求的建议,就是期望各中台团队在交付压力允许的情况下最大化的做到以下两点:

  1. 边界合理:寻找中台的正确边界,平衡研发成本和业务迭代速度。中台的边界应当使得 API 最简化。

  2. 中台对多个业务的抽象逼近最优, 模型在信息量最大的情况下能够保持相对稳定。

下面两张图就是个具体的例子, 前一个模型简单, 相对稳定, 但是在这个模型下能够提供的服务粒度粗。第二个模型更复杂, 这个模型下能够提供相对更细粒度的服务。后者能够适用多个车好多业务线的现有模式, 且信息容量更大,所以在当前的业务矩阵之下是个更好的模型。

车好多的中台组织和孵化机制

车好多之前没有中台,怎么孵化出中台来也是个挑战。

孵化中台有多个方式:

  1. 自由竞争制:个人或者团队自主入场, 自主投入。代码开源,去中心化研发, 通过统一发现机制对外露出。

  2. 中央授权制:由公司做顶层决策,不做团队调整, 做项目强制统一多个技术分支。

  3. 集中孵化制:由公司做顶层决策, 对团队先做整合, 之后由该团队孵化中台。

  4. 重点扶持制:不对称的做研发人员补贴,对特定领域做引导,加速该领域的中台建设。

视情况不同, 我们这几种组织和孵化机制都有采用。

中台的孵化具体有如下几个平行的方向:

  1. 逐步建设市场机制:由前台业务线研发做选型决策,保障业务优先。同时通过 HC 管理引导最优决策,靠市场和预算驱动最经济的决策, 防止中台和前台的膨胀软件。在考核指标上前台考核业务增长;中台则考核前台接入成本、前台新需求延迟、前台定制成本和接口高稳定性。

  2. 建设自由准入能力,同时鼓励经营和创新。除了前面提到的内部开源且允许分支,我们会逐步建设去中心化研发体系,加速分布式创新。同时为了鼓励中台经营, 通过控制业务线分支权利来说防止重复造轮子。

  3. 人才流转策略:中台和前台必须有统一的研发体系和统一的人才流转机制,保持双方的活力。对有基本的能力、偏好和专业度差异的研发人才做定向培养, 支持转岗。

  4. 保障业务连续性和人员稳定性:对中台我们会保留一定程度的顶层设计,避免大范围技术和组织重构。

10

关于人才

最后讲讲人才。不论设计多么完美的机制, 最终还是要靠人来实现。合理的机制仅仅能够避免引人误入歧途, 但是价值创造还是要靠优秀的人才。

车好多对人才的画像可以总结成两句话:做学问要包容求真, 做人要有良知和勇气。 第一点是期望我们的人才能够保持开阔的视野, 对新事物和不同观点的包容,和不断探索寻求真正有价值洞察的欲望, 从而发现别人不能发现的机会。第二点是希望我们的人才能够为公司做正确的决策, 不断让正确的事情发生。同时他也要有勇气,愿意站出来阻止错误的事情发生。我们当下虽然有一些这样的人才,但也渴望更多的这样的人才加入。

11

写在最后的话

中台不是万能的, 但是可以在高确定性和高通用性场景下能创造增量价值。中台应该有合理的应用场景和时间窗口, 需要用一些设计原则来约束, 也需要相应的组织机制支持。中台有自己的生命周期, 要做阶段性的重构和重定位。这就是我对中台的大致理解。

车好多的中台实践不是标准答案,甚至不一定正确。我的分享是仅仅是为了带动高质量的思想碰撞, 也希望得到大家的帮助和反馈。谢谢大家。

  <END>  

文章知识点与官方知识档案匹配,可进一步学习相关知识Java技能树首页概览92016 人正在系统学习中

声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!

上一篇 2021年4月2日
下一篇 2021年4月2日

相关推荐