從no-code到low-code：企業(yè)級(jí)hpaPaaS的未來

引子

宜搭負(fù)責(zé)人驍勇給我舉過一個(gè)例子，我們小時(shí)候逢年過節(jié)穿的衣服，都是去裁縫店選一下材料、量一下尺寸，等個(gè)半個(gè)來月，討回來就可以穿了，衣服合身又喜歡。鏡頭切回今天，我們只需要在天貓、淘寶上看看圖片、選擇合適的尺寸就可以下單了，第二天就可以穿上，偶爾一絲不合身，偶爾大街上撞衫，但我們并不在意，因?yàn)槲覀兿硎艿搅烁嗟谋憷c高效。受益于這個(gè)產(chǎn)業(yè)制定了很多的標(biāo)準(zhǔn)化模型，比如身材模型：S、L、XL、XXL，我不再需要每次都去量身高尺寸，現(xiàn)在標(biāo)準(zhǔn)化生產(chǎn)出來的衣服可以滿足超過 90% 的需求，除明星或特殊場景之外也不會(huì)費(fèi)心思去量身定制。

服裝、飲食、汽車乃至各行各業(yè)發(fā)展至今都已經(jīng)形成非常成熟、高效的產(chǎn)業(yè)鏈，軟件研發(fā)行業(yè)同樣如此，業(yè)務(wù)需求在增長且變化快，越是技術(shù)密集型的工種越容易帶來人力不足的瓶頸。這就越需要更多的標(biāo)準(zhǔn)和模型的制定，標(biāo)準(zhǔn)越趨于統(tǒng)一，就越高效，有時(shí)候 “放棄創(chuàng)造力才是最大的創(chuàng)造力”，本質(zhì)是追求普惠，可以預(yù)見，未來絕大多數(shù)場景將使用標(biāo)準(zhǔn)化模板通過無定制或低定制來完成業(yè)務(wù)需求。

期望的軟件研發(fā)姿勢

接下來就簡單談一談基于 no-code > low-code > pro-code 漸進(jìn)式思路的研發(fā)體系。

一  前置概念

在開篇之前先介紹幾個(gè)概念：

云計(jì)算主要分為三大類服務(wù)：軟件即服務(wù) (SaaS)、平臺(tái)即服務(wù) (PaaS) 和基礎(chǔ)架構(gòu)即服務(wù) (IaaS)。

• 軟件即服務(wù) (SaaS) 是一種通過互聯(lián)網(wǎng)交付應(yīng)用的模式?？蛻裟軌蛲ㄟ^ Web 瀏覽器訪問 SaaS 應(yīng)用，這意味著，客戶無需購買、安裝、維護(hù)和更新硬件或軟件。SaaS 提供商負(fù)責(zé)確保一切順利進(jìn)行，而且客戶通常能夠使用最新版本的應(yīng)用。

• 平臺(tái)即服務(wù) (PaaS) 能夠提供云平臺(tái)和各種工具，幫助開發(fā)人員構(gòu)建和部署云應(yīng)用。用戶可以通過 Web 瀏覽器訪問 PaaS，所以企業(yè)無需購買和維護(hù)基礎(chǔ)硬件和軟件。借助 PaaS，開發(fā)人員還能采用租用的方式挑選所需的功能。

• 采用基礎(chǔ)架構(gòu)即服務(wù) (IaaS)，企業(yè)可以通過按使用付費(fèi)的方式，“租用”服務(wù)器、網(wǎng)絡(luò)、存儲(chǔ)器和操作系統(tǒng)等計(jì)算資源。IaaS 提供商負(fù)責(zé)托管基礎(chǔ)架構(gòu)和處理系統(tǒng)維護(hù)及備份等任務(wù)，這樣，客戶就無需購買硬件或雇傭內(nèi)部專家對(duì)其進(jìn)行管理。

在 PaaS 層有專門用來支持應(yīng)用在云上開發(fā)、部署、運(yùn)行的平臺(tái)，稱之為 aPaaS (Application platform as a service)，在 aPaaS 基礎(chǔ)上，提供 no-code & low-code 方式開發(fā)應(yīng)用的平臺(tái)稱之為 hpaPaaS (High-productivity aPaaS)，提供快速應(yīng)用研發(fā)能力，比如業(yè)務(wù)編排、邏輯編排、模型驅(qū)動(dòng)、頁面編排等。

以上概念加入了一些我的個(gè)人理解，不同平臺(tái)可能有不同解釋，我們接下來對(duì)比一下業(yè)內(nèi)幾款明星平臺(tái)，看能給到我們什么參考？

二  業(yè)內(nèi)精品

• Microsoft PowerApps：微軟全家桶服務(wù)集成的非常好，比如 Excel，全站寫代碼的地方都統(tǒng)一為 Excel 相似的概念 Formula/Fx，另外 PowerBI/PowerFlow 十分強(qiáng)大，定位 hpaPaaS (low-code)；

• Google AppMaker：谷歌產(chǎn)，谷歌全家桶服務(wù)集成的非常好，谷歌工程師文化在 SCRIPTS 體現(xiàn)得比較極致，無論是后端、前端都使用開發(fā)生態(tài)的 JS 語法，代碼提示十分友好，定位 hpaPaaS (low-code);

• Salesforce SaaS：平臺(tái)領(lǐng)頭羊，集 IaaS、PaaS、SaaS 與一體的云平臺(tái)，目前市值 1255 億美元;

• Sap：集 IaaS、PaaS、SaaS 與一體的云平臺(tái)，相比 salesforce，使用的技術(shù)要新一些，體驗(yàn)上要好一些，目前市值 1577 億美元；

• OutSystems：提供桌面 IDE，最近提供的 OutSystems AI 能夠輔助模型設(shè)計(jì)，定位 hpaPaaS (low-code)，作為后起之秀，表現(xiàn)不俗，已獲得多輪融資，在 2018 年估值 10+ 億美元，儼然成為下一個(gè)獨(dú)角獸。

應(yīng)用研發(fā)能力對(duì)比如下：

幾點(diǎn)產(chǎn)品體驗(yàn)感受：

• Google 和 Microsoft 老牌玩家玩 hpaPaaS 這一套相當(dāng)?shù)眯膽?yīng)手，體驗(yàn)相當(dāng)講究，把自家的服務(wù)包括三方常用服務(wù)整合的非常好。

• OutSystems 類似微軟，提供多種流式編排，很多時(shí)候不需要寫代碼，同時(shí)也整合了非常多數(shù)據(jù)服務(wù)，比如 Swagger 的 OpenAPI。

• Salesforce 和 SAP 類似，從單一的應(yīng)用程序，到一套應(yīng)用程序，到一個(gè)快速應(yīng)用開發(fā)平臺(tái)，企業(yè)協(xié)作工具，再到一個(gè)應(yīng)用程序容器和數(shù)據(jù)庫提供，提供了一套完整的生態(tài)鏈，以 SaaS、PaaS、IaaS 的分層方式對(duì)外輸出。

幾點(diǎn)參考：

• 高效整合才能降低成本，這是所有玩家的心智，不容質(zhì)疑。

• 視角要放大，要能夠覆蓋 90% 場景，必須要構(gòu)建一套完整的生態(tài)鏈，從 no-code 到 low-code 再到 pro-code 都要有對(duì)應(yīng)的解決方案，且要做到互相之間能夠打通，這是 Salesforce 和 SAP 給到的經(jīng)驗(yàn)，目前 AppMaker 和 PowerApps 主要針對(duì)表單、表格垂直領(lǐng)域，還不能夠玩大，單一領(lǐng)域視角解決的問題有限。

• 可視化的流式編排針對(duì)特定場景提效明顯，應(yīng)對(duì)稍微復(fù)雜一點(diǎn)的場景，一點(diǎn)也不好玩，比如 AppMaker 就粗暴一點(diǎn)，直接使用 SCRIPTS，書寫表達(dá)式更舒服，不知道使用 OutSystems 的用戶是什么感受。

三  走過的可視化建站

很長一段時(shí)間，國內(nèi)興起了很多可視化建站產(chǎn)品，「可視化建站」是「低代碼建站」的前身，目標(biāo)也是不用寫一行代碼，拖拖拽拽就可以把一個(gè)站點(diǎn)搭建起來，但更多的是從表現(xiàn)層（前端）單一領(lǐng)域去解決問題，只能完成靜態(tài)頁面的效果，對(duì)于真正的業(yè)務(wù)很難走完閉環(huán)。

總結(jié)一下突出的問題：

• 純前端思維，比如數(shù)據(jù)服務(wù)接入方式，缺少像 AppMaker/PowerApps 支持 DataConnectors 的統(tǒng)一數(shù)據(jù)接入層，和各個(gè)系統(tǒng)沒有形成有效整合。

• 能解決的場景也有限，高度復(fù)雜的企業(yè)級(jí) CRM 系統(tǒng)，不是通篇一律的，業(yè)務(wù)邏輯高度復(fù)雜，面臨定制化考驗(yàn)，稍微復(fù)雜一點(diǎn)的，需要做的工作可能會(huì)更多，甚至有時(shí)候搞不定，沒有享受到可視化搭建帶來的福報(bào)。

• 很多專業(yè)開發(fā)在搭建平臺(tái)施展不開才華，缺少專業(yè)級(jí)工具支持，比如 VSCode、Git。

• 不同角色之間不能有效的形成配合，比如后端數(shù)據(jù)接口，不能在可視化搭建工具中反射出來。

• 搭建頁面大多以 Schema 形式存儲(chǔ)，代碼也不好 diff，在運(yùn)行時(shí)動(dòng)態(tài)渲染也會(huì)帶來性能問題。

• ......

看到眾多業(yè)內(nèi)優(yōu)秀的設(shè)計(jì)，給我們帶來了很多奇思妙想，典型的 hpaPaaS 這種架構(gòu)一定程度上能將我們標(biāo)準(zhǔn)化場景完全解決掉，但標(biāo)準(zhǔn)化場景偏消費(fèi)性質(zhì)，消費(fèi)我們生產(chǎn)的物料沉淀、場景沉淀等，這樣的純 hpaPaaS 平臺(tái)應(yīng)對(duì)企業(yè)級(jí)場景肯定會(huì)透支，我們在為能活 102 年的超大型企業(yè)設(shè)計(jì)商業(yè)操作系統(tǒng)時(shí)，不能一律求快、求簡單，還需要考慮靈活性、擴(kuò)展性、復(fù)雜性，在這套系統(tǒng)上要能源源不斷的生產(chǎn)標(biāo)準(zhǔn)化的物料、場景，持續(xù)將復(fù)雜性問題抽象沉淀，形成一個(gè)有效的生態(tài)循環(huán)系統(tǒng)，我們需要的是一種加強(qiáng)版的 hpaPaaS 平臺(tái) —— 企業(yè)級(jí) hpaPaaS 平臺(tái)。

四  企業(yè)級(jí)的 hpaPaaS

以我們「企業(yè)智能事業(yè)部」為例做一下簡單的業(yè)務(wù)分型：

中后臺(tái)業(yè)務(wù)大多是和表單、表格相關(guān)的，這對(duì) hpaPaaS 平臺(tái)來說是好事，但真正代表企業(yè)級(jí)場景特別是財(cái)務(wù)、法務(wù)等系統(tǒng)，涉及到的表單可以用魔鬼來形容，比如表單嵌套表格，表格再嵌套表格（存在必然有合理之處），無法使用一套規(guī)則來描述，強(qiáng)大如 AppMaker 或 PowerApps，對(duì)這類問題基本無解，主要是沒有提供 backup 機(jī)制，企業(yè)級(jí)應(yīng)用最初始狀態(tài)大多是定制型應(yīng)用，如何進(jìn)化為標(biāo)準(zhǔn)化的配置型應(yīng)用，進(jìn)一步成為解決方案或商業(yè)能力，這是「企業(yè)級(jí) hpaPaaS 平臺(tái)」需要重點(diǎn)解決的。

將較年輕的產(chǎn)品 AppMaker 和 PowerApps 定義為商業(yè)級(jí)解決方案，將較成熟的 SAP 和 Salesforce 定義為企業(yè)級(jí)解決方案，商業(yè)級(jí)能解決大多數(shù)通用問題，而企業(yè)級(jí)是要能解決更多復(fù)雜性問題，面對(duì)復(fù)雜性企業(yè)級(jí)問題時(shí)，我認(rèn)為最起碼要做到兩點(diǎn)：

• 將不同場景所需要的能力進(jìn)行分解、分層，最后通過能力的整合來應(yīng)對(duì)，提升靈活變通能力；

• 同時(shí)有通用方案和兜底方案，多種方案之間應(yīng)該遵循統(tǒng)一標(biāo)準(zhǔn)，是打通融合的。

如果非要用一句話概括企業(yè)級(jí) hpaPaaS 能力，我認(rèn)為是從 no-code 到 pro-code 的漸進(jìn)式能力，如下圖：

實(shí)現(xiàn)這樣的「企業(yè)級(jí)的 hpaPaaS」有以下幾個(gè)重難點(diǎn)：

重難點(diǎn)一：從 no-code 到 pro-code

以一個(gè)簡單的業(yè)務(wù)系統(tǒng)為例來說一下這個(gè)過程。

迭代一（no-code 開發(fā)）

最初比較簡單，符合標(biāo)準(zhǔn)化的 CRUD：

1. 進(jìn)行業(yè)務(wù)建模，配置業(yè)務(wù)規(guī)則；

2. 根據(jù)建立好的模型選擇標(biāo)準(zhǔn)化 CRUD 模板，直接產(chǎn)出；

3. 預(yù)覽、發(fā)布。

迭代二（low-code 開發(fā)）

但是有些地方需要稍作定制，比如時(shí)間戳的格式化、頁面上需要額外展示用戶詳細(xì)信息：

1. 將標(biāo)準(zhǔn)化生成的產(chǎn)物，以可視化編輯打開；

2. 修改關(guān)聯(lián)字段時(shí)間的格式化方式、新增用戶信息塊；

3. 保存、預(yù)覽、發(fā)布。

迭代三（pro-code 開發(fā)）

隨著業(yè)務(wù)復(fù)雜度變高，很多業(yè)務(wù)邏輯需要寫更多代碼，也希望代碼被版本控制、進(jìn)行 diff 等：

1. 將標(biāo)準(zhǔn)化生成的產(chǎn)物在 WebIDE 中打開；

2. 編輯視圖，比如關(guān)聯(lián)的動(dòng)作，定位到對(duì)應(yīng)動(dòng)作代碼，修改邏輯；

3. 使用 WebIDE 提供的 git 功能，進(jìn)行代碼對(duì)比及代碼提交；

4. 保存、編譯、預(yù)覽、發(fā)布。

no-code 和 low-code 試錯(cuò)成本低，在創(chuàng)業(yè)時(shí)期我更希望使用這兩種方式，隨著我的業(yè)務(wù)的成長，價(jià)值逐漸被認(rèn)可，對(duì)該產(chǎn)品的要求也變高，這時(shí)候我也愿意投入更多，這時(shí)候可以采用 pro-code 方式對(duì)我的項(xiàng)目進(jìn)行精裝修，這種漸進(jìn)式交付能力將越來越多的被推崇。

在這過程中，有一個(gè)關(guān)鍵點(diǎn)，no-code 到 low-code 再到 pro-code 始終遵循的是一個(gè)標(biāo)準(zhǔn)，在我需要時(shí)可以被任意方式打開。

雖然我們期望未來業(yè)務(wù)研發(fā)只有 10% 的工作需要 pro-code 來完成，但 pro-code 的相關(guān)技術(shù)體系也是不可或缺的，它就是一個(gè)全功能開放的底層架構(gòu)，no-code 和 low-code 在這之上做的更垂直化，所以并不是說 10% 就不需要了，尤其在做企業(yè)級(jí)研發(fā)，pro-code 的存在更是一顆定心丸。

對(duì)于 pro-code 核心關(guān)鍵點(diǎn)有：

• WebIDE：pro-code 環(huán)節(jié)設(shè)計(jì)上是可以使用桌面 IDE 的方式，但未來必定屬于云開發(fā)時(shí)代，桌面 IDE 天然的和 PaaS 平臺(tái)有割裂感，過去我們擔(dān)心 WebIDE 技術(shù)不成熟，今天 vscode 引領(lǐng)了新一代的編輯器變革，帶來諸如 coder、theia 等功能和性能都很完備的 WebIDE 技術(shù)儲(chǔ)備，技術(shù)上沒什么好擔(dān)心的；

• Git 打通：企業(yè)級(jí)產(chǎn)品，沒有那么隨意，一般需要強(qiáng)管控，其中版本控制尤為重要，不管是 pro-code 還是 no-code，最終形態(tài)都是一種代碼形式的標(biāo)準(zhǔn)產(chǎn)物，都應(yīng)該托管在 Git 倉庫上，在必要的時(shí)候可以進(jìn)行回溯和對(duì)比；

• 可視化編輯打通：可視化編輯是 low-code 和 no-code 的代表功能，通過 Recore （統(tǒng)一 DSL）的技術(shù)將可視化和 pro-code 打通，是 pro-code、low-code、no-code 三者之間形成互通的必要條件。

重難點(diǎn)二：服務(wù)的集成

在上面提到的產(chǎn)品中，都有這樣的一個(gè)設(shè)計(jì)，無論是自家的服務(wù)還是別人家的服務(wù)通過一個(gè)集成平臺(tái)，將他們有機(jī)的整合在一起，在任何需要的環(huán)節(jié)，都能被高效的使用。

圖片源自：https://developers.google.com/

我們也提出 OneService 概念，期望將與數(shù)據(jù)相關(guān)的接口或服務(wù)通過 OneService 集成起來，打通生產(chǎn)中的各個(gè)環(huán)節(jié)，如下圖：

重難點(diǎn)三：生命力

我們設(shè)計(jì)的系統(tǒng)，比較關(guān)心兩個(gè)問題：

1. 能創(chuàng)造多少價(jià)值？

2. 能活多久？

我認(rèn)為一個(gè)具有頑強(qiáng)生命力的系統(tǒng)，應(yīng)當(dāng)在時(shí)間維度上持續(xù)創(chuàng)造價(jià)值，有以下幾個(gè)關(guān)鍵點(diǎn)：

• 適合的土壤，大風(fēng)向以及政策鼓勵(lì)，有強(qiáng)烈市場需求；

• 持續(xù)標(biāo)準(zhǔn)化，標(biāo)準(zhǔn)化不是一個(gè)固定結(jié)果，而是一個(gè)動(dòng)態(tài)過程，需要有一個(gè)進(jìn)化機(jī)制，保證標(biāo)準(zhǔn)化的生態(tài)具有自潔能力，適應(yīng)行業(yè)發(fā)展；

• 行業(yè)滲透，打通行業(yè)鏈路上下游，將標(biāo)準(zhǔn)、理念融入到行業(yè)各節(jié)點(diǎn)，能夠反哺自己的生態(tài)，并有助于形成規(guī)模；

• 共同成長，帶動(dòng)行業(yè)成長，行業(yè)的成長就是自己的成長。

五  未來可期

SaaS 化的平臺(tái)，以 SAP 和 Salesforce 為代表在歐美國家活的很滋潤，在中國剛起步，從過去一年的變化可以看到，國家越來越多的政策在鼓勵(lì)中小型創(chuàng)新企業(yè)，意味著未來 toB 市場前景廣闊，阿里整體風(fēng)向現(xiàn)在也是 toB，釘釘和阿里云已經(jīng)在這條路上越走越穩(wěn)，讓我們看到，在 toB 這件事情上時(shí)機(jī)已經(jīng)成熟，而我們現(xiàn)在要做的就是把本土化的 SaaS 平臺(tái)做好、做強(qiáng)。

相關(guān)參考與鏈接

https://www.sap.cn/products/business-technology-platform.html

---

 阿里宜搭招聘 

?  校招/社招

• 宜搭生產(chǎn)力平臺(tái)部，隸屬于釘釘事業(yè)部，是一個(gè)致力于服務(wù)千萬中小企業(yè)進(jìn)行企業(yè)辦公自動(dòng)化及運(yùn)營平臺(tái)數(shù)字化轉(zhuǎn)型的建設(shè)者，更是阿里巴巴及螞蟻集團(tuán)內(nèi)部高效協(xié)同辦公的重要支撐者。

• 宜搭產(chǎn)品官網(wǎng)：https://www.aliwork.com/

• 通過表單、流程及報(bào)表的數(shù)字化、智能化手段和數(shù)字技術(shù)能力，助力阿里 10 萬余員工的高效協(xié)同辦公，提升阿里組織活力與創(chuàng)新力，推動(dòng)阿里巴巴這家多元、多樣、多業(yè)態(tài)經(jīng)濟(jì)體的組織數(shù)字化全面升級(jí)。

• 同時(shí)基于阿里內(nèi)部最佳實(shí)踐，部門正通過技術(shù)產(chǎn)品化，服務(wù)于更多政府及中小企業(yè)的數(shù)字化治理，為政企數(shù)字化轉(zhuǎn)型提供重要支撐。

職位描述

主要負(fù)責(zé)宜搭生產(chǎn)力平臺(tái)部的企業(yè)級(jí)低代碼搭建平臺(tái)、企業(yè)級(jí)辦公自動(dòng)化系統(tǒng)、企業(yè)級(jí) ERP、CRM 等系統(tǒng)、 政務(wù)專有化產(chǎn)品、移動(dòng)端產(chǎn)品等研發(fā)工作；

• 負(fù)責(zé)宜搭生產(chǎn)力平臺(tái)部核心業(yè)務(wù)系統(tǒng)的前端開發(fā)工作；提升企業(yè)系統(tǒng)的整體用戶體驗(yàn)和前端技術(shù)；
• 負(fù)責(zé)表單、流程、報(bào)表相關(guān)的復(fù)雜業(yè)務(wù)搭建平臺(tái)開發(fā)；增強(qiáng)平臺(tái)能力和頁面性能；
• 有良好的洞察能力，能夠通過新技術(shù)、業(yè)界優(yōu)秀產(chǎn)品的分析調(diào)研來提升我們的產(chǎn)品體驗(yàn)；

崗位要求

• 至少兩年以上業(yè)務(wù)系統(tǒng)開發(fā)經(jīng)驗(yàn)，有較強(qiáng)的協(xié)同、合作能力；

• 良好的計(jì)算機(jī)基礎(chǔ)和編程能力，精通 HTML/CSS/JavaScript 基礎(chǔ)，理解 HTTP 及相關(guān)協(xié)議，熟悉瀏覽器和移動(dòng)平臺(tái)特性，了解行業(yè)技術(shù)發(fā)展；

• 熟悉 react, vue, ES6, typescript, npm, webpack, redux, mbox, nodejs 等主流前端技術(shù)棧；

• 兩年及以上前端相關(guān)工作經(jīng)驗(yàn)，主導(dǎo)或獨(dú)立負(fù)責(zé)過一定規(guī)模產(chǎn)品前端，有一定的前端架構(gòu)能力；

• 了解 Hybrid 體系，React Native，F(xiàn)lutter，小程序等有一種以上的實(shí)際使用經(jīng)驗(yàn)，了解對(duì)應(yīng)框架的生態(tài)以及負(fù)責(zé)業(yè)務(wù)的行業(yè)動(dòng)態(tài)；

• 熟悉低代碼搭建相關(guān)的前端技術(shù)是加分項(xiàng)，有 GitHub 開源社區(qū)貢獻(xiàn)是加分項(xiàng)；

• 對(duì)技術(shù)有強(qiáng)烈的進(jìn)取心，具有良好的溝通能力和團(tuán)隊(duì)合作精神、優(yōu)秀的分析問題和解決問題的能力。

簡歷投遞: