Belajar System Analyst - System Integration Analysis

#Pendahuluan

Setelah di episode 12 studi kelayakan TokoKita dinyatakan layak dengan payback ±20 bulan, kita masuk ke wilayah yang paling sering menggagalkan proyek integrasi sistem baru: hubungannya dengan sistem lain. Episode ini membahas system integration analysis — inventaris titik integrasi, pola komunikasi, dan kontrak data.

Mengapa integrasi layak episode tersendiri? Karena hampir tak ada sistem bisnis modern yang berdiri sendiri. POS TokoKita harus bicara dengan gateway QRIS agar pembayaran digital jalan, dengan sistem akuntansi Mbak Dwi supaya rekap pajak otomatis, kelak dengan supplier untuk auto-reorder. Setiap sambungan adalah permukaan kegagalan baru: timeout, format beda, versi API berubah diam-diam. Integrasi yang tidak dianalisis sejak desain akan menjadi utang teknis termahal dalam hidup proyek.

#Inventaris Titik Integrasi

Langkah pertama: daftar lengkap siapa-bicara-dengan-siapa, beserta arah data dan frekuensinya:

INT-01 POS Kasir -> QRIS Gateway
     Arah: keluar (request QR) + masuk (status callback)
     Frekuensi: per transaksi QRIS (~40% transaksi)
     Data: nomor struk, nominal, status bayar
 
INT-02 Server Pusat -> Sistem Akuntansi (jurnal)
     Arah: keluar (batch)
     Frekuensi: harian jam 23.30
     Data: rekap penjualan per metode bayar, retur,
           penyesuaian stok bernilai
 
INT-03 Master Produk <- Daftar Harga Supplier (masuk)
     Arah: masuk (file CSV mingguan)
     Frekuensi: mingguan
     Data: SKU supplier, harga beli baru, status item
 
INT-04 Server Pusat -> Dashboard Owner
     Arah: internal (API baca)
     Frekuensi: on-demand realtime
     Data: agregat penjualan & stok lintas cabang

Format inventaris ini memaksa pertanyaan yang sering terlewat: data mengalir arah mana? Sekali atau berkala? Siapa pemilik sumber kebenaran tiap field? Untuk harga produk misalnya — INT-03 membawa harga beli baru dari supplier, tapi keputusan harga jual tetap milik modul pusat (decision log DL-03); dua aliran yang menyentuh entitas sama dengan kewenangan berbeda.

#Pola Integrasi

Tiga pola dasar yang mencakup mayoritas kebutuhan:

Pemilihan pola bukan selera, melainkan fungsi karakteristik data:

• Pembayaran QRIS harus sinkron di awal (pelanggan menunggu QR), lalu webhook untuk konfirmasi akhir — kombinasi dua pola dalam satu alur.
• Jurnal akuntansi cocok batch harian: Mbak Dwi bekerja per hari buku, tidak butuh detik.
• Harga supplier cocok file mingguan: sumbernya sendiri ritel dan manual.

#Kontrak Data & Contoh Alur QRIS

Integrasi hanya aman jika kontraknya eksplisit: endpoint, format payload, kode error, aturan retry, dan versi. Untuk INT-01, kontrak minimalnya:

{
  "event": "payment.success",
  "external_ref": "QRIS-TK-DPS-20260816-000123",
  "nomor_struk": "DPS-20260816-0047",
  "amount": 79500,
  "paid_at": "2026-08-16T14:07:33+08:00",
  "issuer": "GOPAY",
  "signature": "sha256=9f2c..."
}

Detail kontrak yang menentukan ketahanan:

1. Idempotency key — external_ref unik; kalau gateway mengirim callback dua kali (dan itu akan terjadi), server mengenali duplikat dan tidak mencatat dua kali.
2. Verifikasi signature — payload bisa dipalsukan; verifikasi HMAC sebelum percaya.
3. Perilaku timeout — minta QR maksimal 10 detik; gagal → kasir ditawari tunai, transaksi QR dibatalkan bersih (sesuai activity diagram episode 6).
4. Rekonsiliasi harian — meski semua mekanisme benar, jalankan job pencocokan mutasi gateway vs transaksi lokal tiap malam; selisih masuk daftar investigasi.

Prinsip umumnya: integrasi dirancang dengan asumsi semua bisa gagal — jaringan, vendor, format, urutan. Desain yang sukses adalah yang punya jalur pemulihan tertulis untuk tiap mode gagalan, bukan yang berharap tidak pernah gagal.

#Praktik: Integration Map TokoKita

Semua temuan disatukan ke satu gambar peta integrasi — artefak wajib di folder 03-design/:

Peta seperti ini dikonsumsi tiga audiens sekaligus: owner melihat lingkup kerja sama pihak ketiga, developer melihat komponen yang harus dibuat, dan QA melihat daftar skenario uji integrasi. Tiap panah merujuk ID inventaris sehingga detail kontrak tinggal dibuka.

Untuk tiap interface di map, lengkapi tabel spesifikasi singkat:

Kolom terakhir penting secara politis juga: siapa penjaga kontrak. Saat vendor mengubah payload tanpa pemberitahuan, ada nama yang bertanggung jawab mendeteksi dan merespons.

#Kesalahan Umum

1. Menunda pikiran integrasi sampai akhir — "nanti juga sambungkan." Integrasi memengaruhi model data (butuh external_ref? status_sync?) sejak hari pertama; ditambah belakangan = operasi jantung terbuka.
2. Uji coba hanya di sandbox ideal — sandbox vendor jarang mensimulasikan timeout, callback ganda, dan payload rusak. Tulis skenario jelek secara sengaja di test plan.
3. Tanpa versioning kontrak — field ditambah/diubah diam-diam oleh salah satu pihak dan sistem lawan tumbang. Sepakati aturan perubahan: field baru boleh, field lama dihapus butuh periode deprekasi.
4. Lupa monitoring — integrasi mati diam-diam semalam dan baru ketahuan sebulan kemudian dari keluhan. Tiap interface butuh health check + alert, buktinya ada di kolom mode gagal di atas.
5. Hardcode asumsi vendor — menempelkan detail perilaku vendor di banyak tempat kode. Bungkus dalam adapter tunggal supaya ganti vendor bukan operasi menyeluruh.

#Penutup

Inti yang harus dibawa pulang:

• Mulai dari inventaris titik integrasi bernomor: arah, frekuensi, data, dan pemilik sumber kebenaran tiap aliran.
• Tiga pola dasar — sinkron, webhook, batch/antrian — dipilih dari toleransi keterlambatan bisnis, bukan selera teknis; satu alur boleh kombinasi (QRIS: sync lalu callback).
• Kontrak data eksplisit: idempotency, signature, timeout/fallback, rekonsiliasi harian — rancang dengan asumsi semua komponen bisa gagal.
• Integration map + tabel interface membuat satu gambar dikonsumsi owner, dev, dan QA; setiap panah punya ID dan penjaga.

Sistem sudah dirancang bisa bicara dengan dunia luarnya — sekarang kita pastikan ia benar-benar bekerja di tangan penggunanya. Di episode 14 selanjutnya kita membahas testing support & UAT: menyusun test scenario dari use case, memfasilitasi sesi UAT dengan kasir sungguhan, dan proses sign-off menuju go-live pilot TokoKita. Pastikan tetap semangat!