最近很火的概念是元宇宙，但在軟件設(shè)計(jì)領(lǐng)域，“元”的概念并不新鮮。

如果能把所有的數(shù)據(jù)記錄，用一套“元數(shù)據(jù)”關(guān)系描述出來，就完成了一套“軟件生態(tài)”或“軟件元宇宙”的打造。在同一套“描述語(yǔ)言”中的軟件，互相之間數(shù)據(jù)可以互通、邏輯可以共用，共同形成了一套生態(tài)。如果能夠把現(xiàn)實(shí)世界、宇宙完全數(shù)字化，并且用統(tǒng)一的語(yǔ)言進(jìn)行描述，就完成了一套“虛擬+現(xiàn)實(shí)”生態(tài)的打造，也就是我們說的“元宇宙”。

所以無論是對(duì)軟件還是世界的“元數(shù)據(jù)化”，“元”的本質(zhì)在于抽象、映射、配置化，在這一點(diǎn)上，元宇宙和aPaaS產(chǎn)品的互通統(tǒng)一的。

對(duì)我個(gè)人而言，這些年做了蠻多產(chǎn)品，帶給我最大成長(zhǎng)的集中在2類：

一類是，對(duì)內(nèi)容產(chǎn)品的抽象設(shè)計(jì)，就像之前拆解的B站那樣，只有深入思考過各類內(nèi)容和分發(fā)場(chǎng)景，才能對(duì)互聯(lián)網(wǎng)信息產(chǎn)品有較好的認(rèn)知。

另一類是，對(duì)軟件和平臺(tái)的抽象設(shè)計(jì)，需要PM在通用性和易用性上不斷權(quán)衡，這其中有大量的tradeoff和優(yōu)先級(jí)PK工作。

aPaaS產(chǎn)品就是后面這一類，也是今天我想在本文主要聊的一種產(chǎn)品。

隨著企業(yè)對(duì)軟件服務(wù)的預(yù)期越來越高，垂直、單點(diǎn)的SaaS產(chǎn)品已經(jīng)很難獨(dú)立商業(yè)化。所以能夠拉通SaaS的平臺(tái)級(jí)產(chǎn)品（aPaaS），逐步成為了SaaS產(chǎn)品經(jīng)理的發(fā)力方向。

所以，如果你對(duì)“元”這個(gè)概念的設(shè)計(jì)思路感興趣，或者你是軟件產(chǎn)品從業(yè)者，這篇文章或許能夠給你帶來啟發(fā)。

1.什么是aPaaS產(chǎn)品

要聊清楚軟件和aPaaS平臺(tái)產(chǎn)品，得先從概念入手。

為了方便理解，我先不去寬泛地定義這兩個(gè)詞，直接用實(shí)例講述：

aPaaS是能搭軟件的平臺(tái)，所以仔細(xì)想想， 一套軟件的定義，是什么？

一套軟件通常包含以下九個(gè)層次：

1. 應(yīng)用（application）

2. 數(shù)據(jù)（data）

3. 運(yùn)行庫(kù)（runtime）

4. 中間件（middleware）

5. 操作系統(tǒng)（OS）

6. 虛擬化技術(shù)（virtualization）

7. 服務(wù)器（servers）

8. 存儲(chǔ)（storage）

9. 網(wǎng)絡(luò)（networking）

通常PM所設(shè)計(jì)的界面、交互邏輯，其實(shí)都在1和2的應(yīng)用范疇內(nèi)。其它7種設(shè)備和技術(shù)因?yàn)橛袠O大的外部性，適合作為中臺(tái)，所以隨著互聯(lián)網(wǎng)的不斷發(fā)展，逐步被打包出售。他們的這種打包方法被稱為云技術(shù)，這種服務(wù)形式也就是云服務(wù)，比如阿里云、騰訊云。

這些云服務(wù)的出現(xiàn)，允許一些中小企業(yè)、沒必要自己維護(hù)設(shè)備和基建的企業(yè)能夠通過付費(fèi)租借的形式，便捷地復(fù)用這些服務(wù)。

基礎(chǔ)架構(gòu)即服務(wù)（IaaS）

平臺(tái)即服務(wù)（PaaS）

軟件即服務(wù)（SaaS）

aPaaS也是PaaS的一種。aPaaS的全稱是application Platform as a Service，即應(yīng)用程序平臺(tái)即服務(wù)。Gartner對(duì)其所下的定義是：“這是基于PaaS（平臺(tái)即服務(wù)）的一種解決方案，支持應(yīng)用程序在云端的開發(fā)、部署和運(yùn)行，提供軟件開發(fā)中的基礎(chǔ)工具給用戶，包括數(shù)據(jù)對(duì)象、權(quán)限管理、用戶界面等。”

2.aPaaS產(chǎn)品的設(shè)計(jì)原理是什么

2.1設(shè)計(jì)思路

用以終為始的思維來分析：其實(shí)，基于aPaaS產(chǎn)品搭建而成的軟件，就是一個(gè)SaaS應(yīng)用。

那不妨抽象一下，當(dāng)我們研發(fā)一款SaaS應(yīng)用時(shí)，我們做了哪些事情。

1. 定義線索、商機(jī)、客戶、聯(lián)系人、跟進(jìn)記錄實(shí)體

2. 設(shè)計(jì)實(shí)體的數(shù)據(jù)結(jié)構(gòu)、字段、索引

3. 為每個(gè)對(duì)象定義CRUD接口、數(shù)據(jù)校驗(yàn)邏輯、業(yè)務(wù)規(guī)則校驗(yàn)邏輯

4. 設(shè)計(jì)權(quán)限、審批流程、定時(shí)任務(wù)

5. 前端、移動(dòng)端頁(yè)面開發(fā)

6. 報(bào)表功能設(shè)計(jì)開發(fā)

這6步幾乎是一個(gè)標(biāo)準(zhǔn)CRM應(yīng)用的研發(fā)流程。

1. 降低邊際成本->復(fù)用和抽象是關(guān)鍵

2. 打破數(shù)據(jù)孤島->數(shù)據(jù)底層必須一套

于是aPaaS產(chǎn)品的底層思路就產(chǎn)生了：

只要把研發(fā)過程中的實(shí)體含義、數(shù)據(jù)結(jié)構(gòu)、CRUD進(jìn)行抽象，把數(shù)據(jù)和含義解耦，讓“含義”支持自定義，這樣數(shù)據(jù)層面就會(huì)非常干凈純粹，適合復(fù)用。舉個(gè)例子來說，當(dāng)我們需要一張“線索數(shù)據(jù)表”，傳統(tǒng)的方式是我們定義好“線索數(shù)據(jù)表”的每個(gè)字段完成建表。而將含義解耦后，我們只要讓“線索數(shù)據(jù)表”的描述變得可自定義配置化，就可以將無數(shù)這樣的業(yè)務(wù)表，都集合到統(tǒng)一的元數(shù)據(jù)層面，實(shí)現(xiàn)元數(shù)據(jù)（Meta）的抽象和復(fù)用。

進(jìn)而，如果這些元數(shù)據(jù)支持權(quán)限、租戶管理，也就實(shí)現(xiàn)了既能打破數(shù)據(jù)孤島進(jìn)行交互，又能多業(yè)務(wù)兼容互不影響的效果。

2.2數(shù)據(jù)實(shí)體實(shí)現(xiàn)方法

思路理完，具體實(shí)現(xiàn)層面上，關(guān)鍵點(diǎn)在于“元數(shù)據(jù)引擎”的構(gòu)建，以及meta和data之間的聯(lián)系。

為了實(shí)現(xiàn)“地板拼裝規(guī)則”的邏輯，需要把所有可能出現(xiàn)的“規(guī)則”進(jìn)行抽象。這里實(shí)現(xiàn)層面用的是field類型，而不是column類型，二者的區(qū)別在于：

翻譯過來的意思是“column只是field的一種存儲(chǔ)形式”。

舉個(gè)特別形象的例子，你的一個(gè)excel表格，就是一個(gè)data表，表頭有3列，分別是姓名、性別、年齡，這3列就是column。而姓名列是text文本、性別是布爾值、年齡是數(shù)值需要支持大小排序，這三種規(guī)則就是通過meta對(duì)象模型來實(shí)現(xiàn)的。我們事先定義好了文本、性別布爾值（男、女、其它）等規(guī)則，用object+field的對(duì)象模型規(guī)則存儲(chǔ)下來，支持column去使用，即可實(shí)現(xiàn)上面提到的“數(shù)據(jù)和含義解耦，從而元數(shù)據(jù)可復(fù)用、描述可配置”。

這種設(shè)計(jì)當(dāng)數(shù)據(jù)需要存儲(chǔ)到data中時(shí)，data需要知曉每個(gè)字段是什么樣的object，也就是業(yè)務(wù)系統(tǒng)需要依賴于“元數(shù)據(jù)引擎”。反過來，在業(yè)務(wù)系統(tǒng)在使用業(yè)務(wù)數(shù)據(jù)查詢data時(shí)，也需要“元數(shù)據(jù)引擎”做好column+含義的處理。

2.3業(yè)務(wù)規(guī)則的實(shí)現(xiàn)方法

1. 電銷業(yè)務(wù)可能認(rèn)為“手機(jī)號(hào)”是個(gè)必填字段，否則無法聯(lián)系客戶

2. 其它業(yè)務(wù)可能認(rèn)為“手機(jī)號(hào)”和“微信號(hào)”有其一即可

這兩種規(guī)則在SaaS模式下，都是用硬編碼的模式寫在應(yīng)用程序中的，一旦調(diào)整，需要研發(fā)去改邏輯、驗(yàn)證、上線，在規(guī)則頻繁變動(dòng)的情況下，非常棘手。所以，如果這些規(guī)則也能做到配置化，會(huì)減少很多變動(dòng)成本。

1.規(guī)則引擎：

2.流程引擎：

3.權(quán)限引擎：

SaaS理解為獨(dú)立單個(gè)系統(tǒng)，往往有角色控制即可滿足，而aPaaS可以理解為跨系統(tǒng)復(fù)雜模型，不但要管控系統(tǒng)內(nèi)的功能、應(yīng)用，還得對(duì)meta層、讀寫權(quán)限進(jìn)行管控。比如當(dāng)A工程師是“線索”實(shí)體owner時(shí)，一旦“線索”實(shí)體增加了一個(gè)不可操作的字段，也許是一個(gè)全新的、不被之前權(quán)限定義的字段，這時(shí)就需要對(duì)這個(gè)對(duì)象記錄的權(quán)限進(jìn)行管控，此時(shí)就需要引入對(duì)象、記錄等權(quán)限，只靠角色和數(shù)據(jù)表的權(quán)限，就不夠用了。

3.aPaaS設(shè)計(jì)干貨實(shí)例-權(quán)限設(shè)計(jì)

上面講了很多原理、方法、總結(jié)。這部分想用一個(gè)實(shí)例來讓文章更直觀完整。我想用“權(quán)限”這個(gè)模塊來作為實(shí)例。

權(quán)限模塊，在傳統(tǒng)SaaS中，其實(shí)并不算復(fù)雜。一般一個(gè)產(chǎn)品經(jīng)理半個(gè)人力就能cover住，只需要注意用戶A是否能用某系統(tǒng)，是否能查看某些數(shù)據(jù)、是否有編輯等功能權(quán)限即可。

但在aPaaS中，如上所說，已經(jīng)不僅僅是一個(gè)SaaS的權(quán)限問題，而是多個(gè)錯(cuò)綜復(fù)雜的SaaS權(quán)限問題。關(guān)鍵在于比SaaS來說，aPaaS核心的兩大能力：低代碼靈活配置和打破數(shù)據(jù)孤島，這決定了從產(chǎn)品上來說，一定會(huì)存在大量的元數(shù)據(jù)定義和大量的租戶，這樣一來，權(quán)限系統(tǒng)就會(huì)成倍復(fù)雜。

從數(shù)據(jù)實(shí)體來說，因?yàn)橐肓薿bject，就需要對(duì)這個(gè)維度進(jìn)行權(quán)限管控。object意味著某些字段對(duì)于用戶來說是否可用，這往往是根據(jù)角色來決定的。比如行政可以看到每把椅子的采購(gòu)價(jià)格和實(shí)付價(jià)格，而普通員工卻不關(guān)心也不應(yīng)該看到“椅子采購(gòu)系統(tǒng)”。

data層面，也要有記錄維度的管控。比如對(duì)于薪酬hr來說，應(yīng)該可以看到員工的薪資，而普通員工只能看到自己的薪酬，其區(qū)別不在于“薪酬”這個(gè)字段，而在于“別人的”“自己的”，所以并不是object層面的管控，而是data的record層面管控。

如上，object其實(shí)決定了領(lǐng)域，一個(gè)領(lǐng)域應(yīng)該有一個(gè)對(duì)應(yīng)的profile，比如采購(gòu)人員應(yīng)該負(fù)責(zé)采購(gòu)相關(guān)系統(tǒng)，所以需要一個(gè)采購(gòu)profile。如果采購(gòu)人員同時(shí)兼任HR，那么也應(yīng)該具有HR的profile。profile背后，是對(duì)一些實(shí)體、對(duì)象甚至系統(tǒng)的權(quán)限，可以和業(yè)務(wù)、事業(yè)領(lǐng)域做類似的映射。

在data層面，往往是記錄（record）的權(quán)限。比如“椅子采購(gòu)系統(tǒng)”的超級(jí)管理員應(yīng)該可以看到并修改全部“椅子實(shí)體”數(shù)據(jù)，而采購(gòu)助理可能只能查看、編輯自己提交的記錄，不能編輯別人創(chuàng)建的的“椅子采購(gòu)記錄”，這就是record級(jí)別的管控，一般是用于區(qū)分業(yè)務(wù)內(nèi)的不同崗位、角色。

領(lǐng)域、實(shí)體層面的profile權(quán)限

數(shù)據(jù)、記錄層面的role權(quán)限

人員變更

申請(qǐng)、審批

沖突、疊加

過期、續(xù)期

授權(quán)、回收...

如上，單單一個(gè)權(quán)限模塊，可能就有幾十個(gè)feature需要實(shí)現(xiàn)，而一個(gè)好的權(quán)限模塊，是一個(gè)aPaaS產(chǎn)品的基石，一定程度上決定了用戶復(fù)雜度和量級(jí)天花板。

4.aPaaS產(chǎn)品的PM在設(shè)計(jì)什么

1. 用戶

2. 需求

3. 產(chǎn)品方案

從用戶來說，純無代碼aPaaS產(chǎn)品的用戶，一般是業(yè)務(wù)運(yùn)營(yíng)人員。這個(gè)群體的特征是：

1）離業(yè)務(wù)近，會(huì)有大量的業(yè)務(wù)洞見和需求

2）無代碼能力，需要可視化界面甚至實(shí)施的輔助下完成搭建

特征1決定了：用戶會(huì)有大量的長(zhǎng)尾需求

特征2決定了：aPaaS編輯器的可用性極大影響遷移成本

1. 在大量的長(zhǎng)尾需求中，抽象并找到價(jià)值排序

2. 按照價(jià)值排序，不斷支持aPaaS產(chǎn)品的能力

3. 優(yōu)化編輯器和配置成品的體驗(yàn)

從aPaaS產(chǎn)品的能力來說，這里面最重要的，私以為，是“靈活度”。

1. 支持越復(fù)雜的object，比如數(shù)值、金額等，就能支持更多種數(shù)據(jù)進(jìn)入平臺(tái)

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

3. 支持的layout越多，比如移動(dòng)端界面、PC端界面、組件化，界面可配置能力越強(qiáng)

這里面，object是基礎(chǔ)，action經(jīng)過擴(kuò)充和編排可以流程化成為工作流，整體又通過靈活的多租戶、多角色權(quán)限體系來管控，共同構(gòu)成了aPaaS平臺(tái)的靈活性。

5.總結(jié)

aPaaS產(chǎn)品經(jīng)理，是軟件行業(yè)蓬勃發(fā)展和企業(yè)數(shù)字化進(jìn)程下對(duì)軟件要求不斷提高的產(chǎn)物。從需求和供給的角度上來說，aPaaS產(chǎn)品的發(fā)展都將是一種必然。希望所有的軟件相關(guān)PM都能了解這個(gè)領(lǐng)域、研究這個(gè)領(lǐng)域，這樣就相當(dāng)于站在“產(chǎn)品之外”來設(shè)計(jì)產(chǎn)品，會(huì)有更高層次的抽象意識(shí)。

但反過來說，aPaaS本質(zhì)是一套生態(tài)，如果大家都在做自己的生態(tài)，又不能互通，就會(huì)導(dǎo)致生態(tài)缺乏完整性，那么也就失去了價(jià)值。目前的TOB市場(chǎng)上，salesforce、企業(yè)微信等都有自己的生態(tài)，但國(guó)內(nèi)大量的企業(yè)還在數(shù)字化進(jìn)程中，最終這些生態(tài)何去何從，能建設(shè)到多大，仍存在較多變數(shù)。所以aPaaS領(lǐng)域最終會(huì)演化成怎樣的模式、有多久的周期，仍是未知。

理性地講，aPaaS要抽象起來，或許能裝下整個(gè)宇宙。但是，抽象的成本也是無限增加的。需要兼具智慧和勇氣的各位不斷探索，既不能把a(bǔ)PaaS做成強(qiáng)大但沒有場(chǎng)景的“屠龍之術(shù)”，也不能鉆牛角尖閉門造車，讓產(chǎn)品很難復(fù)用。“抽象歸納和具象定制平衡”的設(shè)計(jì)哲學(xué)，在aPaaS領(lǐng)域成為了核心問題，但在其它產(chǎn)品設(shè)計(jì)領(lǐng)域，也尤為重要。

引用：

科學(xué)網(wǎng)? Force.com的多租戶架構(gòu)理解(二) - 唐李洋的博文

一文講透APaaS平臺(tái)是什么

-END-