戰(zhàn)略筆記：數(shù)字化轉(zhuǎn)型中的低代碼評估與決策指南（“低代碼開發(fā)”會是企業(yè)數(shù)字化轉(zhuǎn)型的理想選擇嗎）

球迷Long導(dǎo)語

低代碼大潮蜂擁而來！

Forrester觀點(diǎn)：“隨著更多公司看到采用該平臺滿足其業(yè)務(wù)需求的好處，低代碼市場預(yù)計2022年將增長到212億美元?！?/span>

Gartner觀點(diǎn)：“84％的企業(yè)已在轉(zhuǎn)向低代碼，因為它具有減輕IT資源壓力，提高上市速度并使企業(yè)參與數(shù)字資產(chǎn)開發(fā)的能力?！?/span>

IDC觀點(diǎn)：“到2024年，低代碼將占所有應(yīng)用程序開發(fā)活動的65％以上。”

低代碼已然成為數(shù)字化轉(zhuǎn)型中不可回避的重要技術(shù)領(lǐng)域。本文在研讀Gatner報告基礎(chǔ)上結(jié)合中國實情給出相應(yīng)觀點(diǎn)。

往期經(jīng)典：

【專家Insight】 企業(yè)數(shù)字化轉(zhuǎn)型戰(zhàn)略完整指南

【專家Insight】戰(zhàn)略筆記：數(shù)字化轉(zhuǎn)型的生態(tài)建設(shè)指南

———————–

很多企業(yè)對于低代碼的討論極為混亂，不同角色語言難以統(tǒng)一似齊梁世界。我們首先要明確低代碼的標(biāo)準(zhǔn)定義，這是多方討論與評價的關(guān)鍵基礎(chǔ)。

圖：低代碼在數(shù)字化工廠的應(yīng)用

一、到底什么是低代碼

圖：低代碼發(fā)展時間軸

低代碼開發(fā)不是新事務(wù)，最早來源于1980s出現(xiàn)的快速應(yīng)用程序開發(fā)(RAD) 工具。

低代碼開發(fā)始于Forrester的博采群議而形成定義。

翻譯：此平臺可通過最精簡的手工coding以及在安裝、培訓(xùn)與部署方面的最小前期投入，實現(xiàn)快速的業(yè)務(wù)應(yīng)用交付。

Forrester對于低代碼的態(tài)度實在是彰明較著，直接闡明低代碼之核心價值：

低代碼開發(fā)平臺能夠?qū)崿F(xiàn)業(yè)務(wù)應(yīng)用的快速交付。

根據(jù)Forrester調(diào)研，大部分公司反饋低代碼平臺使之開發(fā)效率提升5-10倍。

圖：低代碼控件封裝

低代碼開發(fā)平臺能夠降低業(yè)務(wù)應(yīng)用的開發(fā)成本。

低代碼開發(fā)在軟件全生命周期流程上的投入更低、簡單重復(fù)性研發(fā)資源投入更少。（這勢必帶來研發(fā)從業(yè)者的恐慌從而帶來抵觸）。

作為新型開發(fā)工具，低代碼開發(fā)平臺可減少代碼量、簡化開發(fā)流程、縮短開發(fā)周期、提高開發(fā)效率、節(jié)約開發(fā)成本、幫助用戶更好地設(shè)計和實現(xiàn)需求，用戶只需聚焦業(yè)務(wù)邏輯，而非關(guān)注代碼編寫。

圖：開發(fā)從傳統(tǒng)向低代碼過渡

二、低代碼平臺三個核心能力

最普遍的AD&D（移動應(yīng)用開發(fā)與交付），通常需以下三個核心能力以實現(xiàn)其平臺能力：aPaaS、MADP、BPM。

其中，

aPaaS是應(yīng)用程序平臺即服務(wù)的縮寫（云服務(wù)的一種），可為應(yīng)用程序服務(wù)提供開發(fā)、部署環(huán)境。aPaaS平臺提供以下功能：迭代構(gòu)建應(yīng)用程序、即時提供應(yīng)用軟件、按需擴(kuò)展應(yīng)用程序以及集成應(yīng)用程序與其他服務(wù)。（參見Gartner定義）

MADP（移動應(yīng)用程序開發(fā)平臺）能夠更好地應(yīng)對企業(yè)數(shù)字化業(yè)務(wù)與創(chuàng)新性需求，是低代碼開發(fā)能力的重要補(bǔ)充；同時，國外諸多低代碼開發(fā)平臺也在逐漸加強(qiáng)對移動應(yīng)用開發(fā)的支撐能力。

BPM平臺注重流程化開發(fā)，目的是通過系統(tǒng)性的改善企業(yè)內(nèi)部的商業(yè)流程來提升組織效率，目前的BPM平臺前端主要是基于表單來實現(xiàn)快速開發(fā)，樣式比較固定，后端通過分析BPMN流程圖（業(yè)務(wù)流程建模標(biāo)注）來完成一步步的流程開發(fā)。

圖：自動化BPM

在國內(nèi)，同時具備MADP、aPaaS、BPM能力的平臺已在集成三層能力（有時他們自己也不知道，這叫低代碼，雖然是他們在踐行的），包括簡道云、活字格、搭搭云等，這些平臺已具備一定技術(shù)壁壘以及開發(fā)業(yè)態(tài)積累。

圖：低代碼平臺陣營

圖：國內(nèi)低代碼市場格局中的應(yīng)用衍生品牌

圖：2021低代碼廠商Top10

《互聯(lián)網(wǎng)周刊》、eNet研究院、德本咨詢聯(lián)合發(fā)布

開放研發(fā)環(huán)境、沉淀低代碼技術(shù)能力與行業(yè)業(yè)務(wù)邏輯儲備是低代碼可最終嵌入企業(yè)肌體的關(guān)鍵。

三、低代碼的開發(fā)過程

1. 明確需求。

2. 選擇API。

3. 在可視化設(shè)計器中繪制工作流程、數(shù)據(jù)模型、用戶界面，并與客戶確認(rèn)。

4. 連接API。

5. 按需在前端添加寫代碼、自定義SQL查詢或視圖或編碼對接第三方API。

6. 測試用戶接受度。

7. 部署到生產(chǎn)環(huán)境，點(diǎn)擊發(fā)布。

此時我們相信對于低代碼的認(rèn)識可進(jìn)一步明晰了。確實我們傳統(tǒng)上最擅長的車軌共文在這個領(lǐng)域的應(yīng)用極為欠缺，這跟我們所用的技術(shù)基因以及標(biāo)準(zhǔn)仍然以西方為主、但又有了本土化的錯綜復(fù)雜的實踐有關(guān)。在數(shù)字化轉(zhuǎn)型中尤其需要這么一個專業(yè)權(quán)威實現(xiàn)關(guān)鍵認(rèn)識、各類標(biāo)準(zhǔn)上的車軌同文，標(biāo)準(zhǔn)化本身是轉(zhuǎn)型的基礎(chǔ)。

圖：傳統(tǒng)開發(fā)與低代碼開發(fā)的過程區(qū)別

四、低代碼形勢判斷

4.1 進(jìn)化從未停止

上文提到的80年代RAD工具引入用來替代傳統(tǒng)基于文本的開發(fā)平臺。

它們與時俱進(jìn)，與集成開發(fā)環(huán)境(IDE)、圖形用戶界面(GUI)、網(wǎng)絡(luò)和 C/S 架構(gòu)等一同迅速發(fā)展。

早期的RAD工具開拓了可視化拖放機(jī)制、數(shù)據(jù)與行為的圖形化模型、架構(gòu)規(guī)范性的框架和模板化組件幾大關(guān)鍵能力。

如洪水一般，這新生物快速傳播到所有分布式開發(fā)平臺！并推動業(yè)態(tài)快速進(jìn)化

圖：從低代碼看生態(tài)演變、大勢所趨、萬路歸宗

在此期間，某些行業(yè)標(biāo)準(zhǔn)的可視化模型得到了發(fā)展和沉淀，如：數(shù)據(jù)的實體關(guān)系、對象管理的類圖、流程模型和狀態(tài)機(jī)的狀態(tài)轉(zhuǎn)換圖。

同理，衍生出來的還有業(yè)務(wù)規(guī)則管理系統(tǒng)(BRMS) 市場，將快速應(yīng)用程序開發(fā)(RAD) 和AI能力 融合于一身。決策管理套裝(DMS) 市場也在持續(xù)采用這種結(jié)合產(chǎn)物（如最新的 DMN 決策模型）。

圖：RAD與AI

低代碼應(yīng)用程序開發(fā)的重要里程碑其實就是WEB（用于支持對應(yīng)用程序的分布式訪問）和云（實現(xiàn)標(biāo)準(zhǔn)化部署機(jī)制、在PaaS中實現(xiàn)順暢應(yīng)用開發(fā)）的出現(xiàn)。

這就催生了應(yīng)用程序開發(fā)工具市場的兩個分支：

• 快速應(yīng)用程序開發(fā)(RAD) 供應(yīng)商將應(yīng)用程序部署過程實現(xiàn)自動化。在他們的云產(chǎn)品中，普遍追求：應(yīng)用程序通過最少、最小人員操作介入交付。
• 主流的 SaaS 供應(yīng)商利用低代碼使客戶能夠?qū)ζ淦脚_進(jìn)行自定義和擴(kuò)展。然后，他們逐步成為行業(yè)SaaS PaaS 供應(yīng)商，復(fù)用行業(yè)資源、為其他同行業(yè)開發(fā)人員提供面向用戶的業(yè)務(wù)程序與技術(shù)來構(gòu)建下一個應(yīng)用程序…

如今，使用低代碼開發(fā)技術(shù)（即“非編程開發(fā)”）以賦能員工、支撐大規(guī)模應(yīng)用程序開發(fā)已成為某些企業(yè)數(shù)字化辦公協(xié)議中的一部分。

工作組應(yīng)用程序始終是使用非編程開發(fā)工具（例如電子表格）交付的。由業(yè)務(wù)線部門開發(fā)人員負(fù)責(zé)構(gòu)建的應(yīng)用程序已成為促使低代碼開發(fā)工具生長的重要領(lǐng)域。

而且低代碼功能的暗流涌動似的增加、也必然將成為某些非主要企業(yè)平臺的潛在替代品：低代碼工具從未停止攀登應(yīng)用程序領(lǐng)域的金字塔。

4.2 低代碼or零代碼

隨著低代碼的發(fā)展，大家準(zhǔn)備將其推向極致，也即，隔壁大爺也能用的“0 代碼”工具，這對開發(fā)行業(yè)將是顛覆性的。盡管，我們認(rèn)為“0 代碼”工具是低代碼工具市場的一個極小細(xì)分，且暫未實現(xiàn)。

圖：0代碼的發(fā)展過渡

Gartner報告顯示，“0 代碼”開發(fā)工具正在進(jìn)軍業(yè)務(wù)測的應(yīng)用，觸及到業(yè)務(wù)數(shù)據(jù)從而進(jìn)一步穩(wěn)固自身應(yīng)用程序。同時，通過賦能和促進(jìn)非編程開發(fā)的發(fā)展來使應(yīng)用程序開發(fā)大眾化，構(gòu)建大環(huán)境低代碼之勢。

圖：0代碼軟件形態(tài)分類

IT 部門人員為企業(yè)交付所有應(yīng)用程序的日子可以翻頁了。歷史無情、在資本驅(qū)動下的科技行業(yè)更是無情，更是只關(guān)注當(dāng)下和未來，獨(dú)立的企業(yè)IT和影子IT未來都將被消除，業(yè)務(wù)與IT團(tuán)隊必將整合，共同實現(xiàn)數(shù)字產(chǎn)品的全棧交付。低代碼開發(fā)恰好是實現(xiàn)這一點(diǎn)的關(guān)鍵因素也是前提基礎(chǔ)。

4.3 從單一技術(shù)走向產(chǎn)品組合

市面上已有200多家供應(yīng)商以“低代碼”的方式推出產(chǎn)品，服務(wù)范圍覆蓋從簡單的表單創(chuàng)建到全棧應(yīng)用程序平臺，為企業(yè)客戶提供快速應(yīng)用程序開發(fā)(RAD) 服務(wù)。

“0 代碼”開發(fā)產(chǎn)品亦屬此類低代碼工具范疇，主要面向業(yè)務(wù)領(lǐng)域中“非編程人員”（類似業(yè)務(wù)人員、產(chǎn)品設(shè)計人員、運(yùn)營人員等無實際編碼經(jīng)驗的人員）。

低代碼開發(fā)目前尚以用于面向企業(yè)內(nèi)部員工(B2E) 的應(yīng)用開發(fā)為主，但伴隨用戶體驗(UX) 要求的提高以及新型授權(quán)模式的逐步放開，低代碼開發(fā)開始了其高掌遠(yuǎn)跖之路，從技術(shù)后臺逐漸走向to C甚至to B的應(yīng)用支持。

當(dāng)前的問題不在于用不用低代碼，而在于哪些場景適用低代碼？但使用中必須有所準(zhǔn)備。

圖：尋找適合的低代碼場景

接下來我們切入正題，如何評價低代碼！

五、戰(zhàn)略選擇、決策、評估與應(yīng)用

低代碼涉及到的應(yīng)用程序開發(fā)(LCAP) 乃循常習(xí)故、并非橫空出世，數(shù)字化革新的過程中不過是自然而然衍生此類已有技術(shù)能力蜂擁而入，來滿足日益增長的多元化的訴求。

圖：拖拉拽自動形成流程

企業(yè)數(shù)字化轉(zhuǎn)型中在考慮規(guī)劃與技術(shù)資源匹配的時候，對于低代碼工具和市場情況的客觀而科學(xué)的判斷，難以繞開。

5.1 戰(zhàn)略選擇

iResearch對低代碼的場景覆蓋率相對樂觀

• 中小型企業(yè)95% 場景可采用低代碼搭建
• 中大型企業(yè)70% …
• 在某些垂直應(yīng)用場景中，如即時通信等領(lǐng)域，在低代碼基礎(chǔ)上還要其他插件補(bǔ)充的情況下，覆蓋率大約50% …

圖：低代碼覆蓋率

而個人認(rèn)為Gartner的評述更為客觀：

• 取代趨勢。到 2024 年，低代碼應(yīng)用程序開發(fā)將占應(yīng)用程序開發(fā) 65％ 以上。
• 適用領(lǐng)域。到 2024 年，至少 75％ 的低代碼應(yīng)用程序開發(fā)工作將集中在中小型項目里，聚焦非核心的工作內(nèi)容。
• 逐步接受。到 2024 年，有 75％ 的大型企業(yè)將至少使用四個低代碼開發(fā)工具進(jìn)行 IT 應(yīng)用程序開發(fā)和非編程式開發(fā)。

這給信息化、數(shù)字化負(fù)責(zé)人帶來巨大壓力，他們必須盡快提高應(yīng)用交付速度、摒除時間浪費(fèi)、聚集價增值領(lǐng)域。

應(yīng)時應(yīng)勢而生！

此時很多供應(yīng)商們不約而同的提出低代碼解決方案：通過減少或規(guī)避對專業(yè)編程（需IT開發(fā)專崗支持）的需求依賴，來提高生產(chǎn)力。

5.2 供應(yīng)商綜合判斷維度

Gartner追蹤了200多家低代碼開發(fā)工具供應(yīng)商。

在這些供應(yīng)商中：

• 96％ 供應(yīng)商認(rèn)為自己提供了完整的軟件開發(fā)生命周期(SDLC)支持，而不僅僅是扮演設(shè)計和開發(fā)加速器的角色
• 95% 供應(yīng)商目標(biāo)客戶是業(yè)務(wù)線開發(fā)人員
• 88％ 供應(yīng)商提供了公有云部署
• 85% 供應(yīng)商認(rèn)為自己已覆蓋用戶體驗、邏輯和數(shù)據(jù)的全棧，而不僅專門處理應(yīng)用程序的一部分
• 84％ 供應(yīng)商提供了 WebIDE
• 79％ 供應(yīng)商提供基于表單的用戶界面
• 78％ 供應(yīng)商將數(shù)據(jù)庫作為其工具的一部分
• 62％ 的供應(yīng)商提供了私有云部署能力
• 62％ 供應(yīng)商提供移動應(yīng)用程序界面
• 47％ 供應(yīng)商生成的代碼在大多數(shù)情況下可以進(jìn)行手工編輯
• 40% 供應(yīng)商選擇的開發(fā)人員角色定位為業(yè)務(wù)高級用戶
• 30％ 供應(yīng)商提供了桌面IDE
• 5％ 不到提供聊天機(jī)器人

在 top 3 的應(yīng)用場景中：

• 86% 供應(yīng)商目標(biāo)應(yīng)用場景是企業(yè)級應(yīng)用開發(fā)
• 55％ 供應(yīng)商主要終端用戶類型是 B2E
• 而 B2B 和 B2C 的占比分別僅為 20％ 和 25％

圖：慧友云商低代碼B2C樣例

5.3 低代碼開發(fā)技術(shù)的分類與評價

數(shù)字化轉(zhuǎn)型負(fù)責(zé)人必須意識到，低代碼開發(fā)技術(shù)并不是一個靜態(tài)的單一市場，而是相反，

技術(shù)和流程的結(jié)合往往會吸引這幾類開發(fā)者：

• 具有有限軟件開發(fā)技能、經(jīng)驗或素質(zhì)能力的開發(fā)者
• 承受著巨大壓力，需盡快提供“最小可用”或“足夠好”解決方案的開發(fā)者
• 需應(yīng)對不斷變化的需求能持續(xù)快速演進(jìn)應(yīng)用的開發(fā)者

高德納(Gartner) 確認(rèn)了涵蓋了低代碼開發(fā)技術(shù)領(lǐng)域的三個主要細(xì)分市場：

• 低代碼應(yīng)用程序平臺(LCAPs) —— 這是一個新類別，涵蓋了高生產(chǎn)力的應(yīng)用程序 PaaS(HPaPaaS) 以及 RAD 和 RMAD 工具。它關(guān)注通過聲明式的模型驅(qū)動和基于元數(shù)據(jù)的服務(wù)來提供快速的應(yīng)用程序開發(fā)、部署和執(zhí)行。這個市場包括自描述的“0 代碼”應(yīng)用程序開發(fā)工具，并且總體上代表了低代碼技術(shù)供應(yīng)商的最大部分。
• 多維體驗開發(fā)平臺（MXDP） —— 這些產(chǎn)品為專業(yè)開發(fā)人員（有時甚至是非編程開發(fā)人員）提供了一套包含前端開發(fā)工具和后端服務(wù)的集成成熟套件，從而可以跨數(shù)字觸點(diǎn)(digital touchpoints) 進(jìn)行相應(yīng)用途應(yīng)用程序的擴(kuò)展性開發(fā)。

• 流程和業(yè)務(wù)規(guī)則/決策管理系統(tǒng)——這類模型驅(qū)動的（因此是低代碼的）開發(fā)平臺可以在操作模型和程序時進(jìn)行動態(tài)變化。他們通過流程(BPMS) 和業(yè)務(wù)規(guī)則/決策(BRMS / DMS) 實現(xiàn)了業(yè)務(wù)操作的自動化。Gartner的研究范圍也擴(kuò)大到了智能業(yè)務(wù)流程管理系統(tǒng)(iBPMS)，包括了可持續(xù)的智能和動態(tài)流程管理系統(tǒng)(BPM)。盡管“模型驅(qū)動”意味著“低代碼”，但其中一些可以實現(xiàn)復(fù)雜的流程和決策的模型既復(fù)雜又專業(yè)，這可能需要相關(guān)專家協(xié)助才能進(jìn)行開發(fā)。

針對這些典型的低代碼平臺，典型的選擇決策過程如下圖所示

5.4 關(guān)于低代碼的決策

圖：低代碼決策樹 源：Gartner (2019.2)

根據(jù)Gartner的經(jīng)驗，決策標(biāo)準(zhǔn)參考如下：

1、是否需要在沒有專業(yè)開發(fā)人員協(xié)助的情況下進(jìn)行“非編程開發(fā)”？

如果是，可以考慮一個具有“0 代碼”能力的低代碼應(yīng)用平臺(LCAP)，同時要注意工具的能力支撐范圍。

2、是否需要可持續(xù)更新的、復(fù)雜的和可管理的業(yè)務(wù)流程或決策以及相關(guān)的供應(yīng)商技能和流程與決策建模的協(xié)助？

如果是，須與供應(yīng)商提供的流程專家一起考慮使用智能業(yè)務(wù)流程管理系統(tǒng)(iBPMS) 、業(yè)務(wù)規(guī)則管理系統(tǒng)(BRMS) 或 決策管理套裝(DMS)，但要清楚低代碼的哪些優(yōu)勢可能會在這些工具使用中受到限制，并且?guī)磔^高代價。

3、是否需要跨數(shù)字觸點(diǎn)（digital touchpoints ）(例如，移動應(yīng)用程序、漸進(jìn)式 web 應(yīng)用程序、聊天機(jī)器人)的多種應(yīng)用程序類型？

如果是，須考慮使用低代碼的多維體驗開發(fā)平臺(MXDPs)，以便跨多種交互模式擴(kuò)展或增益應(yīng)用程序用戶體驗；對于所有其他業(yè)務(wù)應(yīng)用場景，則須考慮一個低代碼應(yīng)用平臺(LCAP)，它可以在一款工具中提供給你部分或全部流程自動化，滿足用戶體驗需求，同時具有非編程開發(fā)能力，并且聚焦服務(wù)質(zhì)量而非單純性能本身。

5.5 關(guān)于低代碼服務(wù)的評估維度

對于供應(yīng)商提供的所有類型的低代碼開發(fā)產(chǎn)品，可以根據(jù)幾個主要特征來進(jìn)行評價。這些特征構(gòu)成了低代碼工具和平臺的主要評估標(biāo)準(zhǔn)。數(shù)字化轉(zhuǎn)型負(fù)責(zé)人可根據(jù)每個特征對其能力需求進(jìn)行評分：

1、部署類型 – 用于給一兩個開發(fā)人員體驗和部署的工具可以是本地的，也可以是云化的或 PaaS，或兩者都有。同時也要考慮是需要特定的云還是多個云。

2、開發(fā)人員角色 – 是為 快速應(yīng)用程序開發(fā)(RAD) 物色的專業(yè)開發(fā)人員，還是普通技術(shù)開發(fā)者（例如，具有 IT 意識的業(yè)務(wù)分析師）或普通業(yè)務(wù)開發(fā)者（需要“0 代碼”方式輔助），亦或是其某種組合。

3、前端vs.后端 – 對于一款全棧式應(yīng)用程序，是僅需要新的用戶體驗設(shè)計，還是新的后端處理流程，抑或兩者都需要？后端流程自動化可以包含工作流程，也可以從被監(jiān)管的 業(yè)務(wù)流程管理(BPM) 式的流程設(shè)計和交付方法中獲益。

4、用戶體驗 – 用戶體驗的復(fù)雜性是必需要考慮的，對于所有應(yīng)用程序來說復(fù)雜性都在增加，尤其對于 B2C 應(yīng)用程序更甚。對于以多模態(tài)用戶體驗為重點(diǎn)的場景，多維體驗開發(fā)平臺(MXDP) 方式可能是最好的，而對于內(nèi)部 B2E 應(yīng)用程序場景，簡單的基于 web 表單的方式也就足夠了。

5、服務(wù)復(fù)雜性 – 應(yīng)用程序可以對數(shù)據(jù)進(jìn)行創(chuàng)建、讀取、更新、刪除(CRUD) 操作，也可以對來自多個服務(wù)的操作進(jìn)行集成或組合，包括驅(qū)動流程的事件處理和消費(fèi)。

6、市場焦點(diǎn) – 當(dāng)許多工具還集中在通用領(lǐng)域的時候，某些工具隨著相關(guān) SaaS 的應(yīng)用或簡單的客戶群體演變，越來越聚焦在 ERP，CRM 和供應(yīng)鏈等專業(yè)領(lǐng)域上。

7、生態(tài)系統(tǒng)和合作伙伴 – 由于許多平臺選擇者對平臺的能力普遍要求較高，因此一些技術(shù)特性可能不足以滿足他們的訴求。像本地支持、技能可用性和培訓(xùn)機(jī)會、應(yīng)用商店和開發(fā)人員社區(qū)以及服務(wù)提供伙伴質(zhì)量之類的問題就可能顯得尤為重要。

8、治理和敏捷性 – 對于許多用戶來說，度量業(yè)務(wù) KPI 以及應(yīng)用程序開發(fā)和資源使用情況的 KPI 的能力，是一種越來越大的優(yōu)勢。平臺們正在開發(fā)一些能匹配 BPM 功能的可選功能，像記錄應(yīng)用程序目標(biāo)、管理完整的應(yīng)用程序生命周期等。

9、軟件開發(fā)生命周期（SDLC）方法論 – 為應(yīng)用程序開發(fā)過程乃至項目管理提供指導(dǎo)。AI 輔助開發(fā)也可能是種需要。

5.6 關(guān)于低代碼產(chǎn)品工具的評估維度

圖：低代碼能力特征

BPM = business process management; CRUD = create, read, update, delete; DIY = do it yourself; SDLC = software development life cycle 圖源：Gartner (2019.2)

低代碼應(yīng)用平臺(LCAPs) 代表了這些平臺里最大的市場份額。低代碼應(yīng)用平臺(LCAPs) 支持快速應(yīng)用程序開發(fā)(RAD)，使用聲明性的高級編程抽象（例如，模型驅(qū)動和基于元數(shù)據(jù)的編程語言）進(jìn)行部署和執(zhí)行，以及單部署。

共性技術(shù)要素包括：

• 以模型/元數(shù)據(jù)為中心的 UI 層設(shè)計器，支持基本的增刪改查(CRUD) 應(yīng)用程序設(shè)計，最好只需要很少編碼或不需要編碼
• 支持基本的數(shù)據(jù)結(jié)構(gòu)定義和內(nèi)置數(shù)據(jù)庫的通用數(shù)據(jù)存儲（如，RDBMS、NoSQL、flat文件）訪問
• 通過 REST，SOAP 或其他 API簡化對外服務(wù)的訪問
• 通過 API 包裝它們的底層流程邏輯和數(shù)據(jù)
• 支持面向業(yè)務(wù)規(guī)則和常規(guī)業(yè)務(wù)邏輯開發(fā)的編碼模型方法
• 漂亮的性能表現(xiàn)和可控的操作延遲

作為企業(yè)級工具，還應(yīng)考慮以下功能的評價，例如：

• 用戶密集訪問量、數(shù)據(jù)存儲量和高并發(fā)率的彈性伸縮能力
• 高可用性與容災(zāi)恢復(fù)能力
• 應(yīng)用程序訪問、API 和數(shù)據(jù)存儲的安全性
• 開發(fā)階段（或云 PaaS 的運(yùn)行時部署階段）的SLA
• 資源使用追蹤能力
• 對開發(fā)人員和運(yùn)營人員的技術(shù)支持能力

5.7 低代碼采用的關(guān)鍵建議

若要充分發(fā)揮低代碼價值，須要求負(fù)責(zé)應(yīng)用程序開發(fā)和平臺策略的負(fù)責(zé)人必須注意以下事項：

• 對應(yīng)用場景進(jìn)行分類，識別當(dāng)下適應(yīng)、適用、適配于低代碼開發(fā)的場景。
• 選擇恰當(dāng)?shù)牡痛a工具。建議選擇對開發(fā)技能要求不高，尤其要適用于實現(xiàn)加快產(chǎn)品上市的關(guān)鍵場景。
• 給“非編程人員”（包括IT和業(yè)務(wù)方）提供的低代碼開發(fā)工具必須具備相應(yīng)的安全性保障、監(jiān)督性保障與可用性保障。
• 一旦進(jìn)入使用階段，尤其產(chǎn)生局部效果以后，不要有移天易日之心、妄圖過渡消費(fèi)低代碼能力、倉促擴(kuò)大使用邊界。
• 一旦決定將低代碼應(yīng)用于業(yè)務(wù)創(chuàng)新場景部署，要確保該工具的合規(guī)授權(quán)、并經(jīng)評估可實現(xiàn)ROI、實現(xiàn)業(yè)務(wù)目的。

五、結(jié)語

國內(nèi)關(guān)于低代碼的探討經(jīng)常陷入誤區(qū)——低代碼如何實現(xiàn)，而忽略了面向業(yè)務(wù)讓業(yè)務(wù)怎么實現(xiàn)的問題，因此容易陷入一波又一波關(guān)于低代碼有用或者無用的爭吵，此類爭吵實屬無用。

對于低代碼供應(yīng)商來說找到核心用戶、客戶的核心業(yè)務(wù)場景、明晰業(yè)務(wù)流程非常關(guān)鍵。

圖：服務(wù)于誰又將取代誰

而對于要選擇應(yīng)用低代碼的企業(yè)來說，

恰當(dāng)?shù)膱鼍耙约瓣P(guān)于低代碼服務(wù)于誰、取代誰、如何安置的決策等則比低代碼工具的選擇更為關(guān)鍵！

本文編譯及作者：球迷Long

主要參考譯文：

https://www.gartner.com/en/documents/3902331/low-code-development-technologies-evaluation-guide
作者：Paul Vincent, Mark Driver, Jason Wong

部分圖文翻譯：阿里內(nèi)推卓風(fēng)