最近很火的概念是元宇宙，但在软件设计领域，“元”的概念并不新鲜。

如果能把所有的数据记录，用一套“元数据”关系描述出来，就完成了一套“软件生态”或“软件元宇宙”的打造。在同一套“描述语言”中的软件，互相之间数据可以互通、逻辑可以共用，共同形成了一套生态。如果能够把现实世界、宇宙完全数字化，并且用统一的语言进行描述，就完成了一套“虚拟+现实”生态的打造，也就是我们说的“元宇宙”。

所以无论是对软件还是世界的“元数据化”，“元”的本质在于抽象、映射、配置化，在这一点上，元宇宙和aPaaS产品的互通统一的。

对我个人而言，这些年做了蛮多产品，带给我最大成长的集中在2类：

一类是，对内容产品的抽象设计，就像之前拆解的B站那样，只有深入思考过各类内容和分发场景，才能对互联网信息产品有较好的认知。

另一类是，对软件和平台的抽象设计，需要PM在通用性和易用性上不断权衡，这其中有大量的tradeoff和优先级PK工作。

aPaaS产品就是后面这一类，也是今天我想在本文主要聊的一种产品。随着企业对软件服务的预期越来越高，垂直、单点的SaaS产品已经很难独立商业化。所以能够拉通SaaS的平台级产品（aPaaS），逐步成为了SaaS产品经理的发力方向。

所以，如果你对“元”这个概念的设计思路感兴趣，或者你是软件产品从业者，这篇文章或许能够给你带来启发。

 

1.什么是aPaaS产品

要聊清楚软件和aPaaS平台产品，得先从概念入手。为了方便理解，我先不去宽泛地定义这两个词，直接用实例讲述：aPaaS是能搭软件的平台，所以仔细想想， 一套软件的定义，是什么？一套软件通常包含以下九个层次：

  1. 应用（application）
  2. 数据（data）
  3. 运行库（runtime）
  4. 中间件（middleware）
  5. 操作系统（OS）
  6. 虚拟化技术（virtualization）
  7. 服务器（servers）
  8. 存储（storage）
  9. 网络（networking）

通常PM所设计的界面、交互逻辑，其实都在1和2的应用范畴内。其它7种设备和技术因为有极大的外部性，适合作为中台，所以随着互联网的不断发展，逐步被打包出售。他们的这种打包方法被称为云技术，这种服务形式也就是云服务，比如阿里云、腾讯云。这些云服务的出现，允许一些中小企业、没必要自己维护设备和基建的企业能够通过付费租借的形式，便捷地复用这些服务。随着云服务的业务范围从基础到业务，可以分为如下几种服务类型：

  • 基础架构即服务（IaaS）
  • 平台即服务（PaaS）
  • 软件即服务（SaaS）

aPaaS也是PaaS的一种。aPaaS的全称是application Platform as a Service，即应用程序平台即服务。Gartner对其所下的定义是：“这是基于PaaS（平台即服务）的一种解决方案，

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

”一句话讲：aPaaS模式下，非技术人员也可以通过低代码编辑器来“所见即所得”地完成产品的配置开发落地。

 

2.aPaaS产品的设计原理是什么

2.1设计思路

用以终为始的思维来分析：其实，基于aPaaS产品搭建而成的软件，就是一个SaaS应用。那不妨抽象一下，当我们研发一款SaaS应用时，我们做了哪些事情。为了方便理解，我拿大家最熟悉的CRM系统来做case。试想一下，落地一款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.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+含义的处理。

 

2.3业务规则的实现方法

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

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

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

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

规则引擎：

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

流程引擎：

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

权限引擎：

SaaS理解为独立单个系统，往往有角色控制即可满足，而aPaaS可以理解为跨系统复杂模型，不但要管控系统内的功能、应用，还得对meta层、读写权限进行管控。比如当A工程师是“线索”实体owner时，一旦“线索”实体增加了一个不可操作的字段，也许是一个全新的、不被之前权限定义的字段，这时就需要对这个对象记录的权限进行管控，此时就需要引入对象、记录等权限，只靠角色和数据表的权限，就不够用了。综上，通过对规则、流程、权限进行配置化处理，能够让软件的主干业务逻辑部分支持配置化，是aPaaS的核心能力之一。

 

3.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产品的基石，一定程度上决定了用户复杂度和量级天花板。

 

4.aPaaS产品的PM在设计什么

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

  1. 用户
  2. 需求
  3. 产品方案

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

  • 1）离业务近，会有大量的业务洞见和需求
  • 2）无代码能力，需要可视化界面甚至实施的辅助下完成搭建

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

  1. 在大量的长尾需求中，抽象并找到价值排序
  2. 按照价值排序，不断支持aPaaS产品的能力
  3. 优化编辑器和配置成品的体验

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

  • 支持越复杂的object，比如数值、金额等，就能支持更多种数据进入平台
  • 支持的action越多，比如搜索、筛选、排序等，可配置的功能类型就越多
  • 支持的layout越多，比如移动端界面、PC端界面、组件化，界面可配置能力越强

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

 

5.总结

aPaaS产品经理，是软件行业蓬勃发展和企业数字化进程下对软件要求不断提高的产物。从需求和供给的角度上来说，aPaaS产品的发展都将是一种必然。

希望所有的软件相关PM都能了解这个领域、研究这个领域，这样就相当于站在“产品之外”来设计产品，会有更高层次的抽象意识。

但反过来说，aPaaS本质是一套生态，如果大家都在做自己的生态，又不能互通，就会导致生态缺乏完整性，那么也就失去了价值。

目前的TOB市场上，salesforce、企业微信等都有自己的生态，但国内大量的企业还在数字化进程中，最终这些生态何去何从，能建设到多大，仍存在较多变数。所以aPaaS领域最终会演化成怎样的模式、有多久的周期，仍是未知。

理性地讲，aPaaS要抽象起来，或许能装下整个宇宙。但是，抽象的成本也是无限增加的。

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

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