可组合的银行未来是否意味着程序员的终结?

我不确定我什么时候正式加入了“oldie”阵营,但是当我最近参与关于“low/no-code”开发平台的讨论时,我突然意识到我就在那个阵营中。

随着行业的融合,混合和匹配软件的需求不断增长

在我定义它之前,有必要了解一下编码背后的历史。 在学校,我学习了如何使用打孔卡以机器码进行编码。 这被归类为 1GL(第一代语言编程)。 在大学时,我为 6502 处理器编写了一个交叉汇编程序,这让我开始使用 2GL(也称为汇编语言)进行编程。 当我用 Pascal、Basic 和 Cobol 写作时,生活变得轻松多了。 这些是 3GL。 4GL 的一个例子是 SQL,基本上是非过程语言。 这些语言用于告诉计算机做什么而不是如何去做。 最后,我们有 5GL,也称为自然语言。 这些可以将人类指令翻译成可以执行的代码,旨在让计算机在没有程序员的情况下解决给定的问题。

我强烈认为低/无代码既不是 5GL 也不是 6GL,因为这些平台中的许多平台不使用这样的语言,并且在他们的开发方法中更加直观。

低代码/无代码平台通常在其给定的问题域内具有明确定义的边界和上下文,因此配置成为一项相对简单的执行任务,而超出边界的定制变得更加复杂,需要在新工具中进行传统的程序员干预。 Salesforce(用于 CRM)、Pega(用于 RPA/工作流)和 SAP(用于 ERP)是展示这一原则的示例。 Gartner 后来将这些定义为魔力象限产品类别中的组合技术“先驱”,而不是纯粹的应用组合平台。

我不确定“低/无代码”的确切时间,但我的研究发现 Excel 是无代码平台的第一个示例。 对我来说,那是在 80 年代后期,在 IBM 4700 上使用名为 Application Map Generator (AMG) 的开发平台。 该解决方案允许您分离用户界面定义、规则/逻辑和文本。 它的目标是最大限度地重用并简化基于屏幕的解决方案的创建。 它非常适合基于字符的界面。

快进 15 年到 2001 年,当时我与人共同创立了一家公司,该公司创建了一个开发平台,允许您在不编写代码的情况下创建多渠道应用程序(支持离线、Web、移动和门户)。 在内部,我们称其为零代码平台。 然而,我们并不孤单,还有其他类似的平台,一些具有更强大的规则引擎,一些专注于工作流。 从本质上讲,每个平台都有其细微差别和差异化点。

大约在这个时候,Gartner 为此类平台的用户创造了“公民开发者”一词,并在 2015 年晚些时候将该词扩展到集成,说明 IT 部门、业务线 (LOB) 开发人员、移动应用程序开发 (AD) 团队、应用程序团队,甚至业务用户都是“公民集成商”,他们利用这些平台的功能在云中开发、执行和管理集成接口(或“集成流”)。

这些平台吸引了那些需要更多 IT 资源的小型公司,而技术人才短缺推动了对此类平台的不断增长的需求,因为它们是现成的必要性和紧迫性。 在更大的组织中,他们还吸引了没有优先访问 IT 资源的业务领域。 然而,大多数人都在努力取代 Java 或 .Net 等 3GL 中的主流开发。 大多数情况下,IT 部门会引用平台的不灵活性和缺乏可用的训练有素的资源。 提出的其他问题包括:

  1. 源代码控制和重用呢?
  2. 它可以与自动化测试一起使用吗?
  3. 如果我们达到限制,我们可以带来/嵌入我们自己的代码吗?
  4. 它符合哪些安全标准?
  5. 关于可扩展性,我们可以开发或使用第三方用户界面小部件吗?
  6. 它可以扩展吗?

我可以补充更多,但我相信你明白 IT 团队想要保护他们的技能和专业知识,而不是被锁定在专有工具集或不惜一切代价与第三方供应商的长期交易中。

快进到现在(20 年过去了……天哪,我老了)我们来到了“软件正在吞噬世界”的当前商业环境,因此 IT 领域存在“人才争夺战”。 与此同时,技术正在快速发展,很难跟上新的能力。

然而,在可组合银行业务的世界中,重点往往更多地放在结果和业务价值上,而不是您如何完成某事以及用于实现目标的工具和技术。 达到生产版本的速度变得更加重要。 因此,在构建之前购买成为可重用组件的口头禅,现在在编码之前组合以“协调”这些组件的效率要高得多。

在银行业,小型银行受益于现有的“可配置”核心供应商解决方案,允许业务用户定义贷款或存款账户等产品。 较大的银行仍然倾向于最终的灵活性,这通常归结为能够编写核心解决方案中不可能的任何内容。

可组合的银行平台越来越多地提供自己的低/无代码开发解决方案来帮助协调他们的平台。 这应该会带来更高的生产力和上市时间,同时消除宝贵的 IT 资源的热量,大多数公司会声称他们从来没有足够的资源。 IT 部门对管理工作流、业务规则和银行产品定义的工具变得更加熟悉。 他们不太适应,尤其是在大型银行中,用户界面或“集成”任务,API 经济的“愿景”尚未产生承诺实现收益的涅槃状态。

与大多数平台一样,开发平台已迁移到云端。 更好的带宽和更好的浏览器支持使基于云的开发更加可行和可访问。 例如,Appeggio、Betty Blocks 和 Bubble.io 等平台使创建无代码解决方案成为可能。 此类解决方案具有模板和可重用组件,可快速跟踪任何新解决方案的开发。 它们是基于云的,不仅可以自动化开发,还可以自动化部署,无论是移动电话(通过应用商店)还是托管 Web 解决方案的服务器。

应该注意的是,使用遗留系统和内部数据主权解决方案对他们来说是更具挑战性的任务。 一个关键特性是它们管理非功能性需求的能力,因此用户不必为性能、可伸缩性、安全性和弹性进行开发。 与使用代码的传统开发方法相比,仅这些非功能性需求就可以节省 40%。

一些工具在后台有人工智能,尽最大努力理解用户的意图。 他们的目标很明确:您无需成为 IT 专业人员即可构建和部署企业级应用程序。 这并不意味着您不需要 IT 资源。 这只是意味着您可以将资源中心化在紧急和高级任务上,例如采购或创建可重用组件。

对我来说,这样的平台的成熟来得很快,因为总是不可避免地需要一种更智能、更快的方式来实现业务自动化。 随着行业的融合,混合和匹配软件的需求不断增长,正如我们在嵌入式银行业务中所看到的那样。 我并不是说编程已经死了,我只是说当我们把它交给下一代新兴技术人才时,低代码/无代码可以让我们提高生产力。 我们还可以在一个不断寻找优秀程序员和保持业务敏捷性的世界中缩短上市时间,类似于 AWS 在数据中心上抽象自身的方式,无论是在营销“云”作为概念和功能方面。业务成果条款。

因此,虽然低代码/无代码已经并将继续受到批评和限制,主要来自现有企业和开发人员社区,但我看到了向可组合平台发展的必然演进路径,即编写云 IaaS(AWS、GCP , Azure) 被送到数据中心。

关于作者

Dharmesh Mistry 从事银行业已有 30 多年,一直处于银行业技术和创新的前沿。 从最早的互联网和移动银行应用程序到人工智能 (AI) 和虚拟现实 (VR)。

他一直在围栏的两边,他不怕分享他的意见。

他是 AskHomey 的首席执行官,该公司专注于家庭体验,并且是 proptech 和 fintech 的投资者和导师。

在 Twitter @dharmeshmistry 和 LinkedIn 上关注 Dharmesh。

在这里阅读他所有的“我只是说”的沉思。

资讯来源:由0x资讯编译自BACKINGTECH。版权归作者FinTech Futures所有,未经许可,不得转载
提示:投资有风险,入市需谨慎,本资讯不作为投资理财建议。请理性投资,切实提高风险防范意识;如有发现的违法犯罪线索,可积极向有关部门举报反映。
你可能还喜欢