指南:为旧系统演进定义远景
本指南介绍了如何创建用于演进旧系统的远景文档。
关系
相关元素
主要描述

评估旧系统的价值

概念:旧系统演进中所述,在讨论旧系统时,我们假定两点:

  • 系统是庞大而陈旧的。
  • 系统原来的开发不是使用 RUP 完成的。

第二点通常表示现有的开发工具产品不使用惯用的 RUP 名称或者不是 RUP 中期望的形式。它们经常或是缺失,或是落后,或是极其陈旧,以至于没有人认为它们仍然与系统有关系。我们可以假设曾使用了其他技术:设计不是使用面向对象的技术进行的、需求没有利用用例等情况。

此外,我们还假设旧系统代表一个重要的资产,确实值得将以某种形式重新利用,而不是完全将其抛弃。所以必须对当前资产的价值进行评估:它的价值反映在代码中吗?在设计中?在需求中?在一些算法或数据中?或者就是产品享有的市场份额?不幸的是,系统越陈旧,就越难以掌握和使用现有资产。软件文档经常过时,并且有时候必须从代码本身对设计进行反向设计(例如需要“设计恢复”)。

通常认为不得不对旧系统进行处理是负面因素,但是事实上,“先例”系统的存在对于确定比较点和作为信息源使用是非常有价值的。而定义和开发没有先例的系统则要困难得多,风险也要大很多。

尤其是您的旧系统使您能够容易地确定:

  • 需求和业务规则
  • 什么在体系结构上是最重要的
  • 主要用例
  • 用户的优先级、期望和行为

唯一的危险在于旧系统可能成为思考和检验新方法的绊脚石。

一旦完成了对旧系统价值的评估,就可以制定一种方法对其进行演进。

演进旧系统的方法

我们可能希望采取各种演进方式(从简单的功能扩展到彻底的体系结构变更)来完成重新设计和重新实施。对于每种演进方式,将应用不同的技术解决方案和流程形式级别。以下是几个旧系统演进的例子:

扩展

在简单的情况下,您只需要添加一些功能或功能部件。驱动因素(如规章变更、新出现的业务需求或竞争对手提供的新功能)要求对现有的系统进行相应的演进。对于许多旧系统,它们越陈旧,添加起来就越困难,即使是简单的添加。多年扩展所累积起来的结果导致系统体系结构完整性的降低,这样增大了扩展系统的难度。

改变外观

很多时候您并不需要抛弃整个系统,而只需要赋予它新的外观,或者可能需要使用新的用户界面或系统间接口技术。一种解决方案是将旧系统的特定组件封装起来以便赋予它们一个新的接口,或者允许对它们进行重新实施,从而以最小的开发成本得到可接受的结果。例如,许多需要迅速“支持 Web”的应用程序都属于这种情况。

迁移

系统可能已超过了其底层硬件、操作系统或中间件的使用寿命。这是由于技术不再受到维护或维护的成本过高造成的。解决方法是将旧系统迁移到新的平台(硬件或软件)上,同时尽可能保留现有的软件。例如,一个针对 DEC VAX VMS 环境开发的应用程序必须迅速部署到各种基于 Unix 和 Linux 的平台上就属于这种情况。我们将 Rational Environment(一个含有两百万行代码的产品)从自己的专用平台迁移到各种基于 Unix 的平台上,从而产生了现在称为 Rational Apex 的产品,这些就属于这种情况。扩展表示添加特定于域的新行为,而迁移则表示使旧系统适应其他技术平台。迁移中具体的、特定于域的值较少,但是如果未及时有效地进行则可能导致严重的后果。

重新开发

如果旧系统是一个至关重要的系统,但是极其难以演进、无法扩展并且依赖于陈旧的硬件或软件技术,则您可能不得不对其进行重新开发。通常情况下,由于您无法承受失去现有的客户群,因此必须逐步进行这项工作。加拿大自动空中交通系统就属于这种情况,该系统在非常陈旧的硬件和操作系统(超过 20 年)上运行。您可能会提出这个例子并不会在当前出现,但是即使您打算从头开始重新构建一个系统,仍然需要利用旧系统来了解新系统的关键方面。因为旧系统中同时包含了大量的正面和负面经验和知识。

集成

从财务方面考虑,由于对旧系统从头开始进行重新开发对于许多大公司而言并不是一个可行的方案,因此它们通常倾向于使用新技术来开发新的功能部件,然后将这些新的应用程序与旧系统集成在一起。这种方法称为“企业应用程序集成”(EAI),它使得公司向新技术迁移的同时利用了现有的旧资产。有关此方法的更多信息,请参阅概念:企业应用程序集成(EAI)技术:将旧应用程序集成到新体系结构中

“以上全部”

最后,存在这样的情况:公司可能需要依次进行迁移、改变外观和重新开发或集成。这些公司可能需要迅速地将旧系统迁移到新平台上并赋予该系统全新的外观以满足市场需求,然后使用新的技术(软件组件、新的语言和中间件)重新设计系统,逐步替换旧的代码库,这些举措都是为了使产品能够继续发展。这是最具挑战和风险的方法,但可以这么做。

例如,有一家公司,其 MIS 应用程序包含几百万行在 IBM AS/400 平台上开发的 RPG(报告程序生成器)代码,现在必须将这些代码转换为 Java,并且能够在 Web 以及各种 Windows 和 Unix 系统上运行。该公司成功地在两三年的时间内以 Java 重新设计并实施了该应用程序,并且只给用户带来了很小的中断。

评估业务案例

“远景”需要反映一种对业务具有很好了解的方法。您不想对旧系统进行演进,只因为它就是这样。一般情况下,维持旧系统的确是合理的选择,因为在旧系统的开发和掌握中投入的费用通常是沉没成本,而且极有可能并没有什么业务理由需要将旧系统抛弃。但是,维持旧系统所花费的资源也可以用在新的机遇上。如果您发现自己仅仅是忙于维持(纯粹出于感情或历史原因,没有什么有意义的业务原因,或者因为没有考虑过任何替代系统,而将资源投入到旧系统中),则可能必须检查业务案例是否合理了。

一个好的业务案例需要从保持旧系统的现状到各种不同的演进方案,考虑各种替代系统的短期和长期影响。建议业务案例应当在机构的短期的战术业务目标和长期的战略目标之间取得平衡。