然而，人们构造这些IT系统是为了什么？仅仅是卖给客户几个“漂亮的概念”吗？当然不是，这是软件提供商在不断满足客户在业务系统的应用性、敏捷性上的需求而做出的努力。
业务敏捷性取决于企业信息的自由流动、服务和业务流程。而且这也要求IT系统必须能够满足业务的变更：远洋航运集团规划未来几年内把集装箱的吞吐量提高4倍，集团组织构架向多组织化发展……遇到这样的变更，如果你告诉客户：你们仓储系统需要重新构建，组织构架需要重新建模，人力资源系统需要重新编写，财务系统需要重新编写……那将会是一件多么可怕的事情？
事实上，满足IT系统的敏捷性，必须逾越几个最基本的障碍：
（1） 能够统一描述出各种业务，或者说业务对象与业务模型。这些业务对象和业务模型需要很容易被组合或重组。因为企业业务并非随意创建，而是由基本规则在支撑。尽管我们不断宣称需要灵活、敏捷，但这样灵活性的变更发展也必须有一定的原则。这如同企业市场开拓，从一个区域向另一个区域拓展，而绝非游击队的模式： 打一枪换一个地方。
（2） 企业IT系统一般会由多平台（IBM、BEA、Microsoft、SAP、Oracle等）和多技术（J2EE、.NET、遗留技术等）构成。大企业的异构性会更复杂。某项业务可能涉及到企业内部系统、外部环境、供应商、分销商和客户等等。这就使得业务的变更牵涉到众多合作伙伴。所以必须有更好的互联技术来满足不同系统之间的信息交互，这种信息互联必须基于统一的标准和构架，而且能够很容易定位与获取。
SOA为支撑业务敏捷性提供了新的思路和方法
上个世纪九十年代所诞生的了BPR（业务过程再造），除了吸引了很多眼球之外，没有形成实实在在的应用，直到如今逐渐成熟起来的BPM Suites（业务过程管理套件），才让BPR再次走入了人们的视线。这就像是一个迟来的热潮，用户最终发现并发掘了那些概念的价值。
SOA也是一个迟来的热潮。1996年，Garnter就预见到了服务构架的重要性，并提出了SOA概念。但那个时候并没有合适的技术能够满足这种构架。多年以后，伴随着互联网浪潮，越来越多的企业将业务转移到互联网领域，带动了电子商务的蓬勃发展。为了能够将公司的业务打包成独立的、具有很强伸缩性的基于互联网的服务，人们提出了Web Service概念。
Web Service开始流行以后，互联网迅速出现了大量基于不同平台和语言开发的WS组件。为了能够有效地对这些为数众多的组件进行管理，人们迫切需要找到一种新的面向服务的分布式架构。该架构要能够使这些由不同组织开发的Web服务相互学习和交互，保障安全以及兼顾复用性和可管理性。由此，人们重新找回面向服务的架构（SOA），并赋予其时代的特征。在经过IBM、BEA、SAP、Oracle、TIBCO、IONA、SUN、Microsoft等企业的推动下，一批标准的不断补充，参考构架的不断完善，这才使SOA逐渐“从空中降落到地面”。
但是，SOA不是业务敏捷性的最终解决方案。它只是为客户构建IT系统时，提供了一个从“服务”视角解决问题思路和方法。当然任何方法都必须有一套可参考的通用语义和多种实现构架来支持，这就是为什么我们常说的“SOA不是一种架构”的原因之一。
去年10月份由OASIS组织发布的SOA参考模型（Reference Model）深刻阐述了SOA语义层面的概念，特别是对Service的抽象描述：
A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description。
很明显，对Service的描述在这个定义当中并没有限定具体的介质和规范。只是在现有的技术体系下，大家发现采用Web Service来实现Service是个不错的选择。
但SOA参考模型没有提出一套参考架构，其更多的是围绕Service来诠释一些基本概念，比如服务描述（Service Description）、交互（Interaction）、契约和策略（Contract&Policy）等等。这为不同厂商之间的实现留有了发散空间，但也为人们理解SOA增加了难度。
目前，SOA构架大致与下面图有些类似。但具体实现层面，不同厂商之间是不同的。
图3 ：一个SOA参考架构图
主要是围绕：消费者（Consumer）、业务过程（Business Process）、服务（Service）、服务组件（Service Component）和应用（Application）来诠释和分层的。
