2008年7月初，伯顿集团的副总裁兼调研主任Anne Thomas Manes女士出席了该集团举行的年度Catalyst大会。她在会上表示，大多数SOA项目之所以会失败，问题往往出在人员和企业文化方面，而不是出在技术方面。她的这一看法立即在会场上引起了很多人的共鸣。
SOA项目失败的根源出在哪里？根本原因是在人员自身！但为什么人们会一再地在SOA方面犯错呢？背后的原因很值得分析。
没有说明SOA具有的业务价值
IT人员最常犯的一个错误就是，纯粹从技术的角度来对待SOA。他们把过多的时间花在了架构、治理和厂商评估上。尽管这些方面是很重要，但他们忽视了一个问题，那就是“SOA需要解决实实在在的业务问题”。他们把大量的时间和资金用在了扩建架构上，结果却发现一旦完成了工作，却没有一个业务人员明白SOA能实现什么样的效益，长此下去他们也就慢慢地对这项技术失去了兴趣。
建议: 构建SOA，首先要着眼于实实在在的业务问题。先要向业务部门证明SOA会解决哪些业务问题，然后再着手处理技术问题。
这也就是为什么说业务流程管理（BPM）是SOA的“杀手级应用”，BPM可以解决很多业务问题。因为它能改善业务流程，并使之实现自动化; 它提供了可见性，可以掌握运营业绩; 增强敏捷性，让业务部门可以动态改变流程，而不需要IT部门的干预; 减少了浪费，从而降低成本。
低估了组织变革带来的影响
与任何一项转型计划一样，抵制变革会导致项目失败。SOA会给企业的组织带来重大变化，如果企业没有落实精心制订的组织架构，失败那就更加不可避免。
人们担心未知因素是抵制变革的最主要原因，人们需要明白自己能从中得到什么样的好处，并且明白为什么改变工作方式对自己和公司都有利。然而事实上，难就难在组织内部各个级别的人员往往会受到不同的影响，每个级别的业务人员都担心各自的问题，逐个解决比较麻烦。
建议: 制订组织变革管理（OCM）计划，从外部聘请OCM专家帮助SOA项目的领导团队应对变革。例如哈佛大学商学院的John Kotter教授所提出的一套方法，就包括了成功变革的八个步骤。
没有获得执行发起人的强有力支持
要是没有SOA项目执行发起人的强有力支持，SOA项目实现目标的可能性就微乎其微。SOA涉及多个部门、多个系统，属于重大项目。因此需要强有力的执行发起人，而且他要有一定的影响力，能让项目顺利开展下去，并且消除一路上可能出现的障碍。但光有影响力还不够。这个人还要有足够时间致力于SOA项目，以便大家始终保持一种高度的紧迫感。
建议: 如果SOA项目牵涉几个关键的业务驱动因素，执行发起人应当是能够从项目实施中受益匪浅的高层业务主管，让他来掌管及推行驱动SOA路线图的一系列项目。在技术公司中，充当执行发起人的极有可能是CEO、CIO、CTO或者首席架构师。无论选择了谁，这个人必须能力排众议，还应当在领导能力方面有着骄人记录。
实施SOA项目时试图“贪便宜”
SOA不是只是买来的“产品”，而是要去实施的。有些公司明明预算有限，还试图上马SOA项目。因为除了需要的所有中间件外，治理工具、人员培训、基础设施和安全工作等方面也需要巨额投资。
由于SOA具有分布、松散耦合的性质，所以管理生产环境下的SOA具有很大难度。不要在生命周期管理工具方面敷衍了事，不然故障排除起来就好比大海捞针，毫无目标可言。有些公司试图在没有任何外界帮助的情况下开展SOA项目，以便省下聘请顾问的高昂费用。除非这家公司不乏SOA方面经验丰富的员工，否则为了省钱而在没有外界帮助的情况下试图开展SOA项目，只会招致灾难性的结果。
建议: 制订一份SOA路线图，列出一系列项目以及SOA会给公司带来的长远效益。从经济层面证明实施整个SOA项目的必要性，并且让管理班子看到投资回报、净现值、内部收益率或者对公司来说最重要的其他任何财务指标。如果拿出的方案有足够充分的理由，应当能获得足够资金来保障这个项目。另外，还可以使用几款优秀的开源产品，能够大大减少实施SOA项目的总成本。
缺少成功实施SOA的所需技能
在现实中，很多企业本身可能缺乏所需要的许多专业人员和技能组合。而事实上，SOA架构师、业务流程建模师、相关工具管理员、数据架构师及拥有其他许多技能的人员是必不可少的。在SOA方面没有任何经验的情况下试图实施SOA，这是一大错误。因为SOA影响到各IT部门，包括测试、基础设施和安全等部门。这比派几名开发人员去上几堂培训课复杂多了。更不能忘了业务部门这一块，业务人员需要流程改进方面的培训，甚至可能还需要BPM工具方面的培训。
建议: 制订一项全面的培训和资源计划，将该计划列为初期资金申请环节的一部分。尽量减少申请资金的次数，争取尽可能多的先期资金。不然，管理人员可能会觉得SOA项目在没完没了地消耗资金。
缺乏良好的项目管理
SOA项目经理们必须管理项目范围、化解风险、让每个人跟上进度，并且与各个级别的人员进行相应的沟通。征集需求非常重要，必须避免分析麻痹（指项目的分析阶段付出的努力太少）。如果一个公司连一般项目的交付都成问题，那么成功实施SOA项目的难度更会加倍。
建议: 把最好的项目管理资源用到SOA项目上。或者从外面请来一两名明星级的人物来帮助领导这个项目。不管从外面选择谁，对方在交付重大转型项目方面最好要有成功记录。另外，这个人还要有足够扎实的技术功底，能够从概念层面理解SOA。
认为SOA是项目、而不是架构
许多公司很幼稚，以为实施SOA只是实施一个IT项目而已。其实，SOA是一种软件架构，只有企业遵守了面向服务的核心原则，并且确保可交付成果与架构目标和路线图相一致，才能获得所需的效益。SOA需要专业人员，包括业务服务需要借助SOA架构师、开发人员、数据架构师、网络架构师和安全专家的共同努力才能构建而成。一个IT人员身兼多职的日子已一去不复返了。SOA的每个层面都需要专业人员，要有用户界面设计师、业务流程建模师、数据服务专家、业务规则专家和企业服务总线（ESB）专家之类的人员。所有这些专家可能同时致力于同样的服务，这需要高度协作。
建议: 标准的IT团队结构对SOA来说这毫无成效，所以要另辟蹊径。矩阵式组织（matrix organization）和相互协作的会议室环境值得考虑。拆掉小隔间，设立开放工作场所，以便这些专家可以密切合作。另外也有必要让业务人员和测试人员同处一室。到处挂上白板，尽量减少项目进度会议，而是选择更注重协作的手段。
低估了SOA的复杂性
从概念上来说，SOA仅仅是IT人员多年来一直在构建的系统的下一个发展阶段。这个概念理解起来并不难，要正确实施却很难。SOA和BPM的魅力在于它们给最终用户带来了简洁性，因为可以集成各个不同的后端系统，以便它们在用户眼里就像是一个组合式应用系统。SOA的缺点在于，它大大增加了构建及管理软件的复杂性。构建SOA是一项软件工程任务，这不是什么拖放开发工作，许多开发人员需要为顺利完成这种转变而努力。SOA需要遵守相关标准和最佳实践（治理），还需要懂得复杂概念的专业IT人员，才有可能获得预期效益。
实施SOA时需要做太多的事情，结果往往事后才想到安全。所以，及早征集安全需求很重要，那样底层架构才会一开始就获得安全支持。不然，如果以后着手处理安全问题，架构方面极有可能需要重大变动。
建议: 不管企业有多么保守，都要考虑到SOA进展中会遇到各种各样的技术障碍。要留出足够的时间，因为可能会遇到各种各样的集成问题，有些问题是由代码引起的，有些问题是由工具本身引起的。厂商的产品还远远谈不上成熟，可能会出现各种设想不到的问题。要设定切合实际的预期目标，别试图一下子完成太多的事情。从小处着手，经常提供成果，然后不断扩大。将安全问题从“头”抓到“尾”。
没有实施及遵守SOA治理机制
治理对许多人来说是个忌讳字眼。治理是一种SOA管理，要是少了它，就无法保证SOA项目取得成功。
不管怎样，要获得SOA的效益（可重复使用、灵活性和敏捷性等），项目团队就必须遵守公司采用的架构指导准则。这就是所谓的设计时治理。要是没有设计时治理，到头来面临的可能只是一大堆Web服务。要是出现这种情况，也就别指望什么投资回报了，因为很有可能最后一切都是从头构建。如果实施得当，随着时间的推移，SOA会逐渐变得具有成本效益。最终，开发工作将从构建服务变成使用服务。Zapthink公司的Jason Bloomberg称之为引爆点（tipping point），到时SOA就会开始获得敏捷性和灵活性的效益。
另外就是运行时治理。这时候，用户可能需要积极主动地管理SOA生产环境的运行状况。运行时治理可以查看使用了哪些服务、执行策略和服务级别协议（SLA）、检测及排除故障、分析性能以及管理所有资产。但是不要以为一旦部署了运行时治理，就大功告成了。
建议: 把治理当成资金到位、与SOA项目同时开展的一个项目来看待。应当专门设立一支队伍（通常隶属企业架构部门），要有自己的路线图和长远目标。别指望一夜之间就能实施好治理。这是一个漫长过程; 需要好几年才能达到高度成熟的阶段。治理机制不断成熟时，SOA也会随之成熟。在注册中心（registry）、存储库（repository）和服务管理等工具方面要舍得投入，还需要新的测试工具来测试治理。
任由厂商驱动架构
Zapthink公司的Ron Schmelzer创造了厂商驱动架构（VDA）这个词语。过分依赖厂商会带来灾难。厂商的目的是把尽可能多的产品卖给用户，而用户的目标是成功实施SOA，并利用最少的成本为自己的公司提供最大的效益。看到其中的利益冲突了吗？
另外，厂商经常会承诺如果从它一家那里买来所有产品，就能实现无缝集成。可事实上，厂商的产品有好多也是从其他公司那里买来的，结果其产品提供的集成比你从多个厂商那里买来工具进行集成好不到哪里去。
建议: 弄清楚自己需要什么，再跟厂商谈判也不迟。对厂商要进行非常全面的评估。如果把范围缩小到几家厂商，就要请他们上门，证明一下概念，看看能否满足种种要求。要认真盯着对方的一举一动，这时候，厂商再也无法隐藏在那些花哨的PowerPoint幻灯片后面，这样可以防止犯下重大错误。要做好必要的准备工作，阅读其他实施人员所写的博客，请教使用相关工具的咨询公司。另外，找已实施SOA的其他公司或厂商推荐的有关方谈一谈。别指望有何捷径，一定要面对自己做出的决策。