要成功地实施SOA，就需要一个优化的、开放的服务基础设施，基于它，无需编码就建立起跨异构系统的复合应用。
　　有这样一个案例：两家大型企业已达成合并协议，其财务系统也随之需要进行整合。让IT部门感到高兴的是两家企业使用的财务系统都出自同一厂商，并且是同一产品，因此IT部门相信该软件的整合工作会相对快速和简单。然而，工作的最终期限已过去两年，该项目仍然未能完成，预算也超支了200%。到底发生了什么？
　　企业应用系统包括了多个版本和例程——这增加了集成复杂性。两家企业虽然采用了相同的财务系统，但各自的会计业务流程却大不相同，因此分别对应用系统进行了不同的定制。由于定制的业务逻辑隐藏在应用中，因此进行系统合并时必须深入了解复杂的底层技术，这需要开发团队耗费数月编写代码。
　　
　　如何解决这一难题
　　
　　如果企业采用了成熟的服务基础架构，那么以上问题将几乎不会存在：业务逻辑可以在基础架构中进行安全的抽象，并能够采用XML实现快速标准化；应用服务被编译为端到端的工作流，而不是系统间脆弱的连接。这将使合并后的企业能够专注于合并业务流程，而非开发数千行的集成代码。
　　
　　服务基础架构应运而生
　　
　　服务基础架构的出现实际上是企业应用基础架构的自然演进。初期，企业若想定制网络操作系统的功能，就需要自己对系统进行编码。基于HPUX、Solaris或AIX的应用或扩展都包含在各自的系统代码中，这就形成了不具有重用性的孤岛系统。这种方式带来的必然结果是企业IT系统变得越来越依赖于同种设备，久而久之就会导致厂商垄断——企业变成了HP专卖店，或是IBM、SUN的设备专营店。
　　同样的一幕在若干年后随着企业应用软件的出现再次重演。企业为使其SAP供应链应用系统或PeopleSoft人力资源系统适应内部业务流程而进行相应定制时，开发人员需要在SAP或PeopleSoft应用系统内部进行编码。如果企业需要将Siebel CRM解决方案和Oracle数据库进行集成，那么集成代码必须被包含到Oracle或Siebel应用中。企业自己的业务逻辑再次成为了厂商专有软件的内部“财产”。
　　为了将业务逻辑从樊篱中解放出来，企业应用基础架构应运而生。最初的企业应用基础架构是分布式事务处理系统。1995年，BEA推出了Tuxedo平台，它提供了在异构环境中构建和集成C、C 和COBOL应用的框架。通过使用API和集成服务，Tuxedo对技术的底层复杂性进行了有效抽象，从而将功能从底层编码中提取出来。随后，Internet的广泛普及要求企业应用能够与基于浏览器的前端协同工作。应对这一挑战，BEA WebLogic Server 和BEA WebLogic Platform为此类应用的开发、集成和管理提供了业界第一个统一框架，使企业能够从容构建对业务成功至关重要的企业应用。
　　有了用于扩展操作系统和企业应用的平台之后，企业应用开始向面向服务的架构转变：将一个系统表示为一整套可重用的服务，使其他系统能够对该系统进行访问。
　　面向服务的架构（SOA）给这一问题的解决带来了希望，它可以将包含在企业应用中的离散业务功能提取出来，将其组合为可互用的、基于标准的服务。但随着SOA从试用阶段转向实际应用，用户逐渐发现他们需要一种新的软件基础架构来帮助他们快速地组合、发布、配置和管理服务，特别是那些建立和部署了50个以上Web服务的客户对此的需求尤为迫切，因为Web服务的增加会导致“服务蔓延”，从而需要不断地集成并使规模化的难度加大。