分享概要

核心系统转型，近几年是银行业界一个很热门的话题。银行是最早开始构建自己的IT系统去做数字化和自动化的行业之一，经过几十年的发展，这些IT系统和背后庞大的数据成为了银行的一大笔财富，但同时也成为一个负担。

有了智能分析引擎去帮助我们了解老系统之后，我们的第二个难题就是：我们的老系统内外部错综复杂，需要找到一个合适的切入点将它进行拆解和迁移。

1)MVP(Minimum Viable Product) 功能和范围定义

第一步也是重要的一步就是定义MVP的功能和范围，MVP的成败决定了我们是否可以得到业务层和管理层后续的支持。大部分技术迁移的成功就在于我们要证明它有商业价值，并且在可接受的回收期。

首先我们选择了一个老系统没有的功能，从全新功能开始，意味着万一失败，对现在的系统和业务的影响不会太大。另外，也要考虑从最适合用新技术解决的业务痛点开始，痛点不够痛，大家不会动。一旦成功了，会让业务部门和企业感受到实实在在的的价值和回报，这样更容易得到业务部门、管理层和后续资金的支持。我们选择了后台系统最核心最重要的一块业务——支付和结算，以及整个流程中一个小服务——智能审查控制服务。利用大数据分析预测的技术可以大大提升整个审查控制的精确度，帮助我们客户、业务部门和银行控制支付风险。

除了实现功能，我们也在MVP里把基础设施构建好，并没有急着上线新功能，而是通过各种测试和完善，保证新架构的灵活扩展、 稳定、性能和弹性等。

2）新服务和旧系统交互，有机并行

3）迁移现有功能

架构和基础都打好以后，我们才开始迁移现有功能模块。我们选择了邮件交易确认功能。考虑点就是，相对风险较小和容错率相对高一点的业务模块。另外，自动测试是迁移，特别是跨技术栈重构迁移的重要保证。业务系统本身的重构迁移开发和自动测试所用到的用例设计以及自动化工具，应该是同步的。

打好了架构和基础之后，我们面临的第三个挑战是两个系统有机并行，那么就需要开发维护两个系统，平台技术栈和用到的工具都不太一样，团队越来越不负重荷了。我们通过应用和自研相结合，构建了一套自动化工具链，以及同时适配新老系统的开发运维一站式平台，来帮助我们自己。

下图是我们现在的团队所用的工具集的一览图，上面既有一些业界广为应用大家应该也熟悉的一些工具，如Jira、Jenkins、CheckMarx，也有特别适用于IBM-I系统的一些工具，如RTC、RDI和Arcad，而带星号的就是我们自己开发构建的工具和平台。

分享一下我们选择工具和自研设计的一些理念。

1）优先考虑业界优秀的工具。

因为业界的工具会有很多的场景和用户一起论证和不断完善，它们一定程度会比我们自研的更周全。另外，采用业界的工具，可以让我们精力和时间，更专注于我们自己在金融科技和业务领域的专长。

2）当业界没有合适的工具时，我们可以自己研发构建。

当所有业界和自研的工具搭建完成后，一个新问题是：我们在不同的工具平台之间轮换，已经大大影响了我们的工作效率和质量。为了解决这个痛点，我们又构建了适合我们自己的开发运维一站式平台，让大家可以在一个平台完成大部分日常工作。

我们的一体化平台的实现思路并不复杂：现在大部分工具都是API接口的，我们只是on top搭建了一站式平台，通过API自动触发以及连接不同工具上的action，然后通过API从不同平台抓取所需要的信息。之前，我们需要登录10多个工具平台，200多个点击，才能完成一个标准的更改流程。现在只需要登录我们的一站式平台，20多个点击，就可以完成整个流程了。这个平台对于我们同时需要支持新老系统的团队来说，帮助非常大。此外，我们也节省了很多对于同事使用不同工具的学习和培训的成本。

最后我想跟大家分享我们在开发构建工具时对技术栈选择的一些考虑。

• 技术或者模型不分贵贱，IBM-I还是云，瀑布还是敏捷，没有好坏对错，最适合的就是最好的。

• 人和文化（people and culture）比技术更重要。各种技术只是工具，架构和设计的理念，以及一直探索、学习和创新的团队和文化，才是永恒的。