六角形架构更适合数字化银行的核心系统 -FINTECHNA

在接下来的几年中，将会看到大量针对核心银行系统的转型和现代化计划。核心银行系统支持银行的关键银行业务流程和产品，例如个人帐户，卡，贷款等，并且每天处理数十亿美元的金融交易。这些转型计划旨在通过使用云基础架构和新技术，为金融机构提供必要的业务敏捷性，使其能够在日益复杂的市场中竞争，并降低其高昂的运营成本。
许多金融实体已经在云基础架构上开发应用程序一段时间，但实际上很少有实体开始转换其核心系统。在这个充满挑战的旅程中，他们应该认真考虑应用程序特性的差异，这些差异将使这些基础架构得以利用。
首先，新的核心系统必须具有高度的模块化，可以在三个方面进行定义：结构，运营和开发。传统的核心系统不具有这些模块化特性，这是导致当前系统复杂性和缺乏可维护性的主要原因。
核心银行系统的生命周期超过20年。云中的新核心还必须具有很高的持久性，因为由于其支持的流程的关键性和重要性，金融机构无法承受以其他应用程序（例如，渠道应用程序或应用程序）变化的频率来改造这些系统。洞察系统。这意味着应用程序的有用生命周期比要开发它们的技术要长得多。必须采用适当的设计模式，以避免应用程序的技术过时早于其预期的服务时间表。
六角体系结构的使用显然可以帮助为新的核心系统提供必要的功能。在这种体系结构样式中，业务逻辑与技术平台以及与它们通过集成适配器进行交互的其余应用程序隔离，从而确保了应用程序的模块化并促进了其构建和部署的技术基础架构的发展。
实际上，所有改变金融机构核心银行系统的举措都有两个目标：缩短响应市场需求的上市时间；并通过采用私有和越来越多的公共云等云基础架构来提高效率，降低当前系统的高维护成本。
这些技术的采用要求应用程序具有高度模块化的特征，我们可以在三个方面综合这些特征：结构，运营和开发。
 
结构模块化
结构模块化意味着要围绕业务能力而不是技术设计应用程序，并由专门从事业务领域而不是技术能力的团队来设计。该原则对于其他行业的专业人员而言似乎是基础，但在大多数金融机构中却没有实现，在大多数基于技术解决方案的组织中，并且业务领域的逻辑分布在各个层中，例如，一些工作团队在其中工作在大型机环境中，其他团队开发BPM解决方案中的流程，其他团队设计和公开API，等等。
近年来，这种趋势更加突出。人们并不是不断开发其核心系统，而是在其之上添加了技术层，试图提供新的数字和多通道功能，并且由于其成本和所涉及的风险而始终担心接触核心应用程序。实际上，银行历史在系统性金融机构中并不缺少业务连续性故障，这是由其核心系统维护中的错误引起的。
由于这种趋势，维护成本增加了，事件的解决效率和应用程序的发展也受到了影响，因为在以前只有一个团队负责识别和解决问题的地方，现在有几个团队需要协调找出问题的根本原因。
当对业务逻辑的任何修改都需要多个团队的干预和协调时，这种系统演化策略已经限制了在采用Agile或DevOps实践以寻求更好的敏捷性方面的巨大努力。
 
运维模块化
应用程序在运行时必须在它们之间具有最小的依赖关系，以确保其服务的可用性和性能。
如果我们考虑在核心银行系统中处理典型的金融交易，比方说在ATM中使用借记卡进行现金处理，则很容易发现在一次执行交易运行时，系统的不同组件之间存在数百种交互作用。
例如，如果像大多数一级金融机构那样，我们考虑在Cobol中实现的核心系统，则组件之间的这些交互的实现通常将作为整体系统中的COBOL调用来实现。当尝试将此业务功能转换为云解决方案时，其中每个组件都将是微服务，如果所应用的设计模式与设计传统核心系统中使用的设计模式相同，则这些COBOL调用将是转换为例如API Rest，
在这种情况下，很明显，必须彻底改变应用程序的设计方式，这些方式是一种传统单体系统，其内部有数百个运行时交互的地方，现在我们连几个都无法负担运维维护。
运维模块化不仅对提供良好的性能特征很重要，而且对于其对成本，维护敏捷性和应用程序演进的影响也很重要。
在敏捷模型下开发的现代应用程序中，很容易找到每日或每周的部署频率。当我们查看核心银行环境中的部署频率时，我们会发现有些应用程序具有每月甚至每个季度的部署窗口。这些限制的基本原理是由于需要控制部署中的风险。
传统核心银行系统中应用程序的高度操作耦合意味着对业务而言不重要的辅助组件修改会影响关键应用程序，因此必须将其视为关键要素；对于这种低业务价值的应用程序，它们需要广泛的测试阶段和复杂的影响分析。良好的运维模块化消除了关键组件和辅助组件之间的运行时依赖，从而显着减少了系统维护和升级的成本和时间。
 
开发模块化
具有开发模块性的组件在软件级别上具有最小的依赖性，因此可以部署更改而不会影响其余组件。大多数核心银行系统在它们的应用程序之间具有高度的耦合。修改和重新部署某些元素后，它们会将程序和组件从其他应用程序中拖出，从而进行了广泛的影响分析和回归测试，与缺少运维模块性时发生的情况相同。
相同的问题已经在云的新开发中重现，通常与缺少API版本控制政策有关，但最重要的是，与通过文件使用接口有关，从而重现了源自传统系统的设计模式。开发的依赖性是这些传统核心系统缺乏敏捷性和维护成本高的最重要原因之一。
缺乏开发模块化的一个原因是技术层中的应用程序结构，这些结构由不同团队，具有不同存储库的管理，并且必须协调其部署。
实现核心系统的高可维护性应该是新系统开发中的优先目标，因为维护是金融机构任何开发部门中最重要的成本项目。
核心银行系统应用程序的生命周期比构建它们的技术要长得多
核心银行系统支持银行的关键银行业务流程和产品，例如个人帐户，卡，贷款等。
这些系统的生命周期为数十年，因为这些产品的业务逻辑不经常更改。由于与客户交互模型的更改或法规遵从性要求的更改，导致核心周围发生了重大变化，但是产品的加工过程并没有发生重大变化。
这些系统的寿命将比其所构建的技术的寿命长得多。
云平台的发展是快速而持续的。当今的解决方案，标准和模式将在几年之内完全被淘汰。这将有必要随着可用技术的变化来开发应用程序，但是鉴于核心系统支持银行的关键流程，因此任何尝试更新其开发所基于的技术平台的尝试都将面临巨大的阻力。除非通过正确的设计并通过将业务逻辑的元素与技术平台本身隔离开来，否则将导致风险。如果不能实现这一点，将给系统带来严重的技术过时风险，并且将迫使金融机构在技术被克服之后很长一段时间内以高昂的成本来支持技术。
 
使用六角形体系结构开发模块化应用程序并具有较长的生命周期
六角形的体系结构帮助我们开发了具有良好上市时间所需的模块化特性的应用程序，并在核心应用程序中实现了预期的使用寿命，从而避免了基于它们的技术的过时。
六角形体系结构是一种众所周知的体系结构模式，它通过使用适配器从外部隔离我们的应用程序的数据和业务逻辑，从而生成与技术环境和其他应用程序松散耦合的应用程序。适配器提供功能和技术隔离：

• 功能性：核心域业务逻辑将不依赖于外部数据结构或域语言，而是所有输入信息都将转换为我们域或应用程序的语言。这样，与其他应用程序的接口数据结构中的更改只会影响集成逻辑，而不会影响应用程序的业务逻辑。
• 技术。业务逻辑不得链接到技术平台。公开/使用API​​，发布/订阅事件或保留数据，无论使用什么技术服务，都应使用相同的逻辑（相同的代码）实现：Kafka，Oracle，mySQL，MongoDB……这可以确保平台的技术发展将不受它们对应用程序逻辑的影响所限制。

• Rest API的调用是通过适配器进行的，以便将来将Rest API更改为另一个标准时，实现应用程序逻辑的组件不会受到影响。
• 信用管理应用程序在其客户端应用程序的逻辑结构或数据元素中合并，但将其转换为自己的内部语言。这样，如果将来替换或转换客户应用程序，我们可以避免对贷款应用程序的业务逻辑造成影响