新年伊始，一篇原本普普通通的厂家白皮书却引发金融圈IT从业人员的驳斥，大家为此吵得不可开交。
1月，阿里云对外发布《“核”聚变--核心系统转型之路》白皮书。该白皮书对金融机构分布式架构转型所面临问题、新金融业务系统对传统金融核心系统的挑战与要求、解决方案、核心系统迁移实施路径与建设模式等进行了详细阐述。
当然，其核心诉求还是推广自身方案和服务，在商言商、无可厚非。不过文中多处观点颇具争议，犹如一石激起千层浪，引发多位金融IT从业人员的反驳，甚至白皮书中的“反面案例”--某银行架构师直接在朋友圈开炮……
阿里云这篇白皮书都说了什么，为何引起如此之大的争议？各方观点孰是孰非、谁对谁错？这种争吵对于处于风口浪尖的金融行业核心系统转型带来哪些有价值的启示？
为何引起如此大争议
这份白皮书最大争议之处无疑是阿里云所发布的“六大误区”观点：
“误区1：先从简单系统着手进行架构转型，再推导到核心转型。”
“误区2：追求技术架构完成解耦，碎片化供应商，不被绑定。”
“误区3：核心系统按照功能模块切分，再众包给不同的开发商来完成，避免被一家绑定。”
“误区4：业务应用是业务应用开发商的事情，技术平台是技术平台供应商的事情，两者没有关系。”
“误区5：选择应用平迁、不做架构大变化，更最简单和快捷。”
“误区6：选择各个领域的最佳“供应商”,完成各自擅长的工作任务（咨询建模、架构、设计、应用、基础软硬件）。”
白皮书介绍，上述观点是阿里云历时两年多实地走访与调研而总结出的。粗略一看，上述观点可谓与当前行业主流发展现状似乎“背道而驰”。也正因为这种“颠覆性”的观点，引发金融圈一系列争吵。
例如，在“误区1”的观点中，阿里云认为在银行核心技术自主创新的进程中，采取“先外围后核心的技术路线”是一种误区，并断言：“从俭入奢易、从奢入俭难。非核心领域的转型实践对于核心领域参考和借鉴意义有限。”
有部分专家赞同此观点，认为中小银行业务规模、技术团队、资金体量都不能与大行相提并论，在有成熟技术方案和案例的前提下，从核心领域入手不失为一种选择，可以节省迁移成本与时间成本。也有另一些专家则明确反对，某中小银行的分布式架构改造项目负责人直言：在市场技术并不成熟的情况下，中小银行一开始就“在核心领域架构体系上及早纳入自研可控等架构级别考量”并不现实，很可能会造成巨大投资浪费和未知风险，这将是银行不能承受之重。
“误区2”的观点也引发极大争议。阿里云认为在IaaS/PaaS/SaaS/核心数据库这些关键领域完全解耦容易出现磨合问题，“稳定性和性能等非功能性领域出现莫名其妙的问题，协调不同厂商的产品研发对接需要大量的沟通与适配成本。”
是否真的要追求技术架构完全解耦，目前的确存在很多争议。有人认为在底层架构上选择“统一架构”容易在起步阶段更加稳定，之后可以局部优化和解耦。但是某银行IT专家则认为：“解耦所带来的灵活性不能被忽视。阿里云所提到的各种问题恰恰是解耦过程中必须要解决的问题，而不能称之为‘误区’。”
此外，“误区3、4、6”三个观点聚焦于“避免绑定是误区”和“端到端落地实践的重要性”。某银行架构师直言，这些观点过于理想化，“从厂商的角度来看，可以理解。但现实情况中，很难出现一个厂商把所有事情全做了的情况。”
“世界上没有任何银弹可言。通常情况下，寄希望选择一家厂商解决所有问题有些一厢情愿。用户数字化转型是一个长期迭代过程，选择权在过程中很重要。”另一位银行领域的技术专家补充道。
当然，白皮书最大争议来自于“误区5”的观点。阿里云直接用“反面案例”--银行D的案例来佐证观点，认为该行业核心业务规模大、应用数量众多，大量应用集中在集中架构的封闭系统中，采用rpg，cobol等语言编写，行方为了想尽快将系统从封闭系统下移至开放平台，为了快速和简单起见，使用一种并不成熟的代码翻译工具，将整个rpg语言翻译至java语言并部署在开放平台，底层使用分布式数据库承载数据。整体应用架构没有做太多的调整，基本上还是属于集中式架构的范畴，后期存在配合适配、手工性能优化等问题，拖累业务应用建设的整体进度。
这显然“激怒”了银行D项目相关人员。事实上，有知情人士透露，该行恰恰是行业内第一个在不大动业务逻辑的情况下，完成国外数据库下移到国产数据库的股份制银行，该项目涉及多家厂商，且已经稳定运行三年，并多次获得人民银行及各类金融权威机构颁发的重磅奖项。
该行一位全程参与项目的人士直言：“拿事实和数据说话：一、网联每月发布各家银行渠道能力，包括稳定性、性能等指标，我行在股份制银行（网联报告中B类行）基本都是第一，这是对我行分布式核心系统稳定性、可用性和性能质疑最好的回应；二、采用了RPG2JAVA和仿真测试等创新技术，项目实施期间不仅对业务影响做到了最小，投产后也能很好地支持业务需求，‘拖累业务’之说不能成立。”
归根结底，我国金融机构核心系统转型方兴未艾，必然会出现各种争议，涉及到各种理念、技术、方案，需要经过时间来充分检验。与此同时，除了不同技术、理念的争鸣之外，随着十四五规划等系列政策出台，国产数据库技术、产品不断突破，以及从点逐渐延伸到面的诸多实践案例，中国金融机构核心系统转型的大方向之路也逐渐走向清晰。
核心系统转型走向新局面
金融行业关乎国计民生，除了追求利润，还需要考虑监管要求、市场秩序和社会影响，其数字化转型也受到了社会各界的广泛关注。核心系统转型又是金融机构数字化转型的重头戏，但核心系统转型绝非易事，英国TSB银行、美国Capital One系统迁移失败带来的惨痛教训至今历历在目。
事实上，《十四五规划和2035年远景目标纲》为核心系统转型指明了大方向，规划中提到：“稳妥发展金融科技，加快金融机构数字化转型。”“稳妥”一定会是金融机构核心业务系统转型的首要前提。
众所周知，金融业务对安全性、稳定性与持续性要求极高，业务数据更是牵一发而动全身，稍有不慎就有可能造成巨大损失。因此，核心系统的转型，金融机构无论选择何种技术、理念、建设模式，“稳妥”的宗旨将会贯穿始终。
另外，无论是国家政策鼓励，还是中国企业创新力度，都在推动金融核心系统底层技术竞争力的加速提升。以核心系统转型息息相关的分布式数据库为例，2019年9月，央行发布《金融科技（FinTech）发展规划（2019-2021年）》，提到持续加强分布式数据库领域底层和前沿技术研究的部署；最新的《关于银行业保险业数字化转型的指导意见》中明确提出，要提高科技架构支撑能力，加快数据库、中间件等通用软件技术服务能力建设；另外，为规范分布式数据库技术在金融领域的应用、技术支撑、业务连续性与信息安全保障，北京国家金融科技认证中心从六个维度共360个检测项对12款主流数据库产品的标准符合性验证工作。
有专家认为，除了政策鼓励与推动外，中国数据库企业创新力的提升也为金融机构用户带来了更多选择，“除了早期的传统数据公司之外，近年来大型的科技公司、互联网公司以及新兴的创业型企业等多股力量正在加速推动国产数据库创新。整体来看，中国的分布式数据库产品竞争力得到了很大提升，像有些产品在亿级用户规模的金融场景中得到很好验证，这是竞争力的体现。”
事实上，从实践情况来看，中国几类数据库力量的代表均对金融行业异常重视，并且在农商行、城商行、股份制银行等均有成功案例，为金融机构核心系统转型夯实了良好开端。最近两年，有多家股份制银行围绕从外围到核心的迁移思路，将信用卡等核心业务迁移到国产数据库产品之上，逐步实现了对国外商业数据库的替换。
“现在对于所有企业都是机会。但金融业务复杂度远超其他行业，加上业务创新速度快、新场景多，对于分布式数据库产品与技术要求越来越高，联合创新、共同成长是一个重要的方向，中国数据库企业处于蓬勃发展期，此时更加需要倾听用户的声音，从而不断迭代成长。”另一位资深人士补充道。
启示：吵架未必是坏事
中国信通院《数据库发展研究报告（2021年）》报告显示，2020年中国数据库市场规模约为241亿元，预计到2025年，规模将达到688亿元，年复合增长率为23.4%；其中，金融行业的核心系统分布式改造需求旺盛，市场替换国外商业数据库空间巨大。
在增量市场的大背景下，此次白皮书吵架事件未必是坏事。正所谓“明者见于无形，智者虑于未萌”，吵架事件更像是一副催化剂，驱动着中国金融行业、科技企业等相关人士进一步思考和行动。具体来看，首先有利于各方尤其是各种金融机构用户对于核心业务转型的思考；其次，这次吵架事情中所出现的用户各种关切问题，未来有望更加有针对性解决；最后，会进一步推动技术、方案、理念、建设路径走向成熟。
综合来看，金融行业从传统封闭集中式架构向分布式架构转型，不仅仅是一场技术的更迭，更像是思想觉悟、组织架构、业务模式的彻底变革，在大方向日渐清晰的情况下，采用哪些技术、何种建设路径并没有标准答案。正如伟人所说：实践出真知。让我们拭目以待！
举报
免责声明：此文内容为第三方自媒体作者发布的观察或评论性文章，所有文字和图片版权归作者所有，且仅代表作者个人观点，与极客网无关。文章仅供读者参考，并请自行核实相关内容。投诉邮箱：editor@fromgeek.com。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
