主题是：激活SOA的全部潜力还需五年。但是，访谈中隐藏着一个简单的论断，即使用企业服务总线（Enterprise Service Bus，ESB）是实现ESB全部潜力4步中的第三步。Don Rippert模型中的步骤如下：
使用XML，以更标准的方式使用应用程序接口。
捕获一些业务过程，并将它们转化成为Web服务。
引入并全面使用企业服务总线。
产生业务过程执行语言（Business Process Execution Language，BPEL），它可由业务过程建模工具完成。BPEL可以改变应用程序的行为，而无需修改软件。
Rippert先生在采访中表示，尽管很多组织拥有ESB，但是它并没有被完全利用。他进一步的表示，大多数公司仍处于阶段1。与这个ESB所处位置的论断相对比的是，，其发表于近期面向服务架构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有如下特性：
它是面向服务架构的实现。
它通常是操作系统和编程语言无关的；它应能在Java和.Net应用程序之间工作。
它使用XML（可扩展标识语言）作为标准通信语言。
它支持Web服务标准。
它支持消息传递（同步、异步、点对点、发布-订阅）。
它包含基于标准的适配器（如J2C/JCA），用于集成传统系统。
它包含对服务编制（orchestration）和编排（choreography）的支持。
它包含智能、基于内容的路由服务（itenerary路由）。
它包含标准安全模型，用于ESB的认证、授权和审计。
它包含转换服务（通常是使用XSLT），在发送应用和接收应用之间转换格式，简化数据格式和值的转换。
它包含基于模式（schema）的验证，用于发送和接收消息。
它可以统一应用业务规则，充实其它来源的消息，分拆和组合多个消息，以及处理异常。
它可以条件路由，或基于非集中策略的消息转换，即不需要集中规则引擎。
它可监视不同SLA（服务级别合约）的消息响应门限，以及在SLA中定义的其它特性。
它（常常）简化“服务类别”，向更高或更低优先级用户做出适当的响应。
它支持队列，在应用临时不可用时用来保存消息。
它由（地理）分布式环境中的选择性部署应用适配器组成。
维基百科的定义容许“ESB精确定义的变种”。
Manes女士和Rippert先生似乎都同意ESB是有用的，并代表项目后期用于部署SOA的功能集合。维基百科的定义可以作为讨论的起点，主题是关于如何定义这一有用技术。
在随后的讨论中，请关注ESB的定义，而非本文中引证的业界专家的观点。