在SOA出现以前，IT系统对业务的束服表现在两个方面。就企业组织架构来看，因为原来的业务模式是以部门为导向的，IT系统也主要支持部门导向的业务过程，因此IT系统的作用仅限于垂直整合。但是，在充满竞争的业务形势之下，企业需要形成一个充满合力的整体，这也对IT系统提出了新的需求。举例来说，如果一个新员工报到，他的入职可能要涉及人力资源、财务和他将要服务的业务部门。人力资源部会负责从招聘通知、面试、入职到薪资的整个过程，但在这个过程中，还需要了解业务部门通过面试对准备入职员工的满意程度，并把涉及新员工的资料反馈给财务部门。这个过程如果由人为干预转向了自动化实现，就可以视为基于SOA的实现。

　　新员工入职是企业再简单不过的一个业务，但要真正实现自动化，需要实现数据的整合。如果业务部门的IT系统和人力资源部门以及财务部门的系统相对独立，就会涉及系统整合的问题，而这正是实现SOA的第一步。这会包含整合信息孤岛、通过虚拟化技术将应用不同系统（异构）和分布在各地的应用，呈现为一个统一、安全、可管理的整体。而为了达到这一目的，还需要所有的信息系统使用同一个开放标准，来保证系统间实现联通。当实现了这些整合以后，业务部门、人力资源部件和财务部门的业务就通过业务流程贯穿了起来。从组织架构的角度讲，这实际上实现了水平整合。

　　从垂直整合到水平整合，是一个宏观的表现过程，但使用程序是每一个具体的业务人员，因此我们还需要从微观的视角去审视一下这个变化。微观层面IT对业务人员的束服是IT系统对业务束服的第二个方面。

　　业务人员之所有被IT所束服，就在于他们无法用业务术语来描述IT系统中的元素。在过去的IT系统中，所需要的元素是一些低级的技术实体，如代码、对象、组件等，以并不兼容的标准，通过代码、脚本、消息与事件组合在一起构成。这话听起来实在费解，但好在有了SOA以后，业务人员确实不再需要理解它了。

　　聪明的人类发明了抽象这种方法，尽管克隆、纳米的概念及应用，解释起来可能不比相对论容易多少，但经过抽象，已成为使用率颇高的词汇。同样利用抽象这种方法，类似于代码、级件、脚本、消息这样的低阶技术实体，已被包含到高阶的元素之中，高阶的元素已经独立了出来，并以独立存在的实体实现在IT系统中。也就是说，业务人员通过业务流程、业务服务、业务数据对象、业务事件这些与他们有切实联系的词，就可以描述和交流业务模型和业务需求了。到了这一阶段，IT确实已变得象水、电一样方便易用了。

　　经过上边的过程，相信多数人已经明白了SOA的实现方法。但就象相当一部分人，在知道了曾经看似神密的收音机的工作原理之后，会忍不住拿起螺丝刀打开它的后盖，看看它究竟是怎么工作的一样，相当一部分人在了解了SOA的实现过程之后，还是会关注SOA低层的工作原理。

　　就象打开收音机后盖以后，会有相当一部分人感到失望一样，SOA的组件也并不复杂。要把人力资源、业务和财务部门联结起来，就必须形成一条ESB主线，它的目的是在服务请求者和提供者之间传递数据以及对这些数据进行转换的能力。企业的实际业务要比招聘一名员工复杂得多，所提出的需求也复杂得多，为此，还需要引入一些新的设施。就象各个实际的部门需要相对独立的办公环境一样，在基于SOA的系统中实现自动处理服务也需要服务运行时环境。当业务量增大时，协作部门间会建立沟通机制，把需要解决的问题按轻重缓急排列出来，在SOA架构中，负责记录这些问题的是服务注册库，而决定问题轻重缓急级别的则是服务网关。站在企业管理信息系统的顶层，我们还会发现各种各样的流程象车流一样运行在IT系统中，就象我们无法想象繁华的街道上没有交警的情形一样，SOA还需要一个流程引擎。此外，对服务的质量，SOA会利用服务管理来监督；为了业务的安全，还可能设立一个业务活动监控；为了大家的升迁和发奖金有依据，还可能实现绩效管理。这一切就是SOA的全部了。

　　尽管SOA的实现方法并不复杂，但真正实现SOA架构却并不是一件容易的事情。但反观人类追求自由的历史，我们不难发现每一次都会遇到巨大的阻力，但人们追求自由的渴望却一次又一次地突破了这些阻力。也正是因为SOA具备帮助业务人员追求自由的这个特点，所以它的生命力将格外强大。