📢 转载信息
原文链接：https://aws.amazon.com/blogs/machine-learning/learnings-from-cobol-modernization-in-the-real-world/
原文作者：Dr. Asa Kalavade
目前，关于人工智能（AI）赋能大型机应用现代化的讨论非常热烈。董事会都在关注，首席信息官（CIOs）们也都在被要求制定计划。AI确实是COBOL现代化的一个真正加速器，但要取得成果，AI需要仅凭源代码无法提供的额外上下文。
以下是我们与400多家企业客户合作中学到的经验：大型机现代化有两个截然不同的阶段。第一阶段是逆向工程，即理解现有系统实际执行的操作。第二阶段是正向工程，即构建新的应用程序。
第一个阶段是大型机项目成败的关键。然而，代码助手真正擅长的是第二阶段。只要给它们一个清晰、经过验证的规范，它们就能快速构建现代化应用程序。
我们了解到，要成功实现COBOL现代化，需要一个能够确定性地进行逆向工程、生成经过验证且可追溯的规范，并将这些规范引导至任何AI驱动的代码助手以进行正向工程的解决方案。成功的现代化需要逆向工程和正向工程这两者。
成功的核心：成功的Mainframe现代化要求什么
有边界、完整的上下文
大型机应用程序规模庞大。真的非常庞大。单个程序可能包含数万行代码，它会调用分布在整个系统中的共享数据定义、调用其他程序，并通过贯穿整个环境的JCL进行编排。如今，AI一次只能处理有限的代码量。如果你只输入一个程序，它看不到复制本（copybooks）、被调用的子程序、共享文件或将所有内容联系起来的JCL。它会针对它能看到的代码生成看起来合理的结果，但会错过它从未被展示过的依赖关系。在与客户合作中，我们通过首先确定性地提取所有隐式依赖关系，然后向AI提供有边界、完整的单元（其中所有必要信息都已解决），来解决这个问题。这样，AI就可以专注于它擅长的部分（理解业务逻辑、生成规范），而不是猜测它看不到的连接。
平台感知的上下文
这里有一个让人们感到惊讶的事实：相同的COBOL源代码，根据编译器和运行时的不同，其行为也会有所不同。数字如何四舍五入、数据如何在内存中存储、程序如何与中间件通信——这些信息都不在源代码中。它们由代码所构建的特定编译器和运行时环境决定。数十年的软硬件集成不能仅通过移动代码来复制。我们发现，当平台特定的行为已经解决后，AI才能发挥最佳作用。向AI提供干净、平台感知的输入，它就能交付结果。如果输入的是原始源代码，它生成的输出看起来正确，但在行为上却与原始程序不同。在金融系统中，四舍五入的差异不是一个表面问题。它是一个实质性的错误。
可追溯的基础
如果你在银行、保险或政府部门工作，监管机构会问一个问题：你能证明你没有遗漏任何东西吗？仅靠AI不足以提取业务逻辑并生成监管机构可以接受的文档。监管合规要求每一项输出都必须与原始系统有正式的、可审计的关联。我们很早就了解到，可追溯性并非来自于AI阅读源代码。它来自于将代码结构化为精确的、有边界的单元，这样我们就知道什么信息被送入了AI，并且可以将每一个输出追溯到其源头。对于受监管行业的客户来说，这往往是一个项目能否推进还是停滞的区别。
我们如何在AWS Transform中为AI的成功奠定基础
我们构建了AWS Transform，旨在规模化地现代化大型机应用。其理念很简单：为AI提供正确的基础，客户就能获得可以投入生产的、可追溯的、正确且完整的成果。AWS Transform首先构建应用程序的完整、确定性模型。专门的智能体提取跨越整个系统的代码结构、运行时行为和数据关系——不是一次一个程序，而是整个环境。这会生成一个与实际编译器语义对齐的依赖关系图，在AI介入之前就捕获了跨程序依赖、中间件交互和平台特定行为。然后，大型程序被分解成有边界的、可处理的单元。平台特定行为被确定性地解决。单元被调整到适合AI有效处理的大小。接着，AI以自然语言提取业务逻辑，并且每一个输出都会根据我们已经提取的确定性证据进行验证。规范可以追溯回原始代码。当监管机构询问“你是否遗漏了什么”时，就会有一个可验证的答案。其独特之处在于，AI从不“在黑暗中”工作。它处理的每一个单元都有已知的输入和预期的输出，因此我们可以验证返回的结果。市场上没有其他方法能够闭合这个循环。最终产出的是一组经验证的、可追溯的技术规范，这些规范可以接入任何现代开发环境。现代化的难点在于理解现有系统的现状。一旦你将其捕获为精确的规范，AI驱动的集成开发环境（IDEs）就可以自信地构建新应用。
企业转型的端到端平台
没有人只现代化一个应用。我们的客户面对的是数百个甚至数千个相互关联的应用程序组合，他们需要的不仅仅是分析帮助。AWS Transform 自动化整个生命周期：分析、测试规划、重构、重新构想。整个流程。在这个过程中，不同的应用需要不同的路径。有些需要从头开始重新构想。有些只需要进行确定性的、干净的向Java转换。有些需要先迁移出数据中心，之后再现代化。有些将保留在大型机上。我们通过痛苦的经历学到，对它们一概而论是项目失败的原因。组合决策（哪个应用、走哪条路径、按什么顺序）与技术本身同等重要。根据我们的经验，这是企业现代化真正能够完成的唯一途径。一刀切的方法是这些项目失败的原因。另一个被持续忽视的点：测试数据。如果没有真实的生产数据和真实场景，你就无法证明现代化后的应用可以正常工作。我们曾目睹团队完成代码转换的全部过程，然后在数据捕获上停滞不前，因为没有人计划数据捕获。因此，我们从第一天起就将测试规划和本地数据捕获内置到平台中。而不是作为最后的清理工作。这就是实际运作起来的样子：端到端自动化，为每个应用选择正确的路径，内建验证机制。
如何做对
问题不是“我们是否应该使用AI进行COBOL现代化？”当然应该。问题是如何设置AI才能交付成果：为监管机构提供可追溯性、正确处理平台特定行为、在整个应用程序组合中保持一致性，以及扩展到数百个互联程序的能力。这就是我们构建AWS Transform时发现的。确定性分析作为基础。AI作为加速器。一个AWS服务，涵盖了全方位的现代化模式。
而且它正在起作用。
宝马集团将测试时间缩短了75%，并将测试覆盖率提高了60%，从而在加快现代化时间表的同时显著降低了风险。
Fiserv 完成了一个原本需要29个多月的大型机现代化项目，仅用时17个月。
Itau 将大型机应用程序发现时间和测试时间减少了90%以上，使得现代化应用的速度比以往手动工作快了75%。
关于作者
🚀 想要体验更好更全面的AI调用？
欢迎使用青云聚合API，约为官网价格的十分之一，支持300+全球最新模型，以及全球各种生图生视频模型，无需翻墙高速稳定，文档丰富，小白也可以简单操作。
评论区