零、前言
专栏要回答的基本问题:
- 中台是什么?
- 中台从哪儿来?
- 中台到哪里去?
- 中台该怎么建设?
专栏要回答的其他问题“
- 中台与平台/微服务/SaaS 的区别是什么
- 中台与前台和后台的边界怎么界定?有了中台那后台是什么?
- 什么样的企业需要建中台,什么样的企业不需要建中台?对企业到底有哪些好处?
- 业务中台与数据中台的关系和区别又是什么?
- 中台建设有什么样的门槛,需要哪些准入条件?
- 中台该怎么建?分几个阶段?需要什么样的能力?
- 中台建设的结果好坏如何评估?谁来评估?
大纲:
- 来龙去脉
- 中台种类
- 中台定义
- 中台建设必须想清楚的四个问题
- 中台规划建设方法论:D4 模型
- 中台落地第一步:企业战略分解及现状调研(Discovery)
- 中台落地第二步:企业数字化全景规划(Define)
- 中台落地第三步:中台的规划与设计(Design)
- 中台落地第四步:中台的建设与接入(Delivery)
- 中台落地工具资源汇总
一、中台的来龙去脉
普世观点:
- 想要搞清楚一个概念或一门技术,就先要回到历史里,回到它诞生的时间,漫步一遍它发展的历程,去探究一下它产生的背景和原因。
- 知其然知其所以然。
中台发展时间线:
- 2008~2015,孕育
- 用词取自银行业:Middle Office
- 2008 年天猫诞生,天猫和淘宝重复建设问题,烟囱式架构,诞生阿里共享事业部。
- 聚划算爆发,奠定阿里共享事业部的重要地位,埋下了阿里大中台战略的种子。
- 2015,阿里巴巴中台战略诞生
- 马云 2015 年走访 Supercell。
- Supercell 产品多,员工少,研发速度快。
- 张勇发内部信,构建 DT 时代的「大中台、小前台」的组织机制和业务机制。
- 厚平台,薄应用 —> 大中台,小前台。
- 2017,横空出世
- 2016 默默无声但暗流涌动。
- 2017 阿里巴巴和滴滴开始分享各自中台建设经验,相关书籍出现在市面上。
- 2018,全面爆发
- 20180930,腾讯成立技术委员会,打造技术中台。
- 20181126,阿里宣布组织升级,将中台智能化与阿里云全面结合。
- 20181221,京东划分前中后台。
中台为什么火爆?
- 互联网企业的样板效应。
- 大厂的样板和标杆效应。
- 当前的产业互联网,在消费互联网阶段的中后期,消费侧的战场日益白热化。
- 互联网企业为了追求增长,纷纷将目光转向了供给侧,所以 ToB 火爆。
- 云和中台战略是互联网企业进入传统行业很好的切入点。
- 中台是很好的抓手和利器。
- 匹配到了一些行业从系统化向平台话转型的节点。
- 经济形势严峻,企业甚至行业充满不确定性和不可预测性,管理者对未来发展的恐惧和焦虑倍增。
- 中台战略,能力沉淀和复用,用确定性来应对不确定性,拥有快速试错、快速创新的能力和思路,给传统企业突围的方向。
二、中台种类
主流代表:业务数据双中台
业务中台
业务定义:
- 为了售出产品、换取利润,各行业中需要处理的商业上的相关事务。
业务中台定义:
- 需要具体承载支撑业务开展的必要业务元素,封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。
- 通过将不同业务线解决相同问题域的解决方案进行抽象与封装,通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求,实现对于不同业务线的业务支撑。
企业的业务顺利开展,需要解决哪些核心问题?
- 电商场景:把产品卖给用户,换取利润。
- 我的用户是谁?从哪里来?
- 我卖的产品是什么?从哪里来?
- 怎么让用户知道我卖的产品?
- 用户为什么会买我卖的产品?
- 用户怎么买?
- 货怎么送?
- 用户怎么退换货?
- 怎么才能让用户不断地买?
DDD(领域驱动涉及)
- 问题域
- 用户域
- 订单域
数据中台
数据中台成为热点的原因:
- 组织变动小
- 有技术基础
- 痛点明显,解决数据孤岛问题。
- 成本低
- 见效快
- 大势所趋,DT 时代,数据是企业的核心资产。
数据中台与传统数仓和数据平台的区别:
- 关注点不同。
- 前者关注企业层面的数据治理以及数据资产化内容:
- 数据的资产化管理(质量、成本、安全)
- 数据服务的构建。
- 数据的体系化建设(统一模型和指标)
- 后者只关心技术层面大数据底座的打造。
- 前者关注企业层面的数据治理以及数据资产化内容:
数据中台好似一个数据工厂,流程如下:
- 收集数据到原材料仓库;
- 厂房流水线进行数据加工;
- 作为数据产品进入产品仓库;
- 通过数据商店,以各种方式(例如数据 API)对于前台或是业务中台赋能;
- 整个过程通过控制中心进行协调调度。
业务中台与数据中台的关系
- 业务中台生产数据,数据中台二次加工,并将结果再服务于业务,为业务进行数据和智能的赋能。
- 相辅相成,互相支撑,互为输入输出。
- 业务中台承载了企业的通用业务能力,为多业务线赋能;
- 数据中台通过业务数据的二次加工,并反馈回业务中台,为业务进行数据和智能方面的赋能
非主流系列
- 技术中台
- 过滤掉技术细节,提供简单一致,易于使用的应用技术基础设施的能力接口。
- 业界也有说法,技术中台只是一些中间件的集合,是中间件平台,不算中台。
- 研发中台
- 关注开发效能管理的平台。
- 移动中台
- 移动互联网时代,移动优先。
- APP 开发的通用技术组件进行封装沉淀,使新场景能直接复用。
- 管理中台
- 对 人 事 流程 企业运营进行平台化/中台化改造。
- 组织中台
- 组织层面支撑前台组织和应用的快速迭代和规模化创新。
个人思考:
中台是强调资源整合,能力沉淀的平台体系,企业引入这套体系可以避免重复造轮子,减少重复性工作,省出大量时间和精力投入到更重要的事情上。仔细想想,人的工作和成长也是这样,每做一件事,要多沉淀通用的思路和方法,再做一件事,不应该从头再来,而应该复用曾经的成果,取得可叠加式进步。
三、中台定义
企业为什么需要平台化?
- 互联网时代,用户是商业战场的中心,为了快速响应用户的需求,借助平台化的力量可以事半功倍。
平台化作用
- 赋予或加强了企业最核心的能力:用户响应力。
- 平台化思想鼓励企业不断抽象沉淀自己核心的底层能力,通过平台化包装,得以更好的赋能前台业务,用底层的确定下来帮助企业应对前台业务以及最终用户需求的不确定性。
企业为什么建中台?
- 中台化是平台化的下一站,是平台化的下一站,是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。
- 中台关注为前台业务赋能,真正为前台而生。
- 企业采购每年服务费贵,自建花钱多维护困难。
- 前台和后台是两个不同转速的齿轮。企业业务发展,齿轮速率匹配失衡问题显现。
前后台定义:
- 前台:各类前台系统组成的前端业务平台。特点是有用户触电,企业用户直接使用的系统。例如:网站、手机 App、微信公众号、小程序。
- 后台:由后台系统组成的后端支撑平台。特点是管理核心资源(数据+计算)。例如:财务系统、客户管理系统。
中台的终极定义:
- 企业级能力复用平台。
- 企业级:定义了中台的范围。
- 区分开了单系统的服务化与微服务。
- 多条业务线,服务多个前台产品。
- 能力:定义了中台的主要承载对象。
- 能力的抽象解释了各种各样中台的存在。
- 企业差异化竞争力。
- 复用:定义了中台的核心价值。
- 消除重复能力建设。
- 复用 是中台关注的目标。
- 可复用性和易复用性是衡量中台建设好坏的重要指标。
- 业务响应力和业务满意度是考核中台建设进度的重要标准。
- 消除重复能力建设。
- 平台:定义了中台的主要形式。
- 细粒度能力的识别与平台化沉淀。
- 企业级:定义了中台的范围。
中台建设的核心目标:
- 以用户为中心的持续规模化创新。
互联网时代企业综合竞争力的核心体现:
- 企业的用户响应能力和规模化创新能力。
达到中台建设核心目标的手段是:
- 平台化包括中台化。
- 中台根本上解决企业响应力困境。
- 中台弥补前台和后台发展速率不匹配的矛盾。
中台化的定义:
- 利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程。
四、万事预则立:中台建设前必须想清楚的四个问题
中台建设的愿景是什么?
遇事不决看愿景。
建设中台前,第一个要问自己的就是:我们建设中台,愿景是什么?而且更重要的是这个愿景是需要所有的角色,上到企业管理层,下到每一位中台的相关人员都要明确并达成一致的。
中台的用户和客户是谁?
中台建设伴随着企业内的组织重构以及利益和职责的再分配。
管理层关注未来,关注长期战略目标;
产品经理,关注短期战术目标;
根本问题在于长期战略目标和短期战术目标的矛盾。
在保持自己方向的前提下,找到各方利益的结合点,是一件非常困难且有必要的事情。
中台建设虽然需要兼顾各方的利益,但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。
**
中台的钱由谁出?
中台投资结构的两种类型:
- 众筹模式
- 投融资模式
中台的目标怎么验证?
业界中台考核标准作为参考,例如阿里巴巴的中台考核:40% 稳定性 + 25% 业务创新 + 20% 服务接入量 + 15% 客户满意度。
愿景不同,考核方式和指标自然也不同。
这四个问题之所以重要,是因为他们能帮我们判断中台建设的周边环境是否已经准备就绪。
中台孵化的环境是否已经成熟。
五、D4 模型:中台规划建设方法论概述
做业务中台和做分布式系统的差别:
- 企业级
- 首先,解决的是实现企业目标的级别的问题。问题本身模糊,要结合现状以及企业战略,要充分考虑未来架构规划对于战略的影响。
- 其次,面临企业的组织问题。组织问题比业务问题难处理,因为涉及到企业利益的再分配。
- 然后,企业问题在业务层面,和过去做系统不同。面对的将是企业的业务全貌,甚至是未来才会出现的。
- 不是一个级别的事情,困难相差极大。
启发:
- 不要用一个系统级产品和架构的方式,试图来解决一个企业级产品和架构的问题。
- 业务梳理,微服务,领域建模只是手段,本质是在做一个企业级的架构,融入平台新要素的企业级架构:面向用户与创新的平台型企业架构。
中台和传统 EA 的差别:
- 传统 EA 是基于业务流程的梳理,不适用于沉淀成平台甚至中台。
- 传统 EA 是基于现状(As-is)的业务梳理;中台是面向未来(To-be)的业务发展和创新问题。
- 传统 EA 重流程,调研周期长;中台反之。
中台规划建设方法论:D4 模型
四阶段:
- Discovery,全局视野建立。
- 企业愿景和战略为输入
- 行业趋势
- 竞争对手分析
- 用户客群分析
- 业务现状分析
- IT 资产盘点
- Define,收敛与分析各维度信息,定义中台架构。
- 跨业务线的业务梳理的重合度分析。
- 规划具体的实施路径。
- 收敛的仍是企业架构层面。
- Design,针对实施路径中的某一个产品做详细设计。
- 产品级的业务需求分析。
- 功能及架构设计。
- 实施规划。
- 回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估。
- 标准的产品设计流程。
- Delivery,针对设计好的中台,开始具体的交付过程。
- 敏捷结合精益软件开发的方式,快速迭代和基于反馈的调整。
- 最大程度弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题。
- 注重架构的治理与守护,减少实现与设计的偏离。
- 想的深远
- 快速切入
- 保持演进。
六、中台落地第一步:企业战略分解及现状调研(Discovery)
企业级先发散再收敛的过程。Portfolio Discovery,简称 PD。PD 为 4~8 周的头脑风暴工作坊。下图为完整的 PD 工作坊路线图。
PD = 投资组合规划 = 资源最佳分配。
建中台是潜在选项,不应成为既定方向。
Discovery 的三个方向:
- 由外到内:行业与竞争对手分析。
- 成熟方法:五力模型,SWOT,商业模式画布,竞争对手产品线分析,竞争态势分析矩阵等
- 自上而下:企业战略分解。
- 在《论大战略》这本书中就提到:“所谓战略,就是如何达成目标与能力的平衡,并根据环境变换做出合适的调整”。
- 战略平衡三角形:
- 精益价值树(Lean Value Tree)用作战略愿景分解的工具。
- 自下而上:现状调研与分析。
- 常用工具和实践:高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理
相关建议:
- 先完成自上而下的企业战略分解,再开展自下而上的现状调研。
- 准备充分,提前完成无需讨论的调研内容。
- 制定详细计划,根据总时间倒推梳理的范围和粒度。
- 早期粒度放粗,不拘泥细节。
七、中台落地第二步:企业数字化全景规划(Define)
企业级架构方法
TOGAF
从企业最新的愿景战略以及运营模式出发,设计企业的 To-Be 业务架构,然后依次推导,一步一步推导数据架构、应用架构、技术架构。
中台复用的能力类型到底有几种?
企业机构战略的商业运营模型
- 横轴:标准化,标准化越高,企业通过业务模式(业务功能+业务流程)的复用实现业务线的扩展。
- 电商复用到垂直领域
- 纵轴:集成,数据集成,通过对数据的复用,实现业务线扩展。
- 微信用户数据集成到游戏领域。
类比业务中台
业务中台与 SaaS 的区别只是抽象粒度和层次的不同,本质上要解决的问题都是一样的,即业务模式复用。
我们要在不同业务线寻找哪几类共性能力:
- 业务数据。
- 业务功能。
- 业务流程。
- 通用的技术能力。
通过领域分析识别共性能力。
两个工具:领域驱动设计(DDD)+ 事件风暴(EventStorming)。
一个形式:工作坊。
业务流程分析点:问题空间 和 解空间。
识别点:关键聚合。
跨业务线的叠加投影:问题域。
扩展点目的:共性场景和能力识别。
中台与微服务的区别和联系?
没关系。最多微服务支撑业务平台。因为微服务架构运行时依赖的低耦合特性,通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性。
区别:
技术体系 | 问题域 | 关键点 | 好处 |
---|---|---|---|
中台 | 解决业务领域的业务(数据、功能、流程)复用问题。 | 业务能力快速复用。 | 不需要重复的资源投入。 |
微服务 | 轻量级分布式技术架构,解决技术领域的「组件编译时依赖」造成的问题。 | 能够独立部署。 | 依赖推迟到运行时,能实现「组件独立交付」、组件运行时动态扩展、组件技术异构;要承担分布式架构带来的复杂度作为代价。 |
平台型企业架构设计概览
一个完整的平台型企业架构的规划过程。
- 业务线现有业务架构分析,识别痛点做根因分析,进行业务架构改进与设计。
- 参考战略分解后对于各条业务线的目标和举措,融入 To-Be 业务架构设计,使新业务架构同时匹配企业战略要求以及解决短期战术痛点。
- 跨业务线比对分析,发现各业务线的业务功能及业务流程的重叠情况,为后续中台减少的必要性判断提供业务层面支撑和输入。
- 使用 DDD 的战略部分,针对每条业务线,做问题域和限界上下文分析,以及关键聚合的识别。领域角度审视业务本质,找出问题空间,问题域(核心、通用、支撑),区分问题空间对企业的重要性。
- 对业务线领域分析视图,做横向比对和投影,从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。
- 结合现状,做各条线的应用架构设计改进,并通过 As-is 和 To-Be 的应用架构做 Gap 分析,产出 IT 建设的具体机会点。
- 基于跨域的业务架构分析和跨域的领域分析,判断多条业务线的业务重合度:业务模式级别的重合(出行、电商)、业务功能级别的重合(登录、购物车)、业务领域(用户数据打通)级别的重合。基于此,决定是否引入中台建设。
- 分析现状与 To-Be 的最终规划之间的差距,产出具体的机会点列表,并基于多维度做优先级排序,产生最终的路线图。
Q&A
- Q:中台跟平台到底什么区别,这个概念感觉很模糊
这是个好问题,这两个概念也确实模糊,很多企业做的中台和之前做平台也没什么两样。但我觉得还是有些区别的,我先引用阿里行癫在一次采访中对于这个问题的解释:
行癫:原来阿里是个平台,我也做过两年中台,我一直在琢磨中台跟平台到底有什么区别。像阿里巴巴、淘宝、天猫这种平台只要搭好了,客户直接开店就可以了,不需要关心任何事情,但我觉得中台不一样,中台自己单独的产品不能直接产生价值、不能直接对外服务,一定要变成别人产品的一部分,让别人的产品提供更好的服务,这是我理解的中台。
当然这个解释也有很多的背景和上下文,就是阿里刚提出的“被集成”。
但我觉得这个解释也能一定程度上区分出这两个概念,这也是为什么我觉得平台更多是去重,是整合,是你不要做了,来我这儿做;而中台更多是复用,是赋能,是被集成,是你还是自己做吧,但我有这些能力能帮到你,你要不试试?
也正是因为视角的变化,为了争取更多的“用户”,更好的为前台服务,也让中台更多从前台出发,从业务出发,也自然会包含更多的业务属性和业务封装。
所以我认为平台和中台的区别不再表现形式上,而主要在视角的区别上,视角的不同也会导致边界的不同,走上完全不同的道路。
不知道说的是否清楚,是否能解答你心中的疑惑。如果还有问题,欢迎继续留言,我们继续探讨~
八、中台落地第三步:中台的规划与设计(Design)
确定中台产品愿景
电梯演讲**(Elevator Pitch)**的工具发散和收敛产品的愿景。
- 电梯偶遇公司高层,能否在有限时间内讲清楚在做的事情。
愿景上的讨论花再多时间也值得,因为会影响中台设计和建设的后续走向。
确定业务梳理范围
进行细粒度的业务架构梳理,抽取共性,识别中台产品的具体需求。
极客地产如下:
细粒度业务梳理
需求的逻辑:
- 业务需求 -> 客用户需求 -> 设计方案 —> 产品需求
- 正向过程:围绕商业愿景确定探索,客用户真正的痛点驱动出能力,抽象出能力转化为产品特性。
- 逆向过程:满足设计要求,解决客用户问题,实现商业价值。
识别不同业务线可复用的业务数据、业务功能与业务流程,经过分析就形成了中台的具体需求。这些需求,可以通过用户故事(User Storey)的方式描述。
确定 MVP
MVP(Minimum Viable Product):最小可用品。
运营前置:制定迭代计划及接入计划
度量前置:定义验证指标
市面上场景的产品度量指标:
- 战略类。
- 用户类。
- 市场拓展类。
- 降本提效类。
度量指标:
5How 驱动验证指标的设计:
比如管理层视角:
- 我怎么判断中台建设成果?对于新业务的赋能。
- 我怎么验证对于新业务赋能效果?看新业务的上线速度。
- 我怎么验证新业务的上线速度?看新业务从立项到上线的时间。
- …