关于面向服务的架构（SOA）的很多优势已经广为人知，包括：降低集成成本、提高资产重复使用率，并且使IT部门能够更快地对业务中的变化和法规要求作出反应。但是，人们对它的缺陷又了解多少呢？

　　SOA的先行者们都非常清楚，当企业服务实现关键应用时很有可能会产生一些具有挑战性的问题。SOA是对IT规律的扩展，它既是设计和架构方面的重大改革，也是应用开发和业务上的改进。在这里，一些早期的SOA使用者和相关专家给出了在建设新一代数据中心过程中如何跨越障碍的SOA最佳实践。

　　1. 继续已经开展的流程

　　Dow Corning公司企业设计师Joseph Gaus指出，了解SOA的起点相当于寻找受众的过程。他说：“从最开始就应当瞄准那些已经具备多种应用的系统及其用户。”对于Dow Corning公司的多数关键业务流程（例如从订单到现金的处理流程）而言，SAP 是主系统。在过去，这家专业的化学企业也允许其他系统涉足该流程，例如，该公司一项基于Web的应用允许客户以在线方式发出订单。Gaus说：“我们已经习惯于这一流程，而且负责支持该流程的员工也习惯于围绕该流程建设其他的应用。”此外，其他的多种应用也围绕该流程建立，因此也为重复使用创造了机会。他说：“通过这样的流程可以更好地体现SOA的价值。”

　　2. 切勿忽视互操作性的问题

　　三年前，当Washington Group International公司开始实施其SOA项目时，标准和工具还远不像今天这样成熟。该公司应用集成经理Rich Colton指出，其中非常关键的一项挑战就是建设一系列适用于Java和Microsoft .Net客户端的Web服务。Colton发现，World Wide Web Consortium（W3C）标准在Java 2平台企业版中的实施方法与在.Net中的方法是大相径庭的。例如，这两种环境处理远程过程调用（RPC）的方式是完全不同的，而且每一种环境都支持不同的消息负载或内容。他说：“我们在最初就发现互操作性是一个非常关键的问题，但实际实施却没有那么简单。W3C标准也不是能够轻易实现的，因为并不是每一家企业都能够实施所有的部分。”在过去的几年中，互操作性已经有了大幅度的改善，但还没有达到自动化的程度。他说，对于程序员来说，测试工作仍然是相当关键的。

　　3. 不要轻易打开钱包

　　专业SOA咨询企业Linthicum Group首席执行官Dave Linthicum认为，当企业的IT部门开始着手实施SOA项目时，最先要考虑的事情往往是购买新的技术。但在投资新的技术平台之前，IT部门需要清楚地了解所有的信息源并确保以文档的形式记录每个系统定义数据的方式。如果没有做好这些准备工作，企业很可能选择不适合最终技术布局、服务管理要求和安全战略的治理工具。他说：“每一件事情都是相互关联的。企业需要全面了解数据，与数据互操作的服务，以及将它们结合在一起的流程。”

　　4. 认真考虑治理的问题

　　DaVita公司首席应用集成开发主管Bryan Grant指出，为整个企业基础设施建立一套新的框架并非易事，测试和错误都是不可避免的。DaVita是一家通过网络提供肾透析服务的企业，拥有约1255个门诊中心，而且每个中心所生成的数据都会汇集到一个中心地点并且提供给多种应用。开放式的平台可以允许IT小组重复使用各种应用、提供新的服务并且将各类传统应用和打包应用结合起来。然而，将这套系统从点对点式的连接方式转变为更加开放的平台存在着很大的困难。他说：“要想让这样的系统一开放就运转正常是根本不可能的。”DaVita目前正集中精力来改善治理的问题，了解哪些系统正在连接，并且确保投入生产的服务真正发挥生产能力。该公司在实现这些目标后才会购买必要的软件来帮助实现最终的目标。Grant说：“我们过去在治理方面做得并不好。”

　　5. 多给员工一点激励

　　Gaus说，在过去的几年中，Dow Corning公司的开发小组在应用元素的提炼、组件库的建立和代码的重复使用方面干得非常出色。但是，利用已经经过考虑的方法建立新的应用要比真正采用SOA方法更加简便，也更节省成本。他说：“在运行和建设新的应用之前，最关键的是了解应用需要哪些企业数据，以及需要哪些业务流程，并在这些数据和流程的基础上建立相应的服务。这个前期的工作所需的成本通常会更高。”他表示，为了避免以老方式来做事，公司正在考虑将SOA项目预算中的某个比例，例如5%作为奖金发放给有作为的员工。

　　6. 更务实的预算有益无害

　　Linthicum说，“人们都渴望知道应当如何制定预算。但事实上，人们根本不了解预算制定的复杂性，因此，他们常常低估成本。”他曾经建议根据各种变量来确定一份SOA项目定价指导方针，而这些变量通常应当包括数据元素的数量、系统和流程的复杂性，以及所需的新服务等。

　　通常，与SOA建设项目有关的时间和劳动力是应当考虑的主要因素，而不是购买技术所需的成本。企业常常需要顾问的帮助，而且应当充分利用企业内部的资源。例如，精通架构、安全、数据管理、网络和应用开发的企业内部员工。在时间的问题上，Linthicum认为SOA项目中每套正常复杂度的系统所需的开发时间应当为三至四个月。如果是一个有六套系统的项目，则需要两年的时间来完成计划、注资、部署和完成全过程。如果企业想在这一过程中占据主动地位，就必须在前期花足够的时间来完成详细的时间安排和劳动力规划工作。他说：“如果企业对时间的需求估计不足，参与项目的人员很可能会失去信心，因为超期很可能会使项目超出原有的预算。”

　　7. 不要在文档问题上敷衍了事

　　DaVita公司的Grant指出，在SOA开发周期的每一个过程中都必须有明确的文档策略和流程要求。他说：“如果将75%的精力都放在规划和文档上，并将剩余25%的精力放在开发工作中，整个项目将会变得更容易管理。”

　　8. 注册并非灵丹妙药

　　Washington Group的Colton认为，文档服务属性是SOA项目中一个比较麻烦的部分。Colton目前正在实施的一个项目是找到一种方法来同时跟踪服务相关技术细节，如转换要求和服务依存关系，并且跟踪功能问题，如涉及的进程。一些商用的注册并不能同时提供两类信息，而且Colton也不希望匆忙地进行不成熟的技术采购。他说：“我们开发了一个电子表格来帮助我们理解所有需要跟踪的信息。在这一过程中，我们既可以自己解决问题，也可以寻找适合的商用解决方案来满足需求。”

　　9. 不要忘记网络的问题

　　Linthicum表示，很明显，SOA必然会增加网络的负荷。要想实现合理的网络设计，性能建模是必不可少的，而很多企业在这方面做的并不到位。他说：“企业可以分析各类服务的行为来建立性能模型，然后将其扩大一万倍。通过建模，企业可以了解一些情况，包括：要发送的数据包有多少个？网络最多能够提供多大的带宽？”

　　10. 不必太强调技术

　　SOA是一项业务行为，因此在沟通时也应当以业务作为讨论的重点。Washington Group的Colton谈到：“在谈话时应当尽量避免IT语言而使用商业语言。没有人关心它是如何实现的，人们真正关心的是它能够满足哪些商业流程的需要。”