银行核心空心化转型成本有多高

空心化转型的成本有多高

很多咨询报告会美化“空心化”策略，说它“避免了巨额的初始投入”，但实际上，从总拥有成本 (TCO) 和工程复杂度的角度来看，空心化转型的成本非常高昂，甚至在很长一段时间内比维护旧系统还要贵得多。

“Copy API”和“Copy 业务逻辑”带来的成本和痛点，在实际执行中主要体现在以下几个 “隐形大坑”：

1. “代码考古”的成本 (The Cost of Software Archaeology)

这是最昂贵的人力成本。

• 现状：很多东南亚银行的 Legacy 系统（比如 Silverlake 旧版本或自研的 AS/400 系统）运行了20-30年。当年的开发人员早就退休了，文档也早就过时了。
• 痛点：要“Copy 业务逻辑”到新中台，新一代的 Java/Go 程序员必须去读懂那些古老的 COBOL 或 RPG 代码。
• 代价：这需要昂贵的“逆向工程”。你需要高薪聘请懂老技术的专家，或者花费数月时间去梳理一个简单的计息逻辑（比如：闰年的利息到底怎么算？小数点后几位截断？）。这不仅仅是Copy，这是在没有图纸的情况下重建地基。

2. “翻译”与“防腐”的成本 (The Cost of Anti-Corruption Layer)

你不能直接 Copy API，因为老核心通常根本就没有 API（通常是文件传输、存储过程或专有的报文格式）。

• 技术债：为了让现代的微服务能和老核心对话，银行必须构建一个厚厚的 “防腐层” (Anti-Corruption Layer, ACL)。
• 工作量：你需要把老旧的、基于 EBCDIC 编码的、非实时的报文，转换成实时的 JSON/REST 格式。
• 维护：每当老核心的一个字段变了（虽然很少变，但一变就是灾难），这个翻译层就得跟着改。这增加了巨大的维护开销。

3. 数据一致性的噩梦 (The Cost of Consistency)

这是最让架构师头秃的成本。

• 双写问题：如果你把业务逻辑搬到了外面的“中台”，中台算了一遍账，老核心为了出报表和监管合规，往往也要再算一遍（或者接收结果）。
• 对账成本：如果中台算的利息是 100.01 元，老核心算出来是 100.00 元（因为舍入规则不同），这一分钱的差异在银行业务中是不可接受的。
• 结果：银行需要投入大量资源开发 “对账系统” 和 “补偿机制”，每天晚上跑批处理来核对新旧系统的数据。这部分系统的开发成本往往被低估。

4. “付两份房租” (The Cost of Redundancy)

在很长一段时间（可能是5-10年）的过渡期内，银行处于尴尬的境地：

• 老系统：维护费照付（付给 IBM、Oracle 或 Silverlake）。
• 新系统：云资源费（AWS/Azure）、SaaS 订阅费、新开发团队的工资照付。
• 结论：在旧核心彻底关停之前，IT 预算不仅没降，反而大幅上升了。

---

既然成本这么高，为什么 DBS、UOB 乃至 VPBank 还要这么做？

既然成本高昂，那为什么这些聪明的银行不直接买个新核心（Big Bang）替换掉算了？根本原因不在于“省钱”，而在于 “续命” 和 “买时间”。

1. 风险控制（Risk is Cost）

• 如果直接替换核心（Big Bang）失败了，银行可能会瘫痪几天（参考英国 TSB 银行迁移事故，CEO 直接下课，赔偿数亿英镑）。
• 空心化虽然贵，但是是分期付款。它把“由于系统瘫痪导致的银行倒闭风险”转化为了“每年高昂的 IT 开发成本”。银行宁愿花钱买平安。

2. 市场响应速度 (Time to Market)

• 换一个核心系统通常需要 3-5 年。在这 5 年里，因为所有资源都在做迁移，业务部门几乎不能提新需求。
• 在竞争激烈的东南亚（Grab, SeaMoney 都在抢地盘），传统银行等不起 5 年。
• 空心化策略允许银行在 3 个月内就在“中台”上线一个“先买后付 (BNPL)”功能，哪怕后台逻辑很乱、成本很高，只要能先抢占市场就是胜利。

3. 人才断层

• 现在很难招到愿意维护核心系统的年轻人了。
• 通过构建新的中台（Java/Spring Boot/K8s），银行才能招到年轻的优秀工程师。这是一种为了组织转型而支付的成本。

总结

空心化是一种“用空间（成本/复杂度）换时间（敏捷/低风险）”的策略。

它绝不是省钱的方案，而是一个昂贵的权宜之计。对于东南亚银行来说，他们是在驾驶一架旧飞机（Legacy Core），为了不坠机（业务中断），只能花大价钱在空中一边飞一边把引擎换成新的（空心化）。