Jonathan Mack说，现在SOA实施“并不像许多分析机构或Web研讨会所指出的那样普遍”。原因很简单：成功的SOA实施是颇具挑战性的。Jonathan Mack概述了三大挑战：
\u0026#xD;\n- 解决早于SOA的架构——将现有企业资产整合到SOA里去。 \u0026#xD;\n
- 说服公司采用SOA——用具体的事实（而不是总体的陈述）阐述为什么SOA能够产生与其成本相称的效益，得公司涉众（stakeholders）信服。 \u0026#xD;\n
- 设计最有效的SOA路线图——定义实现SOA愿景的过程。 \u0026#xD;\n
虽然大部分SOA实践者们提倡在现有企业应用之上构建一个瘦服务层、尽量重用已经存在的功能，但这样实施的挑战性常常比通常认为的要大得多。Jonathan Mack指出：
\u0026#xD;\n过去构建的遗留系统（legacy systems）是一些零散的批处理或在线处理程序，它们必须按特定的顺序组合起来才能产生有意义的业务功能。那些遗留的处理程序是用于满足实际需要的， 它们常常是根据实际开发流程得到的、而不是与具体的功能相对应。从服务的观点来看，这些程序缺乏一致性和含义。\u0026#xD;\n
关于解决这一问题的实际办法，Jonathan Mack概述如下：
\u0026#xD;\n\u0026#xD;\n\u0026#xD;\n
- 为你将构建的服务增加一个瘦服务层作为过渡。所以要创建一些便于插入服务层的组件，以便遗留系统的程序员们可以按他们过去的方式进行工作（即用明确定义的输入输出来设计程序）。 \u0026#xD;\n
- 从一开始就在服务层中留好监控与异常处理钩子（hooks）。SOA最重要的优点之一，就是它可以精确监控应用的活动。 \u0026#xD;\n
- 若服务（service）比点对点的交互（point-to-point interaction）更具优势，那就构建专门的服务。应为服务的构建定义和发布明确的标准。最重要的一则标准就是：该服务存在多个客户。 \u0026#xD;\n
- 不要迷信卓越中心（Centers of Excellence）。确保拥有一个小型团队，选择成员时应特别注重他们与其他开发者协同工作的能力。从一开始就通过合作共同构建将来作为服务层基础的公共服务。 \u0026#xD;\n
- 尽量构建直接与主机（mainframe）交互的原子服务，尽量用ESB软件来构建合成服务。保持原子服务层与合成服务层的分离。 \u0026#xD;\n
可重用性（reusability）是SOA的一大卖点。不幸的是，这常常是一种信念，而非事实。能够支持这一观点的数据很少很少。Jonathan Mack说：
\u0026#xD;\n要使重要涉众（stakeholders）信服，你的阐述要更加具体才行。虽然用图来解释“SOA如何能帮助解决错综复杂的 系统所面临的问题”很不错，但公司里的涉众想更具体地知道这一努力将如何产生与成本相称的效益。而且，他们很擅长分辨ROI预估里数字的虚实。不论 你采用何种方式实施SOA，假如你希望被认真对待的话，你就必须提供非常实在的数字。\u0026#xD;\n
至于SOA路线图，最近出现了两种流行的SOA实施途经：
\u0026#xD;\n- 企业级（自上而下的）SOA实施途经：风险很高，最初预算要几百万美元。另外，根据不同的规模与复杂程度，这类项目的耗费基本无法准确预估。 \u0026#xD;\n
- 草根级（自下而上的）SOA实施途经：将SOA元素（包括服务和基础设施）作为现有业务驱动的IT任务来实现。这种途径一般不会成功。一来，最终得到的服务仅限于特定的业务问题，对企业的其他部分来说可能不适用（甚至是错的）。二来，构建SOA层所需的时间与开销将有损于项目里的其他业务需求。 \u0026#xD;\n
Jonathan Mack提出的另一种途径是：
\u0026#xD;\n逐步构建SOA。大部分厂商已经觉悟过来，认识到了这是最合理的途径。然而，这做起来并不容易。企业服务总线 （Enterprise Server Bus，ESB）的核心元素——对不同系统间的信息进行转换与转化的能力，以及路由消息的能力——以及用于传递消息的消息传递基础设施，这些必须从一开始 就要具备。公共（共享的）服务（如登录、监控和异常处理等）也应该是最早实现的。\u0026#xD;\n
SOA围绕IT业吵闹了将近10年，由于整体复杂性，至今仍没有万无一失的成功实施方案。每一个新的SOA项目“必须有明确的务实态度，必须对成功的实施步骤（及代价）有深入的研究和理解”。
