然而，在人们考虑快速发展的市场和持续增长的竞争需求时，这些遗留程序可能就会成为绊脚石。此外，它们能给公司的应用程序生态系统带来严重破坏，因为这些应用系统采用的技术现在看都是过时的，而且有多个用户接口或者多个安全框架。从这些原因考虑，如果企业希望保持生产力和竞争力，对遗留应用程序的现代化工作是至关重要的。

在过去的几年中，采用面向服务的架构（SOA）迁移或者现代化遗留应用程序的趋势比较受欢迎。SOA是为了支持遗留应用程序现代化，分布式软件需求，与语言和平台是无关的。这些特性使其成为了公司迁移遗留系统转向现代化的最佳工具。

要知道，现代化遗留应用程序并不是SOA实施的主要目标。这种实施只是让企业变得面向服务的漫长道路上许多步骤中的一步。企业IT组织在通过SOA实现现代化时，根据他们的情况有几种可选方案。

应用程序竖井需要用户在给定业务流程中，使用几个遗留系统来执行一组任务。这一事实使得应用程序冗余成为了开始彻底调整用户和用户接口的理想起点。例如，处理一个处方订货系统，它在订购流程中使用了多个应用程序。这种遗留应用程序被现代化后可以提供对整个系统的单一视图，通过社交媒体软件，业务流程管理系统和商业智能工具实现。

多个遗留系统可以被在幕后集成，通过一组Web服务的结合以及数据访问和服务层的使用实现。这种方法依赖于SOA技术的一个核心原则：抽象。当抽象层次创建好以后，遗留应用程序就不需要再年复一年的重新设计了。

隐藏遗留应用系统的复杂性

许多清单和订货系统都像假设的处方订货系统一样，只是用作为一个例子。老旧系统在继续执行关键业务功能，但是最好是把它们转向现代化并与更新的甚至是未来的应用程序集成到一起。企业不能简单地淘汰和更换这些系统，因此一些现代化遗留应用程序的做法是把它们的复杂性隐藏到适配器或者Web服务的背后。

启用SOA和Web服务已经成为了当今竞争激烈的市场的一种必须任务，这样一来让遗留系统支持服务就至关重要。一旦识别出了候选的应用程序，它们的遗留代码就被复制到一个通用框架中，然后所有引用数据对象都会被替换为通用的数据接口。一旦需要重用或文档化的业务操作已经识别出来了，下一步就是给它“打包”。在这个过程中，从遗留代码中抽取出来的这一组件要形成Web服务描述语言接口（WSDL），每个入口被转换成一个方法，每个变量和参数都被转换成XML数据元素。数据结构变成了复杂的XML元素，并带有一个或多个子元素，方法和参数都将被构建到XML结构中。

最后一步是形成链接向Web服务的代理，并生成到以业务为中心的流程中。该代理与检查参数和生成需要的WSDL有关。一旦代理被调用，遗留代码打包器解析XML输入信息并把输入数据转换成合适的格式。打包好的组件执行之后，打包器把结果转换成可接受的XML出站信息并把它发回到Web客户端。

确保遗留应用现代化的资源

刚开始着手遗留应用系统现代化策略的企业通常会忽略掉各种资源问题。执行此类行动需要合适的资源组合，人才和技能，这样才能确保成功。

很难找到既懂业务流程和遗留应用程序相关功能，又懂底层代码和平台的专业人才。我们要面对现实：当今的许多软件和系统工程师并不熟悉遗留应用程序和平台，比如大型机、COBOL，CICS，IMS等等。所以，你需要理解这些遗留应用程序的专业人士，需要把现代化技术中有资深经验的专业人士加入到团队中。

时间是另一个资源问题，一些企业似乎容易淡化忽略这一点。他们的目标是快速把新工具提供给业务，帮助员工能进行日常操作，在瞬息万变的商业竞争环境中保持竞争力。然而，他们常常有一种误解，认为他们的努力在一夜之间就能得到回报。但事实不是这样的。根据我的经验，企业不会那么快看到积极的结果，最早也得经历几个月甚至一年以后才能看到效果。

此外，有些人认为，实施SOA（并把它用于遗留应用系统现代化）只是另一个IT项目，应该有一个明确定义的完成日期。然而，现实是，变成为一家面向服务的企业需要业务方面定义SOA治理的战略和路线图。成功的SOA之旅会经历一些里程碑（遗留应用系统的现代化只是其中之一），需要按着既定的路线图，一个接一个项目的完成。只有当所有预期目标都实现了，他们相应的里程碑都完成了，那时才能说企业的旅程完成了。

复用遗留应用系统的功能

经常有负责运营和维护人力资源系统的同事向我咨询（该系统用户基数很大，大约能达到50万以上）。业务流程与原来的遗留系统有一些关联，他们尝试使其现代化。然而，现代化主要包括在一个现代的平台上从头写一个新应用。现代化工作的意图是变的支持面向服务，但是结果却南辕北辙。

我们从维护新应用程序确保日常运营正常开始工作；在此期间，我们用Web 2.0技术彻底改善了用户界面，开始对原来的应用程序实现现代化，目标是使该组件支持面向服务，从而作为潜在的候选复用组件。

随着维护需求以及增加新功能的需求越来越多，项目团队要把考虑每个需求的潜在复用能力作为需求分析的一部分工作。这样一来，团队开发的几个Web服务就可能被应用生态系统中的其他项目所使用。实际上，在现代化系统的核心，项目团队在更早的时候就已经使用了上面描述的方法。

团队在面临新功能需求之一时会遇上资源调度问题，这种情况可以采用第三种方法。HR系统一夜之间就可以从遗留数据库中提取到数据，然而，在某些情况下，外部应用程序可能要花比正常更新数据库更长的时间，这样就需要一定的机制来避免资源访问的问题。

团队有意生成自己的消息传递机制，但是没必要创造这样一种新东西，因为组织的SOA基础设施中包含有SOA网管，它可以提供类似的功能。讨论后决定生成指向网管的Web服务接口，该网管将与数据访问层交互，由数据访问层直接与遗留数据库衔接。这种方法给团队增加了应用程序的可选连接方案，可以复用数据访问层并避免在遗留数据库上形成资源冲突。

对遗留应用系统进行现代化，选择合适的出发点和方法并不是容易的事，但是只采用SOA进行遗留系统的现代化，可能有一定战略意味，给你的公司提供满足业务增长需求的手段，同时避免对遗留系统进行大量投资。这也可能是老旧系统向最终退休旅程迈出的一步。

恢复遗留应用系统的功能使企业可以提供给客户现代化的工具，而没有昂贵的“拆除、重建，重头开始”的风险。