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实施道路上，都会遇到各种技术问题和集成问题。你要对此做好充分的思想准备。有些问题是由于你的 编码造成的，还有一些可能是与你使用的工具有关。供应商的产品远远没有达到成熟阶段，出现问题也是很正常的。你要制定一个切合实际的期望，不要为了单纯得追逐时间和数量而忽略项目质量。从小处开始，慢慢积累。从项目一开始就把安全因素考虑在内，不要事后才想到。
文章来源于领测软件测试网 https://www.ltesting.net/