在今年9月于阿姆斯特丹召开的数字化转型周会议上，汇丰银行高级业务分析师Lakshmi Ramasubramanian介绍了使用低代码软件工具开发金融服务应用的优缺点。
作为实物资产与结构性金融业务全球转型团队的一员，Ramasubramanian的工作就是研究企业可能需要的数字工具，而利用低代码工具开发管理应用正是她的关注重点之一。
低代码软件开发，承诺为技术水平不高的人们提供一种快速开发应用程序的方法。此类应用可以用少量代码编写而成，目标是尽量削减编码负担，提供更便捷、更迅速的端到端软件开发生命周期。
无代码则将这个理念更进一步，使人们无需编写任何代码就能构建应用程序。通过功能丰富的开发者界面，用户只须通过拖放操作即可完成应用开发。
低代码和无代码的思路并不新鲜，但多年来曾经以多种不同形式出现。早在20世纪80年代，软件工具供应商就允许技术水平不高的员工使用各类模块、框体和定向线来绘制应用程序设计，借此定义各模块之间的数据交换。之后，软件工具就能生成应用骨架并引入图形设计。
同样是在1980年代，一种名为4G的新型编程语言正式诞生，可帮助非编程人员开发应用程序，并以比传统开发语言（例如C或Pascal）更易于理解的表达来访问关系数据库。
在这两个案例中，低代码工具都解决了当时人们面临的现实问题。程序员成本高昂，在企业不需要高度定制化软件的情况下，平台最好能放低身段、让技术水平较低的员工也能开发出基本的应用程序。
最近，低代码技术还被应用于机器人流程自动化（RPA），以发现可重复的业务流程以备未来使用。低代码方法还可用于构建数据密集型工作流，以及行业特定的业务流程。
无代码工具现可用于创建简单的Web应用、用户界面和业务流程管理类应用。也有不少流行工具能帮助用户开发出原型移动应用和语音类应用。
无代码工具带有内置逻辑，可以在某些类型的应用程序中重复使用。这类应用往往非常简单，而且只包含少量针对特定业务的功能。虽然无代码技术往往不足以支撑数字化转型方面的大规模项目，但低代码软件开发有时却能建立奇功。
将低代码纳入数字化转型流程
Ramasubramanian指出，“过去几年来，我们看到各行各业企业所构建的数字化应用数量开始呈指数级增长。数字化转型正在重新定义企业的运营方式，而且无疑是以技术为支柱。我们现在开始为业务中的每个流程、每项功能都提供相应的应用程序，可能是Web形式、可能是移动形式，或者两者兼有。”
“IDC最近的一项调查预测，未来几年将有约5亿款新应用被构建出来，数量相当于过去40年间全部应用构建量的总和。IDC还预测，到2025年，60%的欧洲企业每天都将部署新软件。”
根据Ramasubramanian的说法，新冠疫情的爆发进一步加速了对原有应用程序进行数字化改造的需求。企业正投资增强自己随时随地与客户联络的能力，改善客户的数字体验，同时也让员工能够在办公室里、家中甚至是其他国家灵活工作。
构建更多数字应用的需求，自然也就提高了市场对于开发人员的需要。优秀的IT开发者当然应该具备交付必要功能的领域知识，以及构建健壮应用所需的编码技能。但各个行业和不同地域往往缺乏这样的开发人员，这时候低代码就成了一个颇具吸引力的选项。
Ramasubramanian强调，“数据管理工具能帮助企业清理、操作、处理和充实其业务场景下各类数字应用所收集到的大量数据。由此收集和处理的数据拥有诸多用途，包括为战略和战术业务决策提供支撑、增强运营效率和改善客户体验等。在某些情况下，此类数据还可实现货币化。数据管理工具在传统上属于IT团队的范畴，由IT团队拥有并开发这些数据管理工具，再交付给业务以满足数据功能要求。”
“而低代码数据管理工具已经成为重要的替代性方案，其所有权可以留在业务部门之内，并使用可复用代码组件和预构建库的组合来完成开发、实现数据管理。因此如果IT团队需要很长的周期才能为业务部门交付新的数据产品，那么利用低代码工具自主设计数据产品就变得极具现实意义。”
“如此一来，IT团队就能专注于构建底层数据基础设施和数据模型；而业务分析师和领域专家则可结合自己的业务知识与低代码工具，着手构建具体数据产品。”
低代码工具可用于金融服务——但务求谨慎
根据Ramasubramanian的介绍，部分低代码工具甚至能够满足金融服务的不同需求，例如针对零售、资本市场和资产管理的核心流程，内部应用或战术性解决方案。金融服务企业往往持有大量与客户交互相关的数据，但其交易历史却存储在不同系统当中。所以常见的数据用例就包括立足各数据孤岛构建聚合视图、小规模自动化业务流程、构建战术数据管道和设计自定义仪表板等。
“但低代码工具并不能替代数字原生软件，后者是对企业IT体系的严肃补充。”
正如四十年前利用框图生成应用程序、或者使用高级语言开发软件来帮助业务用户查询数据库一样，低代码开发在金融服务领域同样占有一席之地。而发掘这种机遇的最佳方法，也许就是让技术专家跟业务用户们组成“融合团队”，共同探索这项技术背后的种种可能性。
– END –
大佬观点
