最近有和很多文章讨论为什么许多面向服务架构（SOA）项目失败了。在七月初，Burton Group副总裁和兼研究总监Anne Thomas Manes说，大多数SOA失败是由于人为和文化问题造成的，而非技术问题。

　　所以，谁应该为SOA部署的失败负责了？是人们自己。但是人们为什么会导致SOA失败呢？下面我们看看一些原因。

　　1.未能解释SOA的商业价值

　　IT人员在部署SOA时最常犯的错误之一是他们往往从纯技术的角度来创建SOA架构。他们在SOA架构、智力和供应商评估方面花费了大量的时间和精力，这点做得相当得好，但他们却忘记了SOA需要解决实际的业务问题。因此，结果往往是他们花了大量的时间和金钱好不容易才创建了一个SOA系统，但是却发现企业的业务人员没有人能理解它所带来的好处并且也没有人对SOA技术感兴趣。

　　建议：SOA建设应该从真实的业务问题开始。这就是为什么BPM（业务流程管理）被称为是SOA的“杀手级应用（killer app）”的原因。通过改善和自动化业务流程，BPM能够解决很多业务问题。它增加了企业运营业绩的可视性，允许企业在没有IT部门参与的情况下动态改变业务流程从而提高了灵活性，消除了浪费，从而降低了企业成本。所以，IT人员首先应该向企业的业务人员展示SOA是如何解决实际的业务问题的，然后才是技术问题。

　　2.低估了机构变革的影响

　　正如任何变革型倡议一样，对于变革的抵制是一个项目的杀手。SOA给企业带来了大量的改变，特别是如果这个企业没有一个健全良好的企业架构时更是如此。对于未知情况的恐惧是人们抵制变化的最重要原因。人们需要了解SOA对于他们有什么好处，以及为什么改变会给他们个人以及企业都能带来好处。所面临的挑战是企业内部不同层次的人受到影响的方式不同。企业的每个层次都有需要加以处理的关注点，并且必须在个体级别上被解决。

　　建议：创建一个机构变革管理（OCM）计划。最好更进一步聘请一位外部OCM转肩，以帮助SOA项目实施领导层处理变化。我强烈推荐SOA部署人员采用John Kotter的八步法。

　　3.未能取得强有力的行政赞助

　　如果没有强有力行政赞助，你的SOA部署工作极有可能不能达到其目标。SOA的部署横跨多个部门和多个系统，这是一项意义重大的项目。你需要一个强势的行政人员来推动项目向前推进，并打破阻碍项目的一切障碍。但是光有影响力本身是不够的。这位行政人员也需要有足够的时间和精力来关注SOA项目的进展情况，并且时刻保持高度的紧迫感。

　　建议：如果你的SOA想要关键业务人员参与的话，那么行政总监应该由一个高级业务人员担任，他可以从SOA项目中得到很大的好处。让业务控制和推动那些驱动SOA路线图的项目投资组合。在技术公司，很有可能是CEO、CIO、首席技术官或首席架构师担任SOA行政总监。不管你选择谁担任这个重要的角色，这个人必须有足够大的权力，并且能够胜任领导职位。

　　4.试图“廉价”部署SOA

　　SOA并不是你购买的，而是需要花精力部署的。一些公司在预算很有限的情况下就尝试SOA架构。要想实施一个SOA项目，除了所需要的众多的中间件外，治理工具、培训、咨询、基础设施和安全都需要庞大的投资。

　　在生产环境中管理SOA是非常具有挑战性的，因为SOA天生就是分布式和松散耦合的。所在，在实施SOA时，千万不要吝啬花在生命周期管理工具上的经费，否则一旦出现问题，发现并修理故障无异于大海大海捞针。有些公司可能会在不借助任何外力帮助的情况下尝试部署SOA项目，以便节省高昂的顾问费用。除非你的IT人员对于SOA项目非常有经验，否则为了节省成本而不是用外部顾问会给你带来灾难性的后果。

　　建议：建立一个SOA路线图，这包含一系列的项目投资组合以及SOA能给整个企业带来的长远利益。为整个SOA项目创建一个合理的财政理由，突出SOA能给整个公司带来的投资回报率（ROI）、净现值（NPV）和内部回报率（IRR）等最重要的财务指标。如果你能营造足够好的商业案例，那么你就能得到足够的预算支持你的SOA项目。此外，市场上有很多开源SOA产品可供使用，它们的性能与商业产品没有任何差别，这可以大大降低部署SOA解决方案的整体成本。

　　5．缺乏所需搭建SOA架构所需的技能

　　要想成功实施SOA项目，企业需要具备很多专门的角色和技能集，但这可能是企业目前所部具备的。你需要SOA架构师、业务流程建模师、工具堆栈系统管理员、数据架构师以及其它许多技能。聘请这些人才需要花费很大一笔钱。在没有任何SOA实施经验的情况下就贸然部署SOA项目是一个重大的错误。SOA影响到企业所有的IT部门，包括测试、基础设施和安全。它要比简单地派遣几个开发人员参加几个技术培训班要复杂得多。同时还不要忘了业务人员。由于工艺改进，业务人员也需要进行培训，甚至可能对流程工具进行培训。

　　建议：制定一个广泛的培训和资源计划，当你提供SOA商业案例时，你可以把这个计划作为你最初向企业申请经费请求的一部分。尽量减少你向企业管理层申请经费的次数，并尽可能提高能预先拿到的预算数额。否则，管理层将会把SOA项目看成是一个耗费预算的无底洞。

　　6．项目管理没有跟上

　　到了最后，SOA项目失败的原因仍然归结公司项目管理不利上来。项目经理的职责是管理活动范围、减轻风险，使每个人都能各司其职，并与各个层次的员工进行沟通和协调。收集要求是至关重要的，并且分析瘫痪必须要加以避免。如果你的企业总是尽力使项目正常运转，那么你部署SOA成功的概率就会增加一倍。

　　建议：把你最好的项目管理资源放在SOA项目上。或者从外部聘请一两位SOA专家负责你的SOA项目。不论你选择谁担当项目经理，这个人必须有成功领导大型SOA项目的经验，并且技术功底足够深厚在概念层上对SOA有一个较深的了解。

　　7．把SOA当作一个项目，而不是一个架构

　　很多企业都天真地认为部署SOA只不过是另一类型的项目而已。 SOA是一个软件体系架构，部署者在实施过程中只有坚持面向服务的原则，并且确保交付成果与架构和路线图是一致的，SOA才能达到预期的利益。SOA需要专业化。企业的商业服务必须是在SOA架构师、开发人员、数据架构师、网络架构师和安全专家的共同努力下开发出来的。过去那种一个人扮演多个角色的时代已经一去不复返了。而在SOA堆栈的各个层次也是专业化的。你的设计团队包含用户界面设计师、业务流程建模师、数据服务专家、业务规则专家、ESB专家等等。所有这些专家可能同时为开发同一个服务而相互合作，所以需要高水平的协作。

　　建议：标准的IT团队结构对于SOA并不是很有效。我更喜欢一个矩阵结构的团队和高度协作化的环境。跳出思维定式并拆掉封闭专家的小盒子，形成一个更加开放的空间，让这些专家开展密切合作。在任何活动区域都竖起一块白板，以供专家们使用。尽可能多地取消例会，用更加具有协作性的手段取代它。

　　8.低估了SOA的复杂性

　　从概念上来说SOA非常简单，它只不过是IT经过这么多年的发展和积累，演化出来的一种高级产物。SOA不是一个很难理解的概念，但它却很难正确部署。SOA 和 BPM的美妙之处就在于它们给最终用户带来的简约，通过整合不同的后端系统是它们看起来像就像一个复合应用。SOA的缺点就在于大大增加了开发和管理软件的复杂性。建设SOA是一个软件工程范畴的活动。而不是简单的拖放开发，许多开发人员正在努力转型以适应这种不同。部署SOA需要坚持SOA标准和最佳做法（治理），并且需要能真正了解SOA概念复杂性的和人才参与。

　　由于部署一个SOA需要考虑那么多的事情，部署人员往往会忽略安全性。尽可能早地搜集安全方面的需求是至关重要的，因为这样可以使得基本架构从一开始就支持安全性。否则，如果后期才考虑安全性的话，极有可能架构将会发生重大变化。

　　建议：不管你是如何小心谨慎，在SOA实施道路上，都会遇到各种技术问题和集成问题。你要对此做好充分的思想准备。有些问题是由于你的 编码造成的，还有一些可能是与你使用的工具有关。供应商的产品远远没有达到成熟阶段，出现问题也是很正常的。你要制定一个切合实际的期望，不要为了单纯得追逐时间和数量而忽略项目质量。从小处开始，慢慢积累。从项目一开始就把安全因素考虑在内，不要事后才想到。

　　9.未能落实和坚持SOA治理（SOA Governance）

　　对很多人来说，“政府（Governance）”是一个令人讨厌的字眼。只要与Governance挂上边的认识东西都是不好的，对吗？呵呵，这次你可是犯了一个概念性错误。这里的“Governance”是治理的意思，而不是政府的意思。

　　无论如何，为了能“享受”到SOA带来的好处（可用性、灵活性、敏捷性）。部署团队必须要坚持公司采用的SOA架构方针。这就是所谓的设计时（design-time）治理。如果没有设计时治理的话，你可能最后得到的只是一堆Web服务。如果这种情况发生了，那么你就不要指望投资回报率（RIO）了，因为一切逗得从零开始。如果你能正确地做到运行时治理，那么随着时间的推移，SOA会变得更具成本效益。最终，开发工作将从创建服务转向消费服务。ZapThink LLC的分析师Jason Bloomberg将这种SOA开始收获敏捷性和灵活性的时间点为拐点。

　　其次就是运行时（runtime）治理。它是你主动管理你的生产SOA环境的健康度。运行治理可让你看到哪些服务正在被消耗，执行策略和服务水平协议，排查故障，分析绩效并管理所有资产。不要以为一旦部署完了你就无事可做了。管理分布式环境是一个很艰巨的任务，绝不能掉以轻心。

　　建议：将SOA治理和SOA部署作为两个作为两个并驾齐驱的项目。应该有一个专门的团队负责SOA治理工作，它通常是企业架构团队的一部分。与SOA部署一样，SOA治理也需要有自己的路线图和长远打算。不要试图在短时间内就能实施治理。这是一个长期的过程，往往需要几年的时间才能达到一个比较高的成熟度。当你的治理成熟时，那么你的SOA也就达到了成熟阶段。为了开展治理工作，你需要注册表、知识库和服务管理工具。同时你还需要新的测试工具以测试治理。

　　10．让供应商主导SOA架构

　　ZapThink分析师Ron Schmelzer“创造”了“供应商驱动的架构（VDA）”这个词。不过，过分地依赖供应商可能会带来在灾难性的后果。供应商的目标是尽可能多的向你销售商品。而你的目标则成功部署SOA，并用最低的成本给自己的公司提供最大的好处。你从中看到利益冲突了昂de吗？

　　此外，如果你购买的所有工具都来自一个供应商，那么该供应商就会对你承诺所谓的无缝集成。现实情况是，每个供应商自己的产品栈都集成了很多其它公司的产品，所以，如果你购买的工具不属于供应商的产品栈，它当然不能为你提供无缝集成。

　　建议：在你同供应商讨论之前，首先要弄清楚你到底需要什么。一定要执行一个非常彻底的供应商评估过程。当你确定了供应商的范围后，让他们实地演示一下如何满足你的需求。擦亮你的眼睛，仔细看他们的演示过程。要透过供应商漂亮的PowerPoint幻灯片抓住问题的本质，这样可以防止你范大错误。你自己也要做足功课。广泛阅读SOA实践者的博客，与使用相同工具的咨询公司进行交流，向已经部署SOA的其它公司取取经，并且厂商推荐者进行深层次交流。不要采取任何所谓的捷径。如果你能做到上述几点的话，你最后做出的决定肯定会让你以及你的公司受益匪浅。