如我们之前多次报道的，SOA成功的一个主要先决条件是IT与业务目标的对齐。在他们的新文章中，来自IBM的Jens Andexer和Standard Bank的Willem Bekker为我们带来了一些SOA的好处，坏处以及尴尬之处。

　　他们把对SOA的业务影响的分析分成若干类：
　　
　　敏捷性

　　·好处： 通过更快速地支持更加灵活的业务流程交付，SOA为企业提供了更好的适应性去应对业务环境的变化，从而带来实际的市场利益。

　　·坏处： SOA的实施通常需要引入一个新实体——卓越中心（Center of Excellence,简称COE），它为企业的其他部门提供技术专家。当涉及到COE的资源配给以及要做出关系整个企业的决定时，会引起COE与其他部门的冲突。

　　·尴尬：

　　传统上以竖井方式组织的企业可能需要改变其组织结构才能完全享受到面向服务的优势。这种转变复杂且昂贵，并且阻力重重。

　　对齐

　　·好处： 通过使IT服务与业务功能对齐，并且用业务的术语进行IT的服务功能的描述时，SOA有助于业务和IT更加紧密地合作。

　　·坏处： 由于将服务的所有者及控制权转移到业务领域，SOA改变了组织间的权利结构，这会激发来自哪些拥有既得利益并极力维护现状的人的反对。

　　·尴尬： SOA实施需要组织结构的调整（往往是很大的调整）

　　企业必须明白变得敏捷意味着什么，以及如何让自己能最好地利用敏捷。尴尬的事实是这本身就是最难学到的经验。

　　业务流程改进

　　·好处： SOA实施通常包括某些程度的流程的重新设计以带来提升业务操作效率的机会。

　　·坏处： 这对业务提出了新的挑战，并需要业务（部门或人员）更多地参与到服务的设计和改进中，由他们来驱动服务的开发流程，启动开发并改变生命周期。

　　这种角色并不是业务线的典型角色，而且会带来不和谐的角色变换。

　　灵活性

　　·好处： 若没有好的软件工程实践，SOA的实施基本不可能。好的软件工程实践通过缩短产品和服务进入市场的时间以及降低开发成本等方式让IT能更快速地响应业务需求。

　　·坏处： 一方面，服务的引入可以把服务实现隐藏在服务接口之后，从而为服务消费者创造了稳定的服务环境。另一方面，SOA实施通常依赖于一组技术，比如业务流程的执行引擎或企业服务总线（ESB）等。

　　即使是优势超过成本，向原有的IT景观中加入新技术也不能让其更简单。但是，仅因为IT景观本身（即服务的实现）变得更复杂并不意味着其对外表现（即对外接口） 就不能更简单，服务的引入就使得IT内部的复杂性在外看来是个迷。

　　·尴尬： SOA项目是基于它能比以往更快更低成本地交付业务价值的承诺而设立的。

　　SOA专注于技术以至于不太可能兑现这种承诺，因为他们不会以业务人员希望看到的术语去描述业务价值。只有当灵活性加速了业务需求的操作或者通过让运行系统更合理而减低其成本时，灵活性才能被看做业务价值。而关注技术的项目不会这么做。

　　数据统一

　　·好处： 可互操作的服务的引入为创建统一的企业数据模型带来了机会。在这里，统一的意思是：

　　·结构 —— 元素间的结构关系是相同的。

　　·语义 —— 语义指的是数据的使用。数据必须有统一一致的含义且不能被误用。

　　·格式 —— 数据的表现形式很重要

　　·类型 —— 类型是由数据的表现及施加在数据之上的一组行为决定的。

　　·时机 —— 何时更新某个属性，实时修改还是间期性批量修改。

　　·生命周期 —— 在什么情况下加入新数据、何时更新以及何时从数据库中最终删除它。

　　·坏处： 这样统一的数据模型往往并不存在，所以开发这样的模型通常会暴露出企业内部的数据是如何分歧的现状。

　　·尴尬： 获得所有数据特征的一致性几乎不可能：

　　处理不一致性是设计服务接口过程中最大的挑战。尴尬的现实是统一的服务接口很难建立。

　　运行监控

　　·好处： SOA的原则自然地使业务流程监控更加容易，业务流程监控可用于度量业务执行是否沿着企业的战略目标的方向前进。

    ·坏处： 为业务流程开发反映企业目标的监控模型本身就需要很多专业性的工作。

　　利用运行系统

　　·好处： 在多数情况下，SOA能利用现有运行系统去实现服务的业务功能。这意味着现有系统的投资可以通过重新包装成服务的方式实现再利用。

　　·坏处： 有些运行系统本身并不容易被再包装成服务。
　　
　　·尴尬： 在某些情况下，需要改造运行系统，或者添加一些逻辑或实现才能被再利用。

　　要获得SOA的成功，仅仅由IT引入一组SOA技术是不够的。它必须要由一组具体的业务目标和期望的驱动，并且需要业务和IT之间的紧密合作才能成功。