早在SOA刚开始引起关注的时候，其目的只是为了把应用功能作为共享服务来提供。许多公司在发展过程中组建了各自的SOA架构，当然现在仍在这么做。只不过区别在于，在过去的几年里业务部门更加了解IT具有的战略价值，而IT部门也更加了解业务部门所要承受的竞争压力。因而， SOA就有可能让IT部门和业务部门之间比过去更紧密、更协调。

业务部门需要可重新组合的一组服务，从而获得新的业务流程来支持新的产品或者服务。而SOA的作用正是发布这些服务，并提供稳定一致的框架。按照该框架，服务可得到治理并编制成应用。虽然许多SOA计划仍处在早期阶段，但提高业务反应能力的承诺却是实实在在的。我们也看到越来越多的企业正向更高级的部署阶段迈进。

下面介绍的这些案例，就是实施SOA的典例。
康卡斯特公司依托领域专门知识建立SOA

你在决定要采用SOA方案时，忍不住会开始购买企业服务总线（Enterprise Service Bus,ESB）、注册中心及其他工具。康卡斯特（Comcast）公司负责应用架构和IT治理的高级经理Tom Adler说，但是这忽视了SOA的重要价值：你可以把创建及部署的应用与它们执行的业务流程结合起来。从架构入手有助于确保你有合理的框架做到这一点，无论现在还是将来需求变化时都是如此。

一年半前，康卡斯特（Comcast）公司启动这个项目时，顶住了请来厂商的诱惑，而是请来了专家，弄清楚公司首先需要什么。而所有厂商只想把ESB卖给康卡斯特。架构方面的工作不仅仅在于确立框架，还要开始确认你在业务流程和应用方面哪些地方存在冗余。这是得到业务部门认可及支持的关键，因为这非常具体地表明了哪些地方有机会节约成本，从而有助于证明有必要对SOA基础设施和工具进行投入，还能表明在何处使用通用服务有助于减少维护和整合方面的复杂性，以便将来提高开发工作的响应能力。而这个目标让公司可以消除冗余服务。

开发架构之后――Adler称之为通用领域模型，康卡斯特的下一步就是开发治理框架，用于服务开发及部署。服务必须进行治理，否则没有人会知道存在某一服务，也不会遵循相应的政策和程序。只有经过治理的服务才添加到服务注册中心中，供其他人重复使用。

很快出现的一个治理挑战就是决定谁拥有服务。康卡斯特公司相当分散，所以这种企业文化自然支持让服务创建者拥有其相应领域的服务。像单次登录这些通用服务自然属于IT部门。

Adler现在意识到康卡斯特漏掉了一个步骤，就是在确定架构后还要开发通用数据服务模型。由于没有标准的数据服务访问公司信息、管理系统之间的相互关系，所以开发人员最终开发的服务以不同方式来完成任务，从而导致不一致性，因而无法兑现SOA的承诺，即轻松实现服务组件的混合搭配。事实上，康卡斯特先前低估了这一重要性，而代价就是事后改动了一些服务，强制使用这种模型。

与单单认为SOA只是技术问题相比，康卡斯特的SOA项目注重架构。这有助于SOA概念得到更广泛的应用，因为公司一开始并没有认为SOA意味着单单使用Web服务，而是把SOA概念运用到了所有项目中，不只是明显具有Web服务功能的项目。Web服务只是公布服务的一种方式――它只是个实现细节而已。实际上，内部的初期SOA项目大多针对遗留应用，从而减少了公司内外（如外部的开票公司）的集成点，而这是让业务部门深为头痛的一大难点。

举例说，开发人员平时使用最适合各自的知识及所构建应用的众多工具和编程语言。由于使用标准的流程和政策，而不是特定的工具和技术方法，开发人员可以更好地遵循架构的意图，而不是让每个项目受制于某一特定的工具或者技术。既遵循统一架构，又允许技术多样性，这也是有实际原因的，在一家有9000名员工的公司，让每个人都使用相同方法是不切合实际的。

类似于那些大规模的公司还要适应不断变化的业务需求和技术机遇。所以定期评审参考架构很重要，避免它不成为约束性措施或者一纸空文，那样就没人会理睬。不管出现哪一种情况，你都得不到SOA的好处。虽然架构不是每个月都在变化，但在康卡斯特公司里Adler还是每个月都要评审一次。