a站和哔哩哔哩(产品领域的元宇宙)有什么区别？
编辑导语：目前企业对软件服务的期望越来越高，垂直、单点的SaaS产品很难独立商业化。aPaaS已经逐渐成为SaaS产品经理的方向。从& quot袁& quot，本文讲解了aPaaS的相关知识。让我们来看看。
元宇宙的概念最近非常流行，但是在软件设计领域中& quotmeta & quot不是新的。如果所有的数据记录都可以用一组& quot元数据& quot关系，一套& quot软件生态学& quot或者& quot软件元宇宙& quot将被完成。
同一套& quot描述语言& quot可以互相共享数据和逻辑，共同形成一套生态。如果现实世界和宇宙可以完全数字化，并用统一的语言描述，一套& quot虚拟现实& quot生态将被建立，这就是我们所说的& quot元宇宙& quot。因此，无论是& quot元数据& quot软件或世界的本质& quotmeta & quot在于抽象、映射和配置。至此，元宇宙和aPaaS产品统一了。
我个人这些年做了很多产品，成长最大的集中在两类：一类是内容产品的抽象设计，就像之前被拆的哔哩哔哩。只有深入思考各种内容和分发场景，才能对互联网信息产品有更好的理解。另一个是软件和平台的抽象设计，需要PM不断权衡通用性和易用性，有大量的权衡和优先级PK工作。APaaS产品就是后一类，也是我今天这篇文章要讲的产品。
随着企业对软件服务的预期越来越高，垂直、单点的SaaS产品已经很难独立商业化。
因此，能够打通SaaS的平台级产品(aPaaS)逐渐成为SaaS产品经理的方向。因此，如果你对& quotmeta & quot，或者如果你是软件产品从业者，这篇文章可能会给你启发。
一、什么是aPaaS产品？要说清楚软件和aPaaS平台产品，必须从概念说起。为了便于理解，我就不对这两个词做宽泛的定义，直接用例子告诉他们：aPaaS是一个搭建软件的平台，所以要仔细考虑。一套软件的定义是什么？一套软件通常包括以下九个层次：
应用(数据)运行时(中间件)操作系统(OS)虚拟化技术(服务器)存储(联网)通常由PM设计的接口和交互逻辑，其实都在1和2的应用范围之内。随着互联网的不断发展，其他7种设备和技术因其具有很大的外部性，适合作为中间站，也逐渐打包出售。他们的包装方式叫云技术，这种服务形式也是云服务，比如阿里云、腾讯云。这些云服务的出现，让一些中小企业和不需要自己维护设备和基础设施的企业，可以通过付费租赁的方式，方便地重用这些服务。
随着云服务的业务范围从基础到业务，可以分为以下服务类型：
基础设施即服务(IaaS)平台即服务(PaaS)软件即服务(SaaS)aPaaS也是一种PaaS。aPaaS的全称是applicationPlatformasaService，即应用平台即服务。Gartner将其定义为：& quot这是一个基于支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。" PaaS(平台即服务)的解决方案。
一句话：在aPaaS模式下，非技术人员也可以通过一个低代码编辑器完成产品的配置和开发。
二、aPaaS产品的设计原理是什么？1.以出发思维分析设计思路：其实基于aPaaS产品构建的软件就是一个SaaS应用。
让我们抽象一下开发SaaS应用程序时我们做了什么。为了便于理解，我以大家最熟悉的CRM系统为案例。想象一下，登陆一个CRM软件分为几个步骤：
定义线索、商机、客户、联系人、跟进记录，设计实体数据结构、字段、索引，为每个对象定义CRUD接口，数据验证逻辑，业务规则验证逻辑设计权限，审批流程，定时任务前端，移动页面开发报表功能设计开发，这几乎是一个标准的CRM应用开发流程。如果你是一个10万销售额的商业领袖，选择这样的标准是没有问题的& quot定制开发& quot制作CRM的模式。但如果你的业务量太小，定制化CRM的ROI极低；更极端的场景是，如果你的10万个销售业务模式差异很大，那你需要10套CRM来支撑呢？这时候就需要一个低成本的方式来开发CRM，才能让ROI正确。并且通过这种方式，我们需要能够拉通底层数据，避免独立搭建10套CRM带来的数据孤岛问题。
降低边际成本——重用和抽象是打破数据孤岛的关键——数据的底层必须是一个集合，于是aPaaS产品的底层思想应运而生：只要在R & amp过程被抽象，数据和意义被分离，并且& quot含义& quot支持定制，这样数据层会非常干净纯粹，适合重用。例如，当我们需要一个& quot线索数据表& quot，传统的方法是我们定义每个领域的& quot线索数据表& quot完成表格。在分离了意义之后，我们只需要让& quot
线索数据表”的描述变得可自定义配置化，就可以将无数这样的业务表，都集合到统一的元数据层面，实现元数据（Meta）的抽象和复用。进而，如果这些元数据支持权限、租户管理，也就实现了既能打破数据孤岛进行交互，又能多业务兼容互不影响的效果。具体点说，就是这SaaS模式下，我们生产的是“成品地板”，这样的问题在于如果有新的地板拼装样式，我们很难调整生产线。但在aPaaS模式下，我们把生产线拆成“木头生产”和“地板拼装”两步，只要保持木头的生产，同时不断更新“地板拼装规则”，就可以源源不断地适应各种“成品地板”需求。
所以，aPaaS产品实际上是定义了一套标准化的“地板拼装规则”和能够识别这个规则转化成拼装动作的“地板拼装规则识别机器”，这个机器就是能够联系meta和data的“元数据引擎”。
思路理完，具体实现层面上，关键点在于“元数据引擎”的构建，以及meta和data之间的联系。为了实现“地板拼装规则”的逻辑，需要把所有可能出现的“规则”进行抽象。
这里实现层面用的是field类型，而不是column类型，二者的区别在于：
Acolumniscollectionofcellsalignedverticallyinatable.Afieldisanelementinwhichonepieceofinformationisstored,suchastheeceivedfield.
Usually,acolumninatablecontainsthevaluesofasinglefield.However,youcanshowseveralfieldsinacolumnbyusingaFormulaoraCombinationfield.Fieldscanalsobeshownasrowsinacardvieworascontrolsonaform.Acolumnisjustonewaytodisplaythecontentsofafield.
翻译过来的意思是“column只是field的一种存储形式”。举个特别形象的例子，你的一个excel表格，就是一个data表，表头有3列，分别是姓名、性别、年龄，这3列就是column。而姓名列是text文本、性别是布尔值、年龄是数值需要支持大小排序，这三种规则就是通过meta对象模型来实现的。
我们事先定义好了文本、性别布尔值（男、女、其它）等规则，用object+field的对象模型规则存储下来，支持column去使用，即可实现上面提到的“数据和含义解耦，从而元数据可复用、描述可配置”。
这种设计当数据需要存储到data中时，data需要知晓每个字段是什么样的object，也就是业务系统需要依赖于“元数据引擎”。反过来，在业务系统在使用业务数据查询data时，也需要“元数据引擎”做好column+含义的处理。
有了数据实体，还需要有大量的业务规则。举个例子，拿线索实体来说：
电销业务可能认为“手机号”是个必填字段，否则无法联系客户其它业务可能认为“手机号”和“微信号”有其一即可这两种规则在SaaS模式下，都是用硬编码的模式写在应用程序中的，一旦调整，需要研发去改逻辑、验证、上线，在规则频繁变动的情况下，非常棘手。所以，如果这些规则也能做到配置化，会减少很多变动成本。要抽象并配置这些业务规则，至少需要3种引擎：
1）规则引擎
类似上面提到的，字段校验、过滤、表单引用联动等，如果可选、必填；字段长度、格式；是否引用关联这些都可配置，大量的基础硬编码工作将被aPaaS取代，研发工程师可以一劳永逸。
2）流程引擎
处理静态规则之外的，当系统发生交互后的流程处理，包括各类触发和执行、通知反馈。比如当用户拨打电话后，记录一次跟进，同时给TA的主管推送一条消息。这样的流程其实抽象出来后，就是“触发”“编排”和“执行”“反馈”，是可以像画流程图一样配置出来的。
3）权限引擎
SaaS理解为独立单个系统，往往有角色控制即可满足，而aPaaS可以理解为跨系统复杂模型，不但要管控系统内的功能、应用，还得对meta层、读写权限进行管控。
比如当A工程师是“线索”实体owner时，一旦“线索”实体增加了一个不可操作的字段，也许是一个全新的、不被之前权限定义的字段，这时就需要对这个对象记录的权限进行管控，此时就需要引入对象、记录等权限，只靠角色和数据表的权限，就不够用了。综上，通过对规则、流程、权限进行配置化处理，能够让软件的主干业务逻辑部分支持配置化，是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产品的用户，一般是业务运营人员。这个群体的特征是：
离业务近，会有大量的业务洞见和需求无代码能力，需要可视化界面甚至实施的辅助下完成搭建特征1决定了：用户会有大量的长尾需求特征2决定了：aPaaS编辑器的可用性极大影响迁移成本所以，我个人认为，aPaaS产品经理的关键在于如下三点：
在大量的长尾需求中，抽象并找到价值排序按照价值排序，不断支持aPaaS产品的能力优化编辑器和配置成品的体验从aPaaS产品的能力来说，这里面最重要的，私以为，是“灵活度”。上文提到，灵活度来自于配置能力。而配置能力的关键在于能把“不变的逻辑”元数据化，同时把“灵活可变的逻辑”配置化、描述化。具体来说：
支持越复杂的object，比如数值、金额等，就能支持更多种数据进入平台支持的action越多，比如搜索、筛选、排序等，可配置的功能类型就越多支持的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协议