Don Rippert模型中的步骤如下：

　　使用XML，以更标准的方式使用应用程序接口。

　　捕获一些业务过程，并将它们转化成为Web服务。

　　引入并全面使用企业服务总线。

　　产生业务过程执行语言(Business Process Execution Language，BPEL)，它可由业务过程建模工具完成。BPEL可以改变应用程序的行为，而无需修改软件。

　　Rippert先生在采访中表示，尽管很多组织拥有ESB，但是它并没有被完全利用。他进一步的表示，大多数公司仍处于阶段1。与这个ESB所处位置的论断相对比的是，Burton Group的分析师Anne Thomas Manes的叙述，其发表于近期面向服务架构Yahoo Group的讨论中。Anne说：

　　......如果缺少我推荐启动SOA的“基本组件”，ESB将不会列在我的清单中。事实上，我并不鼓励人们由ESB开始。ESB并不会鼓励好的SOA行为。ESB本质上是集成系统，而非SOA系统。SOA是用于拆卸应用竖井(application silos)，而集成系统则是修补这些竖井。

　　引用她的书，她接着提及的基本组件包括：

　　一个或多个服务平台(如，.NET，Java EE应用服务器等)

　　SOA管理解决方案

　　注册表

　　如果服务要被暴露在防火墙之外，那么需要XML网关

　　引用组员早期的帖子，她说道：

　　“......ESB特别适合桥接传统应用，因此，在服务基础设施中，它是一个有用的组件。很多ESB也支持可靠消息传递、异步消息传递和发布/订阅交换模式。这些能力都非常有用，但是，在SOA项目的初始阶段可能不会发挥多大的用途。(每个组织有很多不选用这些能力的项目。)在SOA项目的后期，你还可能需要一个编制(orchestration)引擎，并且大多数的ESB都会提供一个。即便如此，ESB也绝对不是组织启动SOA的起点。所有这些能力你一开始并不需要。因此，ESB应该在后期购买。”

　　这似乎符合Rippert先生的观点，即尽管很多组织拥有ESB，但是它并没有被完全利用。Manes女士的评论同样有助于定义ESB的范围，通过暗示许多ESB支持的特性，它确定了一组适当的能力。

　　根据维基百科的ESB定义，ESB有如下特性：

　　它是面向服务架构的实现。

　　它通常是操作系统和编程语言无关的;它应能在Java和.Net应用程序之间工作。

　　它使用XML(可扩展标识语言)作为标准通信语言。

　　它支持Web服务标准。

　　它支持消息传递(同步、异步、点对点、发布-订阅)。