ESB , atau bus layanan perusahaan, adalah pola arsitektur dengan komponen perangkat lunak terpusat melakukan integrasi antar-aplikasi.  ESB melakukan transformasi model data, menangani konektivitas, melakukan perutean pesan, mengubah protokol komunikasi, dan berpotensi mengelola komposisi beberapa permintaan. ESB dapat membuat integrasi dan transformasi ini tersedia sebagai antarmuka layanan untuk digunakan kembali oleh aplikasi baru. 

Pola ESB biasanya diimplementasikan menggunakan runtime integrasi dan toolset yang dirancang khusus (yaitu, produk esb) yang memastikan produktivitas terbaik.

ESB adalah  komponen penting dari SOA, atau arsitektur berorientasi layanan, sebuah arsitektur perangkat lunak yang muncul di akhir tahun 1990-an. SOA mendefinisikan cara untuk membuat komponen perangkat lunak dapat digunakan kembali melalui antarmuka layanan. Layanan ini biasanya menggunakan antarmuka standar (yaitu, layanan web) sedemikian rupa sehingga dapat dengan cepat dimasukkan ke dalam aplikasi baru tanpa harus menduplikasi fungsionalitas yang dilakukan oleh layanan dalam aplikasi baru.

Setiap layanan dalam SOA mewujudkan kode dan data yang diperlukan untuk menjalankan fungsi bisnis yang lengkap dan terpisah (misalnya memeriksa kredit nasabah, menghitung pembayaran pinjaman bulanan, atau memproses aplikasi hipotek). Antarmuka layanan menyediakan kopling longgar, yang berarti mereka dapat dipanggil dengan sedikit atau tanpa pengetahuan tentang bagaimana layanan diimplementasikan di bawahnya, sehingga mengurangi ketergantungan antar-aplikasi. Aplikasi di balik antarmuka layanan dapat ditulis dalam Java, Microsoft .Net, Cobol, atau bahasa pemrograman lainnya, yang disediakan sebagai aplikasi perusahaan yang dipaketkan oleh vendor (misalnya SAP), aplikasi SaaS (misalnya Salesforce CRM), atau diperoleh sebagai aplikasi sumber terbuka.  

Antarmuka layanan sering kali didefinisikan menggunakan Web Service Definition Language (WSDL) yang merupakan struktur tag standar berdasarkan xml (bahasa markup yang dapat diperluas).  Layanan diekspos menggunakan protokol jaringan standar, seperti SOAP (protokol akses objek sederhana)/HTTP atau JSON/HTTP, untuk mengirim permintaan membaca atau mengubah data. Tata kelola layanan mengontrol siklus proses pengembangan dan pada tahap yang tepat, layanan dipublikasikan di registri yang memungkinkan pengembang dengan cepat menemukannya dan menggunakannya kembali untuk merakit aplikasi atau proses bisnis baru.

Layanan dapat dibangun dari awal tetapi sering kali dibuat dengan mengekspos fungsi dari sistem pencatatan lama. Bisnis dapat memilih untuk menyediakan antarmuka layanan berbasis standar di depan sistem lama, menggunakan ESB untuk terhubung langsung ke sistem lama melalui adaptor atau konektor, atau aplikasi dapat menyediakan api-nya sendiri. Bagaimanapun, bus layanan perusahaan melindungi aplikasi baru dari antarmuka lama. ESB melakukan transformasi dan perutean yang diperlukan untuk terhubung ke layanan sistem lama.

SOA dapat diimplementasikan tanpa arsitektur ESB, tetapi ini sama saja dengan hanya memiliki sekumpulan layanan. Setiap pemilik aplikasi perlu terhubung langsung ke layanan apa pun yang dibutuhkan dan melakukan transformasi data yang diperlukan untuk memenuhi setiap antarmuka layanan. Ini merupakan pekerjaan yang banyak (bahkan jika antarmuka dapat digunakan kembali) dan menciptakan tantangan pemeliharaan yang signifikan di masa depan karena setiap koneksi adalah titik ke titik.

Secara teori, ESB terpusat menawarkan potensi untuk menstandarisasi, dan secara dramatis menyederhanakan, komunikasi, pengiriman pesan, dan integrasi antara layanan di seluruh perusahaan. Biaya perangkat keras dan perangkat lunak dapat dibagi, menyediakan server sesuai kebutuhan untuk penggunaan gabungan, memberikan solusi terpusat yang dapat diskalakan.  Satu tim spesialis dapat ditugaskan (dan, jika perlu, dilatih) untuk mengembangkan dan memelihara integrasi.

Aplikasi perangkat lunak cukup terhubung ('berbicara') ke ESB dan menyerahkannya kepada ESB untuk mengubah protokol, merutekan pesan, dan mengubah ke dalam format data yang diperlukan untuk menyediakan interoperabilitas agar transaksi dapat dilakukan. Pendekatan arsitektur bus layanan perusahaan mendukung skenario untuk integrasi aplikasi, integrasi data, dan otomatisasi gaya orkestrasi layanan proses bisnis.  Hal ini memungkinkan para pengembang menghabiskan lebih sedikit waktu untuk mengintegrasikan dan lebih banyak waktu untuk berfokus pada penyampaian dan peningkatan aplikasi mereka. Dan kemampuan untuk menggunakan kembali integrasi ini dari satu proyek ke proyek berikutnya menawarkan potensi peningkatan produktivitas dan penghematan yang lebih besar lagi di bagian hilir.

Namun, meskipun ESB berhasil diterapkan di banyak organisasi, di banyak organisasi lain ESB dianggap sebagai penghambat. Membuat perubahan atau peningkatan pada satu integrasi dapat mengacaukan integrasi lain yang menggunakan integrasi yang sama. Pembaruan pada middleware ESB sering kali berdampak pada integrasi yang sudah ada, sehingga diperlukan pengujian yang signifikan untuk melakukan pembaruan. Karena ESB dikelola secara terpusat, tim aplikasi segera mendapati diri mereka mengantre untuk melakukan integrasi. Seiring bertambahnya volume integrasi, penerapan ketersediaan tinggi dan pemulihan bencana untuk server ESB menjadi lebih mahal. Dan sebagai proyek lintas perusahaan, ESB terbukti sulit didanai, sehingga tantangan teknis ini menjadi lebih sulit untuk diselesaikan.

Pada akhirnya, tantangan dalam memelihara, memperbarui, dan menskalakan ESB terpusat terbukti sangat berat dan mahal sehingga ESB sering kali menunda peningkatan produktivitas yang diharapkan, dan SOA, sehingga membuat frustasi tim bisnis yang mengharapkan kecepatan inovasi yang lebih tinggi.

Untuk mendalami naik turunnya ESB, baca "Nasib ESB."

Arsitektur layanan mikro memungkinkan bagian dalam dari satu aplikasi dipecah menjadi beberapa bagian kecil yang dapat diubah, diskalakan, dan dikelola secara independen. Layanan mikro muncul dan semakin populer seiring dengan munculnya virtualisasi, komputasi cloud, praktik pengembangan Agile, dan DevOps. Dalam konteks ini, layanan mikro menawarkan hal berikut:

• Meningkatkan kelincahan dan produktivitas pengembang dengan memungkinkan pengembang memasukkan teknologi baru ke dalam satu bagian aplikasi tanpa menyentuh atau 'mengejar' bagian aplikasi lainnya. 
• Skalabilitas yang lebih sederhana dan lebih hemat biaya dengan memungkinkan setiap komponen diskalakan secara independen dari komponen lainnya, untuk respons tercepat terhadap permintaan beban kerja dan penggunaan sumber daya komputasi yang paling efisien.
• Ketahanan yang lebih besar, karena kegagalan satu komponen tidak berdampak pada komponen lainnya, dan setiap layanan mikro dapat bekerja sesuai dengan kebutuhan ketersediaannya sendiri tanpa mempertaruhkan komponen lain untuk memenuhi kebutuhan 'ketersediaan umum terbesar'.

Perincian yang sama yang dibawa oleh layanan mikro ke desain aplikasi dapat dibawa ke integrasi, dengan manfaat yang sama. Inilah ide di balik integrasi tangkas, yang memecah ESB menjadi komponen integrasi terdesentralisasi yang lancar, tanpa saling bergantung, yang bisa dimiliki dan dikelola sendiri oleh masing-masing tim aplikasi.