中國低代碼開發平台的混戰

圖片來源@視覺中國

這兩年，無論是資本層面，還是企業IT部門的關注，“低代碼”都是絕對的熱點。互聯網圈也似在一夜之間冒出了各種各樣的低代碼公司。到底什麼是低代碼？低代碼是新技術麼？低代碼開發能給企業帶來什麼價值？企業如何使用低代碼？哪些平台是真的低代碼哪些是渾水摸魚蹭熱點？

我們用大眾聽得懂的語言，好好説一説低代碼。

“低代碼”按字面意思可以通俗理解為“比正常應用開發要少寫代碼”。我們來梳理一下“低代碼”開發平台的使用價值：

1、可以“在雲上”開發“CloudNative雲原生的應用”；

2、怎麼在雲上開發呢？用可視化甚至所見即所得的方式，通過拖拽式開發；

3、在雲上用拖拽可視化開發什麼樣的雲原生應用？以移動端為主的“個性化應用”，需要涵蓋後端和PC端管理能力。

4、開發出的應用特點？往往是業務部門發起的、要快速上線並且整體應用生命週期不超過一年的周邊型應用。

總結下來對低代碼的主流定義就是：為滿足企業業務部門發起的移動端為主的中小應用的需求，用可視化拖拽式和少量代碼就可以快速在雲上開發的雲原生應用，這種雲端平台通常稱為低代碼開發平台。

建議一、“如果你想開發一個OA或者ERP，你還是別用低代碼了”

早在2016年Gartner發佈了企業軟件的三種分類模式報告，其中《速度分層應用報告》中將企業應用分成了三種類型：基礎設施型（如ERP）、差異化型（如CRM）、創新型（如移動端各種應用）。

前面兩種都是企業傳統IT涵蓋的領域，由傳統IT人員維護和主導的固有IT模式。隨着企業互聯網化的程度越來越深，第三種創新型應用需求快速增長，也就是以業務部門發起的非傳統IT主導的應用，這些應用有“互聯網屬性”“在雲上”“上線週期短”“實驗性”“生命週期短”“需求不確定”“傳統IT部門不願意接的燙手山芋”等特點，低代碼平台出現的核心是滿足這些開發需求，而不是去搶OA、CRM甚至ERP的市場。

建議二、企業需要低代碼開發人員，當然不能指望業務部門開發低代碼，但是也不能純指望固有IT部門

國外的低代碼開始火的時候有一個美好願景，希望Citizen Developer（公民開發者）即沒技術背景的業務部門人員可以使用低代碼平台開發企業創新型應用。但是現實很骨感，哪怕有英語優勢可以理解計算機代碼，也不可能出現業務人員就能開發的應用。畢竟低代碼不是無代碼，還是有相當多的編碼和技術需求。

讓IT部門使用低代碼開發平台幫助業務部門開發創新型應用，聽起來合理，實際也有很大的悖論，因為IT部門已經有很多成熟的可以為程序員提升開發效率的工具和系統，沒必要再用一個新的。何況， “正經”的程序員也不希望使用一套“看似替自己幹活實際要革掉自己職業生涯命”的工具，讓自己的開發技術得不到提高。

業務部門的需求是現實的，固有IT團隊不願意接這些周邊的創新型應用也是真的。正因如此低代碼開發平台應運而生，而低代碼平台往往是“業務部門自己的預算去找新的人員（內部或者外部）來滿足這些創新型應用的開發需求”，所以低代碼開發平台，要具備大量的成熟開發者，打造自己的“低代碼開發生態”就是核心要務了。

其實很有意思，研究國外的低代碼領導型公司，就會發現所有領導型的公司都是很“老”的公司，基本沒有新設立的公司。這些公司以前都有自己的核心能力。如Outsystems、Mendix之前主要是做BPM（工作流），Kony之前主要是做MADP（移動開發平台），Microsoft、SAP低代碼開發的核心都是以前的aPaaS和MADP的重組。

可見國外的低代碼開發平台並不是全新的創新型技術，而是基於既有技術基礎的新模式。也就是把基於BPM的流程化、可視化和aPaaS的組件化雲原生以及MADP快速開發跨平台移動互聯網創新應用組合在一起，而形成的主流的LowCode低代碼平台。低代碼公司是不是具備BMP、MADP、aPaaS這三個重要基因中的至少其中一個，是評判該平台是否為低代碼公司的重要標準。

“低代碼”顧名思義就是“比正常應用開發要少寫代碼”。但不是所有能省代碼的開發方式都可以叫“低代碼”，真正的低代碼要有一些必備的特質。

縱觀盤踞Forrester和Gartner低代碼測評領導者角色的平台如Outsystems、Mendix、Appian和Kony等國外知名公司對自己產品的定義，總結下來，低代碼開發平台必須具備的核心要素叫“3+1”：

3個能力：可視化（拖拽式）、MADP（移動優先）、aPaaS（雲上開發環境）。

1個必須：有配套的生態（成熟的開發者、和其他雲或企業內部系統連接的能力）。

當然，很多人還會談到類似於“模型驅動”“表單驅動”“中台能力”“持續集成”等等眾多概念，這些都是可能涵蓋的因素，而不是非必要因素。不同的低代碼開發平台側重點不同這裏就不再贅述。總之，記住3+1就很容易區分“真假”低代碼開發平台。