文/明道雲創始人任向暉

我很喜歡的一位博主陳果昨天發了一篇公眾號文章《低代碼，不要以比"中台"還快的速度爛大街》。 憤世嫉俗的口吻總是能夠吸引眼球，果不其然，等我讀到的時候，閱讀量已經過萬了。

我的事業身家都在零代碼/低代碼領域了，他又是我一直很認同企業數位化專家，還專門寫一篇文章來批判低代碼，搞得我晚飯都沒吃好。

我當然理解他的意思，也認同文章中部分的觀點。 很多低代碼產品缺乏新意，只是可視化開發工具的延伸，很多廠商有概念炒作的嫌疑，自然讓業內磚家忍不住要抄起幾塊磚。 在陳果之前，還有一家知名IT諮詢企業的CTO在視頻號上有過類似的表達，他的口氣真是不屑一顧。 市場有多少低代碼，就有多少「低代碼是個偽命題」的評價。 我也發現傳統企業軟體的諮詢師普遍看衰低代碼，而企業IT管理者則普遍關注低代碼。 點評的人是真不知道做事情的難。

我是利益相關人士，從業於低代碼領域，且看好低代碼未來。 我不能讓這些唱衰的妄斷影響使用者的心智，但也不會空洞地揮舞低代碼的大旗。 我要盡全力說明清楚低代碼的本質是什麼，為什麼這一代產品和過去有本質不同，為什麼它的發展會有益於整個企業IT市場，為什麼爛大街並非一件壞事。

低代碼/零代碼的實質是什麼？

陳果可能認為低代碼平臺的實質是代碼依賴度更低的開發工具。 其實並不是這樣。 包括明道雲在內的這一代零代碼/低代碼（為簡便起見，後面我統稱低代碼）平台的實質是"應用平臺"（APaaS），低代碼只是它的使用特徵之一。 所謂應用平臺，就是DevOps（應用開發和運維體系）的對立面。 應用不再需要通過原生高級語言（Java，PHP，C#等）編寫，也不再需要完整的軟體開發角色分工（DBA，後端開發，前段開發，交互設計，介面設計，測試等）。 真正意義上的APaaS是不會有IDE環境的，也不會有代碼編譯，更不會有搭建應用運行環境的繁複過程。 應用通過APaaS搭建（我避免使用開發這兩字），搭建完成後，就在APaaS上直接運行。

APaaS對用戶結構的改變是不言而喻的。 因為摒棄了DevOps過程，非軟體開發人員終於可以直接參與到應用建設的過程。 有人說，市場上並不缺少開發者，為什麼一定要消除對他們的依賴呢？ 事實是市場上就是缺開發者，更缺的是能力強的應用開發者，因為他們大多數人都在科技行業從業，很少會直接助力一般行業的數位化建設。

即使有優秀的軟體開發者，為了產出高品質的企業應用，依然需要很多專業環節，比如需求分析、系統架構、產品交互設計等等。 這些專業過程極其費神，也非常昂貴。 對於大部分的企業軟體實現，這些過程大多數是草率處理或者被忽略的。

應用平臺的妙處就在於把這些專業過程全部通過平臺來模式化實現，雖然犧牲了一定的靈活性，但提供了高品質和高效率。 我們僅僅為了一個數據詳情頁，是十多位產品設計和前端開發反覆運算數十次以後才達到理想水準的。

模式化實現企業應用到底對靈活性的犧牲大不大呢？ 其實並不大。 大多數的企業應用都是由業務數據的增刪查改操作，工作流執行和管理，以及對業務數據的分析彙報等模式組成的。 這也難怪很多企業軟體都長得非常類似。 即便是通過原生技術棧定製開發，開發實現過程也極度相似。 所以在原生開發市場，也出現了大量的開源框架，讓開發者可以提高效率。 比如國內開發者常常使用Activity這個開源工作流框架來實現Workflow，用Ants這個前端框架來快速實現企業應用的前端介面。 這也難怪陳果認為低代碼並沒有節省多少開發的時間。 但正是這種模式近似性，讓APaaS有了普及運用的可能。 實際上，也正是因為這種靈活度的犧牲，APaaS可以非常專注在企業中後台應用實現上，對其他類型的應用開發心無旁騖。 陳果認為低代碼並不能用來開發所有的軟體，這當然是對的。

至於市場上依然有一部分APaaS會生成原始程式碼，並允許使用者調整原始程式碼，甚至使用第三方編譯環境，我認為這才是陳果說的「新瓶裝舊酒」。。 它們的實質依然是開發工具，只是可視化程度高，對代碼編寫的依賴度小。 很不幸，在這個領域最知名的廠商Outsystems就是這麼一個模式。 即使是IDE模式的APaaS也有價值，它至少大幅縮短了開發週期，但他們還是依賴程式師，沒有接受過軟體開發訓練的人員是很難掌握的。

低代碼不是玩具

人總有望文生義的認知偏見。 說是「零代碼」，「低代碼」，那必定就是簡單的工具。 簡單的工具就只能打造簡單的應用，這是毫無道理的武斷。 Photoshop和After Effects能夠創造出的華彩無比的影像作品和動畫，你從來沒聽說過要寫代碼;能不能寫代碼從來不是評價軟體工具先進性的指標。 過去沒有，以後也不會有。 尤其當應用平臺已經脫身於開發工具市場之外，它提供的就是一個搭建應用的應用，至於能夠設計和搭建出什麼樣的應用，主要依賴的是用戶的創作能力，而不是工具本身能夠決定的。

如果真的像陳果說的，低代碼產品只可以用來完成簡單的工作流和表單流轉的應用，那我們不必大費周章。 在APaaS之外，已經有很多羽量級的SaaS工具可以做到了。 而且，傳統的OA套件也都能夠創建自定義的業務物件和流程，根本輪不到APaaS來替補。

實際上，今天的APaaS能夠承載的業務複雜度是可以相當高的。 明道雲在金融業的ISV夥伴已經複刻出類似於BMC Remedy這樣的ITSM套件，雖然沒有覆蓋100%的業務環節，但把其中個人化程度高的流程部分解決得非常好;我們在稅務科技領域的合作夥伴普華永道，完整地提供房地產行業的稅務精算系統;可口可樂亞太技術中心利用明道雲搭建了實驗室數據管理系統， 我們在交通運輸的標杆客戶佛山地鐵和北京地鐵都已經將APaaS用在了非常高頻的設備管理、安全管理等環節上。 佛山鐵路投資集團甚至專門建立了零代碼實驗室，讓專案專家直接上手設計和搭建應用。 這些事實陳果可能不知道，但是我必須讓潛在用戶群體知道。 我們明明做了一個彈跳桿，卻被業內磚家說成是墊腳石，這是有失公允的。

當然，我也承認，現代APaaS產品有一個建立使用者信任的過程。 在這個階段，很多用戶選擇將APaaS用在一些局部的簡單環節，先進行成熟度和可靠性驗證，這是完全可以理解的。 但這個過渡現象不是我們產品的尺規。

低代碼不是軟體業革命，So What？

陳果指出低代碼並非軟體業的革命，這玩意早就有了。 完全正確，第一代應用平臺產品誕生在上個世紀末，距離現在已經20多年了。 是革命，也早就革命完了。 我們2B創業者追求並非是革命機會，而是漸進的改進機會。 漸進的改進，幅度大一些，持久一些，才是創造商業價值的有力途徑。 革命期的IT產品幾乎必然是低性能的，殘破不全的，只能夠服務先鋒性客戶的。 陳果先生想必非常熟悉Gartner的Hype曲線（技術成熟度曲線），APaaS品類早已過了那個過山車的頂峰，今天正在走進"尋常企業家"。 所以Gartner開始把APaaS作為魔力象限的研究範圍。

當一個市場開始漸進改進之時，正是它開始走向成熟的時點。 這時候，先發優勢和后發優勢都有效。 APaaS的前身——快速開發工具（RAD）身上的缺陷開始被消除，產品能力越來越強，用戶體驗越來越好，有效的商業模式也開始被探索出來。 在這樣的市場中，創業企業不必再承受過大的不確定性風險，看好增長的市場機遇。 尤其是低代碼市場還沒有明顯的領先企業，創業者和投資人當然都卯足了勁。 這也是為什麼過去兩年中，新出現的低代碼產品比較多的原因。

不僅有這四十多家創業公司參與，阿里和騰訊都推出了自己的低代碼產品。 如果不是革命，只是改進，那麼為什麼整個市場會投入如此大的關注呢？ 歸根結底還是因為市場大，需求旺盛。

APaaS可以滿足不同層次的市場需求。 首先它肯定能夠完勝傳統定製開發，即便一個專案不是100%能夠依靠APaaS實現，也可以將APaaS作為主要的基石，額外做一些擴展開發即可。 僅僅定製開發一項，能夠覆蓋的市場規模就極為驚人。 在台灣廣泛存在的區域性軟體服務企業中，大部分從事的都是定製開發服務。 過去，這些需求被散亂的開發人天所滿足，未來，APaaS將成為主要的交付基石。

其次，APaaS平臺可以積累各種行業應用的數據模型和解決方案，通過高水準的抽象后，它也能夠替代一部分專有性要求較低的行業軟體產品。 我們在服務實踐中發現，像製造、工程、專業服務等領域，所謂的行業應用產品都可以被APaaS替代，因為他們大多是半成品，真正要落地到每家企業，還是要做比較多的實施工作，這本質上和APaaS的實現投入是一樣的。 而APaaS還能夠提供額外的靈活度。

第三，很多企業都有了"中台"的理念。 當業務規模成長到一定階段時，企業希望能夠從各個應用或子系統中抽取關鍵業務對象數據，從而實現企業範疇內的數據一致性和共用性。 APaaS真是特別適合干這個工作。 通過一些簡單的集成開發，匯入數據到APaaS上，再通過APaaS所提供的API對外進行服務。 買一套APaaS，基本就擁有了一個數據中台的實質。 這對規模以上企業是有很強吸引力的。 你可以說數據中台的建設需要很多專業技術棧，但是對絕大多數行業來說，APaaS的內置能力就已經夠了八九成了，剩下的一些細節完全可以靠補充和擴展來解決。 我們的一個跨境電商客戶，每天40萬左右的訂單和運單，每個單據都有三到四個工作流要即時觸發，完全運行在我們的雲平臺上。

低代碼產品的確在增多。 多歸多，相比較其他領域，LCAP或APaaS市場的進入門檻依然比較高。 我看到2020年發佈的最長的一個廠商清單也不過40多家（這其中很多依然是快速開發工具的性質）。 但是在同期，CRM產品可能有數百家，就連生產執行系統（MES）產品和廠商都有這麼多。 相比較各自的市場容量，APaaS的競爭遠沒有到爛大街的地步。

我們想成為最爛的那個

我其實是多麼希望低代碼爛大街啊。 什麼叫爛大街？ 就是人盡皆知呗。 川菜爛大街，廣東菜爛大街，火鍋爛大街，那是因為它們都是餐飲業的主流。 低代碼之於企業軟體，爛大街的一天就是成為主流的一天。 所以，我們明道雲就想成為爛大街上最爛的那個，火鍋店中的海底撈。

問題是，成為海底撈真的不容易。 海底撈在餐飲業依靠獨特的服務理念贏取了顧客口碑，在企業軟體行業，這把鑰匙是什麼呢？ 我想了二十年也沒得到確定的唯一答案。 但是對於APaaS來說，我覺得最重要的可能是「易用性」。

易用性是打開行銷獲客、產品價值、管道拓展和客戶服務四個魔盒的通用鑰匙。 解決一個問題，就等於同時解決了四個問題。 尤其是像APaaS這樣的複雜產品，易用性顯得難能可貴。 去年，國內出現了好幾家完全模仿Airtable的產品，我想他們都看中的是Airtable的易用性。

陳果認為APaaS面向「公民開發者」是不現實的。 我認為不僅現實，而且太重要了。 企業的數位化問題憑什麼都要程序員解決？ 如果真的是這樣，那幾十年來的Excel高手們都是幹什麼的？ 理解業務，熟悉業務，掌握數位化工具，是越來越多企業內部尋求的人才物件。 APaaS服務的就是這樣一群專業使用者，通過他們可以間接服務到各行各業的企業。 這樣的人才當然不是爛大街，但是總歸比受過專業訓練的程式師多得多，更重要的是他們同時是需求的提出者和滿足者，省卻的溝通和協作成本是驚人的。 陳果先生擔心低代碼產品離不開專業使用者的使用，這是對的，但是不要忽視這個龐大群體的存在。

所以，我們相信並堅決地服務非開發人員掌握APaaS產品，把產品的易用性永遠放在首要位置。 一個再強大的產品，如果難以掌握，是不可能爛大街的。 相反，把一個複雜產品做得容易理解，容易上手，容易解決問題，真的是一件特別有成就感的事情。 我們在產品設計評審時，最常見的挑戰就是功能的可理解性，而不是功能的多寡。 如果我們自己內部都不能達成統一理解的，就絕對不會發佈給客戶。

我們自信把明道雲的功能和易用性平衡得很好。 市場也給了我們積極的回應。 在產品推出后的19個月中，我們的客戶上至臺灣人民銀行這樣的國家機構，下到幾十人的電商團隊都可以很好地運用。 接下來，我們要做一個更讓自己爛大街的動作。 通過這篇文章，我想預告給大家，明道雲將在今年春節前推出「免費版」，讓人人都可以成為應用開發者的口號真正落實。 好的產品，就應該放下門檻，讓更多人可以接觸到。

海底撈很厲害，能夠免費吃的海底撈更厲害。 歡迎大家下個月到免費的明道雲來吃火鍋。