Phil Murphy是Forrester研究院首席分，主要关注现代化、资产管理、合理化和战略规划。

　　对于大型机而言，Web服务包装是否按照常规发展呢？

　　Phil Murphy：我会给你两个答案。一是是否按照常规发展？没有。对于在MIPS（每秒百万条指令）范围内的人来说没有，因此离开并不意味着有财政意义，但是却想采纳一个架构良好的应用，显示在调解业务功能屏幕上并且能够服务于调解业务功能，将其展示给.NET或者Web接口，为什么不呢？这是一个可以理解为“不要把宝宝和洗澡水一起倒掉”（注：不要良莠一起扔掉）的方法。

　　然后是第二个答案。随着电子商务的繁荣，软件实现这件事情也风行一时。需求量巨大，也造就了巨大的整合。自此之后，想我咨询这个的几乎消失了，这看起来似乎和第一个答案相冲突，但是却反映了软件市场的饱和。如果你正在从事这个，可能你就处于内部软件中了。

　　大型机后端和交互的Web前端之间是否存在一种内在的不匹配？

　　Murphy：绿屏应用是为一种伪对话而编写，如你在看什么，什么正发生；它是一个会话后端和前段。这也是你仍旧用浏览器应用所做的事情；它们并不完全相同，而且本质上是不相容的范式。现在你采用了一些编写糟糕的意面式Cobol编码，它能运转的很好吗？不能。所有的意面式代码都是糟糕的吗？不是。回到八二年，那时你学习写结构式Cobol，用松耦合方式、逻辑内聚，这也正是现在很多服务为之奋斗的。对于服务来说并不是新的；这也是人们所接受的八十年代Cobol所应该呈现的样子。

　　你已经编写了传统的应用现代化技术来解决一次性决策；他们不能用应用组合解决所有问题。这你怎么看待呢？

　　Murphy：多年来，我们一直对“旧东西”应用新技术。我们拥有这些应用已经有30到40年了，每一个技术浪潮中，我们必须要改进；这也正是现代化所致力的事情。我们已经到达一个资产组合达到“BEHEMOTH”（巨兽）的临界点。我们打过补丁、增加新的，改过型。就是希望下一波技术浪潮中，能够应用这些。如果我们曾经所做的能够应用于下一波技术浪潮，“BEHEMOTH”会变得更大。大多数服务厂商使用这种方法是为了现代化一个或者两个应用。我们的确需要整体地看待需求，识别出可以摆脱掉的那些束缚，在做的时候，释放资源，获取业务可信度。

　　这是一个多级的流程——我们拥有什么，条件怎么样，我们在什么地方浪费资金，然后开始修复。一旦开始运作，我们有想法，对所支持的关键业务功能规划应用。业务人员知道这些业务对于业务是多么的重要。向他们展示资源消耗，什么地方花销过度，什么地方状态良好，什么地方没有花销以及所处的糟糕状态是什么；这些都应该调解。如果你可以让这些浮出水面透明化，就可以避免“IT说辞”，“给我一千万建数据库，”转为“我是你的技术花销教练”。如果它不是一个潜在的收入机会，他们会进行商业决策来修复。如果他们决定不予改变，也是个好事，因为这项业务让他们觉得是正确的抉择。

　　你谈到工艺化一个现代化框架。这是由什么构成的呢？

　　Murphy：我把这些放到一个连续统一体。合理化是驱动现代化项目的引擎，在这个连续统一体的最低重点，你会获取现代化，这也是我们做了很久的事情。简单的定义就是，对于现在的应用，任何你所能做的事情就是监控和维护，所以不予告便，但是也不要加强；你可以在某种程度上加强；可以替代或者重写或者撤掉它。

　　下一个阶段是应用资产管理。你需要只能地驱动技术决策。可以就其健康和业务含义开发一个应用详细目录和指标。第三阶段是合理化。现在你的应用智能化，就开始执行吧，将这个作为播种引擎项目，摆脱掉拷贝，现代化这些对于业务的关键应用。第四步是战略应用计划。暴露业务透明性，他们可以进行基于业务的决策。

　　开发者将会为大型机编写新的应用吗？

　　Murphy：他们正在写。有些人会让你相信所有的大型机厂商看起来像Jerry Garcia。但是规格确实是个问题。如果你有几百个MIPS，转移的话确实很容易“死机”，我们正在寻找那些转移到大型机以节省成本的人，但是当规模巨大到迁移费用达到数亿美元时，这让人很纠结。此外，将数百个快艇放在一起并不会得到一个战舰。因此，我们没能全面披露业界正在发生的事情，并不是每个人都应该转移。很多人正在大型机上编写全新的应用，但并不全是Cobol；是运行在zLinux下的Java。

　　昨天，我同一个金融服务交易处理产业的公司沟通，他们正在离开分布式服务器和数据库，进入大型机，因为他们的成长很疯狂。他们模式化其成长模式，并表示大型机将比分布式环境总成本节省30%；考虑到占地面积、电能等。

　　IBM最新发布的zEnterprise将会从根本上上改变迁移决策。他们已经采用了最大的、最糟糕的大型机，用刀片中心放在一个盒子中，通过专用网络放连接在一起并对集中管理暴露出来。无论你是运行刀片机、大型机、Windows、 Linux，还是什么别的，都将在这个盒子上运转，可以集中管理，因而回避了问题，为什么要转移呢？