编辑导读：目前企业对软件服务的期望越来越高，垂直单点的SaaS产品已经很难独立商业化。aPaaS逐渐成为SaaS产品经理的方向。本文从“元”出发，讲解了aPaaS的相关知识。让我们来看看。 　　

　　

　　 　　

　　

　　最近流行的概念是元宇宙，但在软件设计领域，“元”的概念并不新鲜。如果所有的数据记录都可以用一组“元数据”关系来描述，那么一组“软件生态”或“软件元宇宙”就完成了。 　　

　　

　　 　　

　　

　　同一“描述语言”的软件可以互相交换数据，共享逻辑，共同形成一套生态。如果现实世界和宇宙能够完全数字化，用统一的语言来描述，就会构建出一套“虚拟现实”的生态，也就是我们所说的“元宇宙”。因此，无论是软件的“元数据”还是世界，“元”的本质在于抽象、映射和配置。在这一点上，元宇宙和aPaaS产品是可互操作和统一的。 　　

　　

　　我个人这几年做了相当多的产品，给我带来最大增长的有两类：一是内容产品的抽象设计，就像之前拆解的哔哩哔哩一样，要深入思考各种内容和分发场景，才能对互联网信息产品有更好的理解。另一个是软件和平台的抽象设计，需要PM不断平衡通用性和易用性，其中有很多权衡和优先级PK的工作。APaaS产品就是后一类，也是我今天这篇文章要讲的一个产品。 　　

　　

　　随着企业对软件服务的预期越来越高，垂直、单点的SaaS产品已经很难独立商业化。 　　

　　

　　因此，能够拉通SaaS的平台级产品(aPaaS)逐渐成为SaaS产品经理的方向。所以，如果你对“元”这个概念的设计思路感兴趣，或者你是一个软件产品从业者，这篇文章或许能给你启发。 　　

　　

　　#一、什么是aPaaS产品？ 　　

　　

　　要讲清楚软件和aPaaS平台产品，必须从概念入手。为了理解，这两个词我就不宽泛定义了，直接用例子告诉他们：aPaaS是一个可以搭建软件的平台，仔细想想。 　　

　　

　　一套软件的定义是什么？一套软件通常包括以下九个级别： 　　

　　

　　1.应用程序 　　

　　

　　2.数据(数据) 　　

　　

　　3.运行时 　　

　　

　　4.中间件 　　

　　

　　5.操作系统 　　

　　

　　6.虚拟化技术(虚拟化) 　　

　　

　　7.服务器(服务器) 　　

　　

　　8.储存；储备 　　

　　

　　9.建立工作关系网 　　

　　

　　通常PM设计的接口和交互逻辑实际上在1和2的应用范围内。其他7种设备和技术由于具有很大的外部性，适合作为中间站，所以随着互联网的不断发展，逐渐被打包出售。他们的包装方式叫做云技术，这种服务形式就是云服务，比如阿里巴巴云、腾讯云。这些云服务的出现，让一些不需要维护自己设备和基础设施的中小企业和企业，可以通过付费租赁的方式，方便地复用这些服务。 　　

　　

　　云服务的业务范围从基础到业务，可以分为以下服务类型： 　　

　　

　　*基础设施即服务(IaaS) 　　

　　

　　*平台即服务 　　

　　

　　*软件即服务(SaaS) 　　

　　

　　 　　

　　

　　预约挂号也是预约挂号的一种。aPaaS的全称是应用平台aS。 　　

　　

　　服务，即应用平台即服务。Gartner将其定义为：“这是一个基于PaaS(平台即服务)的解决方案， 　　

　　

　　支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。" 　　

　　

　　总之：在aPaaS模式下，非技术人员也可以通过低代码编辑器“所见即所得”来完成产品的配置和开发。 　　

　　

　　# 2.aPaaS产品的设计原则是什么？ 　　

　　

　　## 1\.设计理念 　　

　　

　　从头到尾分析一下：其实基于aPaaS产品的软件是一个SaaS应用。 　　

　　

　　让我们抽象一下。当我们开发SaaS应用程序时，我们做了什么？为了方便理解，我以大家最熟悉的CRM系统作为案例。想象一下安装一个客户关系管理软件需要多少步骤： 　　

　　

　　1.定义销售线索、业务机会、客户、联系人和后续记录实体。 　　

　　

　　2.设计实体的数据结构、字段和索引。 　　

　　

　　3.为每个对象定义CRUD接口、数据检查逻辑和业务规则检查逻辑。 　　

　　

　　4.设计权限、审批流程和计划任务 　　

　　

　　5.移动前端 　　

端页面开发

　　

6. 报表功能设计开发

　　

这6步几乎是一个标准CRM应用的研发流程。如果你是一个运营了10万名销售的业务leader，选择这样的标准“定制化开发”模式做一套CRM是没问题的。但如果你的业务量过小，定制化CRM的ROI极低；更极端的场景是，如果你的10万名销售业务模式迥异，需要10套CRM来支撑呢？这个时候，我们需要一种低成本开发CRM的方式，才能让ROI打正。并且这种方式，需要能够拉通底层数据，避免独立搭建10套CRM带来的数据孤岛问题。

　　

1. 降低边际成本->复用和抽象是关键

　　

2. 打破数据孤岛->数据底层必须一套

　　

于是aPaaS产品的底层思路就产生了：只要把研发过程中的实体含义、数据结构、CRUD进行抽象，把数据和含义解耦，让“含义”支持自定义，这样数据层面就会非常干净纯粹，适合复用。举个例子来说，当我们需要一张“线索数据表”，传统的方式是我们定义好“线索数据表”的每个字段完成建表。而将含义解耦后，我们只要让“线索数据表”的描述变得可自定义配置化，就可以将无数这样的业务表，都集合到统一的元数据层面，实现元数据（Meta）的抽象和复用。

　　

进而，如果这些元数据支持权限、租户管理，也就实现了既能打破数据孤岛进行交互，又能多业务兼容互不影响的效果。具体点说，就是这SaaS模式下，我们生产的是“成品地板”，这样的问题在于如果有新的地板拼装样式，我们很难调整生产线。但在aPaaS模式下，我们把生产线拆成“木头生产”和“地板拼装”两步，只要保持木头的生产，同时不断更新“地板拼装规则”，就可以源源不断地适应各种“成品地板”需求。

　　

所以，aPaaS产品实际上是定义了一套标准化的“地板拼装规则”和能够识别这个规则转化成拼装动作的“地板拼装规则识别机器”，这个机器就是能够联系meta和data的“元数据引擎”。

　　

## 2\. 数据实体实现方法

　　

　　

思路理完，具体实现层面上，关键点在于“元数据引擎”的构建，以及meta和data之间的联系。为了实现“地板拼装规则”的逻辑，需要把所有可能出现的“规则”进行抽象。

　　

这里实现层面用的是field类型，而不是column类型，二者的区别在于：

　　

A column is collection of cells aligned vertically in a table. A field is an

　　

element in which one piece of information is stored, such as the eceived

　　

field.

　　

Usually, a column in a table contains the values of a single field. However,

　　

you can show several fields in a column by using a Formula or a

　　

Combination field. Fields can also be shown as rows in a card view or as

　　

controls on a form. A column is just one way to display the contents of a

　　

field.

　　

翻译过来的意思是“column只是field的一种存储形式”。举个特别形象的例子，你的一个excel表格，就是一个data表，表头有3列，分别是姓名、性别、年龄，这3列就是column。而姓名列是text文本、性别是布尔值、年龄是数值需要支持大小排序，这三种规则就是通过meta对象模型来实现的。

　　

我们事先定义好了文本、性别布尔值（男、女、其它）等规则，用object field的对象模型规则存储下来，支持column去使用，即可实现上面提到的“数据和含义解耦，从而元数据可复用、描述可配置”。

　　

　　

这种设计当数据需要存储到data中时，data需要知晓每个字段是什么样的object，也就是业务系统需要依赖于“元数据引擎”。反过来，在业务系统在使用业务数据查询data时，也需要“元数据引擎”做好column 含义的处理。

　　

## 3\. 业务规则的实现方法

　　

有了数据实体，还需要有大量的业务规则。举个例子，拿线索实体来说：

　　

1. 电销业务可能认为“手机号”是个必填字段，否则无法联系客户

　　

2. 其它业务可能认为“手机号”和“微信号”有其一即可

　　

这两种规则在SaaS模式下，都是用硬编码的模式写在应用程序中的，一旦调整，需要研发去改逻辑、验证、上线，在规则频繁变动的情况下，非常棘手。所以，如果这些规则也能做到配置化，会减少很多变动成本。要抽象并配置这些业务规则，至少需要3种引擎：

　　

1）规则引擎

　　

类似上面提到的，字段校验、过滤、表单引用联动等，如果可选、必填；字段长度、格式；是否引用关联这些都可配置，大量的基础硬编码工作将被aPaaS取代，研发工程师可以一劳永逸。

　　

2）流程引擎

　　

处理静态规则之外的，当系统发生交互后的流程处理，包括各类触发和执行、通知反馈。比如当用户拨打电话后，记录一次跟进，同时给TA的主管推送一条消息。这样的流程其实抽象出来后，就是“触发”“编排”和“执行”“反馈”，是可以像画流程图一样配置出来的。

　　

3）权限引擎

　　

SaaS理解为独立单个系统，往往有角色控制即可满足，而aPaaS可以理解为跨系统复杂模型，不但要管控系统内的功能、应用，还得对meta层、读写权限进行管控。

　　

比如当A工程师是“线索”实体owner时，一旦“线索”实体增加了一个不可操作的字段，也许是一个全新的、不被之前权限定义的字段，这时就需要对这个对象记录的权限进行管控，此时就需要引入对象、记录等权限，只靠角色和数据表的权限，就不够用了。综上，通过对规则、流程、权限进行配置化处理，能够让软件的主干业务逻辑部分支持配置化，是aPaaS的核心能力之一。

　　

# 三、aPaaS设计干货实例-权限设计

　　

上面讲了很多原理、方法、总结。这部分想用一个实例来让文章更直观完整。我想用“权限”这个模块来作为实例。权限模块，在传统SaaS中，其实并不算复杂。一般一个产品经理半个人力就能cover住，只需要注意用户A是否能用某系统，是否能查看某些数据、是否有编辑等功能权限即可。但在aPaaS中，如上所说，已经不仅仅是一个SaaS的权限问题，而是多个错综复杂的SaaS权限问题。

　　

关键在于比SaaS来说，aPaaS核心的两大能力：低代码灵活配置和打破数据孤岛，这决定了从产品上来说，一定会存在大量的元数据定义和大量的租户，这样一来，权限系统就会成倍复杂。但无需担心，可以直接用类比SaaS的方式进行产品设计。

　　

从数据实体来说，

　　

因为引入了object，就需要对这个维度进行权限管控。object意味着某些字段对于用户来说是否可用，这往往是根据角色来决定的。比如行政可以看到每把椅子的采购价格和实付价格，而普通员工却不关心也不应该看到“椅子采购系统”。

　　

data层面，

　　

也要有记录维度的管控。比如对于薪酬hr来说，应该可以看到员工的薪资，而普通员工只能看到自己的薪酬，其区别不在于“薪酬”这个字段，而在于“别人的”“自己的”，所以并不是object层面的管控，而是data的record层面管控。

　　

如上，object其实决定了领域，一个领域应该有一个对应的profile，比如采购人员应该负责采购相关系统，所以需要一个采购profile。如果采购人员同时兼任HR，那么也应该具有HR的profile。profile背后，是对一些实体、对象甚至系统的权限，可以和业务、事业领域做类似的映射。

　　

在data层面，往往是记录（record）的权限。比如“椅子采购系统”的超级管理员应该可以看到并修改全部“椅子实体”数据，而采购助理可能只能查看、编辑自己提交的记录，不能编辑别人创建的的“椅子采购记录”，这就是record级别的管控，一般是用于区分业务内的不同岗位、角色。所以对于aPaaS的权限系统来说，至少要设计2个层次的权限：

　　

* 领域、实体层面的profile权限

　　

* 数据、记录层面的role权限

　　

在这个基础上，还有更多的场景需要考虑，比如：

　　

* 人员变更

　　

* 申请、审批

　　

* 冲突、叠加

　　

* 过期、续期

　　

* 授权、回收

　　

* …

　　

如上，单单一个权限模块，可能就有几十个feature需要实现，而一个好的权限模块，是一个aPaaS产品的基石，一定程度上决定了用户复杂度和量级天花板。

　　

# 四、aPaaS产品的PM在设计什么

　　

从aPaaS产品PM视角出发，想回答“aPaaS产品设计和常规产品设计的不同“，就不得不从PM的核心工作要素谈起：

　　

　　

从用户来说，纯无代码aPaaS产品的用户，一般是业务运营人员。这个群体的特征是：

　　

* 离业务近，会有大量的业务洞见和需求

　　

* 无代码能力，需要可视化界面甚至实施的辅助下完成搭建

　　

特征1决定了：用户会有大量的长尾需求特征2决定了：aPaaS编辑器的可用性极大影响迁移成本所以，我个人认为，aPaaS产品经理的关键在于如下三点：

　　

1. 在大量的长尾需求中，抽象并找到价值排序

　　

2. 按照价值排序，不断支持aPaaS产品的能力

　　

3. 优化编辑器和配置成品的体验

　　

从aPaaS产品的能力来说，这里面最重要的，私以为，是“灵活度”。上文提到，灵活度来自于配置能力。而配置能力的关键在于能把“不变的逻辑”元数据化，同时把“灵活可变的逻辑”配置化、描述化。具体来说：

　　

1. 支持越复杂的object，比如数值、金额等，就能支持更多种数据进入平台

　　

2. 支持的action越多，比如搜索、筛选、排序等，可配置的功能类型就越多

　　

3. 支持的layout越多，比如移动端界面、PC端界面、组件化，界面可配置能力越强

　　

这里面，object是基础，action经过扩充和编排可以流程化成为工作流，整体又通过灵活的多租户、多角色权限体系来管控，共同构成了aPaaS平台的灵活性。这样分析下来，aPaaS产品经理做的工作，实际上是把研发流程变得可视化、配置化。从一次做一个SaaS产品，到一次做一批SaaS产品的配置能力。这需要出众的实体抽象和领域设计能力，以及良好的体验品味。

　　

# 五、总结

　　

aPaaS产品经理，是软件行业蓬勃发展和企业数字化进程下对软件要求不断提高的产物。从需求和供给的角度上来说，aPaaS产品的发展都将是一种必然。希望所有的软件相关PM都能了解这个领域、研究这个领域，这样就相当于站在“产品之外”来设计产品，会有更高层次的抽象意识。

　　

但反过来说，aPaaS本质是一套生态，如果大家都在做自己的生态，又不能互通，就会导致生态缺乏完整性，那么也就失去了价值。目前的TOB市场上，salesforce、企业微信等都有自己的生态，但国内大量的企业还在数字化进程中，最终这些生态何去何从，能建设到多大，仍存在较多变数。所以aPaaS领域最终会演化成怎样的模式、有多久的周期，仍是未知。理性地讲，aPaaS要抽象起来，或许能装下整个宇宙。

　　

但是，抽象的成本也是无限增加的。需要兼具智慧和勇气的各位不断探索，既不能把aPaaS做成强大但没有场景的“屠龙之术”，也不能钻牛角尖闭门造车，让产品很难复用。“抽象归纳和具象定制平衡”的设计哲学，在aPaaS领域成为了核心问题，但在其它产品设计领域，也尤为重要。

　　

所以最后，愿诸君能在抽象与具象之间，用对业务的理解，找到产品力和成本的最佳平衡。

　　

引用：

　　

* 科学网 Force.com的多租户架构理解（二） – 唐李洋的博文

　　

* 一文讲透APaaS平台是什么

　　

* 7.2.1 预置对象管理 · 纷享销客产品手册

　　

## #专栏作家#

　　

花生酱先生，微信公众号：产品之术，人人都是产品经理专栏作家。金融业资深产品经理，对职涯规划与个人发展有丰富经验，产品涉猎广泛，ERP、金融领域较多。

　　

本文原创发布于人人都是产品经理。未经许可，禁止转载

　　

题图来自Pixabay，基于CC0协议