平台化产品设计思考

最近关于平台化的讨论热火朝天，好生热闹。恰好最近用户平台化一期项目进入尾声，作为项目总结的一部分，我想从一名电商基础产品经理的角度，聊聊我对平台化的一些看法。

一、我理解的平台化

从产品角度来看，电商业务的需求有两个特点，业务需求多且繁杂；业务需求时效要求极高。这两个特定是由电商的特点决定的。对于电商行业来说：

1、消费者流失门槛低。对于电商来说，消费者流失门槛极低，因此需要时刻紧盯消费者的一举一动去讨好他们，偏偏人又都是喜新厌旧的动物，因此需要经常进行业务上的调整；

2、电商已是红海，同时行业抄袭成风，因此有新的业务机会需要尽快上马，战机稍纵即逝。

面对这两个业务上的特点，容易导致的情况是，开发同学被业务同学推着走，一见面就是这又有XX个需求，都很急啊，先做上线再说吧。这会导致的问题是，在如此短的时间内上线功能，难以进行系统性、全局的考虑，导致新的业务逻辑在原有系统逻辑上，像打补丁一样一块接一块，最后系统不堪重负，从而使整体的效率及稳定性降低。面对这样的问题，一般大家都会采用系统重构的方法来解决。俗话说得好，船小好调头，小的系统重构起来很简单，大的系统上跑的业务多，依赖多，业务逻辑复杂，重构成本非常高，还是要尽量减少重构系统的次数。在不得不重构系统的情况下，怎么重构系统，才能在开发效率要求越来越高的情况下，实现可持续发展，尽量减少系统重构次数呢？这就涉及架构设计的问题。一个合理的架构，可以在提高开发效率的同时，使系统的可用性越来越高。

这就要有请我们本次文章的主角，平台化出场了。

**在我的理解，**平台化是一种底层功能的架构方案，其实现的是将业务从业务耦合，多头管理，刚性支撑到业务分治，归口管理，柔性支撑的架构转变。

这么说可能不太好理解，且待我解释一下：

1、业务耦合-业务分治

这里说的业务耦合，并不是指正常的业务耦合，而是是指过紧的，不健康的耦合。与其对应的概念是业务分治，指的是业务分别治理，依赖业务之间保持较松的，健康的耦合关系。在业务发展初期业务较少的情况下，新业务处于摸索阶段或者业务边界模糊不清的情况下很容易出现业务耦合的情况。后续随着新业务、模糊业务中的双方都越来越复杂之时，若没有及时解耦，耦合就会越来越紧，系统维护成本原来越大，最终影响到两方各自的发展。平台化，目标之一实现的是从业务的不健康耦合到健康耦合的转变，这就要求要划清业务边界，同时推动耦合双方共同完成解耦；

2、多头管理-归口管理

多头管理是一个下级同时接受多个上级领导的现象，在实际业务场景中，表现为一块业务，由多个团队进行维护的现象。这种情况导致的弊端主要有三个：1、负责团队多，互相踢皮球；2、不同团队之间团队墙导致的沟通成本过高；3、业务难以标准化，业务方接入成本高。无论如何，都是弊大于利。而归口管理，则是按业务范畴进行分工管理，不同团队，不同系统，不同模块各司其职，业务边界分明。平台化，目标之二是实现业务归属从多头管理到归口管理的转变，这要求明确业务功能，明确团队职责，确定接口团队，统一维护业务；

3、刚性支撑-柔性支撑

先来说柔性支撑。柔性支撑是从柔性供应链借鉴来的一个概念，是指外部的需求在需求小批量，多批次，时效要求高的情况下，以合理的成本水平迅速满足业务方需求的能力，需求完成的越迅速，付出的成本越低，其具有的支撑柔性越好。柔性的基础，是复用性，可拓展性，模块式的设计方式。其对应的是刚性支撑，即没有考虑系统柔性的支撑。在业务初期，刚性支撑能快速满足业务方的需求，但长此以往系统整体效率下降，开发的边际成本越来越高，显然无法适应业务的快速发展。平台化目标之三，就是实现业务的柔性支撑，这就要求抽象出业务模型，从此前的以点为维度的支撑，换为以面为维度的支撑。

二、为什么要做平台化

以上是我对平台化的理解，接下来说下做了平台化，我们能收获什么？

在我看来，平台化的效果主要有三点：

1、降本增效，提高效率。

电商作为轻资产行业，最重的资产其实是人才，而人才中，占比最大的往往是我们的技术同学们。在实行平台化之后，由于实现了柔性支撑的关系，能极大解放技术同学，使其快速能完成业务需求，有更多精力投入到比如稳定性，性能提高，技术改造，技术学习等其他重要事项中，这也提高了人效，从另一个方面降低了公司的成本；

2、快速支撑，响应业务。

平台化之后，由于能够快速支撑业务方的日常需求，也使得我们能更快把握住战机，同时在对外合作上，也更有谈判的筹码；

3、边界清晰，管理规范。

平台化会进行业务分治及归口管理，这需要对现有的业务进行梳理，业务边界会变得更加清晰。同时由于归口管理，各个团队对业务能进行更规范的管理，提高沟通效率，避免一件小事找了半天都没有人敢拍板的情况。

三、平台化误区

对于平台化，在推行的过程中由于概念较为抽象，不同业务线应用场景差异较大，因此在理解有很多误区，我也和大家沟通下我个人的一些看法：

1、平台化一定要有旗下很多应用，才可以做平台化？

平台化是一种架构方式的叫法，而不是做大的通用平台才叫平台化。在我的理解，只要被多应用场景，多业务方需求，高需求时效要求，不明确的业务边界搞得系统快hold不住的业务，就可以考虑进行平台化改造。

2、做个大的业务平台，就完成了平台化改造了？

做了大的业务平台，实现了业务分治，我个人感觉，是平台化的开始。业务分治，归口管理以及柔性支撑，其实是平台化由浅及深的三个阶段。每个阶段对生产效率都会有一定程度的提高，但全部实现之后，对生产效率的提升会达到一个全新的高度。路漫漫其修远，大家仍需加油。

3、无论什么业务都适合进行平台化？

并不是所有业务都适合进行平台化，我们也不提倡为了平台化而平台化。有一些业务，面对的业务方较少，业务变化少，系统压力小，此时是否需要做平台化，就需要讨论一下了。毕竟平台化改造，需要投入的资源，时间较多，如果投入产出比较低，则不一定要做。

四、平台化产品模型思考

这段时间，通过对于平台化的思考，我总结了平台化的通用产品模型，在此抛砖引玉，希望大家一起讨论下：

这个模型主要分4层，分为业务层，功能层，接口层，应用层。

**业务层，是指业务分治后，划分清晰的不同业务。**这一层主要对应的是平台化中的业务分治的要求，要求业务边界划分明确，专业的人干专业的事。

**功能层，是指为实现该业务运转需要的业务功能。**这一层主要对应的是平台化中的柔性支撑的要求。

**我个人觉得业务功能可以由三种要素组合合成，分别为前端能力，后端能力以及业务规则组成，因此柔性支撑应该在这三种要素中均进行体现。**具体的做法，就是通过前端的模块化，后端的流程可配置化以及业务规则的可配置化，来实现业务功能的柔性支撑。

接口层，是指对底层功能的封装层。这一层主要对应的平台化中的归口管理的要求。通过接口层，由一个底层服务团队对多个业务方统一提供服务，从而做到底层功能的归口管理。

**应用层，是指业务方的应用层面。**业务方只需要对应接口层，即可实现想要的功能，对他们来说，底部的功能实现都是黑箱的，他们是需要用类似SDK的形式来与接口层进行交互即可。

【架构图见图一】

五、平台化改造实例

以上说了这么多，是不是感觉有些干瘪乏味呢？来上一个活生生的例子。以用户业务Q4进行的平台化改造为例，说明概念是如何与实际落地相结合的。

用户平台化在Q4主要干了4件事情：

1、将用户代码逻辑中实现风控功能的部分解耦，移交风控管理；

2、前端实现SDK化改造；

3、建立流程中心，注册业务实现流程可编排改造；

4、前端进行注册登录页组件化改造。

以上四点对应的是平台化模型的不同层级。

其中风控解耦实现的是业务层的业务分治，SDK实现的是接口层的归口管理，流程可编排及页面组件化实现的是功能层的柔性支撑，最终应用层（目前实现接入的有小店，uni等）需要接入的，只有底层团队提供的SDK，从而实现业务方对底层复杂的业务逻辑无感知的效果。

【用户平台化架构图见图二】

综上，平台化架构是一个在面对需求小批量、多批次、时效要求高的业务场景下的好选择，对于生产效率的提高是有极大好处的。以上是个人对于平台化的理解，可能不一定全部准确，还请大家包涵指正。

趁此机会感谢为用户业务平台化一直辛苦的各位团队成员~

@周末，@墨筝，@海敏，@乔希，@寻欢，@婉悦，@婉明，@完达，@如风，@修侎，@春晓，@欧祎等等，人有点多，列不完and感谢流量团队及uni团队的大力支持

大家一起加油，使我们平台建设得越来越好~

平台化架构模型.png(60.81 KB, 下载次数: 0)

图一——平台化架构图

用户平台化改造模型.png(65.64 KB, 下载次数: 0)

图二——用户平台化改造架构图