让组合式银行业务发挥作用

由柏拉图重新发布

关注： 0

当我在 80 年代首次开始银行技术职业生涯时，我最初是在大型机方面工作。

组合式银行业务需要更广泛的组织变革才能发挥作用

那时，我们有“总部业务用户”团队来指定我们的要求。这些是代表系统实际用户的中间人。我们与实际用户没有直接接触。

几年后，该银行想要尝试今天所谓的敏捷，但当时是快速应用程序开发。目标是加快我们交付解决方案的速度。我们是 IT 行业中第一批配备笔记本电脑甚至手机的人。我们被带出了 IT 办公室，并在其中一个业务部门获得了一间办公室。

与此同时，我们被允许在家或任何我们认为可以提高工作效率的地方工作。我的日程安排通常是早上 6 点起床，编码到下午 2 点，然后休息吃午餐，下午小憩一下。我从下午 6/7 点左右回到办公桌，通常会编码到午夜。这对我有用。

除此之外，最大的变化实际上是获取分支机构最终用户的需求。这对于获得解决方案的可用性和功能产生了巨大的影响。

快进 30 年，这已成为常态。过去 30 年来，我们看到业务用户和 IT 的融合程度不断提高。甚至软件提供商也转向了客户深度参与新产品的模式。

但是，通常对于特定于业务的需求，分析师会记录这些需求，而开发人员会编写代码。几十年来，这种模式一直存在。

人们一直在尝试改变这一点，让业务用户能够使用低代码或无代码解决方案编写自己的解决方案。事实上，我的上一家公司，edgeIPK，是为网络/移动应用程序开发创建无代码平台的先驱。 Gartner 将此类工具的用户称为“公民开发者”。这减少了需求和开发的分离，但我敢说它产生了许多难以维护的解决方案，并且几乎没有促进重用。因此，此类工具尚未真正在企业级关键任务解决方案中使用。

然而，这种情况可能会随着可组合银行业务的发展而改变，其中的重点是开发、发布和使用市场上的构建块，然后允许其他人将这些块“组合”成完整的解决方案。但显然事情并没有那么简单。 Gartner 杰出副总裁分析师兼研究员 Yefim Natis 定义了组合银行业务中的以下五个角色：

企业架构师 (EA)：在高层管理整个解决方案的人员，确保最大程度的重用和一致性。 BIAN 架构是 EA 可以创建的一个很好的例子。 BIAN 为完整银行架构的可组合“构建块”的应用提供了一个很好的模型。
创建者：创建和发布个人计算、功能或业务能力的构建块的开发人员。
策展人：管理构建块的“图书馆”或市场的角色。该库还应包括任何专有或第三方获得的解决方案。
编写者：使用应用程序组合平台和工具（但不一定）从构建块构建解决方案的团队。
消费者：应用程序的实际用户。

有关更多详细信息，请参阅 Yefim 最近的网络研讨会“可组合性的核心原则：通过业务变革实现繁荣”。

我只是说“组合式银行业务”不仅仅是一个 IT 问题，因为它涉及到业务用户。这不仅仅是使用重用库进行标准开发，而且是组织变革，如果没有这种转变，公司将很难看到全部好处。

在过去，企业架构师的角色非常困难，因为它需要深厚的业务和技术知识，能够筛选数百甚至数千个系统并提供更好的蓝图。 BIAN 使这一切变得更加容易，尽管映射现有系统的任务仍然不是那么容易。

正如我在以前的帖子组合式银行业务可以为银行解决许多问题，但它需要进行组织变革，并应得到教育和采用由新角色支持的新工作方式的战略的支持。一如既往，工具和理论都很容易获得，但细节决定成败。有很多组织开展这项工作的强有力的例子，我希望尽快写下它们。