有哪些有效的方法可以对传统的大型 IT 系统（如银行的 IT 系统）进行现代化改造？ 假设有来自几家开发公司的大约 10-20 个独立遗留系统，其中一些是用旧的 JSP 编写的，许多是基于存储过程的，并且几个 db 之间有 dblink，诸如帐户和用户之类的实体在系统之间没有标准化。
替换或重写整个系统不是可行的方法，因为人们正在使用它并且许多部分没有正确记录。 我想学习一些增量步骤来逐步改进，而系统正在使用，而不是停止。
有没有类似系统总线的东西以某种方式集成所有旧系统，并开发微服务来替换旧系统的某些部分？
学习这些东西的方法是什么？
谢谢。
*我是一名软件开发人员，想成为一名架构师，但不知道如何。
【问题讨论】：
标签： architecture refactoring software-design legacy banking
第一步是深入了解谁知道系统的哪些部分。您可能希望以一种显示业务风险的方式将其可视化。无论是软件本身还是部署方式。这可能会让很多人不高兴，表明风险被忽视太久了。然后，您需要仔细了解时间花在哪里以及如何释放容量以开始现代化。您能否进一步自动化部署和测试？你能减少使用的不同技术的数量吗？标准化支持的库版本？对于业务风险而言，变化的数量也很重要。不同部分的稳定性如何，预计会发生什么变化？以及依赖关系，哪些变化会导致其他地方发生级联变化？在您将这一切可视化之后，业务需要决定哪些风险是可以接受的，哪些需要以什么优先级进行修复。这不是技术责任。您需要提供选项及其优缺点、成本和收益，但让企业决定在哪里花钱
【讨论】：
非常非常小心。
问题是，这些系统通常是非常事务性的（作为银行和所有），并且耦合非常紧密。
您应该一次选择一个用例，然后从前端开发它。选择 Bill Pay 之类的东西，构建一个新的 UI，并让它通过任何可用的接口与后端系统对话。如果没有可用的集成 (API) 接口，请构建它们。
一旦您构建了 UI，就可以切出更深层次的用例，同时仍然为实际数据存储库维护后端。在某个时候（理论上），您需要确定涵盖了所有用例，并且您将重写数据存储。根据复杂性，这可能需要数年时间。一些最棘手的界面是管理界面，而不是面向客户的界面，它们是在需要它们之前没人考虑的东西。
很可能，您的大问题甚至不是技术问题，而是将所有这些组迁移到新系统的变更管理。这种变化对人/政治的影响是非常复杂的，并且必须成为您的高级领导层的主要关注点才能使其成功。人们已经习惯了一个界面，并且由于它很旧，它可能“正常工作”，因此可能不会对它进行更改。特别是因为任何新程序都会有错误。
去年，我最近看到我的银行人员对他们的“新”网络界面感到沮丧，最后放弃并回到他们的 3270 模拟器，以便他们能够完成“真正的”工作。 “新”网络界面看起来至少有 10 年的历史，3270 界面可能接近 20-30 年。
【讨论】：