10.3 Integrasi: Hidup di Antara Sistem Lain
Setelah opsi dipilih, solusi harus bisa hidup di lingkungan nyata yang penuh sistem lain. Ini adalah momen yang sering diremehkan oleh tim yang terlalu fokus pada fitur internal. Mereka membangun modul rekomendasi yang canggih, lengkap dengan model AI yang terlatih rapi, lalu tersadar bahwa modul itu tidak tahu cara mengambil data customer dari sistem CRM yang sudah berjalan lima tahun. Atau mereka tidak memikirkan bagaimana hasil rekomendasi akan dikirim kembali ke aplikasi mobile yang digunakan oleh sales di lapangan.
Di sinilah integrasi menjadi pekerjaan utama seorang solution architect.
Bayangkan Anda sedang merancang sistem rekomendasi untuk divisi penjualan. Di perusahaan Anda, data customer tersebar di tiga tempat: CRM untuk data profil, sistem transaksi untuk riwayat pembelian, dan data warehouse untuk agregasi. Sistem rekomendasi Anda perlu menarik data dari ketiganya. Tapi tidak semudah itu. CRM hanya menyediakan akses via API dengan rate limit yang ketat. Sistem transaksi adalah sistem legacy yang hanya bisa mengirim file CSV setiap malam. Data warehouse bisa diquery langsung, tapi query berat akan mengganggu laporan bulanan yang sedang berjalan.
Diagram berikut memperlihatkan bagaimana sistem rekomendasi terhubung ke tiga sumber data dengan pola komunikasi yang berbeda.
Anda tidak bisa memaksa semua sistem berbicara dengan cara yang sama. Anda harus merancang bagaimana solusi Anda akan berkomunikasi dengan masing-masing sistem sesuai dengan kemampuan dan keterbatasannya.
Inilah yang disebut integration view dalam solution architecture. Bukan sekadar daftar koneksi, tapi keputusan tentang pola komunikasi: kapan menggunakan API untuk permintaan langsung, kapan menggunakan event untuk memberitahu sistem lain tanpa perlu menunggu jawaban, kapan menggunakan message queue agar beban bisa diatur, dan kapan cukup dengan batch file yang diproses setiap malam.
Setiap pola punya konsekuensi. API memberikan respons langsung tapi membuat sistem Anda bergantung pada ketersediaan sistem lain. Event-driven membuat sistem lebih longgar terhubung, tapi Anda perlu infrastruktur message broker dan mekanisme retry jika event gagal diproses. File transfer sederhana dan murah, tapi Anda harus siap dengan data yang tidak real-time dan kemungkinan konflik jika dua file diupdate di waktu yang sama.
Berikut contoh konfigurasi Kafka topic dalam YAML untuk alur data dari CRM dan sistem transaksi ke sistem rekomendasi:
topics:
- name: customer-updated
partitions: 3
replicationFactor: 2
config:
cleanup.policy: compact
min.insync.replicas: 2
- name: transaction-created
partitions: 5
replicationFactor: 2
config:
retention.ms: 604800000
cleanup.policy: delete
Seorang arsitek yang baik tidak memilih pola integrasi berdasarkan tren teknologi. Ia memilih berdasarkan karakteristik data dan kebutuhan bisnis. Data customer yang harus selalu terkini? API. Data agregat yang cukup diupdate setiap jam? Batch. Notifikasi ketika ada produk baru? Event.
Lalu ada partner interface. Ini adalah integrasi dengan sistem di luar kendali Anda. Misalnya, jika sistem rekomendasi Anda perlu menampilkan produk dari supplier eksternal, Anda harus merancang bagaimana data mereka masuk, bagaimana validasi dilakukan, dan bagaimana jika format data berubah tanpa pemberitahuan. Partner interface membutuhkan lapisan adaptor yang bisa menyerap perubahan dari luar tanpa mengganggu inti solusi Anda.
Yang sering luput adalah documentation untuk integrasi. Setiap titik koneksi harus dicatat: endpoint, format data, jadwal sinkronisasi, error handling, dan kontak pemilik sistem. Tanpa dokumentasi ini, tim operasi akan kebingungan saat integrasi bermasalah di tengah malam.
AI bisa membantu di sini. Anda bisa meminta AI assistant untuk merangkum pola integrasi dari sistem-sistem yang sudah ada di perusahaan, atau menyusun draft dokumentasi integrasi berdasarkan konfigurasi yang Anda berikan. Tapi keputusan tentang pola komunikasi tetap milik Anda. AI tidak tahu bahwa sistem transaksi legacy hanya bisa diakses via file transfer pada jam tertentu.
Setelah integrasi dirancang, pertanyaan berikutnya adalah tentang data itu sendiri. Siapa pemiliknya? Bentuknya bagaimana? Ke mana alirannya? Inilah yang akan kita bahas setelah ini.