《说透中台》读书笔记

中台发展史

中台这个概念, 无论是从涉及领域的宽度还是从战略到落地的纵深高度来讲, 都是非常非常大的, 向上可以触及到行业趋势, 企业使命愿景战略, 向下又可以落地到分布式架构, 遗留系统重构, 架构演进与守护, 质量保证等等各个方面. 而且就算是同一个行业, 每家企业还都不一样.

在 2008 年, 随着阿里巴巴战略的调整, 天猫顺势而生. 但因为其相较于于淘宝, 有其自身的特点, 所以当时天猫和淘宝就出现了重复建设的问题, 也就是现在大家经常提到的烟囱式系统架构. 烟囱式的系统架构, 造成了大量的重复建设和资源浪费, 怎么办呢? 最自然的想法就是将重复的组织和系统进行整合.

Supercell 是芬兰一家游戏厂商, 造出了部落战争, 海岛奇兵等 APP, 催生了这么多火遍全球游戏的企业, 却只有不到 200 名员工, 而负责一款游戏的每个团队平均也只有 5 到 7 名团队成员.

他们的战略是以最快的速度推出公测版, 让市场来评判, 来验证产品的好坏. 一旦产品不成功, 则迅速放弃, 此时不但不会有任何惩罚, 反而团队会举杯庆祝, 之后立即做出调整继续迅速寻找新的方向. 这就是典型的精益创业的套路.

想让这个机制得以正常运转, 必须有一个前提, 就是产品的构建时间要足够短, 试错的成本要足够低, 这样才能保证团队在大量的试错中, 通过不断从失败中学习, 持续迭代调整, 尽快找到正确的方向, 让创新成功的进度条快速前进. 而背后支撑这个机制得以实现的, 就是 Supercell 经过 6 年时间沉淀下来的游戏开发过程中那些公共的, 通用的游戏素材和算法. 基于这些像乐高积木一样的基础素材和算法, 才可以同时支持几个小团队在几周时间内像搭积木一样快速研发出一款新游戏.

中台是强调资源整合, 能力沉淀的平台体系, 企业引入这套体系可以避免重复造轮子, 减少重复性工作, 省出大量时间和精力投入到更重要的事情上.

中台火爆的契机:

• 互联网企业的样板效应, 某里巴巴忽悠的概念, 其他厂当然要卷啦
• ToC 不好干了, 大家都去卷 ToB 了
• 早期公司内部卷的各个系统烟囱林立, 数据孤岛, 需要用中台做一波收敛和聚合
• 经济大形势不好, 没啥新业务, 互联网企业通过卷中台战略, 把能力进行沉淀与复用, 用确定性来应对不确定性
• 卷 KPI(沃·兹基硕德)

什么是中台

中台其实就是企业级能力复用平台.

• "企业级"定义了中台的范围, 区分开了单系统的服务化与微服务;
• "能力"定义了中台的主要承载对象, 能力的抽象解释了各种各样中台的存在;
• "复用"定义了中台的核心价值, 传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注, 中台的提出和兴起, 让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上;
• "平台"定义了中台的主要形式, 区别于传统的应用系统拼凑的方式, 通过对于更细粒度能力的识别与平台化沉淀, 实现企业能力的柔性复用, 更好地支撑前台业务.

中台的种类

中台最常见的是业务数据双中台, 不过只要有卷的地方, 就有更多其他平台.

业务数据双中台

业务中台就是在产生数据, 数据中台是做数据的二次加工, 并将结果再服务于业务, 为业务进行数据和智能的赋能. 嗯, 一听就是阿里味儿, 冲得很.

业务, 更白话一些来说, 就是为了售出产品, 换取利润, 各行业中需要处理的商业上的相关事务. 所以在早期我们通常会把销售叫作业务员. 网易副总裁汪源就曾在网易云创峰会上提到过: "所有的中台都是业务中台". 因为从广义上来看所有的中台, 不论是业务中台还是数据中台, 亦或其他, 都是为业务, 为企业可以更好地以更低的成本, 更高的质量, 更快的响应速度售出产品, 换取利润服务的. 换个角度看, 从企业架构的层面看, 应用架构, 技术架构, 数据架构都是要匹配公司的业务架构的, 因为"业务", 即售出产品, 换取利润是企业的核心目标.

我们常提到的业务中台, 是狭义层面的业务概念, 业务中台需要具体承载支撑业务开展的必要业务元素, 封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案. 我们常提到的业务中台, 通过将不同业务线解决相同问题域的解决方案进行抽象与封装, 通过配置化, 插件化, 服务化等机制兼顾各条业务线的特性需求, 实现对于不同业务线的业务支撑. 比如电商的业务中台可以这样划分:

同样数据中台就比较好理解, 就是卷 BI 平台, 大部分企业都进行了多年的数据仓库建设, 技术有足够的储备, 所以也比较好卷. 对于数据中台与传统数仓和数据平台的区别, 关键在于数据中台相对于数仓, 大数据平台, 向前台, 向业务又迈出了一步, 不再只是关心技术层面大数据底座的打造, 同时开始更多地关注企业层面的数据治理以及数据资产化的内容: 包括但不限于数据的资产化管理(质量, 成本, 安全), 数据服务的构建, 数据的体系化建设(统一模型和指标)等.

总结一番, 业务中台与数据中台相辅相成, 互相支撑, 互为输入输出. 业务中台承载了企业的通用业务能力, 为多业务线赋能; 数据中台通过对于业务数据的二次加工, 并反馈回业务中台, 为业务进行数据和智能方面的赋能. 两者的紧密配合一起为企业构建起了商业战场强大的后方炮火群, 这也就构成了最著名的业务数据双中台模式.

其他中台

除此之外还有一些非主流的中台:

• 技术中台: 简单来讲就是在 CloudNative 下将使用云或其他基础设施的能力, 各种技术中间件的能力进行整合和包装. 过滤掉技术细节, 提供简单一致, 易于使用的应用技术基础设施的能力接口, 助力前台和业务中台, 数据中台的快速建设. 以我的经验, 就是公司内部的云平台.
• 研发中台: 按他的说法就是关注开发效能管理的平台叫作研发中台, 比如持续集成这种, 我觉得也可以集成到技术中台叭.
• 移动中台: App 开发过程中的通用技术组件进行封装沉淀, App 持续集成, 发布治理平台之类的
• 管理中台: 应该就是内部 OA, ERP 系统平台化
• 组织中台: 组织中台很像企业中的内部风投和创新孵化机构, 为前台组织和团队构建创新型前台应用提供类似于投资评估(项目甄别), 投资管理, 投后管理(孵化与风控), 真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新.
• 其他: 财务中台, 采购中台, 供应链中台, AI 中台, 运营中台, 安全中台

如何落地中台

中台是企业级的能力复用平台, 那首先中台关注的是企业级发展的问题, 一般我们把这种级别问题常常称之为企业的战略问题, 而每家企业的战略不同, 其核心能力也不同, 自然每家企业的中台也各不相同. 因此中台的痛点也很明显.

• 中台的界限本身就比较模糊, 逐渐成了所有前台业务团队共享的一个内部外包团队, 所有的业务都会不断地提需求过来, 需求拥堵和排期的问题开始出现
• 干系方众多, 前边有各个业务前台团队, 后边还要集成企业已有的各种核心系统, 各方对于中台都有不同的理解和诉求, 甚至有些不同干系方的诉求都会相互矛盾和冲突, 中台团队夹在中间很难受
• 虽然响应各个前台业务的需求, 但是真正落地后前台业务也不怎么爱用, 提需求的时候一个比一个积极, 真正做完了需要前台接入的时候, 又是用各种理由推脱, 不太愿意接入

因此我们应该提前想清楚四个问题:

中台建设的愿景是什么

"万事不决看愿景", 愿景帮助我们了解自己中台建设的目标, 帮助我们判断哪些事情是符合中台建设愿景的, 作为中台团队我们需要去考虑. 在这之外, 更重要的是帮我们判断哪些事情不是中台要去做的, 为中台做减法, 这点在中台的建设过程中其实更加重要. 这个愿景是需要所有的角色, 上到企业管理层, 下到每一位中台的相关人员都要明确并达成一致的.

中台的客户是谁

在中台建设之前, 我们最好先搞清楚中台如果作为一款产品, 它的用户是谁? 客户又是谁? 用户和客户是一个群体么? 除了用户和客户还有哪些干系方? 他们对于中台都有什么期望, 这些期望又是否一致. 中台建设虽然需要兼顾各方的利益, 但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题. 中台也不应该只是极力去满足各方的诉求, 中台团队毕竟不是业务的外包团队. 中台需要有自己的思想和规划, 要能做到听得进别人的话, 但是还要明确自己的目标, 走自己的路.

中台的钱由谁出

作者的意思是人和资源从哪出, 是从业务方抽调, 还是招兵买马新搭建团队. 从投资结构来讲, 基本上可以分为两种类型, 即"众筹模式"和"投融资模式". 依鄙人来看, 基本模式是从现存业务方孵化, 搞大了再专门抽成团队.

中台的目标怎么验证

ToC 的收益很容易获得, 可以相对容易地找到一些量化指标来度量产品的成功与否, 比如常见的用户数量, 用户活跃度或是市场覆盖率等. 但中台很难说前台之所以有这些成果, 都是我中台的赋能效果. 相反如果中台在使用过程中出现了故障, 还极易被业务方甩锅. 因此, 以终为始, 在建设前就应该思考如何验证和度量中台, 例如 alibaba 的中台考核方案就是 40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度.

中台建设方法论

一般我们做得更多的是系统级别或是单条业务级别的系统建设或改造. 而在做中台的时候, 我们处理的完全是高一个级别和范围的事情, 已经跳出单个产品, 单条业务线, 涉及到企业的层面, 即企业级的范畴. 既然是企业级的问题, 你将面对的就是企业的组织问题, 即"利益分配", 你卷走了部分业务, 势必会造成别的团队失去了一定利益. 比如最常碰到的就是为什么要配合中台? 我为什么要把数据给中台? 我为什么要用中台. 此外, 你将面对的将是企业的业务全貌, 甚至是那些未来才会出现的, 现在还不知道长什么样子的潜在的创新业务.

再谈一谈传统 EA(Enterprise Architecture), 传统的 EA 方法多是基于业务流程的梳理, 大多的产出物就是企业要采购像 ERP, CRM 这样的系统来解决特定领域的问题. 传统的 EA 方法更多是解决当时信息化背景下的问题, 也就是基于现状(As-is)的业务梳理, 考虑如何通过系统的构建来解决业务流程的信息化改造问题. 而目前大家在构建中台时, 往往信息化程度已经非常高了, 该有的系统都有了, 而中台建设甚至是大家经常挂在嘴边的数字化建设, 更多是为了未来(To-be)的业务发展和创新的问题.

于是这哥们卷出了 D4 模型, 他通过把中台从整体规划到落地交付的过程划分了四个不同的阶段, 包含了两次发散与收敛的过程. 这个方法践行了 Think Big, Start Small, Move Fast 的原则, 既要想得长远, 又要快速切入, 并保持持续演进. 中台背后的本质问题, 其实是一个面向用户与创新的平台型企业架构的问题.

Discovery

在中台规划前先建立全局视野, 在这个过程中我们以企业愿景和战略为输入, 结合行业趋势, 竞争对手分析, 用户客群分析, 业务现状分析, IT 资产盘点, 全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌, 帮助我们做出最正确的判断.

D4 的前两部分 Discovery 和 Define 合起来, 就是一个在企业级先发散再收敛的过程. 有的公司叫作 Portfolio Discovery, 简称为 PD, 是一个 4-8 周的头脑风暴工作坊. 翻译成中文就是投资组合规划, 应用在企业里就相当于产品线规划. PD 的主要目的就是做充分的发散和调研, 也就是利用各种工具和手段帮助我们充分了解行业趋势, 竞争对手的情况, 公司的战略分解以及自下而上的现状调研等信息和环境, 为下一个阶段 Define 的收敛.

Discovery 过程又分为三个阶段:

由外到内: 行业与竞争对手分析

实际上就是产品调研, 以 点 - 线 - 面 - 体 理论为基础. "点"指的就是中台这个事, 它可能只是一家企业发展到一定阶段的产物, 不是开始也不是结束. 要从一家企业的发展过程这条主线上来看待中台这件事情, 来看这个点. 它从哪里来? 为什么会出现? 又将向哪儿去? 甚至思考中台的下一个阶段会是什么? 会被什么替代? "面"就是看多家同行业怎么搞的. 这不废话嘛... 竞品分析当然得看多家公司, 要不 PPT 都写不明白. "体"就是跳出同行业, 比如传统银行金融业也可能在卷类似中台点东西.

总之这个理论的好处一是可以借(抄)鉴(袭)竞品的思路成果, 二是通过学习其他行业, 跳出互联网思维定势, 能够实现企业跨行业的跃进. 最后作者还提到常用的分析手段有五力模型, SWOT, 商业模式画布, 竞争对手产品线分析, 竞争态势分析矩阵等. 这些概念 PM 应该比较熟吧, 毕竟天下产品一大抄 (不是.

自上而下: 企业战略分解

就是"向上管理"嘛. 所谓战略, 就是如何达成目标与能力的平衡, 并根据环境变换做出合适的调整. 战略平衡三角形可以辅助我们理解战略这个概念:

依据战略平衡三角形, 在企业的愿景和目标已经确定的情况下:

• 企业战略就可以简化理解成: 结合企业自身的能力与其所处的环境, 到底需要采取什么样的举措, 才能实现企业预定的愿景和目标呢?
• 而企业战略分解就可以简化理解成: 结合企业各部门自身的能力与其所处的环境, 到底需要采取什么样的举措, 才能实现企业预定的愿景和目标呢?

精益价值树(Lean Value Tree) 用来帮助做战略愿景的分解. 精益价值树是一种以价值成效为导向, 用于分析和沟通业务愿景, 战略与投资的工具. 它的核心是建立从愿景, 目标到投资举措自上而下的对齐, 因此采用一种逐层分解的树形结构.

这个过程, 就是我说的自上而下的战略分解过程. 而某一个中台, 它可能只是最终推导出的一个具体的举措而已, 向上还是要能追溯到对于企业愿景和目标的关联性和价值上, 匹配和对应企业的愿景目标.

自下而上: 现状调研与分析

尊重过去遇到的所有问题, 收集汇总痛点; 另一方面又要求我们能跳出过去的限制, 重新从业务出发, 从用户出发, 去重新探索基于新技术, 新架构下的一些新的可能性. 例如高层访谈, 干系人地图, 组织架构分析, 战略设计思维, 业务架构现状梳理, 用户旅程, 服务蓝图, 领域驱动设计, 应用系统现状梳理, 技术架构现状梳理等等. (虽然我觉得很难, 逃).

Define: 企业数字化全景规划

基于之前 Discovery 发散的各维度信息进行收敛与分析, 对于中台的架构进行定义. 通过对跨业务线的业务梳理进行重合度分析, 并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析, 一起来收敛推导基于中台的企业架构设计.

企业架构方法最常见的方法是 TOGAF, 它基本思路就是从企业最新的愿景战略以及运营模式出发, 设计企业的 To-Be 业务架构, 然后依次推导, 一步一步推导数据架构, 应用架构, 技术架构. 在整个企业架构设计的过程中融入了领域驱动设计(DDD), 结合事件风暴, 对业务流程背后的问题域进行分析, 以及通过不同业务线的问题域重合度分析, 帮助我们透过流程洞见企业各业务的本质, 寻找共性业务元素. 而中台实际就是提炼业务数据, 业务功能, 业务流程以及通用的技术能力.

1. 分析各业务线现状, 再结合识别的痛点做的根因分析, 对于现有的业务架构进行改进, 设计改进后的业务架构方案.
2. 参考战略分解后对于各条业务线的目标和举措, 使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点.
3. 对于改进后的业务架构, 做跨业务线的比对和分析, 以此来发现不同业务线的业务功能及业务流程的重叠情况.
4. 使用领域驱动设计, 针对于每条业务线, 做问题域和限界上下文分析以及关键聚合的识别, 从领域的角度深入一层审视业务的本质.
5. 对于各条业务线分析出来的领域分析视图, 做横向比对和投影, 类似于将几张半透明的画摞在一起, 来找相交部分一样, 找出共性.
6. 结合现有的业务架构及应用架构, 做各条线的应用架构设计改进.
7. 基于跨域的业务架构分析和跨域的领域分析, 讨论判断多条业务线的业务重合度.
8. 最后基于战略重要性, 紧急程度, 成本, 资源就绪情况, 技术就绪情况, 风险, 痛点 Mapping 等做优先级排序, 产生最终的路线图.

Design

就是正常的需求设计, 包括产品级的业务需求分析, 功能及架构设计, 实施计划等, 在 Design 阶段我们需要回答产品的愿景, 边界, 产品形态, 技术架构, 交付计划, 成本预估等等.

设计的过程就不说了, 没啥意思, 文中讲的都很虚. 不过在真正开发前需要去做两点:

• 运营前置: 制定迭代计划及接入计划
• 度量前置: 定义验证指标

运营前置就是在开发前就先站在接入方的角度来制定迭代计划和接入计划, 毕竟业务都是并行了, 越往后拖越难以接入. 度量前置自不用说, 提前想好度量指标后面好去邀功.

Delivery

用快速迭代和基于反馈的调整, 最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题, 并且注重架构的治理与守护, 减少实现与设计的偏离.

敏捷关注的是价值确定的情况下, 如何通过小步快跑的迭代方式按节奏交付价值; 而精益关注的则是在价值并不确定的情况下, 如何用最小成本, 快速定位到真正价值点.

除了中台的建设过程, 同样不能忽略中台的运营, 治理与演进. 重要要搞清的就是中台产品的用户划分, 因为台作为一个公共服务部门, 一定会碰到多个前台的需求, 排期, 质量要求, 非功能需求出现不同的情况. 而中台的资源有限, 且有自己的愿景, 不可能无条件地满足所有前台用户的诉求, 往往就会陷入疲于应对的状态, 对前台的响应和服务质量也会急速降低.

# NFR(Non-Functional Requirement, 非功能性需求)
# SLA (Service-Level Agreement, 服务等级协议)
Offering = Capability + SLA/NFR

最常见的就是三层用户划分机制(3 tiers customer segmentation)

互联网需要中台吗

互联网企业需要中台, 不是锦上添花, 而是生存所迫, 是因为恐惧. 因为竞争过于惨烈, 谁能抢到用户, 谁能获取用户的芳心, 谁能留住用户, 谁就能干掉别人获得成功. 这不是政治需要, 也不是技术需要, 这是生存需要, 是一场你死我活的搏杀. 所以, 互联网企业天生眼里盯着的就是用户, 这是为了生存, 刻在了基因里的. 而用户, 则被惯坏了, 又要求你产品层出不穷, 不断迭代更新; 还得要经济便宜, 不舍得多付出一点成本.

这两类需求本身就是矛盾的, 又要灵活又要经济, 企业还没的选择, 为了生存也必须无条件地继续满足用户的各种"无理要求".

而在企业层面, 中台这个新的中间层的产生, 就是为了调和这个"灵活"与"经济"的矛盾. 前台纵向, 承载了企业的灵活性; 中台横向, 承载的是企业的经济性; 而前台与中台的分离, 博弈与平衡, 本质上就是企业作为一个整体灵活性与经济性的分离, 博弈与平衡.

总结

看完了整个文档, 说实话我还是没明白中台和后台的区别, 尤其是在这个中台已经被拉下神坛的时代更是如此. 不过如果面对一个新事物, 下面这段话我认为是值得收藏的.

永远保持好奇, 先接纳, 再判断. 不要轻易把门关上, 可能会错失掉一些新的东西, 就算是进去转了一圈, 最后发现并没有什么新的价值, 其实也没有多大的损失, 学习有时候不能太功利. 不过话也要说回来, 也要有自己的主动思考能力, 需要快速判断概念是否值得继续投资自己的资源, 毕竟人的精力也是有限的, 不要在价值不大的新概念上浪费太多的精力, 及时踩下刹车. 而对于如何判断是否需要"止损":

• 新的技术在解决什么问题? 为什么之前的技术不能解决? 它的核心突破点是什么? 本质是什么?
• 新的技术和其他解决类似问题的技术有什么关系? 有什么区别?
• 新的技术为什么在现在这个时间段出现? 为什么在现在爆发? 为什么之前没人想到这种新的解决方案?
• 新的技术和我现在正在做的事情是否相关? 新的技术和我想做的事情或方向是否相关?