我的组织从应用中获得了很大的推动力。今天，哪种方法和工具对于应用更新和架构现代化更有意义？保持系统实时更新的最佳策略是云计算吗？

注意业务的同时，开始计算所有电子表格，这些表格是架构师们用于讨论目前应用架构不足之处的。通常应用功能只有三分之一到一半是用来满足业务需求的。

这背后的资源浪费有多么巨大！可能公司已经使用桌面应用建立了自己的一些系统，而其中的一些可能已经变得相当复杂了。因此，企业正在使用15到20年的策略，以及使用率也只有50%，最好的情况下，没有提出不同的策略。

有些人认为新的现代化策略只是要求把应用移动到云端。他们想：“通过使用一些东西以及前端变得平滑，我打算修复一些底层架构的问题。”不幸地是，他们在该领域无法取得进步。如果想要移动到云端，那么分析、解耦并重构当前的系统很有必要。如果企业计划做这些投资的话，那么最好能有一个业务驱动方法。

如果进入到云或虚拟化中没有从业务驱动和历史的角度来看这一方法，是一种愚蠢的行为。如果我是CIO，而一个IT人员来到我面前，但对于促使应用更新和架构进入云端却没有一个业务策略的话，我就不会让其执行。

现在，现在回到那些记录问题的电子表格。如果不是云，还有什么不同的方法？对于处理底层架构的不足、碎片、冗余、自动化缺乏以及在当前的应用和数据架构中运行的问题，又该做些什么？如果没有发现这个，业务和IT基本上是生活在一个非常、非常有限的科技泡沫中。

在企业转型时，许多现有系统都将继续运行作为整体架构的增量改进—业务需求优先。通过确保每一步都有一个业务驱动力，那么IT就不会为了钱而与企业打架了。它应该有很多面，其中一面是企业把钱花在IT上，从而解决业务问题。

从应用现代化工具方面讲，有了一些改进，但还不够，还远远不够。1980年，我开始测试我所想的商业可用的软件重构工具。它是一个COBOL代码重构工具。还有一些技术流传到今天。它相当的基础。它一次只运行一个项目。上个世纪90年代，那些工具和技术有一个短暂的演进，但是他们却没能越过创新的驼峰，很大程度上是因为现代化没有大动力。一直到现在，大部分应用更新工具实际目的是用来维护的。

现在，业务投资转型在复苏，未来主要在三个类别：

• 迁移工具——有些非常复杂。看看Philip Newcomb和The Software Revolution公司。你将会发现一个相当复杂的语言平台过渡技术；它是非常好的东西，但也非常面向技术。
• 屏幕刮板技术（Screen scraper technology）——我们尽我们的动力做它，但它的使用范围仍然很广。
• 整体业务分析和转换工具套件——这一系列的工具可用来整体审查整个系统。例如，现在我正在使用Hatha系统做一个项目。这一业务驱动类型的现代化工具集照顾的整个系统，可以解析、加载整个系统。技术包括一系列的分支，如交叉引用报告和系统智能或多系统智能。对于业务规则提取有一些附加的信息。现在，这些工具有一些扩展性问题。

这里，演变并没有进入快速轨道。如果有人在20多年前的80年代告诉我在现代化工具中只有增量改进的话，我会惊呆了的。我们需要来业务和软件专业人士的需求，来帮助厂商投资迁移和整体工具。工具厂商有容量，也有能力为一一代现代化构建这些技术。现在这发生的不是很多，因为大多数厂商都坚持工具辅助现代化和人工支持，或者做这些工作的一些工具。

企业达到了解应用更新和架构转型的好处时，他们将会获得竞争优势，并且他们成功的案例可能会促进工具的演变。