大型银行核心系统“迭代式”敏捷迁移之路( 四 )


5年过去了 , 这个就是如今的双IT架构的总体样子 。 我们基本上探索出了我们的思路和路线 , 算是找到了一条可持续发展的路 。 另外 , 更重要的是 , 得到了业务部门、管理层和后续资金的支持 , 我们也把单纯的技术迁移转变成技术和业务的同步的迁移和创新 。
大型银行核心系统“迭代式”敏捷迁移之路
文章图片
3、新旧系统保持一致的敏捷节奏和统一的运维模式
打好了架构和基础之后 , 我们面临的第三个挑战是两个系统有机并行 , 那么就需要开发维护两个系统 , 平台技术栈和用到的工具都不太一样 , 团队越来越不负重荷了 。 我们通过应用和自研相结合 , 构建了一套自动化工具链 , 以及同时适配新老系统的开发运维一站式平台 , 来帮助我们自己 。
下图是我们现在的团队所用的工具集的一览图 , 上面既有一些业界广为应用大家应该也熟悉的一些工具 , 如Jira、Jenkins、CheckMarx , 也有特别适用于IBM-I系统的一些工具 , 如RTC、RDI和Arcad , 而带星号的就是我们自己开发构建的工具和平台 。
大型银行核心系统“迭代式”敏捷迁移之路
文章图片
分享一下我们选择工具和自研设计的一些理念 。
1)优先考虑业界优秀的工具 。
因为业界的工具会有很多的场景和用户一起论证和不断完善 , 它们一定程度会比我们自研的更周全 。 另外 , 采用业界的工具 , 可以让我们精力和时间 , 更专注于我们自己在金融科技和业务领域的专长 。
2)当业界没有合适的工具时 , 我们可以自己研发构建 。
例如我们针对IBM-I开发了IBM-I特有的编程语言RPG的自动扫描工具 , 以保证代码的安全和质量 , 还有前面提到的同时适配新老系统的自动化测试框架 。
当所有业界和自研的工具搭建完成后 , 一个新问题是:我们在不同的工具平台之间轮换 , 已经大大影响了我们的工作效率和质量 。 为了解决这个痛点 , 我们又构建了适合我们自己的开发运维一站式平台 , 让大家可以在一个平台完成大部分日常工作 。
我们的一体化平台的实现思路并不复杂:现在大部分工具都是API接口的 , 我们只是ontop搭建了一站式平台 , 通过API自动触发以及连接不同工具上的action , 然后通过API从不同平台抓取所需要的信息 。 之前 , 我们需要登录10多个工具平台 , 200多个点击 , 才能完成一个标准的更改流程 。 现在只需要登录我们的一站式平台 , 20多个点击 , 就可以完成整个流程了 。 这个平台对于我们同时需要支持新老系统的团队来说 , 帮助非常大 。 此外 , 我们也节省了很多对于同事使用不同工具的学习和培训的成本 。
大型银行核心系统“迭代式”敏捷迁移之路
文章图片
最后我想跟大家分享我们在开发构建工具时对技术栈选择的一些考虑 。 第一 , 工具和平台的构建和运行 , 目标也是迁离IBM-I , 跟我们的愿景一致 。 同时我们的目标是一套工具和平台 , 同时适配新老系统 。 第二 , 采用更开放的新技术栈来开发构建工具 , 为原IBM-I技术人员提供从实战中学习新技术栈的机会 。 我们有相当一部分IBM-I程序员 , 在开发工具的实战中掌握了新技术 , 成功转型成为新老系统 , 新旧技术栈都懂 , 业务也很精通的跨界程序员 , 他们已经成为我们这个迁移大计划的骨干力量 。
大型银行核心系统“迭代式”敏捷迁移之路
文章图片
四、思考与总结技术或者模型不分贵贱 , IBM-I还是云 , 瀑布还是敏捷 , 没有好坏对错 , 最适合的就是最好的 。 人和文化(peopleandculture)比技术更重要 。 各种技术只是工具 , 架构和设计的理念 , 以及一直探索、学习和创新的团队和文化 , 才是永恒的 。