小白对中台概念的理解之路
自己的简短要点总结：中台就是企业级能力复用平台。有点像代码里面的abstract class的感觉。把共性的东西，不管是产品流程，数据流程或是研发流程摘出来。它更多是一种对理念、机制的定义，而不是对一个具体产品的定义。
中台一般有一定规模的团队，并有着多种相似并行业务的时候，才有价值的。
Reference: 极客时间的《说透中台》课程。如果觉得笔记有帮助的话推荐大家去听完整的课，讲的更清楚。而且每节课的评论区其实看一看更有收获。
首先，中台这个概念很年轻，所以业界对这个概念本身也仍然没有一个统一的认识 - 大家都在关注，但是又很难讲清楚。
- 中台到底指什么？
- 中台的来源？
- 中台与平台/微服务/SaaS的区别是什么？
- 中台与前台和后台的边界怎么界定？
- 什么样的企业需要中台，什么样的不需要？
- 业务中台与数据中台的关系和区别是什么？
- 中天建设的门槛和准入条件？
- 中台改怎么见？分几个阶段？需要什么样的团队和能力？
中台的发展历史
2008：首先，”中台“这个中文词是由阿里巴巴提出中台战略（2015左右，”大中台，小前台”）而逐渐被大家熟知。而早在2008年，天猫诞生，阿里就出现了重复建设的问题 ==> 建立共享事业部，负责将各个前台系统中的公共部分进行平台化改造。聚划算的爆发让阿里共享事业部的重要地位凸显，埋下了阿里大中台战略的种子。
2015：马云和阿里众高管拜访了芬兰移动游戏公司 Supercell。 这个不到200人的公司，却催生了很多火遍全球的游戏（部落战争，海岛奇兵…）。负责一款游戏的每个团队平均只有5-7名成员，而且可以做到高速迭代。能实现这个的前提是足够段的产品构建时间，而这个前提是由 Supercell 经过6年时间沉淀的那些公共的、通用的游戏素材和算法所支持的。
2017：互联网大厂开始分享各自中台建设的经验。相关书籍也开始出现。
2018：中台迎来全面爆发。腾讯宣布成立云与智慧产业事业群（CSIG），阿里云事业群升级为阿里云智能事业群，将中台智能化与阿里云全面结合。
思考：中台为什么这么🔥？
- 互联网大厂的样板效应。
- 从ToC向ToB侧重。ToC战场逐渐饱和，越来越多的互联网企业参与进传统企业上云和企业数字化转型过程中，把自己的技术和实践带到传统行业。而这个过程中，中台是一个很好的利器。
- 这个时间点正好匹配到了一些行业从系统化向平台化转型的节点。
- 这两年整体的经济大势并不太好，有着很多不确定性和不可预测性。而这个时候，互联网企业通过中台战略，把能力进行沉淀与复用，用确定性来应对不确定性。
中台的一些主要类型
业务数据双中台
业务中台
业务这个词，其实是有些宽泛的。我们常提到的业务中台，是狭义层面的业务概念，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。
当我们思考业务中台时，可以不断地问自己一个问题：企业的业务能够顺利开展，需要解决哪些核心问题？
比如电商的场景，如果我是一家电商企业，我业务要顺利开展，即把我的产品卖给用户，换取利润，一般要解决的核心问题无非包含：
- 我的用户是谁？从哪里来？
- 我卖的产品是什么？从哪里来？
- 怎么让用户知道我卖的产品？
- 用户为什么会买我卖的产品？
- 用户怎么买？货怎么送？
- 用户怎么退换货？
- 怎么才能让用户不断地买？
这些就是一个电商业务能够正常开展所需要解决的最基本最核心的问题，在 DDD（领域驱动设计）中，对于这些核心问题有个专有名词–就是问题域。大家常说的用户域、订单域等等的叫法也来源于此。而对于一家电商企业的不同业务线，大多是因为卖的产品不同，或是卖的区域不同，用户群体不同，但是大多数情况下这些问题的解决方法也是相通和类似的。这就是业务中台之所以能够存在的原因。
数据中台
“业务中台就是在产生数据，数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。” - 阿里巴巴技术方案总监谢纯良
那数据中台与业务中台之间又是什么关系呢？究竟什么才是数据中台？跟过去建设的数据仓库和大数据平台又有什么区别和联系呢？
数据中台与传统数仓和数据平台的区别，关键在于数据中台相对于数仓、大数据平台，向前台、向业务又迈出了一步，不再只是关心技术层面大数据底座的打造，同时开始更多地关注企业层面的数据治理以及数据资产化的内容：包括但不限于数据的资产化管理（质量、成本、安全），数据服务的构建，数据的体系化建设（统一模型和指标）等。
业务中台与数据中台相辅相成，互相支撑，互为输入输出。业务中台承载了企业的通用业务能力，为多业务线赋能；数据中台通过对于业务数据的二次加工，并反馈回业务中台，为业务进行数据和智能方面的赋能。两者的紧密配合一起为企业构建起了商业战场强大的后方炮火群，这也就构成了最著名的业务数据双中台模式。
非主流中台类型
研发中台：将企业的开发流程、最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代。
移动中台：将 App 开发过程中的通用技术组件进行封装沉淀到移动中台中。
组织中台：像是企业中的内部风投和创新孵化机构，为前台组织和团队构建创新型前台应用提供类似于投资评估（项目甄别）、投资管理、投后管理（孵化与风控），真正从组织和制度上支撑前台组织和应用的快速迭代和规模化创新。
企业为什么要建中台
简短的答案：为了在当今互联网时代，快速响应用户的需求。
而从结果来看，在不确定性当道的当今商业战场，真正的弄潮儿也大多是那些具备平台化思维并很早就开始发力平台建设的企业。
平台化思想（platform thinking）鼓励企业不断抽象（abstract）沉淀自己核心的底层能力。中台化是平台化的下一站，是平台不断对自身治理演进、打破技术边界、逐渐拥抱业务、具备更强业务属性的过程。中台关注为前台业务赋能，真正为前台而生。
这里，我们有必要再明确定义一下前后台：
- 前台：每个前台系统都是一个用户触点。例如用户直接使用的网站、手机 App、微信公众号、小程序等都属于前台范畴。
后台：每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。
在互联网企业很多并没有后台的概念，更多直接使用平台的概念，例如分为前台层和平台层，但位置和作用与传统企业里的后台相似。
很多企业的后台，在创建之初的目标，并不是主要服务于前台系统的业务创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。后台管理的往往是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，这样的系统也往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，不能⽀持前台快速的业务创新需求。企业业务不断发展壮大，后台修改的成本和风险越来越⾼，但同时还要响应用户持续不断的需求，怎么办？最自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低。
对于这样的问题，Gatner 在 2016 年发布了一份报告 Pace-Layered Application Strategy。其中的SOR（Systems of record ），SOD（Systems of differentiation）和 SOI（Systems of innovation）三个概念其实就分别对应了后台，中台和前台。
中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。
中台 – 企业级能力复用平台
企业级
企业级定义了中台的范围。它并不是说一个企业只能有一个中台，也不代表一个中台就是只能包含一家企业。企业级更多代表的是中台处理的问题在企业级别：至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。需要的是企业全局视角和跨业务线的能力沉淀。
能力
能力定义了中台主要承载的对象。能力的抽象解释了为什么会有那么多种类中台的存在，也能解释为什么每家企业的中台都不一样，因为不同的企业之所以能够同时存在，就是因为其核心能力不同，可以满足用户不同层面的需求，也就是我们常说的差异化竞争力。
复用
复用定义了中台的核心价值，体现出一种对于前台业务的使用体验更加关注的趋势。
- “企业级”定义了中台的范围，区分开了单系统的服务化与微服务；
- “能力”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
- “复用”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；
- “平台”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。
如果说中台就是企业级能力复用平台的话，那中台化也就是利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程。
中台建设前必须想清楚的四个问题
中台关注的是企业级发展的问题，也就是战略问题。每家企业的战略不同，其核心能力也不同，自然每家企业的中台也各不相同。既然每家的中台都不同，那中台的落地方法还有章可循吗？其实是有的，但比其他技术类的方法要抽象一些。
- 中台建设的愿景是什么？(decide on expectation and success metrics)
这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。 - 中台的用户和客户是谁？
中台的建设通常都会伴随企业内的组织重构以及利益和职责的再分配。如果没有搞清楚中台建设的各个干系方关系，必然在中台的建设过程中就会四面碰壁，陷入“干系人旋涡”之中，面临多方面的阻力，陷入一个非常被动的局面。
我们需要找到企业管理层与业务线关注点的结合点，也就是长期战略价值和短期战术价值的结合点。
但反过来讲，中台也不应该只是极力去满足各方的诉求，中台团队毕竟不是业务的外包团队。中台需要有自己的思想和规划，要能做到听得进别人的话，但是还要明确自己的目标。
中台建设虽然需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。 - 中台的钱由谁出？
市面上的中台建设，如果从投资结构来讲，基本上可以分为两种类型，即“众筹模式”和“投融资模式”。
众筹模式：从业务前台集资，拿出预算或者人力。其实这里隐藏着很大的问题，因为业务前台优先关注的是自己短期的实际问题，自然希望中台短期就可以见效果，帮助自己解决实际的问题。
如果中台的愿景就是为了解决业务方短期的问题，那这个模式也还可以。但大多数中台建设的愿景都是企业战略层面的，这时候如果还是采用众筹模式，就会发现非常矛盾。
投融资模式：建设前期先由投资方出资，按照产品的建设目标经过一段时间的建设期，相对成熟之后，再逐渐地让用户使用，实现收入并收回企业投资且盈利。这种模式的好处是中台团队在中台的建设初期会有更多的自主权，在启动和脆弱期不会受到太多现有业务压力的影响。但缺点是企业需要有较雄厚的战略资源支持，也需要有更大的战略决心。 - 中台的目标怎么验证？
中台建设的另外一个难点就在于对建设结果很难做量化度量。这点不像前台的业务线或是我们常见的 ToC 类型的产品，可以相对容易地找到一些量化指标来度量产品的成功与否，比如常见的用户数量，用户活跃度或是市场覆盖率等。中台作为前台的服务者，不但无法直接分享业务成功的喜悦，反而很容易被甩锅成了背锅侠。
目前业界有一些中台的考核标准我们可以作为参考，例如阿里巴巴的中台考核就是设计成：40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度。
一个典型业务中台建设的例子
做一个业务中台和做一个分布式系统到底有什么不同？
其实这两个不太好放在一起对比。因为中台是一种理念，而分布式系统是一种技术架构。技术出身的人，容易把业务中台就简单理解成微服务，从而导致用微服务做系统的思路和方法做中台建设，必然会遇到一些问题。
做中台，往往涉及到企业所有的业务线，那是不是该把企业所有的业务都梳理一遍呢？如果这么做，基本上就意味着需要调动整个公司的资源，那各条业务线为什么会配合呢？就算是业务会积极配合，那还有后续的问题，到底要梳理到什么粒度呢？就算梳理完所有的业务，规划出一个中台，但你怎么证明你这个中台就是对的呢？就是最好的呢？
其实这些问题的答案，还是之前一直说的”企业级“。
不同于系统级别或是单条业务级别的系统建设或改造， 如果是企业级的问题，你要解决的就是实现企业目标这个级别的问题。这样的问题本身就是模糊的，一般也都是战略级别的，所以不能只从现状的业务入手，要从企业的战略分析开始，充分考虑未来架构规划对于战略的影响。你面对的业务全貌，甚至是那些未来才会出现的，现在还不知道长什么样子的潜在的创新业务。
中台规划建设方法论：D4 模型
第一个阶段是 Discovery – 建立全局视野：在这个过程中我们以企业愿景和战略为输入，结合行业趋势、竞争对手分析、用户客群分析 、业务现状分析、IT 资产盘点，全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌，帮助我们做出最正确的判断。
第二个阶段是 Define – 对各维度信息进行收敛与分析， 对于中台的架构进行定义：通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计。并形成具体的实施路径规划，说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目，在这个阶段也可以回答那个我们关心的问题，我们到底需不需要中台，需要哪些中台。
第三个阶段是 Design – 针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等：例如业务中台产品，在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。
第四个阶段就是 Delivery – 针对一个设计好的中台，开始具体的交付过程：我们采用的是敏捷结合精益软件开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。
这个方法背后其实践行了一种我们称之为 Think Big，Start Small，Move Fast 的原则，既要想得长远，又要快速切入，并保持持续演进。
作为中台的核心技术人员，每天的工作上会有什么不同呢？
作为中台的核心技术人员，我们要具备更强的产品思维，了解更多的业务知识和培养自己的业务视角。中台产品的设计与开发，还需要比一般产品更强的抽象，设计和代码能力，好的中台不是只是把大家拼在一起，交给一个团队就可以了的。真正能发挥出中台的能力，必须要有很强的抽象、设计与实施能力，如今DDD、TDD又一次焕发了第二春，也是于此有一些关系。
下个section我们来看每个阶段的目标和一些常用的工具与实践。
Discovery: 企业战略分解及现状调研
这个过程有一个称呼，叫作 Portfolio Discovery，简称为 PD。实际实施时，PD 是一个 4～8 周的头脑风暴工作坊。
企业到底要不要划分出一部分钱和资源来做中台建设？对公司来讲添加中台这样一个新的架构层次有什么价值？什么时候做最好？优先级怎么样？这是 PD 所主要关注和需要回答的问题。
整体上，Discovery 又可以简单分成由外到内、自上而下和自下而上的三个不同方向的过程。
由外到内：行业与竞争对手分析
其实业界已经有了很多非常成熟的方法，你可以直接使用，例如常见的：五力模型，SWOT，商业模式画布，竞争对手产品线分析，竞争态势分析矩阵等。
自上而下：企业战略分解
什么是战略呢？这个概念可能比较虚。
借助我们经常用到的战略平衡三角形，可以帮助理解战略这个相对较虚的概念。
在企业的愿景和目标已经确定的情况下，企业战略分解就可以简化理解成：结合企业各部门自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？
对于企业战略的分解，业界也有很多工具和实践，例如 BMGovernance 设计的企业战略分析模型等。但为了应对变化越来越快的市场环境，在 PD 中我们使用的是精益价值树（Lean Value Tree）的工具来帮助做战略愿景的分解的。
自下而上：现状调研与分析
我们不但要自上而下地做企业战略的分解，以此来帮助我们思考中台或是其他举措是否必要。同样需要充分地做自下而上的现状调研，来帮助我们了解现状和历史。
常用的工具和实践也很多，例如高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理等等
这里有一个问题，那就是梳理的范围和深度。对企业级的架构梳理，宽度和范围可能会远远超过我们的想象。如果深度控制不好，会发现转了半天还是在一个小的领域和业务线原地打转。所以面对这种问题和风险，有下面几个建议：
- 先完成自上而下的企业战略分解，再开展自下而上的现状调研。因为做完战略分解，我们已经对于公司的行业、业务、愿景、战略已经有了一些了解，再开展调研的时候就会有个全局的把控，对于粒度和深度都更容易拿捏。
- 做好充分的准备，能够提前通过阅读资料和小范围调研完成的内容就提前完成。
- 制定详细的计划，可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够，可以用两天的时间梳理一条业务线的业务架构，这样梳理就可以深入一些。但如果只有半天，则粒度可以适当放粗，先保证有一个全局业务视图。
- 刚开始做的时候，可以粒度粗一些，不要过早陷入细节，不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解，也是最见功夫的地方。在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。
这样的现状调研工作，对于一个中型的有四五条不同业务线的企业，我们实际实施大概需要 2～4 周左右的时间。
Define: 企业数字化全景规划
企业架构方法如 Zachman、TOGAF 等，最长的已经有 20 多年的历史了，可以说已经非常成熟。其中应用最广的应该就属 TOGAF 。TOGAF 的基本思路，就是从企业最新的愿景战略以及运营模式出发，设计企业的 To-Be 业务架构，然后依次推导，一步一步推导数据架构、应用架构、技术架构。
让我们来看一些在企业架构设计实施过程中与中台相关的常见问题。
中台复用的能力类型到底有几种？
借用哈佛大学出版社 2006 年出版的一本讲企业架构战略的书里提到的一个商业运营模型（Business Operating Model）
我们可以给一些中台复用的能力进行归类：
总结下来基本上就是四类：业务数据、业务功能、业务流程以及通用的技术能力。
通过领域分析识别共性能力
使用领域驱动设计结合事件风暴（EventStorming）这两个工具，通过工作坊的形式来对业务流程背后的问题空间和解空间做进一步的分析，识别出关键聚合，再通过跨业务线的问题域叠加投影，找出大家共同关注的问题空间和聚合，从而继续扩展来做共性场景和能力识别。
平台型企业架构设计概览
- 首先通过各条业务线的现有业务架构分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构，解决现在痛点背后的问题。
- 同时还要参考战略分解后对于各条业务线的目标和举措，融入 To-Be 业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。
- 对于改进后的业务架构，做跨业务线的比对和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。
- 使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题空间的问题，并通过问题域的划分（核心、通用、支撑），区分问题空间对于企业的重要性。
- 类似于业务架构，同样对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。这么可能比较抽象，你可以理解成类似于将几张半透明的画摞在一起，来找相交部分一样。帮助我们识别业务数据以及业务模式（功能 + 流程）上的深层次共性能力。
- 结合现有的业务架构及应用架构，做各条线的应用架构设计改进，并通过 As-is 和 To-Be 的应用架构做 Gap 分析，产出 IT 建设的具体机会点，这样的机会点就类似于新建一个 CRM 系统之类的。
- 再基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度，并详细识别重合更多是在业务模式级别的重合（出行、电商）、业务功能级别的重合（登录，购物车）、还是业务领域（用户数据打通）级别的重合。基于讨论结果，决定是否有必要引入中台层建设，以及根据重合情况，详细展开规划中台层的应用架构。
- 最后再分析当前现状与 To-Be 的最终规划之间的差距，产出具体的机会点列表，并且基于多维度（常见的例如战略重要性、紧急程度、成本、资源就绪情况、技术就绪情况、风险、痛点 Mapping 等）做优先级排序，产生最终的路线图。
Design: 中台的规划与设计
和基于现状的传统业务流程梳理不同，我们在业务梳理过程中大量地采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理。
大概来说，就是重新从用户体验和问题域来分析需求。
通过范围内的业务架构梳理，再结合最后的跨场景通用能力的分析，我们就可以对关注领域的业务全貌有了一定深入的了解，并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台的具体需求。对于这些需求，我们是通过用户故事（User Story）的方式描述的。
确定 MVP
通过业务梳理，我们识别和整理了大量的业务中台需求。值得注意的是，此时的所谓中台产品需求，更多的是来源于定性抽象，再考虑到中台的需求往往不像前台业务系统的需求那样明确，所以，从严格意义上来讲，此时的需求仍属于一系列高风险的假设。从实与的中台建设项目来看，往往这些一开始设想的中台需求，到真正开发完成之后，都与最初的设想有很大的偏差。这就意味着，中台建设的周期越长，需求假设的风险和需要为之付出的代价就越大。
为了实现 MVP，保证做出来的 MVP 可用，我们在业务需求上采用端到端纵向切分的方式，结合需求优先级的多维度评分排序，最终确定 MVP 的需求范围，而最终落地的形式可能就是第一个迭代的用户故事列表。
运营前置：制定迭代计划及接入计划
运营计划对于中台可能就是中台产品推广、前台（用户）接入计划以及接入后的运营支持。很多常见情况是，中台建设的中后期才开始考虑这些问题，往往就有些晚了。而且前台是不会停下来等中台建设完，等接入后再开始自己的业务演进，所以往往都是前中台并行。
度量前置：定义验证指标 (Define success metrics)
具体到实施方法，因为每一个中台产品都是不一样的，所以很难给一个标准的答案。在实操过程中，建议你多换位思考，多问几个“怎么（How）”。相信你比较熟悉 5Why 分析法，这里我们可以稍微改一下，用 5How 来驱动验证指标的设计。举个例子，如果我站公司管理层的视角：
那我怎么判断中台建设的成果？如果回答是看对于新业务的赋能，
那我怎么验证对于新业务的赋能效果？如果回答是看新业务的上线速度，
那我怎么验证新业务的上线速度？如果回答是看新业务从立项到上线的时间，
那我怎么验证……
Delivery: 中台的建设与接入
中台人员能力模型
模型中的“爱多思”指的是网易教育中台。
精益的产品研发流程
保持小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证中台建设是一个持续演进和被业务驱动的过程。
整个过程是一个复杂的系统性工程，一般都会涉及到像云化工程，微服务及服务化能力构建，Devops 相关能力构建，数据运营能力构建，敏捷精益过程改进，遗留系统服务化改造，架构守护与演进，以及与中台相关的治理与运营架构构建等工程。
中台产品的用户划分
中台作为一个公共服务部门，一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况，甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。如果我们采用产品化的思维来构建中台，那中台中所沉淀的能力并不是产品的全部，还需要再加上 NFR（非功能性需求）或是我们常说 SLA（Service-Level Agreement，服务等级协议）才是产品，因为不同的前台用户之间，不只是对于中台产品的功能本身有着不同的诉求，同样对于 NFR 或是 SLA 也有着不同的诉求。简单举个例子，比如核心业务对于中台的 SLA 稳定性的要求可能是 5 个 9，性能是 5 毫秒；而一个新的创新型应用，可能还没有用户，就不需要有这么高的要求。
最常见的就是三层用户划分机制（3 tiers customer segmentation）。通过对于前台用户的分层，我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源（人或钱），甚至前台与中台可以通过签署 SLA 来实现对于前台用户的服务承诺。
当我们开始中台建设时，可以只找到一个或是两个种子用户，作为 Tier1 级别的用户来服务。当中台建设到一定阶段之后，对于种子用户的服务已经接近稳定，有了一定的能力沉淀，也能释放出一定的资源了，就可以利用释放出来的资源开始为 Tier3 层的用户构建自助服务控制台（Self-Service Console），并着手构建中台产品的运营团队，制定 Tier3 层的 NFR/SLA。在很多互联网企业，这个过程常常由于做出来的自助服务控制台比较粗糙，看起来也像是对于平台服务的增强和可用性优化和治理的过程，大多数就是一个白屏幕，加一些的配置选项，所以常被称为“平台的白屏化”。
当中台的自助服务控制台创建完成，Tier3 层次的 SLA 也构建完成后，我们就可以重新签订 SLA，将之前的 Tier1 用户迁移到 Tier3 层次，即完成之前种子用户从定制化服务到自助式服务的迁移过程，从而释放出更多的资源用于接入新的前台用户。
如果由于种种原因，无法一步到位实现服务的完全自助化，还可以通过构建 Tier2 层的 SLA，也可以通过重新签订 SLA，将之前的 Tier1 用户迁移到 Tier2 层次，通过“自助 +VIP 服务”的方式，保持对前期种子用户服务连贯性的同时释放出尽可能多的资源。
有用的文章
- 中台概念
- 中台与组织
- 建设经验
- 方法论相关
- 谈谈企业的规模化创新
- 以愿景与目标驱动，让创新无处不在 （精益价值树）
- 当用户不是客户，需求价值怎么定？| 商业洞见 （用户与客户）
- 架构设计实践思路：什么是架构，怎么画架构图？（企业架构展开解释）
一些重点问题的再回顾
业务中台与微服务有什么区别和联系?
他们两个其实没有本质联系。
业务中台与微服务解决的是不同的问题，也处于不同的抽象层次。
前面提到了业务中台解决的是业务领域的业务（数据、功能、流程）复用的问题，而微服务架构作为一种轻量级分布式技术架构，解决的是技术领域的“组件编译时依赖”造成的问题。而且业务中台不一定是微服务架构的，微服务架构也不一定是为了解决能力复用的问题。首先来看业务中台。
业务中台要解决的是业务能力如何快速复用的问题，就算背后是一个大单体，只要暴露出来的 API 能够满足业务能力快速复用的目的也是可以的。
而微服务架构的关键点是“能够被独立地部署”，或者翻译成“能够被独立地交付”更贴切，而这点也是评判一个微服务架构是否能发挥其价值的关键因素。
所以，业务中台与微服务架构并没有啥直接关系，只是因为微服务架构运行时依赖的低耦合特性，通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性而已，只能算是一对好搭档。
技术中台与中间件的区别？
确实，我们看到很多技术中台就是中间件平台包装发展的产物。对于这个问题，说说我自己的理解。技术中台强调的是更多从业务视角出发，而中间件主要是从技术去重的视角出发。具体来说，技术中台为了让业务更好地使用技术相关能力，对于技术做一些治理、安全、可用性和自助式的包装。如果能通过中台这个概念为驱动力，促使企业的内部技术平台再向业务走出一步，无论是针对用户体验做优化，还是通过产品化，让业务可以自助式（Self-Service）地使用企业技术组件的能力，如果能做到这些或是起到这样的驱动力，技术中台这个概念才有价值。上面推荐的《从平台到中台 | Elasticsearch 在蚂蚁金服的实践》，就是一个非常好的对于中间件平台（Elasticsearch 平台）中台化改造的例子。
数据中台与数据仓库的区别？
其实不光是数据仓库，还有数据中台与大数据平台的区别。其实有很多文章也在讨论这个问题，其中最大的一个区别还是数据中台和传统的数据系统出发点（视角）不一样。
原来的数据平台也好，数据湖也好，数据仓库也好，它们的出发点很多时候有局限性，应该说更是一个支撑性的技术系统，即一定要去考虑我先有什么数据，然后我能干什么，依赖现有数据的质量、现有数据的状况，来做这样一个支撑性的技术平台。那数据中台呢？回到我们所讲的中台概念，它更多的是从业务出发，然后再来看这些业务，你需要这些数据服务，它有什么价值？至于说这些数据服务所依赖的数据有没有，只要这个服务有价值，那我们就去想办法拿到数据，如果没有能力，我们就去建设技术能力，去完成数据服务的提供。
所以，传统的数据系统（数仓、大数据平台）更多是偏技术侧，拿着数据和技术找场景；而数据中台更多的是偏业务侧，拿着场景去找数据和技术。也就是说，数据中台的思维是业务思维，它从业务问题出发，这也就是为什么业务部门对数据中台会这么欢迎。《火热的数据中台对企业的价值是什么？》中对此有详细的展开，对数据中台还有疑惑的话，可以重点看一下这篇。其实有这些困惑的问题就在于中台这个概念的出现并没有在技术上有任何的创新。我们仔细想想，是不是没有任何一个新的技术是由“中台”这个概念所驱动出来的？而我们大多也习惯了从技术的视角上去看待新的概念，所以自然就被搞晕了，因为各种中台所使用的技术早就在那儿好多年了，没有什么新鲜玩意儿。这也是理解“中台”概念的一个坎儿，就是能否从技术的视角切换到业务的视角上，用“业务思维”来看待平台。其实这也是理解中台概念的关键所在，也是技术平台发展的一个大趋势。