type=info

本頁面中的內容基于Gartner企業級低代碼開發平臺的標準功能“雙向WebAPI集成”，可能并不適用于“表單驅動的低代碼平臺”和部分“模型驅動的低代碼平臺”。

隨著企業內運行的軟件系統數量增加，如何打通這些數據，避免出現數據孤島，成為企業IT決策者必須面對的課題。而低代碼技術的出現，可以幫助開發者整合現有軟件的數據和業務能力，構建起支撐上層應用開發的數字化平臺，在保護既有IT投資的基礎上，不斷提升企業數字化的廣度和深度。

一、挑戰：數據孤島

隨著企業信息化建設的推進，大量應用軟件被引入到企業運營，有效提升了各業務場景的數字化水平。然而，不同時期、不同廠商和不同交付方式引入的系統，在數據存儲方式、數據格式和主數據/元數據定義上很難做到統一化，導致各系統的數據難以打通，體現為數據鏈接不暢、數據統計不及時、各系統數據對不上等問題。這些問題的本質是相互交織的業務與割裂的軟件系統之間的矛盾。以生產和銷售型企業的訂單為例，一張訂單貫穿從銷售、采購、生產、庫存、物流等多個業務環節，如果這些環節使用的軟件系統無法實現數據集成，員工就必須多次手工錄入訂單，工作效率低，數據錯誤率上升，統計報表的準確性和實效性都難以保證。這種現象通常被稱之為“數據孤島”，是企業數字化提質的最大障礙之一。要想解決這一問題，必須找到其發生的根本原因。

數據孤島在企業中普遍存在，其成因可以歸類為技術和管理兩個方面。

1.1 產生數據孤島的技術原因

技術原因是產生數據孤島問題的直接原因。

大多數企業中存在多個業務系統，運行于不同的部門。當一個系統需要使用其他系統的數據時，則需要有針對性地采用不同的技術手段，如調用系統提供的WebAPI、直連系統的數據庫、基于Excel/CSV文件的導入導出等。在實際操作中，尤其是一些“短平快”的外包項目，數據集成的困難重重。

即便系統均提供了良好的WebAPI和數據庫訪問能力，并配套了準確的技術文檔，做數據集成時，依然需要面對元數據/主數據匹配的問題。比如主數據編碼規范不一致，同一個SKU，在A系統中按照{產品線}-{型號}的規則進行命名，B系統中是{型號}（{產品線}）；或數據層級不一致，同一個SKU，在B系統中存儲為單一層級，在C系統中，SKU上級還設置有專門的產品線主數據。

數據提供方式和主數據匹配問題疊加在一起，大幅增加了各系統間數據集成的技術難度，最終造成并加劇了數據孤島的問題。

1.2 產生數據孤島的管理原因

管理原因是數據孤島的癥結所在。

和企業管理中遇到的大多數問題類似，技術問題的背后是管理問題。在信息化建設過程中，企業IT的長期規劃存在缺位，軟件選型、開發、實施的過程中，在成本和進度的壓力下，過分考慮當下的功能需求，在功能之外的可維護性、規范性方面做過多妥協。比如在定制開發軟件時，沒有將數據接口納入項目范圍等；又或者在開發銷售管理軟件時，為了減少調用ERP的API讀取商品檔案的開發成本，重復開發一個SKU管理模塊等。

在業務需求積壓嚴重，軟件開發成本頻繁超出預算的背景下，數據孤島的產生也就難以避免了。

所以，積極引入新的開發技術和工具，緩解成本和交付壓力，建立并實踐長期的IT規劃，讓應用系統架構在統一的平臺上，才能從根本上解決數據孤島問題。

二、出路：低代碼數字化平臺

從面向未來的長期IT規劃，到可支撐應用層開發的平臺，數字化平臺為新一代的企業數字化打下堅實的基礎。與傳統的信息化建設關注的數據中心和技術平臺不同，數字化平臺增加了對數據和應用層的關注，強調對主數據和業務能力的封裝，在確保數據孤島不再出現的前提下，盡量降低應用層開發的邊際成本，為業務轉型升級提供及時有效的支撐。在“提升應用層開發成本”的旗幟下，低代碼技術和數字化平臺正在融合，基于低代碼平臺整合現有軟件，打造出數字化平臺，再使用低代碼技術編排數字化平臺提供的業務能力，高效開發上層應用，正成為企業數字化建設中最有競爭力的技術選項。

2.1 數字化平臺的系統架構

數字化平臺一方面需要面對需求側，提供數據互通、業務連攜的使用體驗，另一方面也需要面對開發側，提供更高效、更可控的開發賦能。而這一切建立在對充分利用低代碼技術，復用現有軟件、保護IT投資的基礎之上，即打通現有軟件，構建面向未來的個性化業務應用。具體而言，數字化平臺可以劃分為平臺層和應用層，兩者的差別如下表所示。

參考閱讀：低代碼開發純前端或純后端應用

面向需求側：應用架構

面向開發側：技術架構

2.2 建設低代碼數字化平臺

低代碼數字化平臺的建設有兩個技術路線：從零開始建設，適用于現有軟件投資規模小的初創企業或大企業為新業務設立的獨立業務單元（BU）；基于現有軟件建設，適用于現有軟件較多的成熟企業或業務單元。兩者的最大差異主要體現在平臺層的開發方式上，前者的開發難度和成本降低，可適當加快開發節奏，讓平臺跑在應用層設計前面；后者的平臺層開發需要與多系統集成，難度更大、成本更高、存在一定的風險，則更推薦跟隨應用層的設計，有明確的需求再動手。

為了提升開發效率，降低維護成本，在應用層開發中，首推低代碼開發模式（需要低代碼平臺支持調用第三方WebAPI）；在平臺層開發中，也建議優先考慮低代碼的模式（需要低代碼開發平臺支持構建滿足OAith2等安全認證標準的WebAPI），除非必要，不建議回退到開發成本更高、迭代速度更慢的純代碼開發，以免形成整個信息化建設的瓶頸。

從零開始建設

1. 制定IT規劃（重點關注主數據）、開發管理規范和運維管理規范

2. 環境準備：采購或部署版本管理服務（如Git）和最小化的開發/測試環境

3. 使用低代碼平臺開發平臺層WebAPI

   • 主數據的基礎WebAPI：CRUD

   • 主數據的其他WebAPI：常用查詢、有效性校驗等

4. 部署平臺層程序，使用sostest等自動化測試工具，確保平臺層WebAPI的質量

5. 根據IT規劃，使用低代碼平臺，調用平臺層WebAPI開發應用層程序

6. 部署應用層程序，通過功能測試，確保應用層的質量

7. 使用低代碼持續迭代平臺層和應用層

   • 根據需求側反饋，在應用層開發新的業務應用

   • 如涉及對主數據的操作，在平臺層開發對應的WebAPI

   • 如在應用層發現跨應用的共享數據的場景，建議將其封裝成平臺層的WebAPI，減少重復建設

基于現有軟件建設

1. 梳理現有軟件的數據和業務能力

2. 制定IT規劃（重點關注主數據）、開發管理規范和運維管理規范

3. 環境準備：采購或部署版本管理服務（如Git）和最小化的開發/測試環境

4. 使用低代碼平臺開發平臺層WebAPI（可匹配應用層的開發計劃，分期分布執行）

   • 需要長期使用的系統存儲的主數據：對接需要使用到主數據的現有軟件，封裝操作該主數據的WebAPI

   • 計劃淘汰的系統中存儲的主數據：建議將該主數據切換到平臺層，在淘汰該系統之前，由平臺層向該系統完成數據同步

5. 部署平臺層程序，使用sostest等自動化測試工具，確保平臺層WebAPI的質量

6. 根據IT規劃，使用低代碼平臺，調用平臺層WebAPI開發應用層程序

7. 部署應用層程序，通過功能測試，確保應用層的質量

8. 使用低代碼持續迭代平臺層和應用層

   • 根據需求側反饋，在應用層開發新的業務應用

   • 如涉及對主數據的操作，在平臺層開發對應的WebAPI

   • 如在應用層發現跨應用的共享數據的場景，建議將其封裝成平臺層的WebAPI，減少重復建設

三、低代碼數字化平臺與數據中臺

數據中臺是數據倉庫的一種實現方式，將多個系統的數據抽取到一個數據倉庫，完成必要的清洗、對位等數據處理后，作為數據源提供給其他系統使用。數據中臺的核心價值在于整合企業的全部數據，消除數據標準和口徑不一致的問題，打通數據孤島。目前，數據中臺的主要應用場景在數據分析領域。數據中臺更多關注的是數據治理，而不是應用開發。數據中臺對數據抓取和處理的操作進行了封裝，讓用戶可以在其中通過簡單的配置就能實現這些需求，如內置功能無法滿足，則需要通過純代碼的方式進行開發。部分數據中臺解決方案也提供了基于無代碼（或表單型低代碼平臺）的應用開發能力，但無法滿足稍復雜的業務應用開發需求，主要應用于BI報表、營銷推薦、用戶畫像等領域。

低代碼數字化平臺則是一種軟件開發的技術方案，以低代碼開發平臺為核心，提供了多源數據整合，主數據WebAPI開發、業務應用開發等環節的可視化開發解決方案，其目標是在打通數據孤島的前提下，大幅提升企業級軟件的開發效率。低代碼數字化平臺包含了數據中臺的全部功能（可以將數據中臺作為平臺的一個子項目來建設；也可以將數據中臺作為一個獨立的系統，與平臺獨立建設后再做整合），提供滿足常見功能的數據處理組件；在此基礎上，低代碼數字化平臺憑借覆蓋平臺層和應用層的可視化開發能力，在應對多樣化的數據源、復雜的數據處理、多樣化的業務邏輯、易用的用戶界面方面存在較大的效率優勢，更適用于構建覆蓋企業全業務環節的數字化解決方案。

根據實際項目經驗，如果企業現有軟件的數據質量和開放性較高，對個性化應用開發的需求較低，僅需要解決數據治理和分析展示問題，數據中臺是個不錯的技術方案；如果企業對現有軟件有疑慮，期望通過開發個性化應用來覆蓋更多業務環節，基于低代碼開發平臺構建數字化平臺是更有競爭力的技術選項。

擴展閱讀

• 【視頻】打通現有系統+定制核心應用，如何壓榨低代碼的應用價值