IT部门承诺产品的交付时间大都基于一个进度估算，很多情况他们仅仅考虑了通过已有服务聚合产生新产品所需时间。当突然需要构建新服务时，交付时间就不得不随之延长。对于业务人员和用户，他们不关心产品是否采用了更为高效地开发方式，他们所想要的只是根据预期按时交付产品这样一个结果。
因此，SOA同样没有解决如何令用户满意地交付应用和系统这个大难题。
管理阶段
最后来看看应用生命周期的管理阶段。在SOA出现之前，管理应用软件开发项目实在不是一项容易的工作。采用SOA以后，根据SOA应用开发所采用的粒度大小，整个开发项目需要分解成若干小的部分，以便开发团队能够采用分布式地方式对它们进行开发。对于管理者，这同样不是一件容易的事情。应用SOA本身对此并无帮助。而项目经理则开始需要应付诸如选择工具、标准、可重用性和文档等涉及开发的标准问题。
SOA应用给管理者们带来了一个必须时时关注的服务库，此外，他们还需要关注诸如SOA治理等问题，这包括了谁能“拥有”某些特定服务，服务的版本控制，共享服务的安全影响，以及这些共享服务的变化给其他应用带来的影响等。
SOA没有解决管理应用开发项目的所面对的问题。事实上，它反而加重了管理人员的负担。他们不得不时刻留心某一变化对本身和其他与交付业务相关应用服务的影响。一旦应用程序交付，大部分的系统管理和服务管理技术都能帮助IT部门跟踪瓶颈、错误或缺陷。相较于SOA部署，这些技术对于更多传统应用基础设施更为适用。
一个糟糕的SOA应用不如不用?
说了这么多，希望读者不要误解我的意思。正确地实施SOA确实可以产生巨大的效益，它的可重用、更容实现复合应用(或称之为聚合)的能力，甚至对于业务和技术人员沟通语言的改善，都有相当的可取之处。但是，同样也要看到，如果你不能首先控制应用开发最根本的挑战，那么SOA将是比基于组件的传统开发方式更大的挑战。所以，一个糟糕的SOA应用不如不用。
文章来源于领测软件测试网 https://www.ltesting.net/
