如何确保新旧系统的成功更迭？

    培训原系统的开发人员来开发新的系统需要花时间和金钱，因此，在建立新系统时，重用原系统中的逻辑结构就变得非常重要。尽管一些公司表示它们有这个能力，但很少有公司真正有这个实力。为此，确保这种迁移的成功，仔细规划和理解大量的旧系统的迁移就非常重要。

    当我们面对一个需要对旧系统进行升级和改造时，这些问题必须考虑：

    1．这是一个严格意义上的迁移项目，还是只是对原来的系统进行修补，增加一些新的特征？
    2．原系统中有多少东西可以被利用？
    3．如何将整个项目划分成几个阶段，同时既可以以满足业务目标又可以降低项目风险？
    4．我们是否已经掌握了所需的专门技术？如果没有，我们如何掌握？
    5．是否存在标准的工具和平台，如果没有，我们应该如何选择？

    这篇文章提供了一些对上述问题做出回答的方法，这些方法可以降低项目的风险，增加集成或旧系统迁移项目的成功机会。

    迁移策略

    有几个方面的因素会影响迁移的决定，包括是否需要与企业中的其他系统的接口，是否需要其他的功能和业务逻辑，是否有IT厂商能长期提供对现有系统的技术支持。

    迁移项目经常会因为原本可以避免的原因失败，如对问题的错误解决和过高的估计对当前系统的了解。要确保项目迁移的成功，第一步是要仔细了解应用系统目前的状况和成功的关键因素。在项目开始之初，我们需要考虑这些问题：

    1．是需要对现有应用系统进行升级，还是需要对现有系统的业务逻辑和功能做些修改？如果现有的系统能满足需求，那么这个项目就仅仅是技术驱动。很有可能，我们能利用原有系统中那些复杂的业务逻辑。

    2．现有的系统是否能支持需要它支持用户数？计划中的并发数会大大增加吗？如果现有系统没有扩展方面的问题或者用户数比较稳定，可以考虑采用渐进的迁移方法，如图形用户接口（GUI）扩展。

    3．这个应用的复杂性如何？企业的业务流程有多详细？一个界面看起来很简单的应用可能背后隐藏了很多复杂性。定价算法就是这样一个例子，这个算法已经用了20多年了。完全抛弃这些已有功能模块，从头开始进行新系统是充满风险和错误的。

    4．对系统需求的理解和系统的文档化如何？即使一个系统我们每天都在使用，我们仍然未必能完整了解真正的用户需求。有关系统的知识有可能分布在不同的用户组中；一些不常用的功能，我们也许会忘记。最后将需求汇集起来必须包括代码审查和与用户交流两个过程。

    5．对旧系统的了解如何？大多数旧系统将表现层和业务逻辑层以及数据访问层混合在一起，现在的很多技术人员认为要梳理用这种方式写出的代码是很困难的。有一些工具可以用来找出其中的依赖关系，并帮助我们把表现层、业务逻辑层和数据访问层代码分开。

    6．建设新系统，我们手中有哪些资源？现有的员工是否使用者所需要的新技术？如何在现有团队掌握的专门技术和掌握新技术之间找到平衡。培训和指导都是需要付出代价的。

    7．新系统上线的截止日期是什么时候？如果时间很紧，就要采取分阶段、逐步完成的办法。确定新系统实现中的关键因素有助于你制定一个分阶段实现的计划。

    迁移方法

    系统的迁移方法可以分为三类：用一个现存的软件包取代现有系统、新旧系统混合使用、重新开发一个新系统，每种方法各有优缺点。

    用新的软件包 用新的软件包取代现有的系统不是一个可以轻易做出的决定。某些系统，如一个自己开发的数据系统、工作编排表或者消息队列系统，很明显可以用一个现存的商业软件取代。但是，大多数系统不是这么容易做出这种决定的。选择现存的软件包，需要仔细分析业务流程以及这个软件支持那些业务流程。在IT厂商的推销过程中，很容易被诱惑购买他们的产品，最终需要很大的投入来修改以满足你的业务的需求，或者更糟糕，需要让你的业务使用这个软件包。

    组合使用新旧系统 重建一个新系统是一个相当有诱惑力的建议。现在的商业系统至少有1800亿行代码在运行，其中不少还是COBOL语言编制的。深入这些应用内容，我们非常自信因为其中大多数代码都是我们自己写出来的。那么，我们为什么不重新开发一个新的系统，原因有两个：成本和风险。现在的市场是由需求驱动的，对IT项目需要考虑投资回报率（ROI）。

    一个需要大笔预算、而在一到几年看不到任何结果的项目很可能不会被同意的。同时，这样的项目风险也是很高的。现有的系统是多年来随着业务流程的变化形成的，在短时间内重新开发一个同样复杂的系统很容易失败，而且经常需要更大的工作量。

    重建新系统 通常，混合使用新旧系统是一个不错办法，但是，有些系统实在修修补补太多，也太零碎了，就可以考虑重新上一个全新的系统。不过，无论如何，那些特别复杂的业务逻辑还是值得重新加以利用的。有许多工具可以帮助我们完成这个工作。

    迁移工具

    下面我们按照迁移层次的顺序来介绍一些迁移工程中有用的工具。

    GUI扩展工具
    这些工具可以产生一个新的、通常是基于Web的前端，用来访问原有系统。如果促使我们迁移的旧系统的原因是需要用户从标准PC平台（或者远程访问），这些使用这些工具生成一个前端是一种有效的过渡方法。如果满足下面两个条件，这甚至有可能成为一个长期的解决办法：

    1．应用的功能和业务逻辑完全满足当前和可预见的将来的需要。
    2．应用支持所需的用户数没有任何问题。

    这些工具大多依赖于屏幕抓取技术，很容易受到原有系统的扩展性和功能方面的限制。所以，最可能的情况是作为整个系统迁移过程中的第一步。

    软件包裹器（Softwore wrappers）     这一大类包括那些能把一些原系统的代码转化为组件的工具，这些组件可以采用面向对象的接口，如Java 、COM或者DCOM来调用。这些包裹器可以用于很多粒度级别，在较低的粒度级别中，作为代码切片的辅助工具用来区分依赖关系和分离相关的业务逻辑。软件包裹器最重要的特性在于：

    接口支持类型（Java、CORBA等）；
    支持的组件平台（是否与原系统具有连续性）；
    支持的组件语言（旧系统和需要转换）。
    代码切片器（Code slicers）

    老系统中的代码往往将表示层、业务逻辑层和数据访问层交织在一起。另外，老系统中所采用的数据结构和内存存储方式都非常不利于将业务逻辑分离开来进行重用。代码切片器有助于完成这个工作，将依赖关系确定出来，同时将业务逻辑从屏幕控制代码中分离出来。

    语言翻译工具 有一些工具声称可以将COBOL或者PowerBuilder等语言转化为Java代码。这些工具有它们自己的作用，但事实上，这些工具产生的问题往往比它们解决的问题多。如果一定要用的话，建议要谨慎。

    数据访问工具 对于那些采用非关系型数据存储（如，VSAM）的老系统中，数据访问可能会成为一个困难。在需要和其他企业应用系统进行通信和集成的场合，这就会成为一个障碍。这种情况下，对旧系统的改造和升级的第一步是可以采用ODBC和JDBC来访问那些非关系数据库。和GUI工具一样，这尽管不是一个长期的、根本性的解决办法，但可以提供一个快速地将老系统与新系统联系起来的途径，然后，我们可以再寻找一个根本性的解决办法。

    人力因素很多时候，我们的人员并没有掌握成功完成老系统改造所需的技能。很可能，现有的应用系统的技术支持队伍具有完成新系统需要的业务知识，但没有开发新系统需要的技术能力。这些人员的培训费用可不是个小数目。

    根据Gartner的调查，将一个COBOL的开发人员培训为一个专业级的Java程序员，可能需要12个月的时间，而费用可能高达5.7万美元；将一名VB和PowerBuilder开发人员培训为同样的Java开发人员，费用稍微少点，也要5.2万美元和10个月的时间。很显然，不管现有人员以前是否有过这种经验，让他们来完成这种老系统的升级和改造工作会带来成本的剧增。这可能会危及整个项目，这种风险也会影响队伍的士气。

    对如何既保护现有的人力资源投资，同时又转移到新的技术平台上，我们很难找到一个好办法。对每一个组织而言，需要找到人员和项目的合适搭配。这里有一些指导性的建议：

    1．让经验丰富人员接受新技术的培训。典型的课堂培训不能代替实际经验，但可以给人一些帮助，无论他是直接用新技术工作，还是与使用新技术的技术人员交流。而且，要确保这种培训在项目开始前尽早开始。

    2．在总结需求阶段，确保你的技术人员掌握可所需的技术。过度到新技术时候，技术人员不太可能已经掌握了适当的技术。如果有必要，可以从外部寻找自己这样的技术人员。让他们尽早介入项目的设计过程，这种投资是值得的，因为从一开始就做好这些工作，要比后来重头再来，容易也便宜。

    3．考虑找顾问帮助你的技术人员。如果有人可以随时帮助解答问题，这会带来很不同的效果。

    4．选择那些经验丰富的员工加入项目组，即使是在项目开展前期。和那些掌握了最新技术的新手相比，他们可能工作进展会慢一些。但他们知道你的业务，很可能将来会由他们来维护你的系统，这是一个非常关键的因素。

    5．不要把你的项目当成一个试验品，要坚持用测试工具和设计模式。那些没有在类似环境中测试过的不确定的产品、设计和技术很可能导致项目的最终失败。

    6．选择最佳实践。购买符合工业标准的服务器，如IBM的WebSphere和BEA 的WebLogic这还只是个开始，设计模式和框架是人们经验的积累，这些那些开发社区可以获得。使用这些设计模式和开始社区的工具可以减少未来维护上的麻烦。

    7．制定一个现实的进度表。一个团队不得不掌握他们不熟悉的技术本身已经够他们紧张的了，如果再为他们制定一个看起来无法完成的进度表，一定会大大挫伤他们的积极性。如果最终期限时间的确很紧，可以考虑采用前面所述的过渡性解决办法，从而为最终解决赢得时间。

    成功迁移的步骤

    这里提出进行系统迁移的步骤，通过采用这些步骤，可以最大可能地保证系统迁移项目的成功。

    1．区分迁移系统的需求是来自业务，还是来自技术。从人们的需要中区分需求。
    2．在较高层次上对能满足第一步需求的最小系统进行描述。例如，同样的功能但不包括调整屏幕上订单位置，通过纺织品的属性访问Web接口。
    3．在较高层次上描述满足第一步所提出的需求理想化的系统。如，对系统屏幕进行重新设计、对功能进行改善、后台应用系统的事件触发接口、数据库提交的区域销售分析报表等。

    4．分析和寻找能生成步骤二中描述的最小应用系统的工具。在前面的例子中，一个GUI扩展工具很可能就可以满足要求。
    5．确定开发这个最小的系统是理想系统中一个步骤，还是仅仅是一个过渡性方案。上述的例子是一个过渡性方案，因为要修改很多重要的功能，计划的系统必须对现有系统进行修改，而不是仅仅修改它的用户接口（GUI）。
    6．把最小的系统和最理想的系统与要求的时间表和预算进行综合考虑。最小的系统能满足需求吗？今天，很可能没有充足的时间和预算来开发一个理想的应用系统。
    7．基于前面的工作，确定建设新系统的策略（是选择将新的系统和旧系统结合起来使用，还是用新系统完全淘汰旧系统，或者给旧系统包上一个“外壳”），如果需要，还要包括你的过渡性方案。
    8．确定项目所需的资源，包括让你的团队掌握新技术中的计划。这可能需要通过培训、顾问的指导和聘请外面的技术专家，可能要通过其中一种或者多种综合办法。

    现在你已经有了一个开始新系统的初步计划。即使可能没有开发理想系统所需的资源，也值得执行这个制定计划的流程。第一个阶段的成功会给下一阶段带来足够的资源。

    一旦项目开始启动，还要记住：

    1．在需求分析阶段，要分析旧系统中的代码。
    2．确保新系统使用的技术和设计都是经过检验的。
    3．在项目遇到困难之前，就请专家参与项目。
    4．仔细规划和研究项目的每一步。

    结论
    升级旧系统这样的机会对于IT部门而言，是令人激动的。它给IT部门提供了一个体现自己价值的机会，通过IT技术解决了很多使用者都迫切需要的需求。它也提供了一个让IT部门提升技术能力的机会，借此可以更灵活地应归未来的需求。

    但这是有代价的，因为这需要更密切注意项目的管理和费用。项目的前期仔细地规划有助于避免下面这些噩梦，包括使用新技术，和与使用新技术相伴的学习曲线，以及对团队士气的冲击，半路突然冒出的需求，对某些供应商或者个人不切实际的期望等，而一旦克服了这些横亘在面前的困难将会给你增添更大的信心。令人高兴的是，本文提供的这些建议有助于仔细对旧系统的升级和改造项目面临的挑战进行甄别，并最终保证项目的成功。