低代碼開發(fā)平臺-解決SaaS應用的最后一公里（低代碼開發(fā)平臺是什么意思）
今天準備再談下對低代碼開發(fā)平臺的擴展思考，最近2到3年，低代碼開發(fā)平臺可以算作一個小熱點，不論是傳統(tǒng)的BPM廠家，還是原來的快速開發(fā)平臺廠家，包括還有一些中臺建設廠家都逐步推出自己的低代碼開發(fā)平臺。
低代碼開發(fā)平臺概述
對于低代碼開發(fā)平臺的分析，我前面寫過一篇文章可以參考：
從這篇文章大家可以對低代碼平臺有個初步的了解。如果簡單地總結低代碼開發(fā)平臺，可以理解為一切皆是可配置，可建模的。而本書建模的關鍵又在于對業(yè)務領域和現(xiàn)實世界的大量實踐和抽象。
對于低代碼平臺核心要素，我也整理過一篇文章：
即LCDP平臺的核心包括了上圖中的數(shù)據(jù)建模，表單建模，流程建模，權限建模，報表建模和規(guī)則建模幾個關鍵部分的內容，通過這些建模組件，包括這些組件之間本身的協(xié)同來完成一個完整業(yè)務系統(tǒng)和功能的構建。對于這些建模要素之間如何集成和協(xié)同，可以參考上面這篇文章詳細說明，在這里不再重復敘述。
在企業(yè)數(shù)字化轉型和IT架構演進中，前面也談了圍繞云原生技術來打造企業(yè)核心的技術中臺能力，其中的關鍵點是微服務，DevOps和容器云技術。
雖然說這些技術都可以提供應用軟件持續(xù)集成和交付的效率，但是并不會說明顯提升軟件開發(fā)的效率，而對于軟件開發(fā)效率提升來說，共性技術組件的積累，靈活的開發(fā)框架，代碼生成，類似流程，表單，報表等動態(tài)可配置能力仍然是關鍵。
因此我在前面專門寫了一篇文章談到低代碼開發(fā)平臺是云原生整個技術解決方案的一個關鍵補充，通過引入基于微服務架構的低代碼開發(fā)平臺，來加快微服務和模塊化應用的開發(fā)，集成和部署上線效率。
具體可以參考下面這篇文章：
但是軟件開發(fā)中困難的部分是規(guī)格化、設計和測試這些概念上的結構，而不是對概念進行表達和對實現(xiàn)的逼真程度進行驗證。也就是說軟件開發(fā)真正的難點是在于完成從現(xiàn)實世界到軟件抽象世界的轉換和建模，這個首要任務當前并沒有一種很好的自動化完成的方法和工具。
也正是這個原因，我又寫了一篇再論沒有銀彈的文章。
對低代碼開發(fā)平臺的分類
當我重新來思考軟件系統(tǒng)復雜性和低代碼開發(fā)平臺之間的關系時候，需要找到一個方法或邏輯進一步將我前面闡述的內容描述清楚。
簡單來總結下結論應該就是：
- 簡單軟件系統(tǒng)可以有銀彈，但是復雜系統(tǒng)短期沒有銀彈
- 低代碼平臺應分為面向技術人員和面向業(yè)務人員兩類
也就是說對于軟件系統(tǒng)或軟件應用首先應該分類，雖然有很多類似ERP等企業(yè)信息化軟件系統(tǒng)，但是對于大部分小微企業(yè)來說，核心的軟件應用訴求就是電子化表單 流程。也就是說希望能夠將一些紙面表單電子化并統(tǒng)一管理起來。
對于這類應用需求是完全可以靈活實現(xiàn)自動化和智能配置的。
對于低代碼開發(fā)平臺，實際應該分為兩類。
一類是類似商用的普元EOS平臺，或者開源的JEECG平臺。這類平臺實際是面向開發(fā)和技術人員使用，并不是說完全無代碼化，而是真正的叫低代碼，實現(xiàn)低代碼核心還是共性技術組件能力下沉和可復用。
但是具體的業(yè)務規(guī)則和邏輯的實現(xiàn)還是需要你寫代碼來完成，由于共性技術組件可復用，開發(fā)者可以更加專注于業(yè)務功能和業(yè)務邏輯的實現(xiàn)。
我們可以看下JeecgBoot網站的說明。
JeecgBoot是一款基于BPM的低代碼平臺！前后端分離架構 SpringBoot 2.x，SpringCloud，Ant Design&Vue，Mybatis-plus，Shiro，JWT，支持微服務。強大的代碼生成器讓前后端代碼一鍵生成，實現(xiàn)低代碼開發(fā)！ JeecgBoot引領新低代碼開發(fā)模式 OnlineCoding-> 代碼生成器-> 手工MERGE， 幫助Java項目解決70%的重復工作，讓開發(fā)更多關注業(yè)務，既能快速提高效率，節(jié)省研發(fā)成本，同時又不失靈活性！一系列低代碼能力：Online表單、Online報表、Online圖表、表單設計、流程設計、報表設計、大屏設計等。
這類平臺面向開發(fā)人員，更像我們原來經常說到的下沉了技術組件能力的開發(fā)框架和環(huán)境，協(xié)助你實現(xiàn)業(yè)務和技術的解耦，讓你在開發(fā)時候真正專注在業(yè)務功能和邏輯實現(xiàn)上面。
這類平臺本身代碼可見，可修改和可維護。用的技術也是主流的開源微服務開發(fā)框架，開源組件技術的集成，你也不會被綁定和限制。因此可以作為整體云原生技術解決方案的一個重要組成部分。
簡單總結就是這類低代碼平臺不要去管具體的業(yè)務流程，業(yè)務功能和業(yè)務邏輯的實現(xiàn)，你只要做好共性技術組件，做好開發(fā)框架和底層技術支撐，就是一個很好的平臺。
第二類低代碼平臺類似宜搭，輕流，奧哲，明道等。
圖為奧哲低代碼平臺整體架構
這類低代碼平臺更加偏向于面向業(yè)務人員，或者更多是不直接面對底層代碼的零代碼開發(fā)平臺，希望做到的是應用可以通過搭建積木的方式進行快速配置來實現(xiàn)。
我原來一直不太認可這個思路。
但是最近通過復盤和一些產品試用，整體感覺對于中小企業(yè)很多僅僅是實現(xiàn)表單電子化和流程化的場景，完全可以做到類似上面的零代碼和快速配置。
這個實際上和很多年前OA類系統(tǒng)提供的各類單據(jù)快速配置功能完全一致。比如多年前類似藍凌OA系統(tǒng)就已經可以實現(xiàn)這種需求，一個請假單功能，你完全可以自己配置單據(jù)界面，然后設計一個流程并完成掛接。
這類單據(jù)本身對象和數(shù)據(jù)建模都簡單，同時單據(jù)本身也不和其他單據(jù)發(fā)生強耦合和關聯(lián)關系。屬于典型的電子表單 流程的需求場景。
那么這類場景一定是可以完全零代碼化和可配置化的。
低代碼開發(fā)解決SaaS服務最后一公里
首先對前面的內容做一個總結。即低代碼平臺分為面向開發(fā)人員和面向業(yè)務人員兩類，第一類可以作為企業(yè)IT架構轉型和云原生整體解決方案的補充；而對于第二類則面向中小型企業(yè)的表單單子化和流程化需求場景。
由于第二類本身是零代碼和完全可配置的形式出現(xiàn)的，因此這類低代碼平臺不會提供私有云環(huán)境部署和集成，更多的是以SaaS應用的方式提供。
對于SaaS應用可以看到，在前面很多年發(fā)展的并不算太好。其中一個關鍵原因就是SaaS應用本身對用戶個性化需求的滿足度并不會太好，最多提供一些簡單的字段，流程可配置能力，在這個能力外的個性化需求都難以滿足。因此SaaS應用本身雖然實現(xiàn)了服務的統(tǒng)一化和標準化，但是本身也降低了靈活性和個性化。
如果所有用戶的定制化需求SaaS應用都需要滿足，那么SaaS云服務商本身又變回了傳統(tǒng)的應用定制開發(fā)服務商，失去了云平臺和云服務，發(fā)揮長尾優(yōu)勢的意義。
也正是這個原因，低代碼開發(fā)平臺正好可以作為傳統(tǒng)的SaaS應用服務和用戶之間的一個關鍵連接橋梁。即通過低代碼開發(fā)，釋放更多的可配置能力給最終的用戶使用，但是本身又零編碼，既滿足了個性化需求，又實現(xiàn)了SaaS服務的統(tǒng)一化管理。
在這種場景下，低代碼開發(fā)不是解決的開發(fā)問題，而是解決的基于業(yè)務需求快速上線應用的一體化交付問題，也就是說提供低代碼開發(fā)能力只是你SaaS運營服務向用戶端的一個關鍵延伸，你的核心還是SaaS應用服務能力提供。
當把這個關鍵點想清楚后，低代碼平臺變成了SaaS應用延伸的關鍵抓手。
但是當我們重新思考軟件系統(tǒng)本身的復雜性問題的時候，可以看到很多時候并不是簡單的零編碼或者搭積木的方式就能夠完成應用的開發(fā)和交付的。
這個時候你仍然需要去做業(yè)務抽象和建模，去做規(guī)則的開發(fā)和定制。
如果要做到進一步的可配置，你就必須抽象共性業(yè)務組件或業(yè)務能力，也就是說你需要首先在底層建立抽象的共性業(yè)務模型，其次才是支撐前端的可配置開發(fā)。
這種共性業(yè)務模型是否可抽象？
當我們的SaaS應用聚焦到一個高度垂直細分的專業(yè)領域的時候，那么這個模型本質是可以抽象和提取共性的。類似你本身就是做一個項目管理和協(xié)同SaaS應用，或者一個CRM應用。那么你就可以去抽象這類垂直應用的底層業(yè)務模型了。但是如果要擴展到所有行業(yè)，所有應用都能夠抽象大而全的模型，這個本身又是違背了我前面談到了復雜系統(tǒng)沒有銀彈的觀點。
也正是這個原因，在這里給出第二類低代碼開發(fā)平臺的發(fā)展方向，即作為垂直細分的SaaS應用的關鍵延伸能力，而不是去開發(fā)一個大而全的零編碼的低代碼平臺。
最后再次用我在沒有銀彈一文中的一句話作為總結。
沒有任何技術或管理上的進展，能夠獨立地許諾十年內使生產率、可靠性或簡潔性獲得數(shù)量級上的進步。 降低復雜性的基本方法就是把復雜性隔離。
