最近很多人都關注到了零程式碼快速開發平臺，但還是有很多朋友不太瞭解零程式碼，或者說無程式碼快速開發平臺，究竟是什麼，怎麼用，有哪些。今天，我們就來講講。
零程式碼快速開發平臺是什麼？
零程式碼軟體開發並非一個全新的概念。早在1992年，最早的零程式碼企業軟體構建工具就出現在了微軟的 Office 套件中，很多企業極客都記得那個叫做 Access 的資料庫應用。只不過，當年的 Access 只是一個單機版的應用，資料共享依賴繁複的企業網路，而且它也只是提供了一個數據庫的視覺化介面，可以加快構築業務資料表，關聯關係以及用於輸入輸出的表單和報表。
近幾年，因為雲計算和各種開發技術的加持，零程式碼工具在 SaaS 市場重現，並逐步獲得新的地位。它搭建（可能叫“開發”已經不夠準確）出來的企業應用在靈活性和易用性方面已經可以媲美原生開發的企業軟體，而實現業務需求的速度可能不到原生開發的十分之一。零程式碼構築企業應用既有 SaaS 的特點，也有開發工具的性質，所以一般又把這個門類稱為 aPaaS，前面的‘a’就是 Application 的含義。真正的零程式碼開發平臺面向的是廣泛和多樣的需求，在設計 零程式碼快速開發產品的時候，並不確定一個特定的使用者會用它來搭建什麼應用。當然，雖說面向的需求是廣泛的，也不代表 零程式碼快速開發是萬能的。零程式碼開發幾乎都是面向企業應用世界，而很難擴充套件到消費者應用領域，比如遊戲、社交、工具軟體等必然長期屬於原生開發的世界。
因此，零程式碼應用開發平臺是指圍繞企業資料和業務管理需求，透過視覺化方式設計資料結構，使用者互動形式、設定訪問許可權和定義工作流程的平臺。你會發現，即使是原生開發企業軟體，大體也是按照以上這幾個步驟來進行的。
零程式碼開發平臺的能力元素和特性
1）視覺化構築業務物件資料表（Entity），並支援建立關聯。甚至需要支援跨應用的資料表關聯。（這是 零程式碼快速開發未來可能勝出其他方案的關鍵優勢）。
2）為不同的資料場景配置不同型別的檢視（View），能夠定義資料行和列的過濾，能夠設定列表、看板、日曆等不同介面形式。
3）能夠定義不同使用者角色（Role），並賦予角色不同的資料訪問和改寫許可權（Permission Set）。許可權定義越精細越好。
4）能夠建立針對資料的彙總表和統計圖表（Report）。
5）能夠建立自定義的輸入表單（Form），分發給不同角色使用。
6）能夠建立自定義的列印報表（Form Report），用於輸出各類形式表格，透過 E-mail，簡訊傳送或者列印。
7）能夠管理企業使用者、部門、組織結構，並將其用於應用邏輯關係，比如應用的分發，角色的賦予和工作流中的流向資訊。
8）能夠視覺化配置工作流（Workflow），支援特定條件下的資料新增、改寫、刪除等操作，並能夠融入資料填寫，審批等人工流程節點。工作流的執行能夠監控和儲存日誌。
9）應用能夠封裝後分發（Distribution）給不同的使用者。
10）面向企業內部個人使用者的工作臺，儀表臺等特性，實現個性化使用。
不同的 零程式碼快速開發產品會有不同的特色和側重點。因此，以上特性並不一定存在於每一個 零程式碼快速開發產品中。但是，特性越完整的，就越接近一個典型意義上的零程式碼企業應用開發平臺。在以上實現中，有純粹的零程式碼模式，也有個別需要用低程式碼方式來降低產品複雜度，但同時也會讓非技術人員難以上手。
所以，零程式碼快速開發是 SaaS 應用和開發工具的混合，說它是 SaaS，是因為開發者和終端使用者使用的是同一個產品，只是透過許可權和分發關係讓介面千人千面。說它是開發工具，是因為它用模型模擬的應用搭建思路和原生資料庫應用開發是類似的。
軟體的應用特點和二次開發能力共存也不是一個新鮮事物。用 Excel 軟體構築一個個人所得稅計算器，讓使用者可以輸入自己的工資，即可得到應繳稅額，對於使用者來說是應用，對編制這個 Excel 檔案的人來說是開發工具，但他們用的都是 Excel。
零程式碼快速開發難以替代的優勢
1）滿足企業的多樣化需求
企業軟體需求的多樣化是定製開發模式的起源。雖然標準 SaaS 產品能夠滿足企業應用需求中的共性部分，但是因為行業、規模和產品內在特性的差異，每個企業的管理方式和流程都有自己的特點，而且它還會根據企業的規模階段不斷演變。這種差異在不同職能中程度不一，一般來說，圍繞產品設計、製造和服務履行的核心業務流差異度更高，而人事，財務等價值創造的支援環節差異度比較小。在這種背景下，使用者始終在尋求一種既能保持足夠的靈活性，又能夠控制開發的成本和複雜度的方法。零程式碼快速開發基本就是直接針對這個問題而誕生的。
2）從定製開發中需求溝通的痛苦中解脫
企業軟體實現過程中的第一痛點還不是貴，而是需求溝通的複雜。更要命的是，很多時候需求在實施之前都無法100%確定，企業自己無法提出一個完整的解決方案。這時候，要麼需要求助於諮詢機構這樣的外腦，要麼就只能走一步看一步。這兩個方案聽起來都不令人舒適。前者絕非普通中小企業所能夠承受，後者可能會影響系統的開發和實施質量。
零程式碼快速開發的出現倒是讓走一步看一步的方案變得更加現實。企業可以透過零程式碼平臺漸進地開始實施。如果整個系統過於複雜，可以先從一個具體的環節開始，區域性數字化（比如先把訂單管起來）。反正用 零程式碼快速開發搭建的速度足夠快，使用者甚至可以利用零程式碼工具來生成企業應用原型，在實際使用中進行驗證，確認了終端使用者可以掌握，原先識別的問題可以被有效解決之後，再繼續推進更完整的實施。
可以這麼說，零程式碼工具可以讓開發者和使用者之間的距離充分縮短。在極端情況下，使用者甚至可以自己就是搭建開發者自己。他們可能在一兩個小時的搭建後就能夠確認這個方案是不是能夠有效地解決問題。
3）在企業內部打通資料中臺的需求
在企業 IT 中，還有一個致命痛點存在，那就是不同業務系統之間的資料相互隔離，不能綜合使用，使得企業難以進行跨職能的資料相關性和因果分析，也難以實現跨職能的資料自動化。比如要分析一個價格調整措施對財務報表的影響，這個工作在任何一個孤立的資訊系統中是無法完成的，而如果要做到，就至少需要從採購、銷售、營銷和財務系統中獲得資料。
同樣的道理，企業也很難在遇到財務目標無法達成的情況下，自動做出最優的價格決策。這些都是影響企業運營水平至關重要的問題。近年來，Gartner 提出的 Paced Layer 架構，以及阿里給電商企業提供的中臺方案就是針對這種需求的反饋。
大企業當然可以投入專門的資金來打造資料中臺性質的系統，但小企業支付不起，並不代表他們不想獲得這樣的能力。零程式碼快速開發平臺提供了這個可能性。
首先，因為零程式碼快速開發平臺管理資料的模型一致，所以它一般能夠提供一個標準化程度非常高的程式設計介面，從外部系統匯合資料變得相對容易很多，這就像路由器一樣，不管你有多少聯網裝置，它們都可以用統一的協議連線在一起。有了集中的資料，各種應用需求都變得容易兌現。哪怕個別系統依然需要透過抽取資料服務後另行原生開發，也比不斷重複做資料整合工作要高效很多倍。
甚至，如果用 零程式碼快速開發平臺直接管理業務資料物件，這個資料整合工作都可以免除。使用者可以直接在各個職能相關的資料物件中建立關聯，建立彙總查詢，批次抽取資料到BI平臺，建立不同資料之間的自動化。
4）突出的成本和效率優勢
零程式碼開發平臺和原生程式碼開發相比到底能夠提高多少效率目前還沒有精確的計量，但這個效率差至少是10倍以上。傳統開發模式需要10天的，零程式碼快速開發一天之內就能夠搞定。
更重要的效率差別不僅僅是時間，還包括零程式碼平臺可以免除專業技術人員的參與。雖然它要求搭建者熟悉業務，完成基本的邏輯梳理，但畢竟這和動輒需要和好幾位技術人員一起開會溝通需求要高效得多。即便在複雜的應用系統上，也至多隻需要2-3人分工就能夠完成整個專案的實現。因為簡化協作的原因帶來的成本節省甚至都不止十倍了。因為所有人都知道找到靠譜的定製軟體開發團隊幾乎就是一件撞大運的事情。
同時，定製開發通常很難提供高品質的軟體。軟體執行的可靠性，缺陷消除的程度都很難和標準化產品相比，畢竟定製軟體只有一個使用者。而一個 零程式碼快速開發平臺不僅要同時服務很多終端使用者，還要服務五花八門的應用搭建者，它能夠做到一次對，次次對；一次缺陷消除，所有使用者收益的效果。
5）開箱即用和自己動手的兩全
和成型的 SaaS 應用相比，零程式碼快速開發看似有一個缺點，就是依然需要“搭建”。這有點像整體傢俱系統，擺在樣品間很好看，但是實際買回家還需要施工人員來拼裝才能達到預期的效果。
實際上，這個問題並不是無解，甚至很好解。零程式碼快速開發一開始自然不可能獲得各個行業的最佳實踐，讓每個企業都能夠看到“樣板間”效果。但是，隨著時間的推移，使用者企業和整合商的參與，樣板間會越來越多，甚至比 SaaS 產品提供的用例方案更加強大，因為後者提供的是一個固定傢俱的擺設效果，而前者能夠根據不同的房型，提供不同的傢俱組合方案。
而且，在足夠明確的細分市場下（比如金屬加工製造流程管理這樣的顆粒度），可以在 零程式碼快速開發平臺上開發出完全開箱即用的應用，直接分發給不同企業使用。有了這個能力，零程式碼快速開發不僅能夠服務好終端使用者，還能夠催生整合商工作模式的變革，他們不僅可以通過出售IT服務掙錢，還能夠在服務中加入解決方案的價值，消除定製開發成本，大幅提高專案服務毛利。
有了開箱即用的能力後，就能夠大大加速企業採納的意願。而且，才採納以後，“自己動手”的能力依然存在。就像先進的整體家居系統不僅可以組合，而且可以重新組合。
企業軟體的適用模式永遠和企業階段有關，比如小型製造業並不見得需要質量管理單元，但當年產值突破一億元左右後，不僅面臨 ISO 認證的剛性需求，也內在地需要引入全面質量管理。這樣的企業可以在軟體實施後依照實際需要繼續調整、改進和增加軟體模組。這個過程同樣是低成本和高效率的。
6）平臺特徵提供的計算能力保證
在資料庫應用中，有一個潛在的計算效能問題，尤其是在大規模資料表中進行復雜查詢和聯動計算時。
如今，很多行業的企業資料規模都從數千數萬條記錄增長到百萬，千萬，甚至電商廠商輕而易舉可以達到億級資料。在製造和物流行業，物聯網技術也必然帶動更多的聯網物件，產生的資料不僅規模巨大，而且計算形式也需要有針對性地加強。
對於定製實施系統來說，要分別透過分散式資料庫，流式計算等先進技術來克服效能問題是一件極其昂貴的事情。零程式碼快速開發平臺雖然為使用者提供的是一個應用級的產品，但因為它正規化統一，就有機會將這些基礎計算隱藏起來，讓使用者不必關心這些後臺事務就能夠獲得高效能的計算服務。
透過 零程式碼快速開發平臺管理的資料表無論規模有多大，讀寫有多麼頻繁，實時查詢的要求有多高，總有一個計算框架可以勝任。這種平臺的擴充套件性讓客戶可以真正放心，零程式碼快速開發帶來的不僅僅是開發效率的提升，還包括一個伸縮自如的基礎設施服務。即便企業將來的業務規模成長百倍，也不會需要徹底重建 IT 系統。
實際上，年收入數百億美元的業務，背後驅動的IT平臺極有可能就是 Salesforce 的 Force。com 平臺搭建的應用，而不需要是獨立建立的應用系統。
正是因為以上這些優勢，零程式碼快速開發在沒有得到行業命名之前就已經開始逐步滲透到企業IT服務領域。在最近幾年正在悄悄替代大量的定製實施軟體專案，也讓原先依靠標準 SaaS 產品的企業找到了新的選擇。
零程式碼快速開發目前適合的企業
零程式碼快速開發雖然擁有巨大的優勢，但也不代表它能夠滿足所有行業和企業的所有 IT 需求。下面列出了一些常見的排除項。零程式碼快速開發方案對這些性質的需求吸引力不強。
1）行業有明顯的專有特徵
有些行業本身的專有化程度很高，而且企業之間的差異性不大，這時候垂直的行業應用可能更加合理。
圍繞這個特徵最典型的例子就是餐飲業和酒店業。所有餐飲業的運營邏輯都是類似的，除了單店和連鎖可能使用不同複雜度的方案以外，應用模組都大同小異。而且，這個行業解決問題的方法和方式是有明顯的行業特徵的，比如餐廳的排隊等座系統，點單結賬系統等。用零程式碼工具來構建如此專有的場景反而更加麻煩，而且無法有效提供有行業特色的檢視。
2）行業有獨立的程式碼審計要求
金融等行業的核心業務系統因為法規等要求不能使用零程式碼平臺，因為它無法滿足程式碼審計的要求。零程式碼快速開發平臺不一定能夠提供原始碼給使用者企業，而且即使提供，也無法佐證應用系統處理資料的準確性。這些行業因為監管要求高，本身資金也寬裕，所以不會應用 零程式碼快速開發方案在核心業務環節。
3）面向顧客的前臺系統
這個當然就是指的電商網店平臺了。雖然電商零售的基本資料管理和 零程式碼快速開發的能力並無太大的距離，但是面向消費者的前臺系統一般要求更高的靈活性和營銷設施的配套，用零程式碼平臺建立不如直接使用專門的電商系統，比如有贊、微盟等開店方案。它們提供的不僅僅是店面功能，還包括圍繞顧客的營銷服務和支付平臺，這些是 零程式碼快速開發所不擅長的領域。
除此之外的大部分企業 IT 需求，零程式碼平臺都有足夠的優勢來勝任。而且，隨著軟體和服務的界限越來越模糊，很難說未來的 零程式碼快速開發不能擴充套件它的領地。企業軟體的本質就是生產力工具，零程式碼快速開發的核心精神就是圍繞企業的數字化運營提供高生產力選項。
在使用者滲透的過程中，當前階段的零程式碼平臺更多滿足的還不是普通企業的需求，而是那些有一定自建 IT 能力的企業。他們一般擁有若干名資訊化專員，能夠理解自己企業的核心業務流程和問題，能夠和業務部門展開有效的溝通。
除了終端企業使用者外，行業諮詢群體和 ISV 群體也開始更多關注零程式碼工具，因為行業諮詢者永遠都希望擁有屬於自己的落地工具集，而他們很難投入做出自己高質量的原生軟體產品；
而 ISV 群體則常年面臨專案實施成本高，客戶需求差異度大的痛點，希望透過某種平臺來降低開發服務成本，沉澱自己的方案能力，從而讓專案實施具備更多的可複製特點。
行業諮詢、管理諮詢和 ISV 群體對零程式碼平臺的掌握最終會讓這個門類的解決方案走入更多的主流企業使用者。