SOA Architecture

Bayangkan Anda bekerja di perusahaan yang sudah beroperasi lebih dari sepuluh tahun. Selama itu, tim demi tim dibentuk, aplikasi demi aplikasi dibuat. Ada sistem CRM yang dibangun tim sales, sistem ERP yang dibeli dari vendor, aplikasi web untuk customer yang dikerjakan tim digital, dan beberapa database warisan yang isinya data pelanggan dari era sebelumnya.

Sekarang, Anda mendapat tugas baru: membuat fitur yang butuh data dari tiga sistem berbeda sekaligus. Data customer dari database lama, status pesanan dari ERP, dan riwayat interaksi dari CRM. Setiap sistem punya cara akses sendiri, format data sendiri, dan tim yang menjaga masing-masing. Tidak ada satu pun yang saling bicara secara langsung.

Tim Anda mulai menulis kode yang langsung terhubung ke database lama, memanggil API ERP, dan scraping layar CRM. Dalam beberapa minggu, koneksi itu berhasil. Tapi masalah baru muncul: setiap kali struktur data berubah di salah satu sistem, kode Anda ikut rusak. Setiap kali tim lain mengupdate sistem mereka, Anda harus mengecek ulang apakah koneksi masih jalan. Yang lebih parah, tim lain mulai melakukan hal yang sama—mereka juga membuat koneksi langsung ke sistem yang sama, dengan cara yang berbeda-beda.

Perusahaan Anda mulai memiliki banyak titik integrasi yang kacau, duplikasi logika bisnis di mana-mana, dan tidak ada satu pun yang bisa menjamin data konsisten antar sistem.

Masalah yang Diselesaikan SOA

Situasi di atas adalah alasan mengapa pola Service-Oriented Architecture atau SOA lahir. Masalah intinya bukan pada teknologi, tapi pada bagaimana kemampuan bisnis diekspos dan digunakan kembali antar sistem.

Di perusahaan besar, setiap sistem punya data dan logika bisnis sendiri. Tapi banyak proses bisnis yang butuh koordinasi antar sistem. Tanpa pola yang jelas, setiap tim akan membuat jalur integrasi sendiri-sendiri. Akibatnya, muncul yang disebut spaghetti integration—koneksi yang saling terkait, sulit dilacak, dan rapuh terhadap perubahan.

SOA menjawab masalah ini dengan satu prinsip sederhana: setiap kemampuan bisnis harus diekspos sebagai service yang terstandarisasi, bisa ditemukan, dan bisa dipakai ulang oleh sistem lain. Service bukan sekadar API. Service adalah representasi dari kemampuan bisnis yang punya kontrak jelas, batasan tanggung jawab yang tegas, dan kebijakan sendiri.

Dengan pendekatan ini, tim tidak perlu lagi membuat koneksi langsung ke database atau sistem orang lain. Mereka cukup memanggil service yang sudah terdaftar dan terkelola. Perubahan di sistem internal tidak langsung merusak konsumen service, selama kontrak service tidak berubah.

Komponen Utama dalam Arsitektur SOA

Dalam praktiknya, SOA membagi peran menjadi tiga lapisan besar.

Consumer Tier adalah lapisan paling depan. Di sinilah web app, mobile app, atau sistem mitra eksternal memulai permintaan. Consumer tidak perlu tahu detail teknis di belakang layar. Mereka hanya perlu tahu alamat service dan format kontrak yang disepakati. Komunikasi terjadi lewat protokol standar seperti SOAP atau REST.

Service Tier adalah lapisan paling penting dan paling besar dalam arsitektur ini. Di sinilah semua service hidup dan dikelola. Ada beberapa jenis service yang bekerja bersama:

Service Registry bertugas sebagai direktori. Setiap service yang tersedia harus didaftarkan di sini, lengkap dengan kontrak, alamat, dan kebijakan aksesnya. Consumer bisa menemukan service yang mereka butuhkan lewat registry ini.

Orchestration Service bertugas mengatur urutan pemanggilan beberapa service sekaligus untuk menyelesaikan satu proses bisnis. Misalnya, saat customer memesan produk, orchestration service akan memanggil service inventory, service payment, dan service shipping secara berurutan.

Business Service adalah service yang mewakili kemampuan bisnis inti, seperti service pembayaran, service pengiriman, atau service manajemen pelanggan. Setiap business service punya satu tanggung jawab yang jelas.

Data Service bertugas menyediakan akses ke data dari berbagai sumber. Data service menjadi lapisan abstraksi di atas database dan sistem penyimpanan, sehingga consumer tidak perlu tahu di mana data sebenarnya disimpan.

Security Service menangani otentikasi, otorisasi, dan kebijakan keamanan secara terpusat. Semua permintaan yang masuk ke service tier akan melewati security service terlebih dahulu.

Provider Tier adalah lapisan paling bawah. Di sinilah sistem yang sudah ada seperti legacy system, database, ERP, dan CRM berada. Provider tier bertugas menjalankan logika bisnis dan menyimpan data. Service tier berkomunikasi dengan provider tier melalui adapter yang menyesuaikan protokol dan format data.

Alur Kerja SOA

Alur kerja dalam SOA mengalir dari kiri ke kanan. Consumer mengirim permintaan ke service tier menggunakan protokol standar seperti SOAP atau REST. Permintaan ini biasanya sudah melalui security service untuk verifikasi identitas dan otorisasi.

Setelah sampai di service tier, permintaan bisa langsung ditangani oleh business service yang sesuai, atau diteruskan ke orchestration service jika prosesnya melibatkan beberapa langkah. Orchestration service akan memanggil business service lain secara berurutan atau paralel sesuai kebutuhan.

Jika business service membutuhkan data dari sistem yang sudah ada, ia akan memanggil data service atau langsung berkomunikasi dengan provider tier melalui adapter. Adapter ini penting karena menyembunyikan kompleksitas sistem lama di belakang antarmuka yang seragam.

Setelah proses selesai, hasilnya dikembalikan ke consumer melalui jalur yang sama. Consumer tidak pernah tahu apakah data berasal dari database Oracle lama, ERP SAP, atau CRM Salesforce. Yang mereka tahu hanyalah service merespons sesuai kontrak.

Kapan SOA Cocok Dipakai

SOA bukan pola untuk semua situasi. Pola ini paling cocok untuk perusahaan besar yang memiliki banyak sistem heterogen, terutama yang sudah beroperasi lama dan punya investasi besar di sistem warisan.

Contoh nyata ada di industri perbankan, telekomunikasi, dan pemerintahan. Di perbankan misalnya, ada sistem core banking lama, sistem kartu kredit, sistem mobile banking, dan sistem antrian teller. Masing-masing dibangun di era berbeda dengan teknologi berbeda. SOA memungkinkan semua sistem ini tetap dipakai sambil mengekspos kemampuannya sebagai service yang seragam.

SOA juga cocok untuk integrasi B2B, di mana perusahaan perlu bertukar data dengan mitra bisnis menggunakan standar yang sudah disepakati. Service registry dan kontrak yang ketat membuat integrasi antar perusahaan lebih terkelola.

Selain itu, SOA menjadi pilihan saat perusahaan ingin melakukan modernisasi bertahap. Alih-alih mengganti semua sistem lama sekaligus, perusahaan bisa membungkus sistem lama dengan service, lalu secara perlahan mengganti implementasi di belakang service tanpa mengganggu konsumen.

Trade-off, Batasan, dan Risiko Operasional

SOA membawa kompleksitas yang tidak kecil. Protokol seperti SOAP terkenal berat karena membawa banyak metadata dalam setiap pesan. Ini bisa menambah latency, terutama jika service dipanggil secara berantai.

Manajemen yang terdistribusi menjadi tantangan tersendiri. Service berjalan di banyak tempat, dikelola oleh tim berbeda, dan punya siklus rilis sendiri. Tanpa governance yang kuat, service-service ini bisa tumbuh tidak terkendali. Service registry yang tadinya rapi bisa berubah menjadi tumpukan service yang tidak terawat.

Testing juga lebih sulit dibanding arsitektur monolit. Setiap perubahan di satu service berpotensi mempengaruhi banyak konsumen. Tim harus punya strategi contract testing yang matang, bukan hanya integration testing biasa.

Risiko lain adalah overhead organisasi. SOA membutuhkan tim yang memahami governance service, manajemen kontrak, dan kebijakan keamanan terpusat. Jika tim terlalu kecil atau belum matang, beban ini bisa terasa berat.

Ada juga risiko tight coupling yang ironis. Meskipun SOA dirancang untuk loose coupling, dalam praktiknya banyak tim yang membuat service saling tergantung secara tidak sadar. Orchestration yang terlalu kompleks bisa membuat service tier menjadi bottleneck baru.

Implikasi Praktis untuk Tim Engineering

Jika tim Anda memutuskan menggunakan SOA, ada beberapa hal yang perlu dipersiapkan sejak awal.

Pertama, investasi di service registry dan governance bukan opsional. Tanpa registry yang terkelola dengan baik, service-service akan sulit ditemukan dan mudah tumpang tindih. Tim perlu menetapkan siapa yang bertanggung jawab mendaftarkan service, siapa yang menyetujui perubahan kontrak, dan bagaimana service yang tidak terpakai dinonaktifkan.

Kedua, kontrak service harus diperlakukan sebagai aset yang serius. Setiap perubahan kontrak perlu melalui proses review dan versioning yang jelas. Consumer harus diberi waktu untuk menyesuaikan diri sebelum kontrak lama dihapus.

Ketiga, tim perlu membedakan antara orchestration dan choreography. Orchestration berarti ada satu service yang mengatur urutan pemanggilan. Choreography berarti setiap service tahu apa yang harus dilakukan berdasarkan event yang diterima. Keduanya punya tempat masing-masing, tapi jangan mencampur adukkan tanpa alasan yang jelas.

Keempat, monitoring dan logging harus menjadi prioritas sejak hari pertama. Dengan service yang tersebar, melacak satu permintaan yang melewati beberapa service menjadi sulit tanpa distributed tracing. Tim perlu menyiapkan correlation ID yang dibawa dari consumer hingga ke provider tier.

Kelima, keamanan perlu ditangani secara terpusat. Identity propagation harus berjalan mulus dari consumer ke service tier hingga ke provider tier. Jangan sampai setiap service membuat mekanisme keamanan sendiri-sendiri.

Terakhir, sadari bahwa SOA bukan tujuan akhir. Banyak organisasi yang mulai dengan SOA lalu berevolusi ke microservices ketika kebutuhan skalabilitas dan kemandirian tim semakin tinggi. Tapi untuk perusahaan dengan sistem heterogen dan investasi besar di sistem lama, SOA tetap menjadi jembatan yang masuk akal menuju arsitektur yang lebih modern.