6. 项目管理能力低下

　　说到底，这仍归结于公司管理项目的能力。项目经理必须在管理范围减少风险，保持每个人按进度表完成任务，以及向各级人员相应地通报情况。收集需求至关重要，必须避免分析麻痹症。如果连交付一般项目都成问题，在SOA上取得成功将更加困难重重。

　　建议：将最好的项目管理资源投入到SOA项目中，或者到外面找专家来帮助领导项目。这个人应当具有完成大型、变革性项目的记录，还必须掌握足够的技术，能够从概念层面理解SOA。

　　7. 把SOA当做一个项目而非架构

　　许多公司认为部署SOA只是另一个项目。SOA是一种软件架构，只有在公司遵守面向服务的核心原则并确保交付的东西与架构设想和路线图一致时才能取得所希望的好处。一个人包打天下的日子已经过去，你需要用户界面设计人员、业务流程建模员、数据服务专家、业务规则专家、ESB专家等。他们将同时从事需要高度协作的同一个服务。

　　建议：标准的IT团队结构对于SOA是无效的，要拆除隔间，建立使这些专家能够紧密合作的开放空间，尽可能多地选择使用更多的协作技术。

　　8. 低估了SOA的复杂性

　　从概念上讲，SOA就是IT多年来构建的东西的下一个演进，概念不难理解，但正确实施起来却有困难。SOA和BPM的动人之处是其通过集成不同的后端系统，把简单性带给最终用户。但其缺点是大大增加了构建和管理软件的复杂性。构建SOA是个软件工程，许多开发员将拼尽全力才能实现这一转变。交付SOA要求遵守标准和最佳实践（治理），需要懂得复杂概念的天才。此外，实施SOA有太多需要做的事情，以致安全性常常成为事后才考虑的问题。必须一开始就应该充分考虑安全性，否则日后很可能需要对架构进行重大的改动。

　　建议：厂商的产品远非成熟，因此会出现不同的问题，包括集成问题，设定现实的预期值，不要贪大图快。从一开始就构建安全性，不要事后再来补救。

　　9. 没有实施和遵守SOA治理

　　为了取得SOA的好处（重复使用、灵活、敏捷），团队必须遵守公司采用的架构指导方针，也就是所谓的设计时治理。缺少设计时治理，最后得到的可能是JABOWS（一堆Web服务），你将不得不每次都从头建设各种东西。当做得正确时，SOA会逐渐变得性价比越来越高。开发努力最终将由构建服务转变为消费服务。有人把这称为SOA开始收获敏捷性和灵活性好处的转折点。

　　然后就是运行时治理。这正是你主动管理生产SOA环境健康的地方。运行时治理使你可以看到正在消费什么服务，可以执行政策与SLA，可以排查故障，可以分析性能和管理所有资产。不要认为一旦部署SOA就万事大吉，管理分布式环境不是一件轻松的任务。

　　建议：将治理作为一个与SOA部署并行进行的、具有独立投资的项目来对待，不要试图在一夜之间实现治理。达到高成熟度需要几年的时间，随着治理的成熟，SOA也将成熟起来。

　　10. 让厂商驱动架构

　　Zapthink的Ron Schmelzer发明了厂商驱动的架构（VDA）一词。过度依赖厂商会成为一场灾难，厂商的目标是销售尽可能多的东西，而用户部署SOA是希望以最低的成本获得最大的好处。双方存在很大的利益冲突。此外，厂商通常会承诺无缝隙的集成，而现实是，他们从其他公司购买许多产品，以致他们的产品栈并不能提供比你从不同的厂商购买工具时更好的集成。

　　建议：在与厂商谈判前，确定自己需要什么，进行非常全面的厂商评估，将范围缩小到几家厂商时，让他们对你提出要求的东西进行概念证明，并亲眼观察这一过程。这可以防止你犯大错误，厂商将再也不能隐藏在漂亮的PowerPoint背后了。要多做功课，阅读从业者写的博客，与使用这类工具的咨询机构交谈，与其他部署SOA的公司交谈，以及与厂商的推荐人交谈，不要试图走任何捷径。