将你的老旧代码转变为灵活的决策服务

软件业务逻辑的现代化     

        近年来，越来越多的公司开始对原有业务软件系统进行“现代化”改造。为了支持业务转型，将老旧系统进行现代化改造势在必行，但这个过程也伴随着巨大的风险。尤其对于大企业来说，他们越来越需要像一个小公司一样，更加灵活的运营。在这些企业往更加灵活的状态变革的过程中，对一个已经运行了10年乃至更久的老旧系统进行现代化改造常常是整个过程中既不可或缺，又非常痛苦的一部分。市面上有一些公司，提供了与老旧系统现代化相关的产品、服务和解决方案。

        对老旧应用的现代化改造包括了多个方面：用户界面升级、系统架构升级、API接口升级、数据库升级以及核心业务逻辑升级等等。本文将主要关注其中一个方面——如何在新系统或服务中重塑核心业务逻辑。

       “核心业务逻辑”可以理解为系统在处理交易时所做的决策。例如，保险申请系统的核心业务逻辑可能包括：申请人是否符合申请资格，申请人风险等级评估，应该批准、拒绝还是转介处理，以及收取多少费用等。调整和升级这些决策意味着需要重新开发老旧系统的核心业务逻辑，然而若将这些决策部署在现代的敏捷决策管理平台上，则可以更好地满足业务需求。

       美国决策管理咨询公司Decision ManagementSolutions（地址：http://www.decisionmanagementsolutions.com/）的创始人James Taylor认为：核心业务逻辑是老旧系统维护成本最高的部分。受新政策、法规、竞争对手以及客户和市场营销的影响，决策常常处于变化之中。例如，费用计算、审核规则、定价方法等。这些复杂多变的决策隐藏在老旧系统的核心业务逻辑之中，非常消耗维护成本和时间精力。

那么，如何在确保核心业务逻辑正确性的情况下进行现代化升级呢？

代码转化实现老旧系统的现代化

许多机构和他们的咨询顾问大多会采用“以代码为中心”的方法来现代化业务逻辑。这种方法使用不同的工具对老旧系统的软件代码进行分析，并逐个梳理其中的核心业务逻辑，使用转换工具生成新代码，然后进行相应测试确保迁移顺利完成。

尽管这是解决业务逻辑现代化的可行方法，但有着两个明显的局限性：

1.现在的平台与以往不同

与现在的微服务架构比，以前的系统架构更少地进行功能模块化。大多数的老旧系统都是做为单体的应用或者C/S系统（客户端-服务器端）进行搭建的。核心业务逻辑大多基于过程或面向对象的设计而散落在COBOL，C或者C++的函数或方法之中（没错，如今的一些基于“现代语言”如Java和C++开发出来的系统也被认为是传统的做法了）。老旧应用开发的时候，按照决策和服务来组织业务逻辑的概念压根就不存在。

如今更好的做法是在决策管理平台中定义核心业务逻辑，企业可以按照考虑业务问题的方法来组织和管理决策规则。决策做为一个可调用的决策服务，通过REST API来实现和新系统架构的对接。

2.老旧系统并没有考虑未来的改动

老旧系统毫无疑问已经经过了多次增补式的升级。这种升级是基于传统系统的当时状态，增加业务需求的相应功能来实现的。

举个例子，如果一个系统已经被使用了7年，每年发生了2次升级，那么这14次升级总是会受到系统先前状态的限制。传统的系统开发方法并不能很好地支持修改，也没有考虑到意料之外的变化。

以上的情况就会导致修改应用的代码非常复杂-甚至比重新构建一个具有相同功能的系统更为复杂。这不只是普通的一团乱麻，而是一团乱麻组成的更大的一团乱麻！采用代码转换工具来重构系统，会给新的平台带来额外的、完全不必要的复杂度。

决策管理-通过数据驱动的方法实现老旧系统的现代化

如今，新一代的决策管理平台可以运用数据和分析来实现运营决策的优化。一边审视老系统中的历史数据，同时开发调整决策中的规则，然后运行测试比较老系统和新系统的结果，是把老系统中的业务逻辑转换成为新的决策服务的有效方法。

    

        以保险承保为例，可以对比决策管理系统中决策规则和传统系统中决策对用户申请的通过情况，来分析两套规则中的差异，并进一步找出具体的需要修改或增减的规则。

比如，我们发现25%的批准通过率差异是因为风险等级不同导致的，就可以针对性地去增加或者修改风险等级相关的规则。一旦老的代码和新的规则在风险等级评估上达成了一致，那么这个25%的差异就会消失。重复这种“分析-优化”的步骤可以缩小老系统与新的决策管理平台的差异，直至业务逻辑达成一致。

决策管理方法的优点

现代化的业务逻辑，在决策管理平台中用决策规则表达，不需要再遵循传统系统多年来的开发和升级的复杂路径。而且，整体的业务逻辑和最终的结果仍然是一致的。同时，业务逻辑的表达也更加简单，易于维护和拓展。

此外，使用决策管理平台来维护和管理业务逻辑，还拥有着诸多便捷的优点：

• 易于修改与调整

• 可由业务人员理解和管理

• 通过系统化的版本控制实现变更管理

• 高度可拓展的部署方式

总结

我们在将老系统的核心业务逻辑移植到新平台的过程中，使用“数据驱动”的方法可以作为一种很好的补充，在很多情况下，甚至可以取代传统的代码转换的方法。至少在面对庞大而复杂的老系统升级时，它可以作为取得成功的工具和方法论的重要组成部分。