作者：涂鸦-苏铭
来涂鸦工作： job.tuya.com/
业务中台与前端
一、什么是中台
1.1 中台的概念
国内的中台概念起于知名的互联网企业——阿里巴巴，于是很多企业也纷纷开始搭建自己的中台系统，关于中台的文章、书籍也开始兴起。但是最近，阿里的掌门人逍遥子又发起去中台化，认为中台的存在阻碍了公司的快速发展。既立中台，又废中台，这究竟是为何呢？一切都要从中台是什么说起。
中台到底是什么，众说纷纭，却没有一个官方的定义。在王健老师在《当我们谈中台时，我们在谈些什么| 白话中台战略》文章中有提到过关于中台的理解。
在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”。
在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。
这些理解都是没问题，但它们只是说了什么是中台，并没有说明中台是什么。翻了大量文章后，大概找到两个角度的定义，比较贴切，但也有些晦涩。
中台定位的角度：业务中台是对前台应用的抽象，提供多个前台业务之间共享的业务逻辑、数据和计算能力。
中台价值的角度：中台是在多个部门之间共享的开发资源所提供的业务能力、数据能力和计算能力的集合
1.2 中台与前台、后台的区别
在以前的前端开发中，我们将系统分为了前台和后台两部分。前台是用户可以直接接触的产品部分，用户直接在这里产生使用行为，例如用户在淘宝下单、在抖音观看视频、在掘金上发表文章。而后台除了为前台提供访问的服务外，还会管理用户产生的数据，就会提供管理系统来管理、使用这些数据，比如淘宝的商品管理系统。
那我们就能知道，前台是由各类前台系统组成的前端平台，每个前台系统就是一个用户触点。后台是由后台系统组成的后端平台，每个后台系统一般管理了企业的一类核心资源（数据+计算）。
前台和后台就能满足企业和用户的需要了，那么中台在这中间扮演的角色是什么呢？
其实中台是企业发展壮大过程对自身经验复用的产物，当它们发现淘宝和天猫里的商品有共同之处的时候，就不重复造轮子，后台用一套数据模型，前台只需要对页面进行定制化就能减少一部分开发。这个概念如果拿到编程里，正好就是我们说的复用。
因此，业务中台是对前台应用的抽象，同时中台提供多个前台业务之间共享的业务逻辑、数据和计算能力。
中台的一个重要特性就是复用，但是它的程度并不是很高。我们熟知的SAAS其实就是高度复用的例子，它直接复用了一个行业或者业务的形态。用户拿到它可以直接使用
1.3 中台的类型
前面的描述中，注意到用词的读者会发现，一会用“中台”，一会用“业务中台”。这两者是不是存在什么区别。
确实，中台是对所有中台概念的总称，业务中台只是其中的一种。常见的中台如下：
- 业务中台：电商业务中常见的业务会包含支付中心、商品中心、订单中心、会员中心等
- 技术中台：消息队列、技术框架、容器云、Devops平台
- 数据中台：数据建模、日志分析、用户画像
- 算法中台：推荐算法、图像识别、语音识别、搜索算法
在更广义的定义上，还有类似于企业内部资源调度中心和内部创新孵化的组织中台、管理公司广告投放的广告中台。所以在对中台的感知上，要更加的注意它的复用性。
二、中台的价值
中台的价值不如其他业务那么直接，前台的价值就是为了让更多的用户使用，后台的价值就是为前台提供支撑。中台就比较尴尬，它的价值只有提效。
如果一个中台没有做好，不仅不会提效，还可能会阻碍业务的发展
2.1 实例
很多文章上都说到了一个典故，就是阿里巴巴的前CEO马云去芬兰的一家游戏公司SpuerCell参观的时候，发现这家所有员工不到300人的公司，在短短的几年内开发了10款以上的游戏。我们熟知的《部落冲突》、《皇室战争》、《海岛奇兵》就出自于这家公司，而其他游戏大多在试错的过程中被腰斩了。而这家规模不大的公司有如此效率，正是得益于中台。
对这三款游戏比较了解的读者会发现，它们除了UI模型外，其他都大同小异。这些共同的地方中就包括了支付系统、用户系统、游戏引擎等等。这些都由一个强大的中台提供之后，需要开发的地方就大大减少了。
SuperCell公司不仅仅是在技术、业务上使用中台的架构形式，在组织形式上也是如此。紧随其后，国内的互联网也开始了各自的中台战略。比较知名的就是阿里巴巴的“大中台，小前台”战略和华为的“平台炮火支撑精兵作战”战略。
2.2 业务发展中的问题
讨论中台前，我们需要明白中台的出现并不是为了解决业务本身的问题，也不会让我们的工作变得更简单，相反的，只有前后台的时候是最简单省力的。中台的存在还增加了额外的建设工作。那么业务的发展中，中台的出现是为了解决什么问题呢？
我们先假设如下几个场景：
- 公司业务是做电商的，刚刚双十二过去，营销活动下线，马上就要过年了，要做一个年货促销的营销活动。如果1月底过年，扣除双十二活动后几天的活动扫尾，过年前的活动预热。剩下的时间还不到30天，一个营销活动从设计到开发测试再上线是远远不够的。
- 公司业务是物联网的，以在线售卖模组这种硬件商品盈利，后面发现硬件在使用的过程中产生的数据价值更大，要对硬件的使用提供服务商品。对于硬件商品来说，已经构建了一套商品、支付、订单、会员体系。而服务商品，除了在商品、订单的数据模型上有一些差异，其他差别并不大。
- 公司有多条业务线在售卖可乐，在A业务线里，1组可乐是 2 * 3 瓶， 1打可乐（12瓶）是 2 个 2组。在B业务线里，没有组的概念，1打可乐（12瓶） 就是 3 * 4 瓶。A业务线里，可能一次卖一组，也可能卖一打。B业务线一次只能卖一打。现在公司要统计销售了多少瓶可乐了。
在第一个场景中，已经做过的相似业务，短期内需要再完成同样的业务再上线。对于这个问题，在活动规则没有大的改变下，除了UI设计和前端的工作量是不可减少，其他工作都是重复劳动。参加过最近两年淘宝618年中大促、淘宝双十一大促的用户会发现，盖楼、小火车、叠猫猫的游戏规则几乎没差别。但是任何一个活动从零开发的话，就得完整的开发UI、金币、升级、多app端，以及后台的防刷、口令、并发、消息。工作量是难以想象的。
在第二个场景中，是典型的重复工作问题，面对差别不大的两个商品，要构建完整的电商流程，有很多重复的工作在里面。
在第三个场景中，是一个容易被忽略的问题，同一个商品，有两种甚至多种销售规格。如果在后期需要统计可乐这个商品的销售数量，我们就需要对这里特殊处理。要知道，这个商品是分布在两个不同的系统，它们的商品id会不一样，销售规格的CODE也可能不一样。如果这样规格的商品不止一个呢？如果需要将雪碧和可乐组合起来在两个业务线销售，是不是两个业务线的项目都需要修改。
这三个场景的问题，其实都可以看成重复造轮子的问题。
类似的营销活动、类似的电商体系、重复的规格设计（关键是还设计的不一样）
2.3 中台如何解决这个问题的
看到这个地方，一直都在强调中台的一个特点，那就是复用。解决上面的问题，也正是靠的是复用。
场景一中说到的，同样目的的营销活动，它们其实有很多相同的东西。还是以淘宝的营销活动为例，用户通过多种方式获取金币，收集到金币后可以拿来升级、兑换红包。这个过程就正好贯穿了整个营销活动，叠猫猫和火车中只是收集金币的方式不同、UI不同、得到红包的规则有变化。所以下一个活动来的时候，除了主要的流程外，做一个修改就可以快速上线。场景二的例子和这个就比较类似。
场景三的角度发生了变化，因为先有两个业务系统在运营着，商品分别管理在不同的系统里，才导致数据的规格、维度有了差别。如果这里介入中台的话，就需要在中台中对商品的模型进行管理，同时也要提供规格的管理。这样的话，不论有多少种规格，它们计算商品都是在同一维度上，就不会出现问题。
中台的作用，大概如下图：
三、如何建设中台
这里的中台建设，主要是指业务中台，因为技术类的中台其实很容易与业务解耦，和前端开发的关系也没有那么紧密。
3.1 中台的大局观
中台的业务产品与其他的产品是存在较大的区别的。举个其他类型产品的例子，要做一个电商系统，产品先设计前台商城的交互页面、销售的商品类型、展示的列表、支付的流程、后台对商品的上架下架等等。这每个步骤都是针对用户需要，促使用户完成一个行为的闭环，由点到点的设计。
中台的产品设计就不能如此了，它需要考虑公司的架构、业务的发展、通用的业务设计，甚至还需要产品经理了解一些技术。
同样的，以电商为例，电商搭建中台就是为了开新的业务线时起步更快。那么就需要将会重复的部分放到中台集中管理。常见的就是商品中心、订单中心、支付中心、会员中心。这里有个需要注意的是，中台不是凭空而来，而是根据现有的业务，和对将来的业务的展望而来，也就是说中台是动态的。
起初，公司刚起步，满足前台业务需要的商品模型、订单模型就足够了。后来逐步的发展，开启了新的业务线，如果它们类似于淘宝和天猫的关系，对已有的中台影响不会很大，底层一套模型，上层做业务兼容就好。要是类似产业链的关系，淘宝与菜鸟这种，就得考虑，中台是否支撑的了。这是对业务的通用和发展的考虑，在这之前，你需要知道，公司会往哪个方向发展，就得提前设计好。公司的发展方向，和公司的架构关系是非常紧密的，比如京东的电商发展出自己的物流的时候，公司架构里就已有京东物流，阿里巴巴在淘宝天猫后大肆收购物流公司，后来也成立了菜鸟。
由此可以见得，中台产品对产品的经验、能力的要求是非常得高。有人也称产品是总裁培训班。
3.2 业务模型的抽象
中台的大局观里，告诉我们中台的方向，知道应该做什么。这一节讨论，我们怎么做中台设计。
前台系统和后台管理系统是有一定相似之处的，因为它的作用还是对数据进行管理，只是这个数据会用于不同的业务方。以商品为例，我们对商品做后台管理的时候，会考虑商品中心、商品排序规则、页面路径、商品详情、商品操作。
经过这样一番设计，就符合前台的需要了。但是其中有些逻辑放到别的业务里，却不一定可以。比如说排序规则、页面路径，两个业务对商品有不同的排序、路径需求是很正常的。
去掉这些会特殊化的逻辑之外，剩下的东西，就是商品特有的。那就是商品中心、商品详情、商品操作。
这里可能会有人提问，那排序的规则怎么做呢？发散的思考一下，除了商品，以后还可能有别的需要排序的，比如说广告，banner。因此，我们还可以做一个展示中心，专门用来管理排序方面的问题。
这就是业务模型的抽象，将可复用的、不能再小的部分抽象出来。
除了业务模型抽象这个方法之外，还可以使用共性抽取来寻找可复用的模块。见参考文献
3.3 业务边界
从业务模型的抽象里，我们知道如何将一个业务抽象成中台的业务。在具体的工作中，面对那么多业务，是不是都需要把它们中台化呢？答案当然是否定的，很难存在这种所有的业务都通用的情况。那么就需要识别，哪些业务应该中台化，划定中台的业务边界。
在说边界之前，我们得先讨论一下业务的价值。如何去衡量一个业务的价值呢？最直接的方式就是业务带来的收益。前台的价值非常直接，用户使用它，就会产生消费，用户的基数越大，一般产生的业务价值也越大。
以教育平台为例，用户的目的是为了学习，平台如果先推出视频课、直播课、笔记这些功能，用户就会越发的来使用。假如每个课程只有一个文档让用户学习，却大力开发会员系统、营销活动、广告这些功能。看似一直在增加营收，实际上用户会慢慢的流失，反而得不偿失。所以这时，在前台功能开发的时候，就会选择用户更需要的功能开发。
中台也是如此，只不过用户变成了业务的同事，价值从盈利变成了提升效率。其实提升效率带来的价值，也可以通过估算成盈利来判断中台化带来的收益。计算方式大概就是判断 中台化之前的人力成本 - 中台化之后的人力成本 > 中台化投入的人力成本 是否成立。成立的话，说明中台化是值得的。
以下是业务边界正文
在我们的日常工作中，会发现并不是所有的业务都会被使用到。一般来说，80%的业务使用到的功能往往只有20%。要知道这个使用的情况只是现在，想要中台化，还得考虑到公司下一步的战略。因此，我们的目光就需要聚焦于核心业务。
明确了核心业务之后，需要做的一件事就是业务流程标准化，简称SOP（Standard Operating Procedure），即标准作业程序，指将某一事件的标准操作步骤和要求以统一的格式描述出来，用于指导和规范日常的工作。
假设没有SOP会出现什么现状，A业务线的商品上架流程是
新建商品 -> 上架商品， B业务线的商品的上架流程是新建商品 -> 配置价格 -> 上架商品。A业务线的商品的价格在商品里填写，B业务线的商品在价格系统配置。当公司需要统计销售数据时，当公司要统一管理价格时，问题就来了。
那么SOP应该怎么做呢？在平时的工作中，我们会按照业务的流程来工作，这个是工作流。在这个过程中会产生数据，有信息流转，这个是信息流。SOP的工作范围就是对工作流和信息流的处理。可以理解为：
SOP = 工作流 + 信息流
还是以电商的例子来梳理SOP：
1）工作流的获取
这是一个商品从新建到上架的关键流程。期间会产生的数据如下
2）信息流的获取
当我们将不同事业线中的信息流与工作流都梳理出来后，我们就可以统一来看哪些部分是各个业务线都重叠的，从而提取到中台来。
四、中台的误区
1、所有的企业都需要中台
中台的价值在于提升业务的效率，在规模较小的企业里，快速迭代发展才是最紧要的事，中台并不是很必须。另外中台还讲究一个复用性，对于创新的业务来说，它们要做的事就是与已有的不同，是一个创造的过程，中台是将已有的拿来使用的过程。因此中台也不适用于创新业务。当然，除了这两种情况，可能还存在别的不适用场景。所以，并不是所有的企业都需要中台，要根据自身的情况来考虑。
2、服务中心 = 中台？
服务中心是指我们将某一项在公司内部多条业务线都有相同或类似需求的服务抽取出来作为一项公共服务开放给不同的事业线，比如说商品中心、价格中心。而中台的含义会更广泛一点，它可以看作是服务中心的集合。一般来说，一个公司只会有一个中台。
3、瘸腿的中台
有的中台方案只提供了数据读写接口，而没有一个通用的接入方案。依然以商品为例，使用方想接入中台，大概要解决的问题如下：
- 使用商品相关的功能是否只需要很少的接口就可以完成数据传输。商品的sku、价格、发布都管理好了，不需要再次开发
- 对接的成本是否小于开发的成本
- 功能完善，能够胜任目前的业务场景
至少解决了这些问题，中台的价值才能体现出来。
4、兼职的中台建设团队
中台的迭代也是受业务线的影响的，如果有兼职的中台团队，就会发生一些问题。比如说两个业务线，对中台的模型都有修改，因为中台在其中一个团队建设，优先考虑自己所在团队的可能性就会更大。其他团队日后也有类似的需求时，还需要强行满足目前中台的设计，不然就需要重新开发。中台的通用性，可能就会随着业务迭代慢慢的降低了。
五、前端与中台
这里确实得承认一个事实，就是在中台的项目里，前端与中台的联系是最浅的。中台在SOP的过程中，考虑的是流程和信息的复用。前端的复用其实有很大的局限性，那就是对组件的复用性，组件最重要的体现是交互和数据结构。交互如果不可复用，那么这个组件需要做大量的工作来适应变化。对于后端来言，中台的价值会更大，统一的数据模型会更方便业务的发展，在业务变得复杂的时候，它的价值就更大了。
作为前端开发，要想更加深入中台，可以尝试从这三个关键字入手：微前端、业务、数据。
微前端：本来是一种利用微件拆分来达到工程拆分治理的方案，可以解决工程膨胀、开发维护困难等问题。它的特性正好和中台是契合的。中台的复用性决定，它的业务来自于业务线，并且会分成一个一个模块。这些模块之间是不能有太复杂的联系的，所以它可以分布在不同的系统。使用微前端来开发中台，是再好不过了。
业务：中台的业务是和每个接入中台的业务线都有关系的，想要更好的理解中台，就需要先理解每个业务线的业务。不然开发的时候，你很难预料到会出现什么问题。前端对比后端来说，业务上是比较薄弱的，从数据提交到后台之后，前端就不知道具体的业务流程了。这个只能多和后端、产品沟通来弥补自身的不足。
数据：前端使用的数据一般都是后端提供的接口，对整体的业务模型并没有一个概念，这会导致你很难估量一个数据模型修改带来的成本。前台业务的话，大部分并不复杂，流程比较清晰，基本拿到数据就知道业务了。但是中台却不一样（其实后台也是），当你创建了一个商品，可能这个商品需要去几个系统同步各种数据，这些数据间还会存在关系。有些数据，可能你都不知道它有什么作用。以公司ISS的商品为例，商品需要关联一个物料编码，这个物料编码会和SAP物料有关联，最后关联到物料的价格上。如果你不知道这个数据的意义，那你就没发回答商品怎么配置价格的问题。
六、总结
中台架构也不是银弹，不能解决所有遇到的效率问题。是否应该开发中台，还是需要结合公司的业务、发展的实际情况。了解业务中台，对前端来说，是换了一个角度看待问题。平时总是会关注用什么技术，解决什么问题，却没有关注过解决这个问题会带来的价值。尤其是这种，解决的问题带来的价值还是间接性的。将产品的思维放在工作里，更能发现业务的价值，提出更有建设性的意见。
由于本人中台开发经验还有待积累，所以上面内容的观点有些来自于下面文章。大家有兴趣可以仔细阅读。
参考文献
3、 漫画：什么是中台？
来涂鸦工作： job.tuya.com/
