提到中台和SaaS，总是有很多疑问。 比如说什么是中台？ 企业搭建中台的价值是什么？ 中台架构如何设计？ 对此，本文作者回顾了多年来项目建设的得失，总结了自己在产品架构方面的经验，希望能够解答大家的疑惑。

说到中台和SaaS，你想问这样的问题吗？

有哪些中心？ 企业搭建中台的价值是什么？ 中台架构如何设计？ 业务中台和数据中台有什么区别？ 什么是SaaS？ 中台和SaaS有什么区别？ 什么是SaaS开放服务？ 弹性？ 边界？ 中台系统为什么能够积累业务能力，复用业务能力，消除重复建设，消除业务系统的“烟囱”和“孤岛”，提高业务系统和组织的内部效率？ 中台组织为何能够快速响应前台业务团队的需求，提供频繁低成本的业务试错能力，促进业务团队创新？ SaaS产品为何能够向市场开放服务，提供标准化、低成本、高效的行业解决方案和产品服务，共同构建促进繁荣和创新的生态系统？

我从事互联网产品架构师工作六年多，专注于中端和SaaS产品架构和技术架构。 我的项目经验包括电子商务/新零售/数字营销/O2O等行业。 这篇万字的文章是我多年来在项目建设中的得失回顾。 希望总结的产品架构经验能够清晰地回答这个问题，帮助大家理解中端和SaaS产品架构。

目录：

该中心为谁服务？ 企业的经营能力是什么？ 什么是行业解决方案？ 基于中台构建方式的SaaS产品架构示例 1、中台为谁服务？

中台的概念最早由阿里巴巴提出。 更准确地说，马云认为，面对未来快速变化的商业社会，具有市场竞争力的组织模式是通过频繁、低成本的试错建立一支灵活、精良的前端团队。 进行业务创新，为了支撑这样的前端团队，需要建立一个中端团队，负责构建复用业务能力的软件平台。

很多时候我们在谈论中国平台的时候都会有很多争议和质疑。 主要原因是我们搞错了中国平台服务的前台。 不是我们一般理解的前台。 我们通常指的是APP、UI、应用层、应用软件、客户端。 叫前台，但在中台服务理念中，中台服务的前台更多指的是具有自主性、灵活性的前台业务团队。

这就是阿里巴巴所说的“大中小前台”策略。 从业务和组织的角度来看，小前台首先团队成员数量少，只需要少量的营销和运营轻资源，而不需要投入产品甚至开发这些重资源； 其次，团队易于建立和调整，即使是临时的，人力组织成本低； 最后，面对市场变化，反应速度更快4s店销售前台岗位职责，业务流程更加直接敏捷，能够频繁地进行低成本的业务试错。

从产品和技术的角度来看，它是一个用于支持多个灵活且复杂的前端团队的系统平台。 前端团队是纯业务团队，中端团队提供全套产品和技术支持。 除了提供可复用的产品能力外，还可以快速响应业务团队的市场需求，以低成本快速迭代产品，支持业务快速试错。

假设某订餐APP在两个城市开通服务，在上海订餐，在北京订餐，并成立上海运营团队和北京运营团队。

两个团队在本地化运营过程中可能对市场需求存在一些差异。 例如，北京和天津的运营团队在紧急招募骑手、运力管理、商户运营、用户奖励活动等日常运营方面不会完全相同。 由于经营环境、地域、市场竞争等因素，会存在一定的差异。

同样，当订餐App开始拓展新的品类，比如从餐饮订餐到花束、超市、药品订餐等时，新成立的运营团队对产品功能需求的差异可能会更多地集中在服务品类上，比如产品管理、商户资质、发货时间、品类属性等

这种差异是由于业务环境不同，存在一定的业务灵活性和自主性。 如果没有这个，我们会发现订单业务的主要逻辑（消费者下单、店铺履行合同、骑手配送）不会因地区和品类而异。 并改变。

通过订餐APP的反例，我们可以认为“小前台”是指那些因业务需要而建立的前台业务团队。 在相同的行业环境（订餐行业）中，此类团队所使用的业务系统，其业务的主要关注点逻辑相似甚至相同（消费者下单、商店履行合同、骑手送货）。

因此，前端业务团队需要能够高效地复用现有系统，以满足业务快速扩展的需求（例如开辟新区域、新品类）。 同时，需要针对业务环境（如门店招聘、产能管理、营销等）具有高度的灵活性和自主性。 营销、骑手奖励、团队 KPI）以满足各自的业务需求。 “大中平台”是指能够满足前端团队复用业务能力和自主性需求的系统。

2、什么是业务能力？

我们以订餐APP为例。 从消费者旅程的角度来看，订餐APP的核心业务流程是消费者购买并下单、商店接单并履行订单、骑手取货并送货到家立即地。

消费者、商家、骑手扮演着实现商业闭环的角色，而订餐APP作为平台则负责提供实现商业闭环的业务能力。

在订餐APP中，为了完成消费者购买和点餐的业务流程，设计了商品列表、店铺列表、购物车、订单支付，以及登录注册、短信验证、送货地址等产品功能模块。 参见图1核心业务流程和领域模块（产品功能）。 这里区分流程和职能的主要原因是流程依赖于特定的角色和业务。 函数是帮助流程实现的一种方式和手段。 换句话说，流程最终是完成业务目标并获得结果所必需的。 功能是过程中实现某种行为过程的方式。

消费者采购订单业务流程的最终目标是实现下单的结果。 登录注册、产品列表、购物车、支付等产品功能都是为了实现这个业务目标而设计的，是流程的一部分。 它们共同构成了消费者购买和订购业务流程的业务目标。 流程中的相关功能是根据业务目标的业务需求来设计的。

假设我们的订餐APP不是针对大众消费市场，而是针对小团体内部使用，那么就不需要开放手机号码进行登录注册功能，而是使用团体内部员工账号来进行登录。登录。这个时候，业务的最终目标就是集团内部。 员工角色进行采购和订单。 这些都是影响功能部分的产品模块设计的业务目标和需求结果。

同样，门店招募、菜品管理、订单管理、骑手招募、运力管理、配送管理、时效管理等都是为了实现门店订单履行业务流程和骑手即时配送业务流程而设计的产品功能模块。

从整个订餐APP来看，业务能力是由三个流程组成的一个业务闭环。 这种业务能力是通过多年的订餐业务实践和积累而产生的。 它有能力为订餐行业提供解决方案，并且可以重复使用。 运营能力。

可以说，一个企业的业务能力就是为所在行业提供行业解决方案的能力。 提供的行业解决方案高度依赖于公司所拥有的资源和能力。 公司所处的市场竞争环境、内部组织环境、技术积累。 、人员结构等，都会影响其计划的最终效果。

顺便说一句，要讨论一个公司中台的价值，首先需要了解该公司的行业、业务能力、建设中台的出发点和目标，以及技术积累、组织能力、人力资源结构等..不然就没用了. 无意义的。

三、行业解决方案 1、业务类型和领域类型

一个行业从形成一定的市场规模到实施旅游行业解决方案，至少要经历探索期、成长期和成熟期。 在探索期间，将会出现大量创新的行业解决方案。 此类解决方案受市场不确定性较大、频繁变更的业务流程难以复用，探索期更关注跑通业务模型和产品PMF。

行业解决方案进入成长期后，会经历优胜劣汰，剩下的都是经过市场检验、沉淀了业务能力、有复用可能性的解决方案。 同时，成长阶段更关注业务的大规模扩张，这与中台理念相呼应。

此时的业务能力本质是针对特定场景的行业解决方案，具体可以分为业务类型和领域类型。

面向业务的行业解决方案面临的市场越来越复杂多变，行业竞争也越来越激烈。 除了解决和满足市场需求和用户需求外，还需要解决可持续商业模式的问题。 简单来说，可以解出多少个解？ 赚少赔钱，让用户和企业都高兴的问题是，业务很容易受到市场变化和新政策的影响。 好在行业特征和边界比较清晰，垂直业务子行业很多。

常见业务行业解决方案：

基于领域的行业解决方案更侧重于组织管理、办公协作、行政、人事、财税、法律事务、发票、工具等，需要解决企业所有的行政和职能问题。 简单来说，他们解决的是公司内部人员之间的协作效率。 问题面临的是成熟的市场环境和商业环境，不太可能受到市场变化和新政策的影响。

常见的基于现场的行业解决方案：

常用的行业分析方法：

2、行业特征及边界

当两个行业的行业特征和业务流程相似时，是否可以共享一套业务流程，以提高公司开展新业务的效率，节省产品开发资源？

例如，电商交易场景和订餐交易场景都有两个核心业务流程：消费者采购订单和门店履行订单。 它们还具有登录注册、产品列表、购物车、订单支付等产品模块功能。

既然功能模块相似，那么电商交易场景和订餐交易场景是否可以共用一个中台系统呢？ 这样可以减少返工联觉的问题，并通过共享和复用提高产品构建效率。 当遇到不同的流程和功能时，进行具体的处理，以适应两种交易场景的需要。

答案是不。 这一观点从一开始就秉承了中台的初衷和理念。 中台服务于灵活成熟的前端业务团队，复用行业解决方案。 不同行业之间有其特点和界限。 这是困难的。 通过产品或技术手段实现具体复用，中端架构设计不需要为了具体而具体。 即使电商交易团队和订单交易团队之间的部门权责、组织架构存在诸多差异，但必须强行统一使用一个，整合中间必然会出现很多职责和边界问题。端服务，很容易导致组织和业务冲突。

有没有其他办法可以解决这个问题，既不违背中台理念，不跨行业共用一套中台，又不会造成重复建设等问题？

我们假设，当订餐APP产品建设完成后，订餐前台团队拓展到更多新区域、新品类，业务蓬勃发展，订餐行业的中台和业务能力得到复用。 现在我们计划拓展新的赛道，进军B2C电商行业。 我们一定会考虑哪些订餐业务能力和产品模块有机会在电商行业得到复用。

从行业特点分析，订餐行业基于LBS技术提供O2O需求和服务，用户通过地理位置定位就近实体店购买（当前的消费需求让实体店的概念可以细分，包括后端仓库） 、社区超市、便利店等），通过骑手即时配送到您家，配送时间约50分钟。

在电子商务行业中，用户可以从任何区域的商店、超市、工厂、经销商等处购买产品。 可选产品的数量理论上是无穷大（无限制）。 跨省市可通过特快专递送货到家，送达时间约1-3天。

行业特点决定了产品采购、商家资质、分销业务流程都有较大差异。 电商交易场景和订单交易场景属于两个不同的行业。 它们与大行业和子行业不相关，不能直接共享相同的业务流程和业务流程。 塔。

3、共享机制

从组织架构上看，订餐业务和电商业务分别由同一公司的不同业务团队负责。 除了业务运营和其他相关职责外，每个业务团队都需要行政和职能部门的支持，例如人事、行政、财务等，大多数公司会采用共享的行政和职能部门来支持公司内的所有业务团队。 这些结构在企业管理中尤其常见。

以业务单元为基础的业务组织结构是互联网公司的最爱，尤其是以业务发展为主导的公司。 产品和研发部门还可以共享职能，以支持整个公司的所有业务团队。

这时产品规划就不能局限于某个业务线，而应该针对整个公司的业务来进行。 否则，产品和研发部门会因业务部门的业务发展压力而无节制地扩充人力资源，造成冗余过多、组织臃肿。 ，缺乏统筹规划影响产品质量。

产品和研发资源向业务迭代倾斜。 产品模块设计只能满足当前业务需求，甚至重复建设。 缺乏对未来业务发展的思考，最终导致产品维护成本增加，无法维护“烟囱”系统。

参考阿里巴巴、腾讯等小型互联网公司的中台建设，我们可以得出一个有趣的推论。 当一个拥有多条业务线的公司面临多个行业、跨行业时，就会有多个中台系统来满足公司不同的业务。 同时，将可共享的能力内置到SaaS产品中，并向市场开放服务。

例如，阿里巴巴集团标志下有电子商务业务（天猫、天猫）、金融业务（蚂蚁金服、支付宝）、旅游票务业务（飞猪）等，阿里巴巴已经开放了登录天猫的能力帐户并使帐户登录独立。 SaaS产品为阿里巴巴和非阿里巴巴集团第三方提供使用天猫账户的联合登录。 用户甚至无需提供账户注册功能，提高了用户注册门槛，让数亿天猫用户享受一键登录服务。 。

阿里巴巴通过开放账户登录、支付、营销等各项能力，打造电商生态平台，促进电商行业的繁荣，提升整个集团的市场价值和行业影响力。 （具体开放能力请参考阿里巴巴开放平台）

除了阿里巴巴集团开放的能力建设生态平台外，多业务线的企业也可以综合考虑研发资源和业务效率，将合适的产品模块商业化为SaaS，减少重复建设和水塔岛系统。 尤其是跨业务单元和部门，可以有效提高研发资源和业务能力的利用率，产品架构边界清晰。

中台的复用能力是为了提高业务开发的效率。 在中台的基础上封装SaaS产品并向市场开放服务。 提供的服务均为垂直业务，业务功能边界清晰，适用场景广泛，复用场景多样。 类型。

SaaS可以说是中台的下一站。 如果说中台服务于前端团队和企业前端业务团队，那么SaaS产品则开放服务于整个行业。

顺便说一句，中间平台一定是行业内的中间平台，尤其是面向业务的公司搭建的中间平台，公司的业务对其依赖度很高。 它是行业解决方案，因此不存在跨行业的中间平台。 这是由中台理念和架构风格决定的。 的。

4、垂直细分行业

当行业规模足够大时，由于市场和用户需求的发展，很多专注于垂直领域的行业将会被细分。 这些细分行业彼此之间具有一定的业务关系和相似性。

据国家统计，2020年国外零售电商交易额接近10万亿元，其中90%由B2C、C2C、B2B三大电商子行业构成。

从行业特征来看，前端业务存在差异，但业务流程相似，存在复用或共享的机会。

电子商务行业的特征示例：

B2C和C2C的交易对象都是个人卖家。 消费者侧的产品购买、搜索推荐、订单履行、客户关系管理、物流售后等产品模块业务流程相似，具有复用价值。

B2C和B2B货物转让者都扮演着商店的角色。 店铺管理端的商品管理、品类管理、商户资质、押金、商品要求、合规要求等产品模块业务流程相似，具有复用价值。

如果我们继续细分B2C调货店的角色，我们还可以根据店铺资质和运营能力将其分为平台直营、品牌直营、品牌加盟、品牌代理运营、品类经销商等。 在实际运营过程中，由于投资和特许经营要求、前期资质条件、品类运营等方面的差异，会设立前端业务团队或人员负责相关工作。

找到前端业务中不同的部分和相似的业务流程部分，直到整个业务完成闭环。 然后复用类似的业务流程和产品模块，甚至对一些产品进行SaaS设计。 这样可以有效减少重复施工，节省产品。 研发资源同时提升整个电商产品线的系统性能。

了解行业和行业特点，根据特点识别行业特点的差异，复用相似的业务流程和功能，可以带来更高效的业务效率，同时防止重复建设对独立性和功能性的影响。前端团队的自主权。 通过将业务能力的复用转化为特定场景下的行业解决方案，提高整个系统的效率，促进企业内部的业务创新。

四、中台类型及组织定义 1、业务稳定性

可复用的业务能力不仅仅是具体的业务逻辑和模块供多个需求方或团队使用，而是要准确理解公司业务的核心逻辑和流程，公司的行业情况、市场环境、竞争状况等，提炼出来核心业务流程闭环，进而积累业务能力，最终实现公司业务的复用，支撑快速响应以用户为中心的需求。

业务能力能够复用的首要前提是业务稳定性高。 如果业务因为市场或者其他原因变化过于频繁，就缺乏复用价值。

以订餐行业为例。 经过多年的发展，该行业已进入成熟阶段。 美团订餐和饿了么占据了90%以上的市场份额。 美团订餐和饿了么APP的用户旅程体验已经成为国外订餐行业的一门生意。 工艺标准。

从行业成长期开始，核心业务流程平均变更频率约为5-10年，流程功能（领域模块）平均变更频率约为1-3年，平均变更频率约为1-3年。在前端团队的独立需求是半年左右。

当行业成熟后，业务逐渐稳定，核心业务流程和领域模块固化不变。 有一定概率，前端团队的需求会因为市场增速放缓而进入日常维护阶段。 根据行业发展趋势和平均变化频率，可以提前识别和规划复用能力平台。

2、三类中间平台及组织定义

搭建中台系统需要用到哪些理论知识？

常用的架构方法：

另外，《中台产品总监手册》作者二爷分享了中台MSS模式，阿里巴巴、腾讯等各大互联网公司都会采取多种方式。

中台架构和SaaS架构均基于云计算，符合云计算服务模式和架构风格。 设计中台产品架构时除了掌握至少一种方法外，还需要了解云计算相关知识，特别是三种服务模型（IaaS、PaaS、SaaS）、镜像、容器、弹性、边界等概念。

从行业发展规律来看，新的技术范式通常会在15-20年左右出现，并发展出新的架构理论和技术。 从2006年提出云估算的概念到现在已经16年了，云估算的技术范式已经基本完成。 迭代，下一代技术革命主要以Web3.0为基础，发展基于云计算的去中心化网络及其他相关技术，如物联网、AI、区块链、元界等。

云计算深刻影响了信息技术和互联网的发展，奠定了现代互联网的基础。 至少在可预见的未来10-20年，云计算将继续支撑互联网的发展。

一套中期架构至少要满足企业未来3-5年的战略规划，支撑业务发展的上限。 直接照搬或模仿大厂商的中台架构往往在建设中容易失败。 主要原因是中台架构需要考虑公司的愿景。 、战略目标、组织能力和资源投入、行业环境、市场竞争等，就像如果你复制天猫全套产品功能，很难重建一个网上商店，因为它可以被抄袭和模仿，而且它是一种可见的产品形式。 ，你看不到的包括业务知识、组织能力、资源投入、企业愿景和战略等。

中台的概念从诞生到落地已经经历了六年的时间。 行业中出现了各种中台，如业务中台、技术中台、移动中台、数据中台、管理中台、组织中台等。 等等，每一个中间平台都是公司业务理解和业务需求的产物。 这里我们不讨论哪个中间平台更好更适合。

再次，虽然一个公司的业务能力和资源，但搭建中间平台的出发点和目标，以及市场竞争环境、内部组织环境、技术积累、人力资源结构等环境激励因素4s店销售前台岗位职责，并不讨论中台的建设是否有效，或者说中台的建设没有意义。

中台的本质是一个支持多个灵活、成熟的前端团队的系统平台。 它是一个满足前端团队对业务可复用和自主化需求的系统。 它是针对特定场景的行业解决方案，是实现业务目标的业务系统。

只要是业务系统，就需要落地。 从实现业务系统的技术角度，追溯源头，业务系统由业务流程、模块功能、业务数据和使用业务系统的角色组成。

业务流程和产品模块功能规划到业务中平台，业务数据规划到数据中平台，业务中平台和数据中平台技术实现中所应用的技术需求规划到技术中平台。

中台部门由产品和技术研发组成。 该部门的核心职能是搭建和维护公司能力复用平台（中台平台），满足前台团队快速响应市场变化的需求。 Its and job , , and ranks be to the 's , goals, and , human and other , be to a of , and as much as .

Among the three -end :

The -end is the , of IaaS, PaaS, and cloud , k8s, and other among the three cloud ; the data -end is the most to , data that both and ; The is the most prone to . When , it is to all and . It must not only meet needs, but also and refer to . , it must go deep into the team and the 's and goals, and the reuse of .5. SaaS 1. The and SaaS

The and SaaS is in its . The main goal of is to , reuse , , "" and "" , and and The of the ; , it is to to the needs of the front-end team, low-cost trial and error , and team .

The main why China and can is that have a with huge and high rate, which makes it for the to take all. will use their own and to get in more and . Such and have given rise to the for . It can be said that are by the and . The is to find more and lower-cost and . To the rapid and of the .

In 2009, NIST (Japan's of and ) three for cloud , and at the same time, a fee model was born. The main of the model in this way is to open and IT usage costs. low-cost and apply best to build an to and .

The SaaS in the , Fried , an e- . Its main open is to a set of e- with rich .

that there is no such SaaS , what is to build an e- with rich and ?

The first step is to a and team, then and , and order for and . the of the e- , the team also needs to and bug fixes. For brand who only need to sell goods, the The cost is too high, the is too long, and the is too small.

Or from an team will such as , , after-sales, etc. The cost is too high and the risk is too high.

The three of IaaS, PaaS, and SaaS the to open . The model on , costs and usage costs, and low-cost and high- best to the . each other and build upon each other to build a .

e- such as , , and to the SaaS from the of cloud , they are also open and use fees to usage costs for and best in the e- field. The is that and e- are bound and on each other due to . This is also the in .

The main the and SaaS at the level is the for open . The the front-end team and is to solve the needs of the model. From the of and , the The open the of the , meets the needs of the front-end team, and is for the and goals.

The open out by the three of cloud are to the and meet all needs in the . They large-scale , , and such as and . , and low-cost and high- for the .

the build SaaS for -end on the 's goal of -end . it has the and to its , it is only doing and the front-end team, or it wants to more and get in more , and then open to build an to meet the needs of the and .

SaaS need to build a on the of and . If the and low-cost trial and error and , then the of the are . the 's , and best are all after low-cost trial and error.

2. and

A set of and is to the of . Have you ever heard that "first-rate make , -rate make , and third-rate make ?" From the of , you are all in the . Build and run . Only those who pass will be for the next round. Only in the stage can be , begin to , the cost of is , and large-scale is made. In the stage, the brand will a moat and the top in the . It will begin to build open and to build .

Not only new such as web3.0, but also the of other are in the stage. The of and is to an end. Most have begun to apply and and to meet needs. Not much space.

Most of the needs from the 's , or . Their is to solve the of or roles in the of the 's . They are all a of needs under . In , there will still be . It is rare that a only in a . When with needs, you open your mind and for , even cross- . Find and .

3. of SaaS

Since () the , have been the of . After the era and the wave of and , a new on cloud has about The of lower cost and have to the 's , and at the same time, it has also the form and the and that the .

are very for using SaaS model and -end :

SaaS on the cover FMCG, goods, , , , e-, and many other . They can be into four types based on the level of and :

TOC , , and are of high , and make quick , and focus on small-, -based ; TOC , , and are , and have . take a long time to make , and are in large- . 主要是； TOB , and have high , the is small, and it is easy to make , and front-line can often make ; TOB , , and are very , the are , high-level , and the are large, the boss to .

of SaaS using SaaS model and -end

The and is a that . The is for it; the four to the four lines and lines, and the is for it; each to the front The is for the team's needs. Every is a SaaS and an open .