在同一套“描述语言”中的软件，互相之间数据可以互通、逻辑可以共用，共同形成了一套生态。如果能够把现实世界、宇宙完全数字化，并且用统一的语言进行描述，就完成了一套“虚拟 现实”生态的打造，也就是我们说的“元宇宙”。所以无论是对软件还是世界的“元数据化”，“元”的本质在于抽象、映射、配置化，在这一点上，元宇宙和aPaaS产品的互通统一的。
这种设计当数据需要存储到data中时，data需要知晓每个字段是什么样的object，也就是业务系统需要依赖于“元数据引擎”。反过来，在业务系统在使用业务数据查询data时，也需要“元数据引擎”做好column 含义的处理。
从用户来说，纯无代码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 预置对象管理 · 纷享销客产品手册
