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的其他公司讨教，也要向厂商的推荐人核实。切勿走任何捷径，你要为自己所做的决定负责。