我们已经介绍了如何 大型机现代化不仅仅适用于金融行业，那么为什么不解决房间里的大象呢？ 世界上最大的现代化挑战集中在银行业。
在互联网出现之前和 云计算在智能手机和移动应用程序出现之前，银行通过大型电子结算网关和操作大型机作为记录系统来进行支付。
金融服务公司被视为机构，因为它们管理和推动全球经济体系的核心方面。 金融机构的核心是 IBM 大型机。
如果银行成功地将其大型机应用程序和数据资产提升到类似云的灵活性、敏捷性和创新的现代标准，以满足客户需求，那么银行将获得最大收益（如果失败，损失也最大）。
为什么大型机应用程序现代化停滞不前
近年来，我们经历了全球经济的不确定性，从 2008 年的“大而不能倒”危机到目前疫情后的高利率导致某些大型储户银行过度暴露和破产。
虽然银行倒闭往往是管理决策和政策不当的结果，但我们有充分的理由将部分责任归咎于现代化举措和战略的延迟。 难道高管们就不能进行更好的分析来发现数据中的风险吗？ 为什么他们未能推出新的移动应用程序？ 是否有人入侵了它们并将客户拒之门外？
每个人都知道推迟大型机应用程序现代化会产生机会成本，但人们相信更改当前支持操作的系统是有风险的。
社区和区域银行可能缺乏技术资源，而大型机构则面临巨额技术债务、严重的数据移动问题或难以应对业务案例。
大大小小的银行都可能在一项或多项现代化或迁移举措上失败。 随着努力的白费，这些组织内的 IT 领导者感觉自己得不偿失。
现代化改造工作不应要求对大型机代码进行大规模重写，也不需要费力且昂贵 提升和转移 锻炼。 相反，团队应该对对业务最重要的优先事项有意义的内容进行现代化改造。
以下是银行的一些很好的用例，这些用例不仅仅是简单地重新启动现代化计划，而是在高度分布式软件架构和当今对客户体验的高期望的背景下显着提高其大型机的价值。
改造核心系统和应用程序代码
许多银行害怕解决其现有大型机代码中的技术债务，这些代码可能是在分布式系统出现之前用 COBOL 或其他语言编写的。 通常，设计原始系统的工程师已经不在，业务中断也不是一个好的选择，因此 IT 决策者通过在中间层进行修修补补来推迟转型。
Atruvia AG 是全球领先的银行服务技术供应商之一。 超过 800 家银行依靠其创新服务处理近 1000 亿笔年度交易，并由在四个数据中心运行的八个 IBM z15 系统提供支持。
他们决定进行适当重构，用 Java 编写 RESTful 服务，并与大型机上运行的现有 COBOL 一起编写，而不是进行彻底替换。 通过逐步用现代 Java 取代 85% 的核心银行交易，他们能够为银行客户构建新功能，同时将大型机上的工作负载性能提高 3 倍。
通过更快的恢复确保网络弹性
大多数银行都有数据保护计划，其中包括某种形式的冗余 灾难恢复（DR），例如数据中心生产大型机的主要副本，也许还有每隔几个月进行一次新批量上传的异地辅助备份或虚拟磁带解决方案。
随着数据量的大小不可避免地增加，事务和应用程序端点越来越多，通过传统备份技术制作它们的副本变得越来越昂贵和耗时，并且重构它们也很慢，这可能会留下停机灾难恢复间隙。 迫切需要更及时的备份和恢复来保护现代银行的计算环境，包括 勒索软件。
ANZ 是澳大利亚排名前五的银行，寻求提高其更及时的大型机备份和更快的灾难恢复性能的能力，以确保其超过 850 万客户的高可用性。
他们构建了站点间弹性能力，使用其镜像运行 IBM zSystems 服务器 超级交换 功能无需中断即可实现多目标存储交换，因为如果正在进行备份或恢复过程，任何相同的服务器都可以接管生产工作负载。
得益于更好的系统可用性，ANZ 的 IT 领导层高枕无忧； 更重要的是，他们现在拥有现代化的灾难恢复态势，可以通过认证为其客户提供业务连续性。
通过企业范围的业务和风险分析获得可见性
银行在影响客户满意度、财务绩效、基础设施投资和风险管理的关键业务决策的几乎每个方面都依赖先进的分析。
大型机上庞大数据集上的复杂分析查询可能会耗尽计算预算，并且需要数小时或数天的时间才能运行。 将数据移动到其他地方，例如云 数据仓库——可能会带来更大的传输延迟，导致数据陈旧和决策质量低下。
土耳其第二大银行 Garanti BBVA 部署 适用于 z/OS 的 IBM Db2 Analytics Accelerator，这可以加速查询工作负载，同时减少大型机 CPU 消耗。
将分析工作负载与大型机生产环境的问题和成本分离，使得 Garanti 每晚都可以运行 300 多个分析批处理作业，而过去需要两天才能运行的合规性报告现在只需一分钟。
以 DevOps 速度改善客户体验
银行的竞争力在于向客户提供创新的新应用程序和服务产品的能力，因此敏捷的开发测试团队不断贡献软件功能。 我们自然倾向于将这些概括为智能手机应用程序的前端改进 应用程序编程接口与云服务驱动的集成。
但是等等，几乎所有这些新功能最终都会触及大型机。 为什么不让大型机团队成为该领域的一流参与者呢？ 开发运营 运动以便他们能够参与其中？
丹斯克银行 (Danske Bank) 决定将近 1,000 名内部大型机开发人员带入全公司范围内的 DevOps 转型运动，使用 IBM Application Delivery Foundation for z/OS (ADFz) 作为功能开发、调试、测试和发布管理的平台。
甚至现有的 COBOL 和 PL/1 代码也可以被摄取到 持续集成/持续交付 管理管道，然后在开发人员的 IDE 中直观地打开和编辑。 这里不再需要绿屏了。 该银行现在将新产品推向市场所需的时间是以前的一半。
阅读丹麦银行案例研究 https://www.ibm.com/case-studies/danske_bank_as
Intellyx 采取
即使是较新的“云中诞生”金融科技公司也应该明智地考虑自己的创新需要如何与交易对手不断变化的混合计算环境进行交互。
移动应用程序上的交易最终仍将影响全球支付网络、监管实体和其他银行，每个银行在每个请求满足背后都有自己的大型机计算和存储资源。
这里永远不会有一条单一的前进道路，因为没有两家银行是完全相同的，并且在大型机应用程序现代化之旅中可以进行许多可能的转变。
IT 领导者需要从某个地方开始，选择最适合其业务需求以及大型机所在的独特应用程序架构的用例。
查看 IBM Z 和云现代化中心，了解有关大型机现代化的更多信息
