Un ESB, o bus de servicio empresarial, es un patrón arquitectónico mediante el cual un componente de software centralizado realiza integraciones entre aplicaciones.  Realiza transformaciones de modelos de datos, maneja la conectividad, realiza el enrutamiento de mensajes, convierte protocolos de comunicación y potencialmente administra la composición de múltiples solicitudes. La ESB puede hacer que estas integraciones y transformaciones estén disponibles como interfaz de servicio para su reutilización por nuevas aplicaciones. 

El patrón ESB suele implementarse utilizando un tiempo de ejecución y un conjunto de herramientas de integración especialmente diseñados (es decir, un producto esb) que garantizan la mejor productividad posible.

Una ESB es un componente esencial de SOA, o arquitectura orientada al servicio, una arquitectura de software que surgió a finales de los años . SOA define una forma de hacer reutilizables los componentes de software a través de interfaces de servicio. Estos servicios suelen utilizar interfaces estándar (es decir, servicios web) de tal manera que se pueden incorporar rápidamente en nuevas aplicaciones sin tener que duplicar la funcionalidad realizada por el servicio en nuevas aplicaciones.

Cada servicio en un SOA incorpora el código y los datos necesarios para ejecutar una función de negocio completa y discreta (p. ej. verificar el crédito de un cliente, calcular el pago mensual de un préstamo o procesar una solicitud de hipoteca). Las interfaces de servicio proporcionan un acoplamiento flexible, lo que significa que pueden llamarse con poco o ningún conocimiento sobre cómo se implementa el servicio debajo, reduciendo las dependencias entre aplicaciones. Las aplicaciones detrás de la interfaz de servicio pueden escribirse en Java, Microsoft .Net, Cobol o cualquier otro lenguaje de programación, suministradas como aplicaciones empresariales empaquetadas por un proveedor (por ejemplo, SAP), aplicaciones SaaS (por ejemplo, Salesforce CRM) u obtenidas como aplicaciones de código abierto.  

Las interfaces de servicio se definen con frecuencia mediante el Lenguaje de Definición de Servicios Web (WSDL), que es una estructura de etiquetas estándar basada en xml (lenguaje de marcado extensible).  Los servicios se exponen mediante protocolos de red estándar, como SOAP (protocolo de acceso a objetos simples) /HTTP o JSON/HTTPS, para enviar solicitudes de lectura o cambio de datos. La gobernanza del servicio controla el ciclo de vida para el desarrollo y, en la etapa adecuada, los servicios se publican en un registro que permite a los desarrolladores encontrarlos rápidamente y reutilizarlos para ensamblar nuevas aplicaciones o procesos comerciales.

Los servicios se pueden crear desde cero, pero a menudo se crean exponiendo funciones de sistemas de registro heredados. Las empresas pueden optar por proporcionar una interfaz de servicio basada en estándares frente a los sistemas heredados, usar el ESB para conectarse directamente al sistema heredado a través de un adaptador o conector, o la aplicación puede proporcionar su propia api. En cualquier caso, el bus de servicio empresarial protege la nueva aplicación de la interfaz heredada. Un ESB realiza la transformación y el enrutamiento necesarios para conectarse al servicio del sistema heredado.

Es posible implementar un SOA sin una arquitectura ESB, pero esto sería equivalente a tener un montón de servicios. Cada propietario de la aplicación tendría que conectarse directamente con cualquier servicio que necesite y realizar las transformaciones de datos necesarias para satisfacer cada una de las interfaces de servicio. Esto supone mucho trabajo (aunque las interfaces sean reutilizables) y crea importantes problemas de mantenimiento en el futuro, ya que cada conexión es punto a punto.

En teoría, un ESB centralizado ofrece el potencial de estandarizar (y simplificar drásticamente) la comunicación, la mensajería y la integración entre servicios en toda la empresa. Los costos de hardware y software se pueden compartir, aprovisionando los servidores según sea necesario para el uso combinado, proporcionando una solución centralizada escalable.  Se puede encargar (y, si es necesario, capacitar) a un único equipo de especialistas el desarrollo y mantenimiento de las integraciones.

Las aplicaciones de software simplemente se conectan ("hablan") con el ESB y dejan que éste transforme los protocolos, enrute los mensajes y los transforme a los formatos de datos necesarios para proporcionar la interoperabilidad necesaria para ejecutar las transacciones. El enfoque arquitectónico del bus de servicio empresarial admite escenarios para la integración de aplicaciones, la integración de datos y la automatización del estilo de orquestación de servicios de los procesos de negocio.  Esto permite a los desarrolladores pasar mucho menos tiempo integrando y mucho más tiempo concentrándose en entregar y mejorar sus aplicaciones. Y la capacidad de reutilizar estas integraciones de un proyecto a otro ofreció el potencial de ganancias de productividad y ahorros aún mayores en la fase descendente.

Sin embargo, mientras que en muchas organizaciones el ESB se desplegó con éxito, en otras muchas se llegó a considerar que el ESB era el cuello de botella. Hacer cambios o mejoras en una integración podría desestabilizar a otros que usaron esa misma integración. Las actualizaciones del middleware de ESB a menudo afectaban a las integraciones existentes, por lo que se requerían pruebas significativas para realizar cualquier actualización. Debido a que la ESB se administraba centralmente, los equipos de aplicaciones pronto se encontraron esperando en la fila para sus integraciones. A medida que crecía el volumen de integraciones, la implementación de alta disponibilidad y recuperación ante desastres para los servidores ESB se hizo más costosa. Y como proyecto multiempresarial, el ESB resultó difícil de financiar, haciendo que estos desafíos técnicos sean mucho más difíciles de resolver.

En última instancia, los desafíos de mantener, actualizar y escalar un ESB centralizado resultaron tan abrumadores y costosos que el ESB a menudo retrasaba las mismas ganancias de productividad que él, y la SOA, estaban destinados a producir, frustrando a los equipos de línea de negocios que anticipaban un mayor ritmo de innovación.

Para profundizar en el ascenso y la caída del ESB, lea "El destino del ESB ".

La arquitectura de microservicios permite dividir el funcionamiento interno de una aplicación en pequeñas partes que pueden modificarse, escalarse y administrarse de forma independiente. Los microservicios surgieron y ganaron fuerza con el aumento de la virtualización, la computación en la nube, las prácticas de desarrollo ágil y DevOps. En estos contextos, los microservicios ofrecen lo siguiente:

• Se mejoró la agilidad y la productividad de los desarrolladores al permitirles incorporar nuevas tecnologías en una parte de una aplicación sin tocar o "ponerse al día" con el resto de la aplicación. 
• Escalabilidad más simple y rentable al permitir que cualquier componente se escale independientemente de los demás, para responder con la mayor rapidez posible a las demandas de carga de trabajo y hacer un uso más eficiente de los recursos informáticos.
• Mayor resiliencia, porque el fracaso de un componente no afecta a los demás, y cada microservicio puede cumplir con sus propios requisitos de disponibilidad sin poner en riesgo a los demás componentes con un requisito de "mayor disponibilidad común".

La misma granularidad que los microservicios aportan al diseño de aplicaciones puede aplicarse a la integración, con beneficios similares. Esta es la idea detrás de la integración ágil, que divide el ESB en componentes de integración descentralizados y de grano fino, sin interdependencias, que los equipos de aplicaciones individuales pueden poseer y administrar ellos mismos.