SOA的首要目的是让企业的业务能够快速地响应或领导变化，即“业务敏捷性”(Business Agility)。而SOA自身，首先是设计原则和风格;其次它是来自实践、应用这些原则和风格的架构范式;再次，SOA是支持和实现这些原则和风格的技术、标准和产品;最后，它是保证企业各方有规可循、透过在“服务”的生命周期中相互协作来达成业务敏捷的管控策略(Governance)。
SOA是IT正在发生的一个大的变化和范式转移，这就意味着企业的业务与IT将面临业务敏捷性的挑战，两者显然还需要更好的协作和对齐。
传统IT不支持业务敏捷性
权威咨询报告结果显示，中国大多数传统企业缺乏一个方法让业务和IT真正地“亲密接触”，有效地沟通、协作，让IT很好地服务业务，而IT和业务又很好地跟企业战略对齐，即缺乏一个合理的企业架构。
除此之外，传统的做法需要加强业务建模。有些企业，在业务优化和创新的各种实践中，逐渐建立起了业务流程模型。但是大多数企业对自己的业务模型仍停留在自发状态，缺乏业务方面的严谨企业架构实践。这种缺乏，带来几个问题：一是业务优化、应变和创新缺乏形式化的基础，缺乏数字化的基础，很容易靠感觉办事。二是业务和IT之间缺乏“可追溯性”(Tracability)，在将业务的需求映射到IT的时候，使用模糊的自然语言，在操作的细粒度上交流(用例，use case)，这种模糊性带来了翻译后的失真和变形。所以我们说，在传统实践中，业务建模这一环需要加强。没有好的业务建模和业务架构实践，业务敏捷性难以保证。
向支持业务敏捷性的IT演进
传统模式需要引入新的IT架构范式和抽象层次。企业的业务活动/流程需要多个系统相互协作来支持，如何集成它们?如何在集成的基础上，重用已有系统的能力和数据，协调它们来增值，也就是响应业务的新需求?如何让这种集成和增值发生得多快好省，说变就变?
首先，增加了一个新的抽象层次，就是“业务层次上的契约”，用来描述不同的业务组件(或者业务对象)之间交互的接口。在SOA环境下，也就是通常所说的“服务”，业务组件化建模所得到的服务模型，解耦了业务架构和IT架构，提供了业务架构和IT架构之间良好的映射能力和变化的可追溯性，即在服务定义不变的情况下，业务和IT可以独立地演变，带来很好的灵活性。
在SOA中，当我们启动一个项目，我们将首先从企业的业务建模入手，通过对业务进行分析，来得到服务模型、流程定义等。通常，采用领域模型分析方法，对业务组件化，标识服务，定义服务的描述细节，检测服务是否符合业务人员的期望值，是否服务于企业的战略和目标。经过这个业务层次的建模过程之后，我们转向技术层次，也就是服务和流程的实现。如果我们没有什么遗留系统，一切是从头开始的一个应用，事情将很简单，我们会采用已有的解决方案和技术来设计这些服务。
另外，在SOA的实践中，通常会创建一个数据服务层。而这通常会集成EII(Enterprise Information Integration)的技术和最佳实践，不过也会建立在Web服务等标准和开放技术的基础上。
最后，SOA Governance被用来在整个服务的生命中期中，将来自业务和IT的人协调起来，让他们各司其职，有规可循，相互协作来分析和定义服务，创建、组装和部署服务，运行和管理服务，监控和优化服务等。
