误区9：

　　“你真正需要的是Web服务”

　　有时候，我们会遇到另外一种看法，认为Web服务是生成SOA ROI的必要条件。从这个角度来考虑，面向服务技术架构和基础设施投资的重要性就要退居其次了，这两者往往也是商家炒作的对象。还有一种错误的观点认为“目前是创建大量Web服务的最佳时机，因为我们可以晚些时候对要求的技术架构上进行投资。

　　此外还有一些更具诱惑力更有破坏性的假设。它们很有诱惑力，因为不通过战略规划和投资就做成的Web服务，即便宜又简单。但是它们的破坏力是很强的例如：

　　·不良SOA基础-服务架构重点关注Web服务开发，因此它处于不断演进的过程中，而不是单纯依靠设计的。典型的进化驱动程序是范围狭小、作用时间短暂，垂直要求而不是IT战略目标。这无疑会产生分散的、支离破碎的、集成程度不高的服务和安全基础，因此无法带来稳定的ROI.

　　·操作低效能—如果在各种没有战略结构基础的平台上传播Web服务势必会在服务安全管理、服务部署以及服务管理、服务定标等方面遇到很多操作问题，这些操作会花费大量的资金。

　　·业务灵活性缺失-花一分钟看看我们在文章之初谈到的功能表，重新审视一下支持业务灵活性所必须的功能。这些都是复杂、相互依赖、相互依存的要求。业务灵活性不会从一堆的Web服务中演进。必须事先对其做好规划，将其设计成为一个由许多互补请求以及功能所组成的有粘性的集合。

　　要想无需战略规划或者投资就增加Web服务是在短期开销节约以及长期成本方面做出的权衡之后得出的结论，无疑短期利润要让位于不断增长的结构低效能，因为短期的利润会导致长期的系统维护和修理工作异常的昂贵。

　　结论：评估SOA设计方向

　　到目前为止，这些讨论让我们对成功实施SOA所必须的要素有了基本的了解。同时，我们也认清了某些关键的设计误区。这些误区往往是SOA实施产生问题的根源。最后，我们看一下，IT领导者是如何运用他们所学的知识确保SOA成功实施的。

　　我们先看一下上述表中列出的功能能力。在一个架构或者SOA成功实施的基础设施中，必须以有形的形式对这些功能能力进行协调。这就意味着每一个功能能力都要映射到有形的架构/基础设施要素以及SOA设计解决方案的策略当中。

　　此外，我们对于常见设计误区的了解也是很有价值的，有了这方面的知识，IT领导可以从更高的一个层面评估SOA设计方向。

　　这就需要对功能能力有一个清晰的认识，避免对服务定向解决方案产生误解，我们可以通过一系列的问题展示这些误解，并将这些问题上报给SOA设计小组。下面的列表概括了问题分类。总的说来，这些问题可以用作测量SOA是否运转正常的标准。

　　和IT功能相关的问题也是增加投资回报率的关键：

　　·如果将每个功能都映射到SOA/企业系统或者拟定解决方案架构的子系统当中呢？

　　·用于交付SOA相关功能的拟定方案是否真的具有结构深度呢？

　　·IT功能和SOA设计的其它方面究竟有何种联系呢（我们是如何在服务定向解决方案中协调它们之间的关系呢？）

　　和一般SOA设计误解相关的问题：

　　·拟定解决方案本质上是一个SOA供应商产品栈？

　　·是不是大家更倾向让SOA产品供应商定义解决方案架构？

　　·拟定解决方案架构为整合误区1（“SOA供应商栈是服务架构”）中IT企业资产提供了一个综合计划吗？

　　·选取SOA结构要素的标准是什么？（是否能够证明选择的合理性？）

　　·拟定服务基础设施设计的根本是ESB产品吗？

　　·SOA性能设计战略是拟定解决方案的关键部分吗，或者供应商产品可以解决这个问题？

　　·拟定安全架构主要依赖SOA供应商安全产品的功能吗？

　　·拟定解决方案会为整合SOA治理模型提供结构支持，以便确保开发可重用服务吗？（方案是如何支持治理的？）

　　·拟定解决方案能够有效地满足SOA措施的信息架构需求吗（如果可以，要如何去做呢？）

　　·在解决方案架构中，SSL是信息安全的重要组成部分吗（如果不是，又要如何处理呢？）

　　·在提供主机服务平台以外，拟定解决方案是否提供了更有深度的内容呢？

　　最后，管理人员需要开通更多与SOA设计小组沟通的渠道，以便更好的展示他们对于交付关键IT功能以及避免拟定误区有那些独特的主张。高效的SOA设计师同样也要欢迎管理人员的加入，并能够着眼全局（文章中提到的策略和问题）开发结构解决方案。由此得到的反馈信息可以帮助管理者对专业人员以及SOA工程师的经验做出评定。只有这样，SOA实施才有可能获得成功。