SOA作为拯救者？

　　我们认为，第一，SOA在这争论中不占在任何一方。相反，SOA会促进遗留系统迁移和让遗留系统再现活力。当一个组织已经基于商业需求要淘汰遗留系统，SOA可以帮助从旧系统里面抽取接口以便迁移。如果替换支持这些类似的服务，迁移转换可以更顺利的进行，那样就会减少迁移的风险。我们有时将这个称为“心肺机”选择，因为这样可能在不破坏服务的基础上关掉遗留系统应用程序。
 
　　另一方面，SOA的一大好处就是可以再现活力：建立商业服务，从旧系统里面抽取潜在能力，以便从遗留系统应用程序里面取得更多有用的东西。将这些服务合并成更广泛的SOA实施来支持敏捷的业务进程。我们将这观点叫做“朽木可雕”，因为能让遗留系统再现活力的机构可以从遗留系统应用程序里面得到比原始开发者预期还要高的更多有用的东西。
 
　　这里的问题就是SOA不告诉你是“心肺机”的方法正确还是”朽木/雕刻”方法正确。相反，SOA可以帮助这两个中的任何一个—虽然总体来说，遗留系统再现活力比遗留系统迁移来说有更大的胜算，因为心肺机的方法只能在一定范围内降低迁移的风险。决定一个遗留系统应用程序去留的底线是业务优先级而不是架构。
 
　　对两个会议听众来说两个解决方案

　　回到Smartco：如果SOA不能帮助他们决定是淘汰还是保留遗留系统应用程序，那么他们怎么做决定呢？非常有趣的是，答案对于两个会议的人来说是不同的。对于那些要求淘汰遗留系统应用程序的管理者和架构者来说，我们推荐迁移方法。但是对那些技术人员的会议，再现活力是我们的推荐选择。

　　那好，我们给出的是什么呢？我们怎么能同时推荐淘汰遗留系统和保留遗留系统？只有少数人参加了两个会议，毕竟他们很快就会明白有些东西是错误的，是吧？
 
　　没有那么快的。实际上，我们根本不推荐两个矛盾的方法，因为我们实际上不是建议Smartco真的淘汰遗留系统应用程序。相反我们会给Smartco的第一组与会者建议：计划淘汰遗留系统。毕竟，Smartco架构者估计在最好的情况下也要5到7年来完全淘汰应用程序。在这段时间内，他们有很多机会再评估计划。只是因为原来没有得到保证的遗留系统迁移被列入了今后5年的开发计划中。
 
　　在第二个会议中，我们对专业人员指出我们将淘汰遗留系统列入计划的主意实际上对他们来说正中下怀。毕竟遗留迁移和遗留再现活力的技术挑战实质上是交叠的，特别是项目的早期阶段。两个方法涉及到使用迭代、自上而下和自下而上方法来从系统里面抽取遗留系统应用程序接口以便更好的支持改变业务进程需求。在迁移方案中，一定数量的服务最终从旧应用程序里面转换成新系统，但不是全部立刻就转换。
 
　　专业人员也认识到淘汰遗留系统的问题很少是“不是你死就是我活”这样的情况，在某个特定时刻，及时关掉一些旧的东西是有好处的。实际上，他们指出直到今天，现在的遗留系统应用程序的前系统仍然在Smartco数据中心起作用！实际上他们只对前系统功能影响一小部分，但是他们不具备足够的业务动力来关掉所有东西。并且如果旧系统仍然比预期的要长的话，有什么理由淘汰遗留系统呢？
 
　　ZapThink采取的方法
 
　　现在的系统遗留应用程序和其前身在这个群体中并没有丢失。业务可能上下波动，遗留系统应用程序受到抱怨，但是它又是实际的业务需求---不是认识上的业务需要---最终决定了哪个遗留系统应用程序能力应该被转换成一些新的应用程序。此外，SOA是这种灵活性的关键因素。毕竟，从商业角度来讲，IT应该以商业服务的形式交付各个功能和信息，同时隐藏技术细节，包括是否这个基础实施是一个应用程序的一部分还是另外一个应用程序。
 
　　这个故事还有另外一个重要的寓意：SOA在商业灵活性方面的获益对长期计划有直接的影响。用传统的紧耦合方式的IT，背离计划是典型的费钱、痛苦的经历（虽然我们一直这样做）。有了SOA，你就可以应对变化了。不止是长期计划可以改变，你现在会乐意盼着它们去改变。如果你已经正确的实施了SOA，在它们出现的时候你可以处理这些改变，所以大胆的去做相应的计划吧。