中台技术学习笔记

近来被困家中，学习了一下中台技术。在极客时间买了个课程《说透中台》，2020-02-17一天学完，感觉还是不甚了了。照例做了一点学习记录，收获就是知道了几个名词，不至于被人说懵。

中台技术学习笔记

1中台概念

1.1定义：前台-后台-中台

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

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

中台：企业级能力复用平台。

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

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

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

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

 

企业级定义了中台的范围。企业级更多代表的是中台处理的问题在企业级别，即至少包含多条业务线或服务多个前台产品（团队）

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

复用定义了中台的核心价值，也承载了上面讲到的从平台化到中台化的演进过程。

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

 

原因：

企业在平台化的过程中，为了能不断地给前台业务提供更好的服务，来支撑企业对于用户的持续响应，增加企业的用户响应力，企业需要构建自己的中台。

 

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

 

1. 在建设中台前，第一个要问自己的就是：我们建设中台，愿景是什么？而且更重要的是这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。
2. 中台的用户和客户是谁？用户一般只前台业务人员（孩子），客户一般指企业管理层（家长）。中台建设虽然需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。
3. 中台的钱由谁出？市面上的中台建设，如果从投资结构来讲，基本上可以分为两种类型，即“众筹模式”和“投融资模式”。

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

中台建设的投融资模式，就是中台建设的前期（从 0 到 1），不是直接从前台业务团队划出资源，而是由企业本身的战略储备资源投资建设。经过一定时间的建设期，比如 6 个月，然后逐渐找适合的前台业务进行试点接入，如果效果好的话再推广到更多的前台业务团队。当服务稳定之后，对前台也产生了稳定的价值之后，再逐渐从前台收取一定的资源。所以如果你所在的企业建设中台的愿景，是为了解决偏短期战术层面的痛点和问题，可以采用众筹模式加演进式的投资结构来启动，这样的好处是中台的启动会比较平滑，资源利用率高，初期新增成本较低。但如果中台建设的目标是偏长期战略层面的问题，比如业务转型，那还是建议更多地考虑使用企业战略投资，使用投融资模式，这样更利于中台建设的健康快速发展。

1. 中台的目标怎么验证？

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

1.3中台规划D4方法论

中台这种平台型的企业架构时会有很多力不从心的方面，例如：传统的 EA 方法多是基于业务流程的梳理，产出的也多是要采购或是研发什么样的系统来解决业务流程上的一些问题，所以大多的产出物就是企业要采购像 ERP、CRM 这样的系统来解决特定领域的问题。而对于如何沉淀成平台甚至是中台，好像并不是那么适用。传统的 EA 方法更多是解决当时信息化背景下的问题，也就是基于现状（As-is）的业务梳理，考虑如何通过系统的构建来解决业务流程的信息化改造问题。而目前大家在构建中台时，往往信息化程度已经非常高了，该有的系统都有了，而中台建设甚至是大家经常挂在嘴边的数字化建设，更多是为了未来（To-be）的业务发展和创新的问题，与传统 EA 的方法好像也不太搭。传统的 EA 方法多是比较重的流程，需要做长时间大量的调研，产出动辄几百页的规划文档。这在十几年前信息化发展不高、瀑布式流程还占主导地位的时代也是可行和主流的，但是以现在互联网甚至是传统企业的 IT 变化速度，可能就算是花了大力气规划出来，也就过时了，也不太搭。

中台背后的本质问题，其实是一个面向用户与创新的平台型企业架构的问题。

 

2中台落地

2.1Discovery-Define

 

总结下来，共性能力基本上就是四类：业务数据、业务功能、业务流程以及通用的技术能力。

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

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

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

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

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

2）平台型企业架构设计概览

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

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

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

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

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

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

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

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

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

 

 

2.2中台的规划与设计（Design）

1)确定中台产品愿景

工具：“电梯演讲”  解决：愿景的充分收敛

如下：

 

2)确定业务梳理范围

有了清晰的愿景，就可以让我们的业务梳理更加聚焦。不一定要梳理全部业务场景。基于中台的建设愿景，我们就可以在横向端到端价值链和纵向的业务线上收敛到一个聚焦的区域。

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

 

3)细粒度业务梳理

基于现有的流程或系统，对现有业务的流程进行梳理，例如在电子商务领域大家经常提到的四流，具体指的是信息流、商流、资金流、物流的梳理工作，使用的工具也大多是流程图这种非常成熟的工具。这种基于已有流程的梳理有时候会有一些限制，简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。

回到问题的原点，基于用户需求在当前的业务及技术条件下，重新设计解决方案的思维方法，可以避开上面提到的业务债陷阱，也多用于创新型业务的设计过程，而这种思维方式也大量参考和借鉴了设计思维（Design Thinking）的方法。所以和基于现状的传统业务流程梳理不同，我们在业务梳理过程中大量地采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。

回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理，从效果上来看也是非常不错的。（但是工作量剧增，时间拖长，还有有些用户比较保守，不允许动已有系统）。

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

 

4)MVP原则

中台的建设过程中，引入了精益创业中的 MVP 原则（Minimum Viable Product，最小可用品），也实现了我之前提到的整体原则中的 Start Small。为了实现 MVP，保证做出来的 MVP 可用，我们在业务需求上采用端到端纵向切分的方式，结合需求优先级的多维度评分排序，最终确定 MVP 的需求范围，而最终落地的形式可能就是第一个迭代的用户故事列表。

 

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

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

 

6)度量前置：定义验证指标

常用指标：四类

不断追问，直到指标可度量。一定是业务层指标比应用层技术指标更重要。

2.3中台交付  delivery

1.交付的第一步

一定是要组建一支有战斗力的队伍，中台的建设需要的能力与传统产品还是有比较大的差别。

2.建设工作

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

 

在中台的实际建设过程中，我们也建议引入精益思想，结合到软件的开发过程中，小批量快速开发产品，快速引入度量，基于测量的数据快速对于之前的需求假设进行验证和认知，并基于此做快速的调整。

• 敏捷和精益的区别？

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

 

 

3.中台的运营、治理与演进

中台作为一个企业的平台类产品，服务的不是企业的最终用户，所以和互联网里经常提到的基于产品的用户侧运营还不太一样，中台在位置上更像是企业内部的一个服务企业前台应用的 ToB 产品。

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

如果我们采用产品化的思维来构建中台，那中台中所沉淀的能力并不是产品的全部，还需要再加上 NFR（非功能性需求）或是我们常说 SLA（Service-Level Agreement，服务等级协议）才是产品。

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