低代码打造面向未来的数字化平台

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开发、业务应用开发等环节的可视化开发解决方案，其目标是在打通数据孤岛的前提下，大幅提升企业级软件的开发效率。低代码数字化平台包含了数据中台的全部功能（可以将数据中台作为平台的一个子项目来建设；也可以将数据中台作为一个独立的系统，与平台独立建设后再做整合），提供满足常见功能的数据处理组件；在此基础上，低代码数字化平台凭借覆盖平台层和应用层的可视化开发能力，在应对多样化的数据源、复杂的数据处理、多样化的业务逻辑、易用的用户界面方面存在较大的效率优势，更适用于构建覆盖企业全业务环节的数字化解决方案。

根据实际项目经验，如果企业现有软件的数据质量和开放性较高，对个性化应用开发的需求较低，仅需要解决数据治理和分析展示问题，数据中台是个不错的技术方案；如果企业对现有软件有疑虑，期望通过开发个性化应用来覆盖更多业务环节，基于低代码开发平台构建数字化平台是更有竞争力的技术选项。

扩展阅读

• 【视频】打通现有系统+定制核心应用，如何压榨低代码的应用价值