ACM通信
数字改造项目中遗产现代化的混合模型
如果有一个术语在IT领域中没有失去它的相关性，那就是“遗留转换”。几十年前，Visual Basic、Java和c++等技术被广泛用于从当时主要运行在大型机上的遗留技术进行转换的最终状态。随着Java的广泛采用，它成为大多数这些技术的最终状态愿景。具有讽刺意味的是，几十年前的传统，在今天的大型企业中仍然是传统，特别是在大型公共部门组织中。十年前的现代应用程序包现在也被归类为遗留应用程序包;很难改变和维护。
关键任务应用程序继续在这些遗留技术上运行，将它们从这些技术转移到现代技术是一项艰巨的任务。许多这些举措要么失败了，要么产生了部分好坏参半的结果。然而，正如我们所知，现代技术提供了更高程度的敏捷性、灵活性和无缝的消费者体验。现在比以往任何时候都更需要摆脱传统技术。
没有一个面向未来的组织的议程上没有数字转型。在许多情况下，制定一个远离遗留技术的健壮路线图是数字转型的核心。摆脱遗留问题的方法可以大致分为两类:
- 自底向上的方法
- 自顶向下方法
自底向上的方法
自底向上的现代化是系统集成商和产品供应商经常使用的术语。有许多供应商声称提供将遗留系统中嵌入的业务逻辑转换为现代应用程序的功能。有多种方法可以做到这一点;它涵盖了以下一个或多个方面:
- 使用产品提取业务规则/业务逻辑。这可能是以下一个或多个:
- 应用程序日志分析
- 语言转换器
- 中介体如Cobol -> Java ->应用程序的选择
- 文档的逻辑。
- 将提取的逻辑建模为现有的或修改过的规则/逻辑。
- 在新系统中配置。
自顶向下方法
顾名思义，这与自底向上方法相反。当业务逻辑/业务规则有很好的文档记录，且几乎没有缺陷时，通常使用自顶向下方法。在这里，文档是100%真实的来源，并像任何业务需求规范一样使用，即使其中一些可能需要根据新时代的产品特性重新编制文档。
以上两种情况都是“幸福之路”的情况，我们知道数字程序中的“幸福之路”是一个神话。
自底向上方法在代码中实现的逻辑相当简单的情况下工作得相当好，也就是说，没有太多的弯路或偏差。当代码在其生命周期中针对特定场景进行定制时，情况就变得复杂了。当代码已经有几十年的历史，并且在其生命周期中有多个异常场景时，这一点尤其重要。
当代码的每一部分都有文档记录并与主文档集成时，自顶向下方法可以很好地工作;也就是说，当为异常场景引入新的逻辑时，将修改主文档而不是创建单独的文档。
让我们以一个已经存在了30年的政府服务为例。或者一个已经存在了10年的银行系统。人们只能想象，由于立法的更改、bug修复，甚至为了处理特定的情况，业务逻辑将经历多少次迭代。在这种情况下，自上而下的方法和自下而上的方法都不能保证100%的准确性。比方说，我们正在处理一个支付系统——不允许出错，而且它必须是100%准确的。
进入混合模型!
那么，什么是混合模型?通常情况下，混合模型从自顶向下方法开始。应该假设文档的准确性超过70%。您可以使用这个模型构建基本逻辑。一旦设计和开发完成，您就可以集成一个比较逻辑，将新构建的系统的输出与已开发场景的现有系统的输出进行比较。这通常在功能测试或早期功能测试阶段完成。如果比较是100%准确的，继续进行进一步的测试。然而，这是一种罕见的可能性。很有可能在某些情况下你无法达到100%的相似度。
下一步是剔除没有100%匹配的特定情况。在遗留系统中运行这些特定的用例，并对这些用例使用自下而上的方法。它可以启用跟踪来查看代码如何遍历，或者通过捕获日志并从日志中进行逆向工程。这些技术可以深入了解偏离标准陈述的业务逻辑的情况。将这些内容合并到文档中——关键是这是一个迭代过程，直到对所有测试用例和场景执行功能测试为止。最初70%的可预测结果在后续迭代中逐渐改进，并逐渐接近100%的标记。
在确信功能测试相当成功之后，在集成测试和用户验收测试中重复类似的步骤。如果您只使用规则引擎，那么集成测试就更加重要，因为您的规则引擎很有可能是无头的。触发规则及其变化的场景由调用这些规则的系统驱动，有时是评估引擎或客户交互引擎(如CRM)。
一旦你涵盖了所有的测试阶段;你很有可能已经覆盖了系统中100%的规则。
因此，下次当有人联系您说“有保证的遗留转换”时，请三思!
总部位于澳大利亚堪培拉，Madhu Pulasseri是印孚瑟斯的交付合作伙伴和数字过程自动化实践经理。
没有发现记录