分析：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，并用最低的成本给自己的公司提供最大的好处。你从中看到利益冲突了吗？

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

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

来源：eNet硅谷动力

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友