中台

源起孕育阿里巴巴中台战略诞生横空出世全面爆发中台的分类主流代表：业务数据双中台业务中台数据中台为什么要建中台？中台的定义中台建设前必须想清楚的四个问题中台规划建设方法论中台规划建设方法论：D4 模型企业战略分解及现状调研（Discovery）为什么用 PD 这样的方式规划中台？由外到内：行业与竞争对手分析自上而下：企业战略分解自下而上：现状调研与分析企业数字化全景规划（Define）企业级架构方法中台复用的能力类型到底有几种？通过领域分析识别共性能力中台与微服务有什么区别和联系?平台型企业架构设计概览中台的规划与设计（Design）确定中台产品愿景确定业务梳理范围细粒度业务梳理确定 MVP 运营前置：制定迭代计划及接入计划度量前置：定义验证指标中台的建设与接入（Delivery）精益产品研发流程中台的运营、治理与演进中台落地工具资源汇总

源起

孕育

2008~2015

因为在 2008 年，随着阿里巴巴战略的调整，天猫顺势而生。但因为其相较于于淘宝，有其自身的特点，所以当时天猫和淘宝就出现了重复建设的问题，也就是现在大家经常提到的烟囱式系统架构。

烟囱式的系统架构，造成了大量的重复建设和资源浪费，怎么办呢？最自然的想法就是将重复的组织和系统进行整合。正因如此，阿里共享事业部正式诞生，负责将各个前台系统中的公共部分进行平台化改造，经历了一段痛苦的摸索之后，借聚划算爆发的契机，才真正奠定了阿里共享事业部的重要地位，埋下了阿里大中台战略的种子。

阿里巴巴中台战略诞生

在 2015 年，马云带领阿里众高管一起拜访了位于芬兰、号称是世界上最成功的移动游戏公司 Supercell。说起这家公司，你可能会觉得比较陌生，但是提到这个公司开发的游戏，相信你一定有所耳闻，《部落战争》《海岛奇兵》《卡通农场》等等知名的游戏都出于这家游戏公司之手。

但当时触动马云和阿里高管团队的是，催生了这么多火遍全球游戏的企业，却只有不到 200 名员工。而负责一款游戏的每个团队平均也只有 5 到 7 名团队成员。团队有充分的自由，他们可以自行决定开发什么样的产品，之后就会以最快的速度推出公测版，让市场来评判，来验证产品的好坏。一旦产品不成功，则迅速放弃，此时不但不会有任何惩罚，反而团队会举杯庆祝，之后立即做出调整继续迅速寻找新的方向。

嗯，是的，这就是典型的精益创业的套路。

但要想让这个机制得以正常运转，必须有一个前提，就是产品的构建时间要足够短，试错的成本要足够低，这样才能保证团队在大量的试错中，通过不断从失败中学习，持续迭代调整，尽快找到正确的方向，让创新成功的进度条快速前进。

而背后支撑这个机制得以实现的，就是 Supercell 经过 6 年时间沉淀下来的游戏开发过程中那些公共的、通用的游戏素材和算法。基于这些像乐高积木一样的基础素材和算法，才可以同时支持几个小团队在几周时间内像搭积木一样快速研发出一款新游戏。

这种方式触动了到访的阿里巴巴高管团队，这种理念与阿里巴巴及业界这么多年一直在尝试和构思的“厚平台，薄应用”架构方向不谋而合。就是这次拜访，坚定了阿里巴巴管理层对于组织架构调整的决心，也加速催化了阿里巴巴中台战略的正式诞生。

随后不久，在 2015 年 12 月 7 日，时任阿里巴巴集团 CEO 的张勇通过一封内部信说道：“今天起，我们全面启动阿里巴巴集团 2018 年中台战略，构建符合 DT 时代的更创新灵活的‘大中台、小前台’组织机制和业务机制。”

至此，阿里巴巴中台战略正式诞生，而之前的“厚平台，薄应用”也顺势变成了“大中台，小前台”。

横空出世

在 2017 年我们逐渐开始在社区里听到了越来越多关于中台的声音，阿里巴巴和滴滴出行不约而同地开始分享各自中台建设的经验，而与中台相关的书籍也出现在了市面上。

互联网大厂的集体发声，让中台这个概念时隔了两年之后又重新回到了大家的视野当中。

据我了解，很多企业无论是互联网大厂，还是一些比较有战略眼光的企业，也都是在这个时间点开始重新审视并重视这个已经出现苗头的新概念。

最早一批开始动手的企业大多也是在这个时间开始了自己的中台整体规划与建设，而我也是在那个时候开始与中台结缘，关注并研究中台，实际参与到一个个客户的实际中台项目中的。

但当时大家面对的问题和困难也很多，像阿里巴巴或是滴滴出行这类的企业，在分享中台的时候，更多的是以自己发展历程的角度和自己的问题出发。这也毋容置疑，但是大家回头来审视自己企业的中台建设时，每家的情况都不一样，每家的问题也不同，自己的中台到底应该是什么样子？怎么建设？这些问题很多都是在书中、在分享中找不到直接的答案，只能靠自己一点一点摸索。

至此，一些勇敢的先行者们就开始了各自的中台探索之旅，虽然这注定是一条布满荆棘的道路。

现在回头再看，有些当时的探索最终失败了，有些探索仍在继续。但无论如何，这些先行者们的探索和经验得失，为我们现在理解和建设中台扫清了很多障碍，没有这些探索和思考，也不会有现在的这些经验与共识。

全面爆发

2018 年 9 月 30 日，腾讯宣布了 7 年来最大规模的组织变革，新成立了云与智慧产业事业群（CSIG）。同时，腾讯新成立了技术委员会，宣布未来将打造技术中台。

2018 年 11 月 26 日，阿里宣布进行组织升级，阿里云事业群升级为阿里云智能事业群，将中台智能化与阿里云全面结合。

2018 年 12 月 21 日，京东集团人力资源部发布关于京东商城组织架构调整的公告，公告内容称：“在新的组织架构下，京东商城将围绕以客户为中心，划分为前中后台。中台为前台业务运营和创新提供专业能力的共享平台职能。

中台的分类

主流代表：业务数据双中台

业务中台

我们常提到的业务中台，是狭义层面的业务概念，业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。

企业的业务能够顺利开展，需要解决哪些核心问题？

比如电商的场景，如果我是一家电商企业，我业务要顺利开展，即把我的产品卖给用户，换取利润，一般要解决的核心问题无非包含：

我的用户是谁？从哪里来？

我卖的产品是什么？从哪里来？

怎么让用户知道我卖的产品？

用户为什么会买我卖的产品？

用户怎么买？

货怎么送？

用户怎么退换货？

怎么才能让用户不断地买？

这些就是一个电商业务能够正常开展所需要解决的最基本最核心的问题，在 DDD（领域驱动设计）中，对于这些企业业务开展需要关注的核心问题空间有个专有名词，就是问题域。大家常说的用户域、订单域等等的叫法也来源于此。

而对于一家电商企业的不同业务线，大多是因为卖的产品不同，或是卖的区域不同，用户群体不同，但是这些问题也都是要解决的，大多数情况下解决的方法也是相通和类似的。这就是业务中台之所以能够存在的原因。

所以，我们常提到的业务中台，可以理解成狭义的业务中台，通过将不同业务线解决相同问题域的解决方案进行抽象与封装，通过配置化、插件化、服务化等机制兼顾各条业务线的特性需求，实现对于不同业务线的业务支撑。

数据中台

讲完了业务中台，我们再来看目前热度最高的数据中台。数据中台为什么这么火热？我总结下来主要是这么几个原因。

见效快。目前大部分传统企业的问题还在于数据不通，“数据孤岛”现象比较严重，数据中台的建设对于痛点的解决直接，驱动力强。

组织调整负担小。一般来说，有一定规模的企业都已经有了大数据团队或是 BI 团队，这个团队自然就承载着相关的职能，不需要再做大的组织调整。

有一定技术基础储备。大部分企业都进行了多年的数据仓库建设，或是随着前几年大数据的浪潮，已经构建了多年的大数据技术平台。

大势所趋。大家都在讲 DT（Data Technology）时代，对于数据的价值，企业的认识也越来越深刻，大家已经意识到数据不再只是一种运营辅助分析的工具，而逐渐成为企业的核心资产和竞争力。

业务中台就是在产生数据，数据中台是做数据的二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。”

而对于数据中台与传统数仓和数据平台的区别，关键在于数据中台相对于数仓、大数据平台，向前台、向业务又迈出了一步，不再只是关心技术层面大数据底座的打造，同时开始更多地关注企业层面的数据治理以及数据资产化的内容：包括但不限于数据的资产化管理（质量、成本、安全），数据服务的构建，数据的体系化建设（统一模型和指标）等。

为了方便理解，在 ThoughtWorks 我们经常把数据中台比喻成一个数据工厂，通过收集到原材料仓库，经过厂房流水线的数据加工，最终作为数据产品进入到产品仓库，通过数据商店，以各种方式（例如数据 API 的方式）对于前台或是业务中台赋能，整个过程通过控制中心进行协调调度。

这个比喻形象生动地体现了数据中台对于数据的二次加工的过程，同时还描述了通过数据实验室承载为数据赋予智能，通过办公室完成数据的治理与资产化的相关处理。

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

为什么要建中台？

当今这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。

这背后的逻辑很简单，不断地快速响应、探索、挖掘、引领用户的需求，才是企业得以生存和持续发展的关键因素。

那些真正尊重用户，甚至不惜调整自己、颠覆自己来响应用户的企业，将在这场以用户为中心的商业战争中得以生存和发展。反之，那些在过去的成就上故步自封，存在侥幸心理希望用户会像之前一样继续追随自己的企业，则会被用户淘汰。

很残酷，但这就是这个时代最基本的的企业生存法则。

而平台化之所以重要，就是因为在这场以用户为中心的现代商业战争中，它赋予或加强了企业最核心的能力：用户响应力。平台化思想（Platform Thinking）恰好鼓励企业不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业应对前台业务以及最终用户需求的不确定性。

从结果来看，在不确定性当道的当今商业战场，真正的弄潮儿也大多是那些具备平台化思维并很早就开始发力平台建设的企业，这也在一定层面上佐证了平台化对于一家企业的重要性。

好，现在我们想明白了第一个问题，企业为什么需要平台化。但是平台化并不是一个新概念，很多企业在这个方向上已经做了多年的努力和积淀。那为什么最近几年“中台”这个相对较新的概念又会异军突起？对于企业来讲，传统的“前台 + 后台（或是平台）”的平台化架构为什么不能满足企业的要求呢?

这就引出了我们的核心问题：企业为什么要建中台？

中台化是平台化的下一站，是平台不断对于自身治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台业务赋能，真正为前台而生。

前台：由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机 App、微信公众号、小程序等都属于前台范畴。

后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。（在和很多互联网的朋友聊过之后，在互联网企业很多并没有后台的概念，更多直接使用平台的概念，例如分为前台层和平台层，但位置和作用与传统企业里的后台相似，我这里直接统一使用后台这个概念来代表。）

我们看到很多企业的后台，在创建之初的目标，并不是主要服务于前台系统的业务创新，而更多的是为了实现后端资源的电子化管理，解决企业管理的效率问题。这类系统要不就是当年花大价钱采购的套装软件，需要每年支付大量的服务费，并且版本有的也已经非常老旧了，定制化困难；要不就是花大价钱自建，年久失修，一身的补丁，同样变更困难，基本改不动了，也是企业所谓的“遗留系统”的重灾区。

可以这么说，大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么变更速度就根本跟不上前台业务发展的节奏。总结下来就两个字“慢”和“贵”，对业务的响应慢，动不动改个小功能就还要花一大笔钱。

有人会说了，你不能拿遗留系统说事儿啊，我们可以新建后台系统啊，整个 2.0，问题不就解决了？

这是一种解决问题的思路，不过就算是新建的后台系统，因为后台管理的往往是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，这样的系统也往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，不能⽀持前台快速的业务创新需求。

此时的前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好，转速也自然是越慢越安全。

所以，随着企业业务的不断发展，这种“前台 + 后台”的齿轮速率“匹配失衡”的问题就逐步显现出来了。

企业业务不断发展壮大，后台修改的成本和风险越来越⾼，这就驱使我们尽量保持后台系统的稳定性，但同时还要响应用户持续不断的需求，怎么办？最自然的就是将大量的业务逻辑（业务能力）直接塞到前台系统中，因为前台离用户近，响应也相对快。

但是这样也是有代价的，这样的后果就是引入重复，同时还导致前台系统不断膨胀，变得臃肿，形成了一个个大泥球的“烟囱式单体应用”。这个局面的结果就是，前台系统的“用户响应力”被渐渐拖垮，用户满意度逐渐降低，企业竞争力也随之不断下降。

对于这样的问题，Gatner 在 2016 年发布了一份报告 Pace-Layered Application Strategy。报告中给出了一种解决方案，即按照“步速”将企业的应用系统划分为三个层次（正好契合前中后台的三个层次），不同的层次采用完全不同的策略。

而 Pace-Layered Application Strategy 也为“中台”产生的必然性，提供了理论上的支撑。

在这份报告中，Gatner 提出，企业构建的系统从 Pace-Layered 的角度来看可以划分为三类：SOR（Systems of record ），SOD（Systems of differentiation）和 SOI（Systems of innovation）。每一类的系统都有着不同的变化速率，因此也会有不同的生命周期，适合不同的技术架构和不同的开发过程，甚至是采用不同的投资模式。

回到之前说的后台与前台的两层架构，如果映射到这个模型上其实就是只有 SOR（后台）与 SOI（前台）的两层应用架构。这样的情况下，我们又要尽力保持后台（SOR）系统的稳定可靠，⼜要前台系统（SOI）能够⼩而美，快速迭代。因此就自然出现了上文提到的“齿轮匹配失衡”的问题，感觉鱼与熊掌不可兼得。

怎么办？Pace-Layered 中的 SOD 就是答案，它提供了比前台（SOI）更强的稳定性，以及比后台（SOR）更高的灵活性，在稳定与灵活之间寻找到了⼀种美妙的平衡。

中台就是 SOD。有了这层“中台”，我们既可以将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的“能力炮火”支援。

中台就像是在前台与后台之间添加的⼀组“变速齿轮”，将前台与后台的速率进行匹配，是前台与后台的桥梁和润滑剂。它为前台而生，易于前台使用，将后台资源顺滑地通过前台导流向用户，支撑企业更好地响应用户。

好了，现在我们可以小结一下，回答企业为什么需要建中台这个问题了。很简单，企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。

中台的定义

我给中台的定义就是：

企业级能力复用平台。

很简单，是不是有点失望？但是为了找到一个我觉得还靠谱的定义，我几乎花了快两年的时间，期间有各种各样的定义曾浮现出来，但至少到目前为止，我觉得只有这个定义最贴切、最简单、也最准确，它能解释几乎所有我碰到的关于中台的问题，例如：

为什么会有那么多中台？

中台化与平台化的区别是什么？

中台化和服务化的区别是什么？

中台该怎么建设？

……

这 9 个字看起来简单，重要的是其背后对“中台”价值的阐释，下面就让我为你一一拆解来看。

1. 企业级

企业级定义了中台的范围。不是说一个企业只能有一个中台，也不代表一个中台就是只能包含一家企业，企业级更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队），如果一个中台只为了支持一条业务线或产品线，那就不是中台，即使它用了服务化或是大数据等技术。

企业级这一点非常非常重要。它让我想清楚了，中台建设的事情并不是一个技术问题，而是一个要上升到企业架构的问题。做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景。

想清楚了这一点，我对中台的理解就有了一次质的变化，也终于知道为什么一开始用做系统服务化的方式做中台会面临那么多的问题，比如最常见的组织和干系方以及利益再分配的问题。

从中台的兴起与爆发我们也能看到一个趋势，就是越来越多的企业，无论是想提升自身的运营效率，还是出于业务创新发展的需求，都已经把企业全局视角、跨业务线的能力沉淀，提到了前所未有的战略高度。

2. 能力

提到中台，最常听到的一个词就是“能力”。可能是因为能力这个词足够简单，又有着足够的包容度与宽度。

能力定义了中台主要承载的对象。

能力的抽象解释了为什么会有那么多种类中台的存在，也能解释为什么每家企业的中台都不一样，因为不同的企业之所以能够同时存在，就是因为其核心能力不同，可以满足用户不同层面的需求，也就是我们常说的差异化竞争力。

3. 复用

复用定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。传统的平台化对于“可复用性”和“易复用性”并没有给予足够的关注，更多关注的是如何消除掉重复的能力建设，既所谓的“去重”。

但中台的提出和兴起，体现出一种对于前台业务的使用体验更加关注的趋势。让人们通过对于“可复用性”和“易复用性”的关注，将目光更多地从平台内部的建设转换到平台对于前台业务的支撑上。这里有一个从治理到赋能的视角转换，既从“去重”到“复用”的关注上。

“去重”与“复用”虽然经常一起出现，一起被提及，但是谈论的完全不是一件事情，目的不同，难度也不同。“去重”讲的更多是向后看，是技术驱动的；“复用”讲的更多是向前看，是业务驱动和用户驱动的。而正这个视角的转变，我认为是理解中台概念的关键，所以

“复用”是中台更加关注的目标；

“可复用性”和“易复用性”是衡量中台建设好坏的重要指标；

“业务响应力”和“业务满意度”是考核中台建设进度的重要标准。

这也能解释为什么很多互联网企业，将对于平台的治理，通过业务抽象以及可配置化和白屏化的改造升级，把这个过程称之为对于平台的中台化改造过程。

4. 平台

平台定义了中台的主要形式。区别于传统应用系统拼凑的方式，中台通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务，来满足对于业务的快速响应和复用的需求。

“企业级能力复用平台”这个定义虽然看起来简单，但经过这么长时间对于中台的实践与思考，我觉得这个定义背后所代表的意义是目前对中台价值的最贴切的阐释。

“企业级”定义了中台的范围，区分开了单系统的服务化与微服务；

“能力”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；

“复用”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；

“平台”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。

中台建设前必须想清楚的四个问题

中台建设的愿景是什么？

“遇事不决看愿景”，这是我在做中台规划和落地过程中，说得最多的一句话。

太多时候我们把解决方案和问题本身混为一谈。中台只是一个解决方案而已，但是很多时候我看到人们却把中台当成了问题本身，纠结于别人的中台都是什么样子，自己的中台该是个什么样子，而不是关注中台到底有没有解决该解决的问题，甚至希望中台解决什么问题还没有想清楚。

所以我经常被问到的也是，中台应该什么样？中台应该怎么建？而我一般会先反问一句：你建中台是为了解决什么问题呢？对于企业和业务又有什么价值？很多情况下，对方并不能清晰直接地回答，或是说了一堆像消除烟囱，移除孤岛等“大话”。在我看来，这就是还没有搞清楚中台建设的愿景。

中台就像一个产品一样，需要一个明确的愿景，要让所有人能够清晰明确地知道，中台建设对于企业对于业务的价值，从而可以一起始终向着同一个方向持续前进。如果愿景缺失，那我们就会很容易在中台建设过程中迷失自己的方向，失去定力。

愿景帮助我们了解自己中台建设的目标，帮助我们判断哪些事情是符合中台建设愿景的，作为中台团队我们需要去考虑。在这之外，更重要的是帮我们判断哪些事情不是中台要去做的，为中台做减法，这点在中台的建设过程中其实更加重要。

尤其是在中台建设初期，项目往往还处于试点的阶段，可支配的人员和资源不会特别多，如果没有自己的方向，就会陷入到上面小王所处的境地，把中台变成一个内部共享的外包团队。

所以在建设中台前，第一个要问自己的就是：我们建设中台，愿景是什么？而且更重要的是这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。

具体怎么做到呢？我们在实际的实施过程中，会有一些工具和实践，我会在后面讲中台设计的课程中再给你展开分享。

中台的用户和客户是谁？

这个问题也同样非常关键，因为中台是企业级的事情，必然会面对组织的问题以及庞杂的干系人问题。

再说得直白一些，就是中台的建设通常都会伴随企业内的组织重构以及利益和职责的再分配。如果没有搞清楚中台建设的各个干系方关系，必然在中台的建设过程中就会四面碰壁，陷入“干系人旋涡”之中，面临多方面的阻力，陷入一个非常被动的局面。

所以在中台建设之前，我们最好先搞清楚中台如果作为一款产品，它的用户是谁？客户又是谁？用户和客户是一个群体么？除了用户和客户还有哪些干系方？他们对于中台都有什么期望，这些期望又是否一致呢？

为了想清楚这个问题，我们可以把企业想象成一个家庭，具体到某一条业务线就像是家庭里的一个孩子，他关注的更多是我今天能不能多玩一会儿，也就是我们常说的短期的战术目标，回到企业里就是我这条业务线今年甚至这个月的 KPI 目标能否实现。

而企业管理层就像这个家庭的家长，他关注更多的是孩子的未来，高考的时候能不能多拼过几万个别人家的孩子，实现可持续发展，也就是我们常说的长期战略目标，关注的是未来五年，十年甚至是更长的时间企业会是什么样子。

而中台此时就像是一款 K12 的英语教育产品一样，那你思考一下，如果你是这款产品的产品经理，你会更关注谁呢？是作为产品实际用户的孩子的短期战术目标，让他玩得爽，甚至跟游戏一样？还是产品实际买单的人，也就是作为产品客户的家长的长期战略目标，甚至为了达到最好的效果，不惜牺牲孩子的用户体验？

这个例子里，根本的问题在于长期战略目标和短期战术目标的矛盾。答案其实也很简单：都要关注。我们需要找到企业管理层与业务线关注点的结合点，也就是长期战略价值和短期战术价值的结合点。

而且对于中台来讲，情况可能比上面提到的更复杂，他的干系方还不止是用户和客户这两方，因为其所处的特殊位置，干系方往往纷繁复杂。在保持自己方向的前提下，找到各方利益的结合点，是一件非常困难且有必要的事情。否则，在建设过程中就会受到各方的阻力，产生摩擦，导致中台很难推进落地。

但反过来讲，中台也不应该只是极力去满足各方的诉求，中台团队毕竟不是业务的外包团队。中台需要有自己的思想和规划，要能做到听得进别人的话，但是还要明确自己的目标，走自己的路。而自己的目标，就是来源于上面提到的中台建设愿景，而中台的愿景也往往来源于企业的战略需要。

所以，我常说，中台建设虽然需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。

想清楚这一点非常重要，因为下一个问题就跟这一点相关，就是中台的钱到底该由谁出？

中台的钱由谁出？

我们常说谈钱伤感情，也往往选择避而不谈。但是钱的问题往往是很多问题背后的本质，也是中台建设过程中很多矛盾的来源。

这里的钱说的比较白话，对于企业内部，可能代表的就是人和资源。所以，这个问题还可以引申到中台的人从哪来？从前台团队借调么？还是重新招聘新组建呢？一个中台建设往往会持续很长的时间，那这些人的成本又由谁来承担呢？如果说中台是为前台业务赋能的，是不是就应该从前台各业务的预算中划分出一部分作为中台的建设预算呢？

这些问题如果没有考虑清楚，也会给中台建设带来非常大的麻烦。

在我看来，市面上的中台建设，如果从投资结构来讲，基本上可以分为两种类型，即“众筹模式”和“投融资模式”。当然，我们还能看到这两种类型的混合模式。

先说“众筹模式”。相信你一看就明白，众筹模式就是用户预付款，生产方承诺一定时间后提供某一类型的产品。回到中台建设的背景下，就是从业务前台集资，有钱的捧个钱场没钱的碰个人场，能出预算的出预算，能出人的出人，来组建中台团队，然后再反过来服务于前台业务团队。

我在前面几讲中也提到过，中台是为前台业务而生，所以看起来前台出资源，中台为前台服务，拿人钱财替人消灾，天经地义。

其实这里隐藏着很大的问题，问题就出在了中台建设的愿景和中台的投资模式的匹配上。因为业务前台优先关注的是自己短期的实际问题，从原本就资源紧张的前台业务中，再划分一定的资源来搞中台建设，业务前台作为中台建设的实际出资方，前面讲了他也会更关注短期的战术目标，自然希望中台短期就可以见效果，帮助自己解决实际的问题。

如果中台的愿景就是为了解决业务方短期的问题，其实还好。但我看到的大多数中台建设的愿景都是企业战略层面的，都是为了企业长期的发展考虑而建设的。

这时候如果还是采用众筹模式，就会发现非常矛盾。企业管理层，往往也是中台的发起者，他关注的更多是长期的战略目标，中台团队需要听；但前台业务团队作为中台的实际出资方和使用方，即是用户也是客户，他关注的是相对短期的战术目标，需要短期就看到中台建设的成果对于业务的实际价值，中台团队更要听。这时候中台的团队就自然会被长期目标和短期目标相互拉扯，非常难受。

所以如果中台建设的愿景是解决企业长期战略的目标，那我建议尽量采用另外一种大家都比较熟悉的“投融资模式”，或者至少是投融资模式与众筹模式的组合模式。

投融资模式，顾名思义，就是一个产品的建设前期先由投资方出资，按照产品的建设目标经过一段时间的建设期，相对成熟之后，再逐渐地让用户使用，最终通过对于用户的服务，让用户满意，实现收入并收回企业投资且盈利的模式。目前大部分的创业公司都是采用类似的模式，相信你也很熟悉了。

那对于中台建设的投融资模式，就是中台建设的前期（从 0 到 1），不是直接从前台业务团队划出资源，而是由企业本身的战略储备资源投资建设。经过一定时间的建设期，比如 6 个月，然后逐渐找适合的前台业务进行试点接入，如果效果好的话再推广到更多的前台业务团队。当服务稳定之后，对前台也产生了稳定的价值之后，再逐渐从前台收取一定的资源，可以是人也可以是其他资源，既所谓的收回投资并实现盈利。这里的盈利只是个比喻，可能是满足了企业管理层对于企业战略目标的需求。

这种模式的好处是中台团队在中台的建设初期会有更多的自主权，在启动和脆弱期不会受到太多现有业务压力的影响，能更好地实现中台自己的建设愿景。但缺点是企业需要有较雄厚的战略资源支持，也需要有更大的战略决心。我看到很多互联网企业的中台建设，也往往都是采用类似的模式，所以在外界看来，他们的中台建设都非常直接且迅速。

所以如果你所在的企业建设中台的愿景，是为了解决偏短期战术层面的痛点和问题，可以采用众筹模式加演进式的投资结构来启动，这样的好处是中台的启动会比较平滑，资源利用率高，初期新增成本较低。但如果中台建设的目标是偏长期战略层面的问题，比如业务转型，那还是建议更多地考虑使用企业战略投资，使用投融资模式，这样更利于中台建设的健康快速发展。

中台的目标怎么验证？

还记得一开始提到的小王的故事么？中台建设的另外一个难点就在于对建设结果很难做量化度量。这点不像前台的业务线或是我们常见的 ToC 类型的产品，可以相对容易地找到一些量化指标来度量产品的成功与否，比如常见的用户数量，用户活跃度或是市场覆盖率等。

当然中台也可以说，前台之所以有这些成果，都是我中台的赋能效果，但是这往往很危险。因为我们拿不出详细的数据来证明这些用户、这些占有率里到底是有多少是因为中台建设的成果。相反，前台业务可能会说中台还拖了后腿，你看要不是前几天中台挂了两次，连累了我们前台业务，数字可能比现在还要好很多，等等。

你看，中台作为前台的服务者，不但无法分享业务成功的喜悦，反而很容易被甩锅成了背锅侠。

所以，以终为始，在建设前就应该思考如何验证和度量中台。通过提前考虑这个问题，让我们可以在建设的中后期规避一些扯皮和风险。

目前业界有一些中台的考核标准我们可以作为参考，例如阿里巴巴的中台考核就是设计成：40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度。

那我们自己的中台能不能简单复用人家的指标呢？答案肯定是否定的。中台建设的愿景不同，考核的方式和指标也自然不同。

比如回到极客地产的这个例子，中台建设的愿景是支持业务转型，支撑的是新的业务，那可能早期就没必要要求那么高的稳定性和接入量，可能只支撑一到两个新的业务线，更多看的是服务的满意度，或是其他指标。

具体到一家企业某个中台的验证指标设计，这是一个复杂过程，而且往往还会不断演进，需要结合上面提到的中台愿景、投资模式、干系人利益点以及其他相关因素来综合设计。我们用到的一些思路和想法，我会在中台的规划与设计篇再为你展开来讲。

最后，建议你不要等建设完了再去考虑如何度量的问题，尽量提前考虑甚至在建设之前就约定清楚，这样才能最大程度地帮助中台建设不走偏，不乱了阵脚。

中台规划建设方法论

中台规划建设方法论：D4 模型

之所以称之为 D4，主要是我们把中台从整体规划到落地交付的过程划分了四个不同的阶段，包含了两次发散与收敛的过程。

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

第二个阶段是Define，帮助我们基于之前 Discovery 发散的各维度信息进行收敛与分析，对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计。并基于多维度的打分，形成具体的实施路径规划，说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目，在这个阶段也可以回答那个我们关心的问题，我们到底需不需要中台，需要哪些中台？

第三个阶段是Design，帮助我们针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。例如对于业务中台产品，在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。

第四个阶段就是Delivery，这个时候我们就可以针对一个设计好的中台，开始具体的交付过程，我们采用的是敏捷结合精益软件开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。

整个 D4 过程，是一个从战略到落地，从企业架构到产品架构最终交付的过程。而且遵循敏捷与精益的思想，整个 D4 的过程也是不断迭代的，例如每一个季度到半年，我们可以重新做一次轻量的 Discovery 和 Define，来不断对企业架构做敏捷的调整，以应对市场和自身的变化和不确定性。

企业战略分解及现状调研（Discovery）

D4 的前两部分 Discovery 和 Define 合起来，就是一个在企业级先发散再收敛的过程。我们公司内部对这个过程有一个称呼，叫作 Portfolio Discovery，简称为 PD。实际实施时，PD 是一个 4～8 周的头脑风暴工作坊，下图为你展示了一个完整的 PD 工作坊路线图，帮助你理解。

对于中台的整体规划，也就是回答要不要建中台、建哪些中台、谁先建谁后建这些问题，我们现在也是通过 PD 这样一个过程来评估和判断的。那你可能会有疑问，为什么 PD 这样一个方法，可以帮助我们做中台的规划判断呢？这里我们先简单来说明一下

为什么用 PD 这样的方式规划中台？

Portfolio Discovery 翻译成中文就是投资组合规划，应用在企业里就相当于产品线规划。说得直白一些，就是假如我是一家公司的 CIO，今年手里有 1 个亿的可支配 IT 预算，我最关心的就是在接下来的一段时间（可能是 1 年，也可能是 3~5 年），为了企业发展的目标，

我需要花多少钱在数字化建设上？

这些钱该怎么花？怎么分配？要新增哪些系统，是购买还是自研？要干掉哪些系统？优化哪些系统？继续维护哪些系统？保持哪些系统不变？

要不要建个中台？

……

你看，说白了还是钱怎么花最值的问题，本质上也都是资源分配的问题，如何在资源有限的前提下找到最好的投资组合，或者说如何把钱花在最该花的地方上。

而建中台只不过是其中的一个潜在选项而已，潜在的解决方案之一，即基于企业的战略和现状，我们需要在应用架构中添加一个中台层来解决目前企业遇到的问题。

中台这种解决方案到底适合不适合企业，仍然是需要调研和判断的。所以，如果我们一开始就把中台作为一个确定的既定方向，难免会限制住我们的视野，有可能会错过比中台更好、更简单、更有效的解决方案，或是过早地进行过度设计，在根本不需要中台的场景下，大张旗鼓地开展中台建设，劳民伤财。

那企业到底要不要划分出一部分钱和资源来做中台建设？对公司来讲添加中台这样一个新的架构层次有什么价值？什么时候做最好？优先级怎么样？这也正是 PD 所主要关注和需要回答的问题。

而为了避免拍脑袋的情况出现，Discovery 作为 PD 的前半程，主要目的就是做充分的发散和调研，也就是利用各种工具和手段帮助我们充分了解行业趋势、竞争对手的情况、公司的战略分解以及自下而上的现状调研等信息和环境，为下一个阶段 Define 的收敛，也就是对于企业新的业务架构、应用架构、技术架构甚至是组织架构的设计，提供充分的信息支撑和依据。

整体上，Discovery 又可以简单分成由外到内、自上而下和自下而上的三个不同方向的过程。

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

所谓知己知彼百战不殆，在详细了解自身之前，我们有必要先将视野放开一些，看看行业的大趋势与竞争对手都在做些什么。

记得梁宁老师就曾经在得到专栏《产品思维 30 讲》中提过“点 - 线 - 面 - 体”的理论。如果说中台本身只是一个点，那它可能只是一家企业发展到一定阶段的产物，不是开始也肯定不是结束。所以，要从一家企业的发展过程这条主线上来看待中台这件事情，来看这个点。它从哪里来？为什么会出现？又将向哪儿去？甚至思考中台的下一个阶段会是什么？会被什么替代？我在观察一家企业的中台建设历程，包括整个中台大趋势的形成和发展的时候也是这样来看的。

有了线就足够了么？还不够，我们还需要再上升一个维度，来看看同一个行业中的其他线，也就是同一行业中的其他企业在做什么？战略都是什么？数字化建设的重点又是什么？有没有同时在做中台建设？建设的目标又是什么？效果怎么样？

但这里要注意的是，分析不一定就代表要直接借鉴，人家都在建中台我们就要建中台，这个思路不可取，因为即使处于同一个行业，但是由于企业愿景战略、商业模式、客户群体等差异，每家企业也都不尽相同。

最后还要跳出面，从更高的维度“体”，来审视企业所在的这个行业本身，或者从其他的行业，其他的面上来学习。而这么做一般会有两个好处：

一是如果其他面上有好的概念或是方法，我们可以借鉴过来，帮助自己的企业在自己的行业里取得先机。中台这个概念起始于互联网行业，目前就正在被各个行业参考和借鉴。

另一个好处，就是如果发现更好的面、更好的行业，能够实现企业跨行业的跃进，可能就抓住了走上另一个快车道的机会。话说回来，目前很多企业的中台建设，目的就是识别企业核心能力，沉淀到中台，并以此为跳板和支撑，进行业务的创新和探索，想要跳到另一个更有发展的全新赛道上。

说了那么多行业调研与竞争对手分析的好处，那具体怎么来做呢？其实业界已经有了很多非常成熟的方法，你可以直接使用，例如常见的：五力模型，SWOT，商业模式画布，竞争对手产品线分析，竞争态势分析矩阵等。

自上而下：企业战略分解

如果说 PD 最主要的一个产出物是数字化建设的蓝图和路线图，那 PD 的输入就是企业层面的愿景和战略。

我们之前关于愿景谈得比较多了，应该也比较容易理解，就是到达一定时间希望企业可以变成的样子或是达到的目标，例如对于极客地产这个例子，愿景可能就是 2022 年实现业务从重资产到轻资产的转型，更具体比如服务类业务占总收入的比例要达到 70% 以上。

在这里再多说一句，我们也确实见到过很多企业在并没有明确企业愿景的前提下，就开始了大范围、大规模的中台建设。这就像是舰队在还没有明确目的地的前提下，就贸然出海一样，很可能随波逐流，最后迷失在汪洋的海上，弹尽粮绝。所以如果一家企业是这样的情况，一定需要先补上这一部分的内容。

在这里呢，我们就先假设在开始规划中台前，企业就已经有了明确的愿景和战略作为 PD 的输入。

再来看战略这个词，我们理解起来可能就会觉得比较模糊和虚。在《论大战略》这本书中就提到：“所谓战略，就是如何达成目标与能力的平衡，并根据环境变换做出合适的调整”。

下面是我们经常用到的战略平衡三角形，可以帮助你理解战略这个相对较虚的概念。

通过这个战略平衡三角形，我们简单地做一些数学变换，就可以解释“企业战略分解”到底是什么了。下面这个推导过程，可能有些烧脑，如果一时理解不了可以多看几遍，相信会对你理解战略这个词有很大的帮助。

好，我们开始。依据战略平衡三角形，在企业的愿景和目标已经确定的情况下：

企业战略就可以简化理解成：结合企业自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？

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

好，推导完毕。而对于企业战略的分解，业界也有很多工具和实践，例如 BMGovernance 设计的企业战略分析模型等。但为了应对变化越来越快的市场环境，在 PD 中我们使用的是精益价值树（Lean Value Tree）的工具来帮助做战略愿景的分解的。

精益价值树是一种以价值成效为导向，用于分析和沟通业务愿景、战略与投资的工具。它的核心是建立从愿景、目标到投资举措自上而下的对齐，因此采用一种逐层分解的树形结构，如下示意图：

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

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

如果把企业战略分解理解成从企业愿景自上而下的分析推导过程，那是不是直接按照推导出的举措具体实施就可以了呢？

往往还是不够的，因为每家企业经过长时间在市场中的搏杀，能生存并发展到现在，都会出现各种各样的问题和限制。如果脱离现状，无视这些问题与限制，就肯定会面临非常大的阻力与风险。

所以我们不但要自上而下地做企业战略的分解，以此来帮助我们思考中台或是其他举措是否必要。同样需要充分地做自下而上的现状调研，来帮助我们了解现状和历史。一方面充分尊重过去遇到的所有问题，收集汇总痛点；另一方面又要求我们能跳出过去的限制，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的可能性。

这里我们常用的工具和实践也很多，例如高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理等等。

充分且多维度的现状调研与分析，不但能让我们对于业务、应用、技术、数据、组织现状，也就是企业架构现状有一个全面清晰的认识，还可以通过访谈与调研，补充时间线上的上下文，包括过去发生了什么？为什么现状是这样子的？未来大家希望是什么样的？为什么？

不过这里有一个问题你可能需要关注，那就是梳理的范围和深度。不要忘了我们此时做的是企业级的架构梳理，宽度和范围可能会远远超过我们的想象。如果深度控制不好，会发现转了半天还是在一个小的领域和业务线原地打转。

所以面对这种问题和风险，我建议你：

先完成自上而下的企业战略分解，再开展自下而上的现状调研。因为做完战略分解，我们已经对于公司的行业、业务、愿景、战略已经有了一些了解，再开展调研的时候就会有个全局的把控，对于粒度和深度都更容易拿捏。

做好充分的准备，能够提前通过阅读资料和小范围调研完成的内容就提前完成。

制定详细的计划，可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够，可以用两天的时间梳理一条业务线的业务架构，这样梳理就可以深入一些。但如果只有半天，则粒度可以适当放粗，先保证有一个全局业务视图。

建议刚开始做的时候，可以粒度粗一些，不要过早陷入细节，不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解，也是最见功夫的地方。在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。

这样的现状调研工作，对于一个中型的有四五条不同业务线的企业，我们实际实施大概需要 2～4 周左右的时间，当然还要视客户而定。完成调研工作后，我们就对企业各方面的现状有了一个比较全面的了解，并且也收集到了每条业务线大量的痛点和问题，这样就有了对未来架构的展望。

企业数字化全景规划（Define）

企业级架构方法

企业架构方法如 Zachman、TOGAF 等，最长的已经有 20 多年的历史了，可以说已经非常成熟了。其中应用最广的应该就属 TOGAF 了，在市场上占据了至少半壁江山，也最为我们所了解。TOGAF 的基本思路，就是从企业最新的愿景战略以及运营模式出发，设计企业的 To-Be 业务架构，然后依次推导，一步一步推导数据架构、应用架构、技术架构，就是这样一个过程。

我们现在在做以中台为潜在预设目标的企业数字化全景规划时，也参考了 TOGAF 的这个思路，基于 Discovery 发散收集来的各个维度的信息，在 Define 阶段结合自上而下企业战略分解的举措和自下而上现有业务架构梳理和分析的问题及痛点，重新设计新的业务架构，并进一步推导出其它的相关的架构设计。

只不过相对于传统的企业架构方法，整个过程做了剪裁和轻量化处理，引入了事件风暴、DDD 工作坊等协作互动形式，整个过程各个关键角色充分讨论，协作共创，力争在过程的轻量前提下，还能保证结果的准确与一致。

但这里有一个关键点，因为前面提到过中台从架构层面就是平台型的企业架构，那对比过去我们常做的系统型企业架构，如何从企业整体的视角，更准确地识别出多业务线之间的共性业务元素，对我们来讲也是个不小的新挑战。

为了解决这个问题，前面讲方法论概述的时候其实已经提到过，我们是在整个企业架构设计的过程中融入了领域驱动设计（DDD），结合事件风暴，对业务流程背后的问题域进行分析，以及通过不同业务线的问题域重合度分析，帮助我们透过流程洞见企业各业务的本质，寻找共性业务元素。

给这个过程做个比喻，就像是给业务照了一个 B 超一样，帮助我们更好地透过现象看到内在的实质。

对于企业架构方法，例如 TOGAF 的相关资料比较多，这里就不展开了，我在最后的总结里会给你一些参考资料，你可以进一步拓展阅读。

那利用剩下的篇幅，我想着重讲一些在企业架构设计实施过程中与中台相关的常见问题。

中台复用的能力类型到底有几种？

第一个问题，如果说中台就是企业级能力复用平台，那在做企业架构设计的过程中：

我们到底要在不同业务线中寻找哪几类共性能力？

我们经常讲的业务中台中的业务到底又具体指的是什么呢？

那为什么中台一般都是业务、数据、技术这三者的组合呢？

为了回答这几个问题，先来给你看一个模型：

这是哈佛大学出版社 2006 年出版的一本讲企业架构战略的书里提到的一个商业运营模型（Business Operating Model），它提出两个象限：

横轴代表标准化（Standardization），标准化越高，你可以简单理解成企业就是通过业务模式（业务功能 + 业务流程）的复用实现业务线的扩展。比如像电商网站的各个垂直网站，或是全球化，都是通过将电商的业务模式复用，通过复用到不同的垂直领域，或是不同的地区来实现不同业务线的扩展。

纵轴代表集成（Integration），也可以理解成数据集成，这种运营模式的企业就是通过对数据的复用，来实现业务线的扩展的。比如最常见的像腾讯，通过对微信用户数据的集成和复用（导流），来帮助新的业务线（例如游戏）快速扩展。

那为什么要提到这个模型呢，因为这里的“商业运营模型”就很像我们中台里的能力复用方式，即你复用的到底是业务模式；还是复用的是业务数据；还是两者都不是，只是复用了更底层的技术部分。

如果两条业务线，数据也是一套，业务流程也一模一样，那很简单，它们其实就可以共用一套系统，这也就是我们最常见的大单体系统。但这越来越成为一个反模式，除非在一些标准化极高的场景，例如核心财务系统。

如果两个不同的业务线之间，业务模式很相似，但是数据反而需要隔离开，那就是右下的区域。一般可以通过业务中台来沉淀通用抽象的业务流程，或者直接使用多租户的企业内部 SaaS 来实现业务模式的复用。在这个象限，业务中台与 SaaS 的区别只是抽象粒度和层次的不同，本质上要解决的问题都是一样的，即业务模式复用。

SaaS 抽象层次高，更靠近业务，但对于业务的标准化要求高，灵活度小。业务中台正好反之，抽象层次较 SaaS 低，介于 PaaS 和 SaaS 之间（所以很多企业管业务中台叫 ApplicationPaaS，或是 BussinessPaaS），离业务较 SaaS 远一些，但更灵活。这也回答了很多人困扰的业务中台与 SaaS 的区别问题。

这里可以多说一句，国外最近出现了一种 Headless Commerce（无头电商），去年也出现过 Headless CMS。我认为这波国外 Headless 的趋势，就很像是国内的中台一样，也是在 PaaS 和 SaaS 之间在找到一个新的抽象层次而已。

好，说完了右下，再来说左上，指的是那些虽然业务模式不同，但是可以通过数据的集成、打通与复用来实现业务线扩展的场景，一般也可以通过业务中台和数据中台来解决。因为业务中台里承载的也有数据，或是说业务中台生产的就是业务数据。

而前面提到过，数据中台则是对于业务中台生产的数据，进行二次加工，例如一些大数据计算、跨域的业务数据整合计算或是一些 AI 赋能场景。

好了，希望通过上述的分析，能帮你理解这些不同中台（包括业务中台，数据中台，技术中台，以及业务中台与 SaaS，业务中台与数据中台）的概念和差别。

而回到一开始的问题，我们到底要在不同业务线中寻找哪几类共性能力？现在也非常清晰了，总结下来基本上就是四类：业务数据、业务功能、业务流程以及通用的技术能力。

通过领域分析识别共性能力

既然企业可复用的能力就是以上这四大类，那抛开相对独立的技术能力不谈，对于剩下的业务数据、业务功能和业务流程三类共性业务能力，具体来说，我们要如何识别呢？

还是举极客地产的例子，对于物业业务线和长租公寓业务线这两条业务线，表面上看起来解决的是完全不同的问题。但是这并不能代表这两条业务线之间没有业务数据、业务功能或是业务流程复用的场景呀，比如最直接的就是打通连接物业的业主数据和长租公寓的用户数据，通过例如最简单的积分机制共享，来实现物业业主向长租公寓用户的转化，实现用户的导流和新业务热启动，加速新兴业务的快速发展。

那到底怎么才能透过业务流程识别出有哪些类似的能力复用场景呢？没错，就是领域驱动设计（DDD）。

我们就是对于已经梳理的业务，又深入了一层，使用领域驱动设计结合事件风暴（EventStorming）这两个工具，通过工作坊的形式来对业务流程背后的问题空间和解空间做进一步的分析，识别出关键聚合，再通过跨业务线的问题域叠加投影，找出大家共同关注的问题空间和聚合，从而继续扩展来做共性场景和能力识别。

而整个过程也是采用头脑风暴和工作坊的形式。

中台与微服务有什么区别和联系?

说完了业务，我们再来谈谈在技术架构设计中，大家最关心也是同样感到困扰的另外一个问题，就是业务中台与微服务架构有什么关系？这也是谈及中台时经常会被问到的问题，至少能排到 Top5 里，正好讲到技术架构部分，我稍微谈一下我的理解。

先给出我的答案：这俩没关系！

是不是有点反直觉，毕竟这两个概念经常被一起提，很多讲业务中台的书讲到技术架构也都在讲微服务，你怎么说这俩没关系呢？

别急，且听我慢慢道来。

总的来说，业务中台与微服务解决的是不同的问题，也处于不同的抽象层次。

前面提到了业务中台解决的是业务领域的业务（数据、功能、流程）复用的问题，而微服务架构作为一种轻量级分布式技术架构，解决的是技术领域的“组件编译时依赖”造成的问题。

而且业务中台不一定是微服务架构的，微服务架构也不一定是为了解决能力复用的问题。

首先来看业务中台。业务中台要解决的是业务能力如何快速复用的问题，就算背后是一个大单体，只要暴露出来的 API 能够满足业务能力快速复用的目的也是可以的。这个很容易理解，那我就着重解释一下我对于微服务架构的看法。

提到微服务，不得不说目前被业界普遍接受并采用的我司首席科学家 Martin Fowler 给微服务下的定义：

这里边有个关键点，我认为没有引起大家足够的重视，以致于我认为目前市面上绝大多数的号称微服务架构的系统从老马的定义上来看，都是伪微服务架构。这个关键点就是“能够被独立地部署”，我认为翻译成“能够被独立地交付”更贴切，而这点也是我认为评判一个微服务架构是否能发挥其价值的关键因素。

这也是我前边提到的“组件编译时依赖”的问题。其实组件化一直是大家都追求的，例如我们常见的 jar 包和各种开源的组件本身就是很好的组件化封装。微服务从技术上看无非是将组件间的依赖点从“编译时”推后到了“运行时”而已。

不要小看这一点变化，带来的好处是非常多的。因为依赖被推迟到了“运行时”，才可能实现类似于“组件独立交付”、“组件运行时动态扩展”、“组件技术异构”等好处，但同样也需要承担分布式架构带来的复杂度作为代价。

那为什么说大多数的微服务架构都是伪的呢？因为有集成测试或其他因素存在，导致实际上并没有做到真正的独立交付（注意不是部署）

还有微服务架构要想真正发挥价值，主要一点就是其中的“服务”要做到足够稳定（说来容易做起来具难）。

所以，业务中台与微服务架构并没有啥直接关系，只是因为微服务架构运行时依赖的低耦合特性，通常被用于实现业务中台中不同能力单元的团队分离、技术分离、交付周期分离等特性而已，只能算是一对好搭档。

平台型企业架构设计概览

最后我们还是快速过一遍，一个完整的平台型企业架构的规划过程。

1. 首先通过各条业务线的现有业务架构分析，再结合识别的痛点做的根因分析，做业务架构上的改进与设计，从而对于现有的业务架构进行改进，设计出新的改进后的业务架构，解决现在痛点背后的问题。

2. 同时还要参考战略分解后对于各条业务线的目标和举措，融入 To-Be 业务架构的设计当中，使新的业务架构设计同时匹配企业战略要求以及解决短期战术痛点。

3. 对于改进后的业务架构，做跨业务线的比对和分析，就能帮助我们发现不同业务线的业务功能及业务流程的重叠情况，为后续中台建设的必要性判断提供业务层面上的支撑和输入。

4. 使用领域驱动设计（DDD）的战略部分，针对于每条业务线，做问题域和限界上下文分析，以及关键聚合的识别，从而试图穿越流程，从领域的角度深入一层审视业务的本质，到底是在解决哪些问题空间的问题，并通过问题域的划分（核心、通用、支撑），区分问题空间对于企业的重要性。

5. 类似于业务架构，同样对于各条业务线分析出来的领域分析视图，做横向比对和投影，从领域层识别不同的业务线中的问题域、限界上下文以及聚合的重合度。这么可能比较抽象，你可以理解成类似于将几张半透明的画摞在一起，来找相交部分一样。帮助我们识别业务数据以及业务模式（功能 + 流程）上的深层次共性能力。

6. 结合现有的业务架构及应用架构，做各条线的应用架构设计改进，并通过 As-is 和 To-Be 的应用架构做 Gap 分析，产出 IT 建设的具体机会点，这样的机会点就类似于新建一个 CRM 系统之类的。

7. 再基于跨域的业务架构分析和跨域的领域分析，讨论判断多条业务线的业务重合度，并详细识别重合更多是在业务模式级别的重合（出行、电商）、业务功能级别的重合（登录，购物车）、还是业务领域（用户数据打通）级别的重合。基于讨论结果，决定是否有必要引入中台层建设，以及根据重合情况，详细展开规划中台层的应用架构。

8. 最后再分析当前现状与 To-Be 的最终规划之间的差距，产出具体的机会点列表，并且基于多维度（常见的例如战略重要性、紧急程度、成本、资源就绪情况、技术就绪情况、风险、痛点 Mapping 等）做优先级排序，产生最终的路线图。

中台的规划与设计（Design）

确定中台产品愿景

讲到现在，你肯定知道了，第一步还是要先搞清楚这个业务中台的愿景和目标，因为这是我们整个中台建设过程的基础，也是中台建设的初心。

还记得我们之前提到过的么，中台的建设就是一条布满荆棘之路，充满曲折。在过程中我们会遇到各种各样的问题与选择。而一个好的中台愿景能让我们始终保持初心，不轻易迷失方向。

那如何来为中台制定一个好的愿景呢？我一般到一个企业去做中台相关的咨询时，我问对方中台建设负责人的第一个问题都是：你们说要做中台，那中台建设的愿景是什么？

我得到的大多数都是肯定的回答，毕竟没有谁会承认自己的项目连个目标和愿景都没有。但是一旦追问到愿景具体是什么的时候，一般就会开始一段漫长的讲述，从公司的历史到现状、从行业聊到企业管理层最近的讲话，总之我总结下来就是：领导说要做中台，我们做就是了。

我认为这样是比较危险的。毕竟我们前面提到过，中台的愿景作为所有问题的出发点，需要足够简单明确，才能做到像一个指南针一样，成为我们中台建设过程中指引方向的工具，也才能做到前面提到过的“遇事不决看愿景”。

这里推荐给你一个简单好用的工具，我们经常用这个工具来帮我们发散和收敛产品的愿景，当然对于中台也是同样适用的，就是电梯演讲（Elevator Pitch）。

顾名思义，电梯演讲假设的场景，就是我们在电梯上偶遇公司管理层，能否在有限的时间内给对方讲清楚我们在做的事情，比如中台。这就要求我们做到足够的收敛。因此电梯演讲的形式，主要是限定了几个产品最关键因素，比如用户是谁，解决什么问题，差异化特点是什么等等。其中每一个要素都非常重要，如果你回答不出来，或是团队的回答不一样，就在一定程度上体现出大家对于中台建设的愿景还没有达成一致，也就为后续各种问题的出现埋下了祸根。

你不要小看这么一个小小的电梯演讲，感觉只要回答几个问题就可以了。从我实际的经验来看，每次规划中台产品愿景的讨论都会超时，一开始觉得可能这么简单的事情，一个小时就能搞定了，后来因为讨论过于激烈，时间拓展到半天时间，到现在我们一般都会预留半天甚至是一整天的时间，来做中台产品愿景的充分发散和收敛。

但即使我们花了这么多的时间，我仍然认为这是十分有必要的。在愿景的讨论上花再多的时间也是值得的，因为这会影响我们中台设计与建设的后续走向，一旦形成，也就会成为我们中台建设的基础，这一步的重要性怎么渲染也不为过。

这里有一个问题，还是要提一下，愿景的价值和难点就在于充分收敛。但我见过很多企业的愿景虽然也用了电梯演讲的方式，但是结果满满地铺了一面墙，看着虽然震撼，但是其实效果是大打折扣的，毕竟我们也没法在一个电梯时间复述完一整面墙的内容。还是那句话，做加法易，做减法难。

确定业务梳理范围

中台产品的愿景确定后，下一步就需要进行细粒度的业务架构梳理，抽取共性，识别中台产品的具体需求了。

但是，同样是企业级的原因，此时我们面对的问题往往就是不知道该从哪里下手。毕竟中台有企业级属性，就算是业务梳理也会涉及到企业的全业务线，而且是端到端全流程的梳理工作，工作量之大也往往让人望而却步。

是不是所有的业务线都要梳理？是不是端到端的所有阶段都要梳理？业务梳理要到什么样的粒度？这些都是经常面对的问题。

一般到这里，不同企业的情况就不一样了。如果公司整体规模不是特别大，其实做全业务端到端的业务梳理也是可以的，而这样的好处也是比较全面不容易出现遗漏，对于企业的业务现状能有一个整体的全貌，识别的中台共性需求也会比较准确。

但是很多企业，尤其是中台诉求最高的往往是一些多业务线的大型集团型企业。对于这种规模的企业，做全业务的端到端梳理基本上是不可能的，要不然仅仅是协调人员就是一个麻烦的问题。这时候我们就需要先确定一个范围，再在这个范围内进行业务的梳理和展开。

那这个范围该如何划定呢？还是那句，遇事不决看愿景，这时候我们前面讨论的中台愿景就有用武之地了。

还用极客地产为例，中台建设的愿景是希望通过将成熟业务的能力进行沉淀，并复用到其他新型的轻资产业务线例如长租公寓业务中，通过能力的复用快速实现业务的轻量化转型（具体的电梯演讲这里就不展开了）。

而目前的情况是，极客地产专注于服务 IT 群体，地产和物业业务发展成熟，有了非常健全的 IT 基础设施。现在针对这一人群挖掘出了很强的长租公寓需求，但是长租公寓作为新的业务线，无论是从投资拓展、设计、招标采购、工程建设、装修改造、客户管理到物业运营等等，这些方面都是从零开始。

回到业务梳理范围的问题上，有了清晰的愿景，就可以让我们的业务梳理更加聚焦。

首先从业务线上来看，就不一定所有的业务线都需要梳理。还是看极客地产这个例子，旗下涉猎广泛，还有业务线专注在投资、文化和教育等方面，因为这些业务线都是长期独立发展，与前面提到的极客地产中台产品的愿景目标也没有太大的直接关系，所以可以先直接跳过。

然后就是从端到端的业务价值链上。通过分析，由于企业的战略是轻资产服务化，所以对于像地产行业的工程建设，也就是盖楼盖房的部分，与企业基于轻资产战略投注的新业务都不适用，所以也不需要再进行梳理。

至此，基于中台的建设愿景，我们就可以在横向端到端价值链和纵向的业务线上收敛到一个聚焦的区域。

再在这个聚焦的区域中进行业务梳理和展开，就会更加有效率和聚焦。

细粒度业务梳理

在确定了梳理范围之后，接下来就是具体的业务梳理工作了。

一般大家的做法都是基于现有的流程或系统，对现有业务的流程进行梳理，例如在电子商务领域大家经常提到的四流，具体指的是信息流、商流、资金流、物流的梳理工作，使用的工具也大多是流程图这种非常成熟的工具。

但是这种基于已有流程的梳理有时候会有一些限制，简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。什么意思呢？就是对于一些长期且成熟的业务，现有的业务方式可能并不是一个最好的方式，而是由于长时间发展以及和过去的各种周边限制以及 IT 限制妥协的产物。

举个例子，往往时间比较长的业务线都会有非常复杂的审批审核流程。但是审核和审批流程其实只是一种解决方案，要解决的问题可能是过程造假或是其他的一些内部风险和问题。复杂的审批流程也往往是信息化时代甚至是更早的纸质时代的过程管控的产物，由于信息化更多只是将线下的流程线上化，所以一直延续至今，而且为了高度复刻还原纸质时代的流程，还非常中国特色地出现了各种的奇怪的审批逻辑，例如会签等等。

但是如果我们重新回到问题域，重新思考问题本身，我们就发现可能在当今这个数字化的时代，在大数据和 AI 已经广泛应用的今天，甚至可能不再需要流程审批这样一个过程。通过新的技术，我们可以用实时的审计分析或是风险识别来发现业务过程中的一些异常，甚至通过完全的自动化，消除中间人员参与的环节，从根本上解决这些问题，从而真正发挥数字化的威力。

这种回到问题域本身，回到问题的原点，基于用户需求在当前的业务及技术条件下，重新设计解决方案的思维方法，可以避开上面提到的业务债陷阱，也多用于创新型业务的设计过程，而这种思维方式也大量参考和借鉴了设计思维（Design Thinking）的方法。

所以和基于现状的传统业务流程梳理不同，我们在业务梳理过程中大量地采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理，从效果上来看也是非常不错的。

当然不是说哪种方法更好，不同的工具和方法有不同的适用场景和优劣势，如果都能灵活掌握，甚至可以结合使用，充分发挥出各自的优势。

通过范围内的业务架构梳理，再结合最后的跨场景通用能力的分析，我们就可以对关注领域的业务全貌有了一定深入的了解，并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台的具体需求。对于这些需求，我们是通过用户故事（User Story）的方式描述的。

确定 MVP

通过业务梳理，我们识别和整理了大量的业务中台需求。值得注意的是，此时的所谓中台产品需求，更多的是来源于定性抽象，再考虑到中台的需求往往不像前台业务系统的需求那样明确，所以，从严格意义上来讲，此时的需求仍属于一系列高风险的假设。

从我实际参与的中台建设项目来看，往往这些一开始设想的中台需求，到真正开发完成之后，都与最初的设想有很大的偏差。这就意味着，中台建设的周期越长，需求假设的风险和需要为之付出的代价就越大。

所以，我们在中台的建设过程中，引入了精益创业中的MVP 原则（Minimum Viable Product，最小可用品），也实现了我之前提到的整体原则中的 Start Small。

为了实现 MVP，保证做出来的 MVP 可用，我们在业务需求上采用端到端纵向切分的方式，结合需求优先级的多维度评分排序，最终确定 MVP 的需求范围，而最终落地的形式可能就是第一个迭代的用户故事列表。

那已经有了具体的用户故事列表，是不是我们就可以开始着手开发了呢。先别急，有两个事情，我们建议在开始中台建设之前就需要考虑，那就是运营计划和度量指标。

运营前置：制定迭代计划及接入计划

首先我们来看看运营计划。对于中台可能就是中台产品推广、前台（用户）接入计划以及接入后的运营支持。

我过去看到的情况是，中台建设的中后期才开始考虑这些问题，往往就有些晚了。而且很多情况下，前台是不会停下来等中台建设完，等接入后再开始自己的业务演进，所以往往都是前中台并行。

这个过程就很像是我们开发中的分支开发一样，修改的又是同一块内容，所以当合并的时候就会非常痛苦。

所以提前考量运营计划尤其是接入计划，尽量使用合理的接入计划（我看到有很多企业把这个接入计划叫作上车计划，非常形象）来规避一些风险，对于中台产品的建设也非常关键。具体的运营策略，在下一篇中讲为你展开介绍。

度量前置：定义验证指标

另一个需要在中台产品建设开始之前就要想清楚的就是度量指标。这一点，不知道你是否还记得，我们在之前讲中台建设前需要想清楚的四个问题时，已经讲到过了。具体为什么需要将度量指标设计前置到开发之前，之前已经阐述过了，在这里我就为你分享一些度量指标的设计思路。

首先，我们先来看看一般我们常用的有哪些指标。我把市面上最常见到的产品度量指标，分为了四个大类，也就是战略类、用户类、市场拓展类与降本提效类。基于每一个维度展开，都能找到很多的常用度量指标。

而对于中台来讲，难就难在与市场和用户之间还隔着一层前台，所以在度量上就不如直接接触用户的前台系统这么清晰。但是我们讲中台是为前台业务赋能的，又不能脱离开业务，单纯只在技术上做一些度量，例如接口稳定性和接口数量等，这样也不符合中台对于业务支撑赋能的定位和价值。

所以我们一般在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果。这里要强调一下，虽然维度和视角不同，我们要保证所有指标体现的中台建设目标必须是一个。

而具体到实施方法，因为每一个中台产品都是不一样的，所以很难给一个标准的答案。在实操过程中，建议你多换位思考，多问几个“怎么（How）”。相信你比较熟悉 5Why 分析法，这里我们可以稍微改一下，用5How来驱动验证指标的设计。

举个例子，如果我站公司管理层的视角：

那我怎么判断中台建设的成果？如果回答是看对于新业务的赋能，

那我怎么验证对于新业务的赋能效果？如果回答是看新业务的上线速度，

那我怎么验证新业务的上线速度？如果回答是看新业务从立项到上线的时间，

那我怎么验证……

你看，大家经常会说度量比较难，其实每个人心里都有一杆秤，只不过我们没有把这个秤清晰地表达出来。通过 5How，我们可以不断追问，将每个人心中的这杆秤发掘出来，来更好地指导我们中台产品的建设和推进。

中台的建设与接入（Delivery）

接下来就进入了 D4 的第四个阶段，也就是最后一个但可能也是时间最长的交付阶段了。

而交付的第一步一定是要组建一支有战斗力的队伍，中台的建设需要的能力与传统产品还是有比较大的差别。给你分享一个孙志岗老师的中台人员能力模型，我认为非常有启发，希望也能帮助你理解中台对于团队能力的要求。这个模型孙老师写过一篇文章，文章中还提到了中台建设过程中一些难点，我会把文章统一放到最后一篇总结中作为扩展阅读推荐给你。

模型中的“爱多思”指的是网易教育中台。

当组建了一支成型的中台建设团队之后，其实后续的建设工作就和我们一般的项目或产品的建设过程类似了。但是因为中台所处的特殊位置，对产品界定要求和对建模的难度，都比其他终端产品的复杂度要高一个级别，所以我们建议采用精益的产品研发流程，保持小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证中台建设是一个持续演进和被业务驱动的过程。

精益产品研发流程

这里叫精益产品研发流程，主要是面对中台建设过程中的不确定性，引入精益思想来实现价值的定义和快速流动及度量，再结合敏捷开发实践，让整个软件开发过程轻量、迅速、敏捷、价值驱动。

精益这个词相信你应该并不陌生，上一讲我们讲到的 MVP 就来自于精益创业。市面上大家还经常提到精益软件开发、精益生产制造等等，本质上都是将精益思想作用于某一个垂直领域的成果。

精益思想之所以流行，关键在于其定义了一套完整的思想框架，而最终核心目标就是消除浪费、创造价值。在中台的实际建设过程中，我们也建议引入精益思想，结合到软件的开发过程中，小批量快速开发产品，快速引入度量，基于测量的数据快速对于之前的需求假设进行验证和认知，并基于此做快速的调整。

这里你可能会有个疑问，敏捷和精益到底有什么区别？

其实精益和敏捷现在确实是常常掺在一起来讲的，我发现很多时候大家并没有搞清楚两者的区别。简单来讲，敏捷关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值；而精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点。

我们发现，由于中台建设的复杂度非常高，所以将精益思想结合敏捷思想应用到中台的建设和开发过程，再配合后边马上会谈到的中台运营机制的建立，可以让我们更好地应对中台建设过程中的各种问题，例如最经典的中台边界界定问题。

至于我们具体的做法，你可以参考下图，其中涉及的工具和实践都是比较成熟了，这里就不做展开了。其中最主要的就是通过数据运营，也就是基于度量指标的持续验证，来对之前做的需求价值假设做快速验证，并且不断调整，在精益思想中就叫尽善尽美。而团队要做的就是不断地加速这个反馈环路的运转速度。速度越快，我们应对不确定性的能力就越强，交付中台产品价值的能力也就越强。

当然整个过程是一个复杂的系统性工程，一般都会涉及到像云化工程，微服务及服务化能力构建，Devops 相关能力构建，数据运营能力构建，敏捷精益过程改进，遗留系统服务化改造，架构守护与演进，以及与中台相关的治理与运营架构构建等工程。

中台的运营、治理与演进

除了中台的建设过程，同样不能忽视的就是对于中台建设过程中的持续治理及演进，以及真正接入了前台之后对于中台的运营管理。

目前市面上我们碰到的很多中台建设过程中的困难和问题，在我看来都是没有做好中台的治理与运营导致的。对于中台的整体治理和运营机制，目前业界的理解也不太一致，毕竟中台作为一个企业的平台类产品，服务的不是企业的最终用户，所以和互联网里经常提到的基于产品的用户侧运营还不太一样，中台在位置上更像是企业内部的一个服务企业前台应用的 ToB 产品。

而对于企业内部的 toB 平台类产品如何做运营，也是目前业界比较关注的点。今天我就讲几点我认为比较关键的部分，注意这几个问题，能让我们在中台建设过程中少走一些弯路，少遇到一些坑。

而第一步要搞清楚的，就是中台产品的用户划分。

看到这里相信你肯定会疑惑，中台作为企业内部的平台类产品，所有的前台都应该是中台的潜在用户，尤其又都是自己企业内部的兄弟部门，为什么还要为前台用户做划分呢？

这就是有意思的地方，也是我在过去中台建设过程中吸取的教训。一开始我们在中台建设过程中，也并没有对于前台做任何划分，一视同仁、平等对待。

但是中台作为一个公共服务部门，一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况，甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。而中台的资源有限，且有自己的愿景，不可能无条件地满足所有前台用户的诉求，往往就会陷入疲于应对的状态，对前台的响应和服务质量也会急速降低。

怎么办呢？问题的根本在于，虽然我们说中台是企业级能力复用平台，但我们经常会忽略的一点就是，如果我们采用产品化的思维来构建中台，那中台中所沉淀的能力并不是产品的全部，还需要再加上 NFR（非功能性需求）或是我们常说 SLA（Service-Level Agreement，服务等级协议）才是产品，因为不同的前台用户之间，不只是对于中台产品的功能本身有着不同的诉求，同样对于 NFR 或是 SLA 也有着不同的诉求。简单举个例子，比如核心业务对于中台的 SLA 稳定性的要求可能是 5 个 9，性能是 5 毫秒；而一个新的创新型应用，可能还没有用户，就不需要有这么高的要求。

Offering = Capability + SLA/NFR

既然如此，如何利用有限的资源，服务好不同用户的不同诉求呢？答案就是对于前台用户基于需要的能力和 NFR/SLA 做用户划分。这听起来可能会觉得有些新鲜，但是其实环顾一下我们周围，很多的产品都是这样来处理用户划分，从而实现用户的分层响应与运营的。

而最常见的就是三层用户划分机制（3 tiers customer segmentation）。通过对于前台用户的分层，我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源（人或钱），甚至前台与中台可以通过签署 SLA 来实现对于前台用户的服务承诺。

举个例子，当我们开始中台建设时，可以只找到一个或是两个种子用户，作为 Tier1 级别的用户来服务。对于这个种子用户的需求作为最高优先级的需求来对待，并建立例行的沟通机制和服务响应机制。因为此时的服务还处于初建时期，还不是特别的成熟，所以可以采用“免费”的方式动用企业的战略资源来进行建设。这样，对于前台用户来讲，资源是免费的，而且是一对一式服务，自然也会乐意配合到中台的建设过程中。

当中台建设到一定阶段之后，对于种子用户的服务已经接近稳定，有了一定的能力沉淀，也能释放出一定的资源了，就可以利用释放出来的资源开始为 Tier3 层的用户构建自助服务控制台（Self-Service Console），并着手构建中台产品的运营团队，制定 Tier3 层的 NFR/SLA。在很多互联网企业，这个过程常常由于做出来的自助服务控制台比较粗糙，看起来也像是对于平台服务的增强和可用性优化和治理的过程，大多数就是一个白屏幕，加一些的配置选项，所以常被称为“平台的白屏化”。

当中台的自助服务控制台创建完成，Tier3 层次的 SLA 也构建完成后，我们就可以重新签订 SLA，将之前的 Tier1 用户迁移到 Tier3 层次，即完成之前种子用户从定制化服务到自助式服务的迁移过程，从而释放出更多的资源用于接入新的前台用户。

如果由于种种原因，无法一步到位实现服务的完全自助化，还可以通过构建 Tier2 层的 SLA，也可以通过重新签订 SLA，将之前的 Tier1 用户迁移到 Tier2 层次，通过“自助 +VIP 服务”的方式，保持对前期种子用户服务连贯性的同时释放出尽可能多的资源。

此时我们就已经有了三层的用户划分机制，可以在企业内更大范围地发布 Tier3 的自助式服务，通过这种方式实现更多用户的接入。同时，因为已经释放出一些中台的资源，我们就可以继续选取下一个关键的种子用户（一般是关键业务），作为新的 Tier1 级用户开始第二轮中台建设的推进。

至此，通过中台的用户分层和运营机制，就可以构建不同层次的运营体系，从而实现资源的合理调配。我们也就避开了前面提到的中台建设过程中的各种问题和陷阱，对用户分级运营，从而解决需求矛盾、排期冲突、资源紧张、推广缓慢等问题。