Un ESB, letteralmente bus di servizio enterprise, è un pattern architetturale in base al quale un componente software centralizzato esegue integrazioni tra le diverse applicazioni.  Effettua trasformazioni di modelli di dati, gestisce la connettività, esegue l'instradamento messaggi, converte i protocolli di comunicazione e potenzialmente gestisce la composizione di multiple richieste. L'ESB può rendere disponibili queste integrazioni e trasformazioni come interfaccia di servizio per nuove applicazioni. 

Il modello ESB viene in genere implementato attraverso un runtime di integrazione e un set di strumenti progettati ad hoc (ovvero il prodotto esb) per assicurare la migliore produttività possibile.

L'ESB è un componente essenziale della SOA, Service-Oriented Architecture, architettura software affermatasi alla fine degli anni '90. Essa definisce un modo per rendere riutilizzabili i componenti software mediante interfacce di servizio. In genere vengono utilizzate interfacce standard (ad esempio servizi Web) per poter rapidamente incorporare i servizi in nuove applicazioni senza doverne duplicare le funzionalità .

Ogni servizio in ambito  SOA incorpora codice e dati richiesti per eseguire una funzione di business completa e discreta (ad es. controllare il credito di un cliente, calcolare la rata mensile di un prestito o elaborare una richiesta di mutuo). Le interfacce di servizio forniscono un legame debole, nel senso che possono essere chiamate con poca o nessuna conoscenza del modo in cui il servizio è implementato a livello sottostante, riducendo le dipendenze tra le applicazioni. Al di là dell'interfaccia di servizio, le applicazioni possono essere scritte in Java, Microsoft .Net, Cobol o in qualsiasi altro linguaggio di programmazione, fornite come pacchetti di applicazioni enterprise da un fornitore (ad es. SAP), applicazioni SaaS (ad es. Salesforce CRM) o ottenute come applicazioni open source.  

Le interfacce di servizio sono spesso definite utilizzando il linguaggio WSDL (Web Service Definition Language), una struttura di tag standard basata su xml (Extensible Markup Language).  I servizi vengono esposti utilizzando protocolli di rete standard, ad esempio SOAP (Simple Object Access Protocol)/HTTP o JSON/HTTP, per inviare richieste di lettura o modificare i dati. La governance dei servizi controlla il ciclo di vita dello sviluppo e nella fase appropriata i servizi vengono pubblicati in un registro in modo che gli sviluppatori li possano trovare e riutilizzare rapidamente per assemblare nuove applicazioni o processi di business.

Pur potendo essere creati da zero, i servizi spesso vengono generati esponendo funzioni di sistemi legacy di registrazione. I business possono decidere di anteporre ai sistemi legacy un'interfaccia di servizio basata su standard, utilizzare l'ESB per connettersi direttamente al sistema legacy con un adattatore o un connettore oppure lasciare che l'applicazione fornisca la propria api. In ogni caso, l'ESB scherma la nuova applicazione dall'interfaccia legacy. Esegue la trasformazione e l'instradamento necessari per connettersi al servizio del sistema legacy.

È possibile implementare una SOA senza architettura ESB, ma questo equivarrebbe a disporre di un insieme disarticolato di servizi. Ogni proprietario dell'applicazione sarebbe costretto a connettersi direttamente al servizio di cui ha bisogno ed eseguire le necessarie trasformazioni dei dati per adeguarsi a ciascuna delle interfacce di servizio. Questa soluzione è alquanto laboriosa (anche se le interfacce sono riutilizzabili) e comporta ulteriori complicazioni nella successiva manutenzione, poiché ogni connessione è di tipo punto a punto.

In teoria, un ESB centralizzato offre la possibilità di standardizzare, e semplificare notevolmente, la comunicazione, la messaggistica e l'integrazione tra i diversi servizi di un'azienda. I costi hardware e software possono essere condivisi, disponendo i server secondo necessità per l'utilizzo combinato, fornendo così una soluzione centralizzata scalabile.  Un singolo gruppo di specialisti può essere incaricato dello sviluppo e della manutenzione delle integrazioni (e, se necessario, opportunamente formato in materia).

Le applicazioni software si connettono all'ESB ("colloquiano" con esso) e lasciano a quest'ultimo il compito di trasformare i protocolli, instradare i messaggi e trasformarli nei formati dati richiesti, fornendo l'interoperabilità necessaria per l'esecuzione delle transazioni. L'approccio architettonico dell'ESB supporta scenari per l'integrazione delle applicazioni, l'integrazione dei dati e l'automazione dei processi di business basata sull'orchestrazione dei servizi.  In questo modo gli sviluppatori possono dedicare molto meno tempo all'integrazione e molto più alla consegna e al miglioramento delle proprie applicazioni. E la capacità di riutilizzare tali integrazioni da un progetto all'altro offre il potenziale per incrementi di produttività e risparmi ancora maggiori a valle.

Ma nonostante l'ESB sia stato implementato con successo in numerose organizzazioni, in molte altre ha finito per essere percepito come il fatidico collo di bottiglia. Apportare modifiche o potenziamenti a un'integrazione può destabilizzare altri che hanno utilizzato quella stessa integrazione. Gli aggiornamenti al middleware ESB ha spesso influito su integrazioni esistenti, rendendo necessari test consistenti per l'esecuzione di qualsiasi aggiornamento. Essendo l'ESB gestito centralmente, i gruppi dedicati alle applicazioni si sono presto trovati a far la fila per le proprie integrazioni. Con il crescere del numero di integrazioni, l'implementazione dell'High Availability e del disaster recovery per i server ESB è diventata più costosa. Inoltre, il progetto ESB, essendo trasversale alle aziende, si è dimostrato difficile da finanziare, rendendo queste sfide tecniche ancora più difficili da risolvere.

In ultima analisi, le complessità legate alla manutenzione, all'aggiornamento e alla scalabilità di un ESB centralizzato si sono rivelate così impegnative e costose da ritardare quegli aumenti di produttività che proprio l'ESB, e la SOA, avrebbero dovuto realizzare, frustrando le aspettative dei gruppi, nei vari settori di attività, che avevano sperato in un ritmo più sostenuto di innovazione.

Per un approfondimento sull’ascesa e la caduta dell’ESB, leggi “The fate of the ESB” (Il destino dell’ESB).

L'architettura basata su microservizi consente di suddividere i componenti interni di una singola applicazione in elementi più piccoli che possono essere modificati, scalati e amministrati in modo indipendente. I microservizi hanno cominciato a farsi conoscere e apprezzare con l’avvento della virtualizzazione, del cloud computing, delle pratiche di sviluppo agile e della metodologia DevOps. In tali contesti, i microservizi offrono i seguenti vantaggi:

• Maggiore agilità e produttività nella fase di sviluppo consentendo agli sviluppatori di incorporare nuove tecnologie in una parte dell'applicazione senza toccare o "aggiornare" il resto. 
• Scalabilità più semplice e conveniente grazie alla possibilità di modulare qualsiasi componente a prescindere dalle altre, per rispondere in modo più rapido possibile alle esigenze del carico di lavoro e utilizzare con maggiore efficienza le risorse di elaborazione.
• Maggiore resilienza, poiché il malfunzionamento di una parte non influisce sulle altre e ogni microservizio può soddisfare i propri requisiti di disponibilità senza vincolare gli altri componenti a requisiti di "massima disponibilità comune".

La stessa finezza di dettaglio che i microservizi apportano alla progettazione delle applicazioni può essere riportata all'integrazione, con vantaggi analoghi. Questa è l'idea alla base dell'integrazione agile, che suddivide l'ESB in componenti di integrazione minuziosi e decentralizzati, senza interdipendenze, che i singoli gruppi dedicati alle applicazioni possono possedere e gestire autonomamente.