Lima Kesalahan yang Paling Sering Muncul Saat Integrasi Sistem

Proyek integrasi punya pola kegagalan yang mengejutkan konsisten. Teknologinya berbeda-beda, industrinya berbeda-beda, tetapi bentuk masalahnya berulang.

Kabar baiknya, karena polanya berulang, semuanya bisa diantisipasi. Berikut lima yang paling sering muncul, beserta pertanyaan yang seharusnya diajukan di awal.

Satu: menyamakan "sistemnya terhubung" dengan "datanya bisa dipakai"

Ini kesalahan yang paling mahal karena baru terasa di akhir.

Dua sistem bisa saling bertukar data dengan sempurna dan tetap tidak berguna, kalau ternyata keduanya memaknai hal yang sama dengan cara berbeda. Sistem gudang mencatat "selesai" saat barang keluar dari rak. Sistem pengiriman mencatat "selesai" saat barang diterima pelanggan. Keduanya mengirim status "selesai", keduanya benar menurut definisi masing-masing, dan laporan gabungannya salah.

Contoh lain yang sering muncul: satuan yang berbeda (kilogram versus ton), zona waktu yang tidak disebut eksplisit, kode pelanggan yang formatnya berbeda antar sistem, atau tanggal yang di satu sistem berarti tanggal pesan dan di sistem lain berarti tanggal kirim.

Pertanyaan yang mencegahnya: sebelum menulis kode apa pun, minta setiap pihak menuliskan definisi dari sepuluh istilah yang paling sering dipakai. Perbedaan yang muncul di lembar itu adalah pekerjaan sesungguhnya. Lebih murah menyelesaikannya di rapat daripada di produksi.

Dua: mengabaikan apa yang terjadi saat salah satu sisi mati

Dalam demo, semua sistem menyala. Dalam kenyataan, tidak.

Server tujuan sedang diperbarui. Koneksi internet cabang putus dua jam. Sistem mitra membatasi jumlah permintaan dan mulai menolak. Ini bukan kejadian luar biasa; ini hari Selasa biasa.

Integrasi yang dirancang tanpa memikirkan kondisi ini akan kehilangan data secara diam-diam — bentuk kegagalan terburuk, karena tidak ada yang tahu sampai seseorang menyadari laporannya janggal berminggu-minggu kemudian.

Yang perlu ditentukan di awal:

• Kalau pengiriman gagal, apakah dicoba ulang? Berapa kali, dengan jeda berapa lama?
• Kalau tetap gagal setelah semua percobaan, data itu disimpan di mana? Siapa yang diberi tahu?
• Kalau data yang sama terkirim dua kali karena percobaan ulang, apakah sistem tujuan tahan? (Sifat ini disebut idempotent, dan ketiadaannya menghasilkan tagihan ganda atau stok minus.)

Tiga: membangun hubungan langsung antar setiap sistem

Menghubungkan dua sistem itu sederhana. Menghubungkan tiga masih terkendali. Menghubungkan enam sistem secara langsung satu sama lain berarti lima belas jalur yang harus dijaga, didokumentasikan, dan diperbarui setiap kali salah satu sistem berubah.

Jumlah jalur tumbuh jauh lebih cepat daripada jumlah sistem. Inilah alasan banyak perusahaan merasa integrasi "makin lama makin susah diurus" padahal tiap penambahannya terasa kecil.

Alternatifnya adalah menyediakan satu titik tengah — bisa berupa API terpusat, antrian pesan, atau basis data operasional bersama — sehingga setiap sistem hanya bicara dengan satu pihak, bukan dengan semua pihak. Enam sistem berarti enam jalur, bukan lima belas.

Titik tengah ini memang pekerjaan tambahan di awal. Ia terbayar sejak sistem keempat.

Empat: tidak menyiapkan cara melihat apa yang sedang terjadi

Ketika seseorang bertanya "kenapa data pesanan kemarin belum masuk?", tim harus bisa menjawab dalam hitungan menit, bukan hari.

Tanpa pencatatan yang memadai, jawabannya hanya bisa didapat dengan menebak dan mencoba ulang. Ini menghabiskan waktu orang yang paling mahal di tim, berulang kali, untuk pertanyaan yang sebenarnya sederhana.

Yang minimal perlu ada sejak hari pertama:

• Catatan setiap pertukaran data: kapan, dari mana, ke mana, berhasil atau gagal, dan kalau gagal karena apa.
• Cara mencari catatan itu berdasarkan pengenal yang dipakai orang bisnis — nomor pesanan, nomor polisi, kode pelanggan — bukan hanya berdasarkan waktu.
• Pemberitahuan otomatis ketika kegagalan melewati batas wajar. Kalau tidak ada yang memberi tahu, yang memberi tahu adalah pelanggan, dan itu terlambat.

Ini sering dianggap pekerjaan "nanti kalau sempat". Dalam pengalaman lapangan, ia justru bagian yang paling sering menyelamatkan proyek.

Lima: tidak menyepakati siapa pemilik data

Ketika dua sistem sama-sama bisa mengubah informasi yang sama, cepat atau lambat keduanya akan berbeda. Lalu muncul pertanyaan yang tidak ada jawabannya: yang mana yang benar?

Tanpa kesepakatan di awal, tim akan menyelesaikannya kasus per kasus, dengan cara yang berbeda setiap kali, dan ketidakkonsistenan menumpuk diam-diam.

Aturan yang menyelesaikan sebagian besar kasus: untuk setiap jenis data, tunjuk satu sistem sebagai pemegang kebenaran. Data pelanggan dimiliki CRM. Data stok dimiliki sistem gudang. Data posisi kendaraan dimiliki platform tracking. Sistem lain boleh membaca dan menyimpan salinan, tetapi kalau ada perbedaan, pemilik yang menang.

Kesepakatan ini memakan waktu satu rapat. Ketiadaannya memakan waktu berbulan-bulan.

Benang merahnya

Perhatikan bahwa dari lima hal di atas, hanya satu yang benar-benar teknis. Sisanya adalah kesepakatan yang harus dibuat manusia sebelum kode ditulis: apa arti istilah, apa yang terjadi saat gagal, siapa bicara dengan siapa, bagaimana melihat masalah, dan siapa yang berwenang.

Ini menjelaskan mengapa proyek integrasi yang dikerjakan tim teknis paling mahal sekalipun bisa tetap gagal, sementara proyek dengan teknologi biasa saja bisa berjalan bertahun-tahun tanpa drama. Yang membedakan bukan kecanggihannya, melainkan seberapa banyak hal yang sudah disepakati sebelum ada yang mulai membangun.

Kalau Anda sedang merencanakan integrasi, luangkan waktu untuk kelima pertanyaan di atas lebih dulu. Biayanya beberapa jam rapat. Penghematannya jauh lebih besar dari itu.