理论上，集中式 ESB 可以实现标准化并显著简化整个企业服务之间的通信、消息传递和集成。硬件和软件成本可以分摊，从而根据组合使用的需要配置服务器，提供可扩展的集中式解决方案。可以指派一个专家团队（并在必要时进行培训）来开发和维护集成。

软件应用程序只需连接（“对话”）ESB，然后将其交给 ESB 来转换协议、路由消息并根据需要转换为数据格式，从而提供执行事务所需的互操作性。企业服务总线 (ESB) 架构方法支持应用程序集成、数据集成和业务流程的服务编排方式自动化场景。这使得开发人员能够花费更少的时间进行集成，而将更多的时间专注于交付和改进应用程序。如果能够在一个项目切换到下一个项目时重复使用这些集成，则有可能进一步提高工作效率并节省下游成本。

但是，尽管 ESB 已在许多组织中成功部署，但在许多其他组织中，ESB 却被视为瓶颈。对一种集成进行更改或增强可能会破坏使用同一集成的其他人的稳定性。ESB 中间件的更新通常会影响现有集成，因此执行任何更新都需要进行大量测试。由于 ESB 是集中管理的，应用程序团队很快发现自己在排队等待集成。随着集成量的增长，为 ESB 服务器实现高可用性和灾难恢复的成本变得越来越高。作为一个跨企业项目，ESB 已证实很难获得资金支持，因此更加难以解决这些技术挑战。

最终，维护、更新和扩展集中式 ESB 的挑战已证实非常艰巨和昂贵，因此 ESB 经常延迟它和 SOA 本来计划获得的效率增幅，这让期望加快创新步伐的业务团队感到沮丧。

要更深入地了解 ESB 的兴衰史，请阅读“ESB 的命运”。