最近有许多文章都讨论了为什么许多面向服务架构(SOA)行动都以失败告终。7月初，Burton集团副总裁兼研究总监Anne Thomas Manes 在其公司的动员大会上表示：“大多数SOA案例的失败都是人员和文化问题的结果而非技术问题”。对于她的观点我表示非常的赞同。
我们现在知道SOA行动的失败应该归咎于谁了―――人员，愚蠢的人员!但为什么他们会造成SOA失败呢?让我来解释一下。
1 他们未能解释SOA商业价值
IT人士最常犯的错误之一就是单纯从技术角度处理SOA。他们在架构、治理和厂商评估上花费大把的时间，这是好的，但是他们却忘记了SOA必须 解决实际的业务问题。因此，他们会发现当他们花费了许多时间和资金去建立架构之后，业务方面的人员没有人能理解其中的好处，对这项技术也并不感兴趣。
建议：从实际的业务问题着手。这就是为什么BPM(业务流程管理)对于SOA来说是杀手级应用软件的原因。通过改善业务流程并将其自动 化，BPM能够解决许多业务问题。它提供了操作性能的可视性，在没有IT介入的情况下允许流程改变以提高敏捷度，消除废物以降低成本等等。首先，我们应该 展示SOA将如何解决现实业务问题，而后再解决技术问题。
2 他们低估了组织变革的影响
对于任何转型行动来说，“抗拒改变”都是一个项目杀手。SOA为组织带来的是巨大的变革，尤其是如果组织并不具有良好的企业架构的时候。抗拒改 变的一大原因是对于未知的恐惧。人们需要了解有甚么正等待着他们，以及为什么变革将有益于公司与他们个人。我们面临的挑战是处于不同层次的人们受到不同方 式的影响。每一个业务层次都有需要逐个解决的问题。
建议：建立一个组织变革管理(OCM)计划。我将进一步外部聘用一个OCM专家来帮助SOA行动的领导团队来应对变革。我认为John Kotter的八步走方法论是很好的选择。
3 他们未能保证强有力的执行支持
没有强有力的执行支持，SOA行动完成其目标的可能性很小。SOA跨越多个部门与多个系统，也是一项重大的事业。你需要一个强大的执行力与影响 力来推动该行动向前迈进并打破沿途的障碍。但是单单影响力是不够的。你还需要有足够的时间去关注SOA行动并将它的紧急程度放在很高的水平。
建议：如果你的SOA与关键业务结合在一起，那么 提供执行支持的人应该是一个高层业务人士，他将充分地受益于这个行动。让业务拥有并推动项目列别以促进SOA路线图的实施。在技术公司中，执行支持很可能 由首席执行官、首席信息官、首席技术官或是首席架构师担任。不管你选择谁，这个支持者必须能够克服所有的障碍，具有成功的领导能力。
4 他们试图廉价的从事SOA
SOA并不是你所购买的商品，而是你所从事的事业。一些公司试图以低廉的预算来接触SOA。除了所有的中间件产品所需的所有资源之外，SOA还有在治理、培训、咨询、基础架构以及安全方面巨大的投资。
由于其分布与松耦合本质，在生产环境下管理SOA是很有挑战性的。不要在管理工具的生命周期方面吝于花费，否则问题将像大海捞针一样困难。一些 公司试图在没有任何外部协助的情况下从事SOA以节省在昂贵的咨询方面的费用。除非你拥有经验老到的SOA人员，这样做将可能带来灾难。
建议：在建立SOA路线图的同时制定项目列表以及SOA将为公司带来的长远利益的远景。为整个SOA行动建立财务认证，为公司展示投资回报率、 净现值、内部收益率等最重要的财务指标。如果你呈现一个足够好的业务案例，你就将得到足够的资金来启动该行动。同时，几个大的开源产品也能够被用来大大的 降低SOA实施的整体成本。
5 他们缺乏执行SOA所需技能
有一些执行SOA所需的专门角色和技能也许在组织中并不存在。你需要SOA架构师、业务流程建模、工具包管理员、数据架构师以及许多其他技能。 这些职位都并不便宜，但如果在没有任何SOA经验的情况下从事SOA则会成为主要错误。SOA会影响所有的IT部门，包括：测试、基础架构和安全。这比起 派出几个开发员去参加一些培训要复杂得多。而且，你还不能忽略业务方面。业务需要流程优化培训，甚至是BPM工具的培训。
建议：建立全面的培训和资源计划，并将之作为首要需求纳入SOA业务案例资金预算。尽量减少你要求更多资金的次数，在起步时尽量多的争取资金。否则，管理层可能会将SOA行动看作是无休止的资金投入。
6 他们项目管理失败
最终问题将归结到公司的项目管理能力上来.项目管理必须要管理范畴、减轻风险、保证每一个人跟上进度并为处于各个层次的人们提供恰当沟通。需求 的收集是至关重要的，同时还必须要避免分析瘫痪。如果你的组织执行普通项目都很困难的话，那么SOA成功面临的挑战将是成倍的。
建议：把您的最佳项目管理资源放在这个项目上。不然的话就到组织外部请一两个权威来领导此次行动。不管你选择谁，他们都应该在开展大型、变革性行动方面具有丰富的经验。更有挑战性的是这个人还需要有足够的技术背景来从理念层面理解SOA。
7 他们将SOA看作是一个项目而非架构
很多公司都天真的认为实施SOA仅仅是一个项目而已。SOA是一个软件架构，而只有公司坚持以服务为导向的核心原则，确保其交付与架构远景和路 线图一致，SOA才能带来所需要的利益。SOA要求专业化。一个商业服务可以通过SOA架构师、开发人员、数据架构师、网络架构师以及一个安全专家的努力 建立起来。一人全能的时代已经一去不复返了，在各个层次都有专业分工：有用户界面设计师、业务流程建模、数据服务专家、业务规则专员、企业服务总线 (ESB)专家等等。所有的这些专家可能同时致力于同一个服务，这也需要高水平的协作。
建议：标准的IT团队结构对于SOA来说是没有效果的。要摆脱传统思维的束缚，我更为偏好矩阵式组织和作战式环境。拆掉隔间，建立一个开放的空 间以供这些专家近距离的一起工作。这同样也帮助了商务团队和测试员。在四处挂上白板， 尽可能消除会议安排，选择更具协作性的方法来代替会议。
8他们低估SOA的复杂性
你并不了解你未知的一些东西。从概念上说，SOA仅仅是IT 随着时间的下一个演变结果罢了。这并不难理解，但却很难正确的实施。SOA和BPM的好处在于为终端用户带来的简化，这是通过集成各种后端系统形成了对于 用户来说综合性的应用软件做到的。SOA的缺点是大大增加了建立和管理软件的复杂性。建立SOA是一个软件工程的练习，而不是拖放开发，许多开发人员都会 在这样的过度中受到煎熬。SOA要求对标准的一致坚持和最佳实践(治理)并需要理解这些复杂概念的人才来实施。
要实施SOA需要做的事情太多,安全往往是事后才考虑到的. 因此事先收集安全需求是很关键的,这样能从已开始就以潜在的架构支持安全.否则, 如果安全问题事后再解决就很可能需要做出架构上大的调整。
建议：不管你如何保守，都要做好遇到各种技术障碍的准备。你将遇到许多集成问题，有的是由于编码引起的，而有的则是工具本身导致的，因此要及时 的建立起来。厂商的产品都远远不够成熟，这将带来问题。要定下实际的期望值，但不要过于急躁去实现。从小处着手，实现价值。起始阶段就要建立安全系统，不 要事后考虑。
9 他们未能实施和坚持SOA治理
治理对于许多人来说都不是个好词，因为任何事情只要跟“政府”沾边也就不可能是好的。错!!如果我们将之称为SOA管理，也许人们就不会有诸多微词了。
不管怎样，要实现SOA的好处(再利用、灵活、灵敏)，团队就必须要坚持遵照公司采用的架构指导。这就是所谓的设计时间治理。缺少了设计时间治 理，你将有可能仅仅得到一堆Web服务而已。这样一来你就相当于将投资回报率甩出了窗外，因为你将一切从零开始建立每一个服务。SOA如果恰当实施，它将 随着时间变得更具有成本效益。最终，发展SOA的努力将从建立服务转向消费服务。ZapThink LLC的一位分析师Jason Bloomberg将此称为转折点，这是SOA从灵敏和敏捷度上获益的开始。
其次是运行时间治理。这是你主动管理你的SOA生产环境的环节。运行时间治理可以让你看到是什么样的服务在被使用，执行政策和服务水平协议，排查问题，分析性能和管理所有资产。别认为你一旦部署了这些你就做到了，管理一个分布式环境并不是一个能够轻松完成的任务。
建议：将治理看作是你的SOA实施过程中全程全资的一个行动，应该具备一个专职团队(通常存在于企业架构之内)与其自己的路线图和长期远景。不 要尝试在一夕之间完成治理。这是一个旅程，需要几年的时间来达到高水平的成熟度。随着治理的成熟，你的SOA也随之成熟起来。投资一个注册表、存储和服务 管理工具，你还需要新的测试工具来测试治理情况。
10 他们让厂商来推动架构
ZapThink的Ron Schmelzer创造了这样一个表述“厂商驱动架构”(VDA)，暗示我们过多厂商的介入将会是一个灾难。厂商的目的是向你出售尽可能多的商品，而你的 目的则是成功的实施SOA，以最小的成本为你的公司带来最大的利益。看到利益冲突了吗?
除此以外，厂商承诺如果你购买他们所有的工具你将得到完美无暇的集成。事实是，他们已经从许多其他公司购买了太多的产品，这你从各家厂商购买工具的效果是一样的。
建议：在与厂商接触之前了解自己的需求，对厂商进行透彻的评估。在将选择范围缩小至几个厂商时，请他们到现场就你的需求向你表述他们的理念，亲自看 着他们实施。这样厂商就没有办法用漂亮的PPT文档来伪装，这可以防止巨大的错误。私下进行调查研究，阅读一些实践者的网络日志，向使用这些工具的咨询公 司咨询，向实施SOA的其他公司讨教，也要向厂商的推荐人核实。切勿走任何捷径，你要为自己所做的决定负责。
