Kita sering overbuild sistem untuk menghindari membuat keputusan.

Tambah Payment Provider Harusnya 1 Minggu. Kenapa Tim Kamu Butuh 3 Bulan? AI sekarang bisa bantu generate adapter payment provider dalam hitungan menit. Jelasin interface-nya. Tunjukkan contoh response-nya. Selesai.

Tapi di banyak tim yang saya kenal dan pernah saya pimpin onboarding provider baru masih butuh 3 bulan. Kadang lebih. Bukan karena engineer-nya tidak kompeten. Bukan karena teknologinya kurang canggih. Karena ada pertanyaan paling mendasar yang tidak pernah dijawab.

Dari niat yg baik, abstract sebisa mungkin, biar extensible, katanya

Saya belajar ini dengan cara yang cukup mahal: mengulang pola yang sama di domain berbeda. Payment. Risk. Platform. Commerce. Di perusahaan berbeda. Dengan tim berbeda. Polanya selalu sama. Niatnya selalu baik.

Visinya jelas: kami ingin sistem yang fleksibel, siap untuk semua kemungkinan.

Jadi kami mendesain:

• Multiple payment provider dari awal, karena "nanti pasti butuh lebih dari satu"
• Workflow yang bisa dikonfigurasi, karena "setiap use case pasti berbeda"
• Adapter yang extensible, karena "kita tidak mau lock-in ke satu pola"

Di atas kertas, arsitekturnya terlihat mature. Clean. Siap untuk masa depan. Tapi di realita, semuanya lambat lho..

Abstraksi Ada. Tapi Onboarding Tetap Butuh Berbulan-bulan

Ambil payment domain sebagai contoh yang paling konkret. Abstraksi sudah ada. Interface provider sudah terdefinisi. Secara teknis, menambah provider baru "tinggal implement interface." Tapi kenyataannya, onboarding provider baru butuh berminggu-minggu.

Tim terus memperdebatkan flow yang sama, bukan karena debatnya produktif, tapi karena tidak ada yang pernah benar-benar selesai. Setiap diskusi berakhir dengan "tergantung use case-nya" tanpa ada yang memutuskan use case mana yang sebenarnya jadi prioritas.

Setiap perubahan kecil, mengubah satu field, menambah satu validation rule, tiba-tiba membutuhkan koordinasi lintas tiga tim. Proporsinya tidak masuk akal dengan ukuran perubahannya. Semua orang sibuk. Sprint velocity terlihat bagus. Tapi delivery provider baru tetap berbulan-bulan.

Masalahnya Bukan di Code

Lama-lama saya mulai melihat polanya. Masalahnya bukan di code. Masalahnya bukan di engineer.

Masalahnya bukan di arsitekturnya. Masalahnya: tidak ada yang pernah benar-benar memutuskan.

Pertanyaan paling fundamental yang seharusnya dijawab sebelum mendesain apapun tidak pernah dibahas secara eksplisit:

Apa sebenarnya lifecycle payment dari awal sampai akhir?

Siapa yang own setiap tahap dan apa artinya "own" dalam konteks ini?

Flow mana yang harus distandardisasi, dan mana yang boleh berbeda per provider?

State disimpan di mana, dan siapa yang boleh mengubahnya?

Pertanyaan-pertanyaan itu tidak nyaman untuk dijawab. Karena menjawabnya berarti menutup kemungkinan lain. Berarti berkomitmen pada satu arah. Berarti ada yang harus berkata "tidak" ke permintaan yang terdengar masuk akal.

Tidak ada yang mau jadi orang itu.

Jadi kami melakukan yang paling nyaman bagi engineer: tambah abstraksi.

Abstraction Debt

Abstraksi terasa seperti solusi. Interface yang generik. Adapter yang pluggable. Configuration yang fleksibel. Dari luar terlihat seperti engineering yang matang, tim yang sudah "berpikir ke depan."

Tapi abstraksi yang dibuat sebelum keputusan diambil bukan solusi. Dia adalah cara yang paling elegan untuk menunda keputusan.

Ketika interface kamu bisa menampung semua kemungkinan, kamu bukan sedang menyelesaikan masalah. Kamu sedang memindahkan ketidakpastian ke dalam sistem. Dan setiap kali ada perubahan, ketidakpastian itu kembali muncul ke permukaan sebagai debat, sebagai koordinasi yang tidak produktif, sebagai onboarding yang butuh berbulan-bulan.

Saya menyebut ini abstraction debt: hutang keputusan yang disembunyikan di balik layer teknis. Kamu tidak akan melihatnya di code review. Tidak terdeteksi di architecture diagram. Tapi terasa di setiap sprint planning ketika tim kamu masih mendebat pertanyaan yang seharusnya sudah selesai tiga kuartal lalu.

Apa yang sebenernya terjadi

Baru saya benar-benar memahami ini secara penuh ketika kami membangun ulang payment core dipekerjaan. Situasinya tidak asing: sistem lama, banyak provider, onboarding yang konsisten lambat. Semua orang tahu masalahnya. Tidak ada yang tahu harus mulai dari mana.

Kali ini, saya paksa pertanyaan-pertanyaan itu untuk dijawab dulu. Sebelum ada satu baris desain pun:

Apa kontrak minimum yang harus dipenuhi setiap provider untuk bisa diintegrasikan? Di mana state disimpan, siapa yang jadi single source of truth untuk setiap transisi?

Lifecycle event mana yang wajib ada, dan mana yang boleh opsional per provider? Siapa yang own setiap transisi state, bukan "tim mana", tapi "service mana"?

Proses itu tidak mulus. Ada yang tidak setuju. Ada yang merasa kami membatasi sistem terlalu awal. Ada perdebatan yang cukup panjang.

Tapi kami memutuskan. Dan kami menuliskannya secara eksplisit dengan menjadikan itu decision record, bukan hanya sebagai asumsi tersirat di kepala masing-masing.

Hasilnya: onboarding provider baru yang sebelumnya butuh berminggu-minggu menjadi 4 kali lebih cepat.

Bukan karena sistemnya lebih pintar. Bukan karena engineer-nya lebih senior. Bukan karena tooling-nya lebih canggih.

Tapi karena tidak ada lagi pertanyaan mendasar yang harus didebat ulang setiap kali ada provider baru. Semua orang tahu kontrak minimumnya. Semua orang tahu di mana state disimpan. Semua orang tahu siapa yang bertanggung jawab untuk apa.

Keputusan yang terasa seperti "membatasi fleksibilitas", justru yang membuka kecepatan.

Trade-off yang Sebenarnya Dihindari

Ini yang berubah dalam cara saya melihat kompleksitas sistem:

Sebagian besar kompleksitas sistem payment bukan karena problemnya susah. Tapi karena ada keputusan yang belum diambil dan sistem yang menanggung ketidakpastian itu.

Trade-off yang sebenarnya kami hindari selama ini sangat sederhana: Berkomitmen pada satu flow vs mendukung semua variasi.

Tidak ada yang salah dengan mendukung variasi. Tapi kamu harus membayar cost-nya secara sadar dan eksplisit, bukan karena tidak ada yang berani memilih.

Abstraksi bukan masalahnya. Dalam sistem payment dengan banyak PSP, abstraksi memang diperlukan. Masalahnya adalah kapan dan mengapa abstraksi itu dibuat.

Abstraksi yang lahir dari keputusan yang jelas = leverage. Abstraksi yang lahir dari keputusan yang dihindari = debt.

Overbuild Detection

Sekarang, sebelum saya menambah kompleksitas apapun ke sistem, saya pakai empat pertanyaan ini:

1. Apakah ini menyelesaikan use case nyata yang sudah terkonfirmasi atau skenario hipotetis yang terasa logis?
2. Keputusan apa yang sebenarnya sedang dihindari dengan abstraksi ini?
3. Jika abstraksi ini dihapus hari ini, apa yang benar-benar rusak, bukan dua tahun ke depan, tapi sekarang?
4. Apakah kita mengoptimalkan kejelasan hari ini, atau fleksibilitas masa depan yang belum kita tahu pasti akan dibutuhkan?

Pertanyaan keempat adalah yang paling sering mengungkap masalahnya. Karena "fleksibilitas untuk masa depan" adalah framing yang paling sering dipakai untuk menghindari komitmen hari ini. Dan komitmen yang dihindari hari ini adalah kompleksitas yang harus dihadapi tim kamu setiap sprint.

Putuskan Dulu

Kalau sistem payment kamu terasa kompleks, kemungkinan besar bukan karena problemnya sulit. Tapi karena ada keputusan yang belum kamu ambil dan sistemmu sedang menanggung ketidakpastian itu untuk kamu.

AI bisa bantu generate adapter lebih cepat. Tapi kalau lifecycle, ownership, dan kontrak minimum belum diputuskan, yang bergerak lebih cepat hanyalah kompleksitasnya.

Putuskan dulu. Baru build. Jangan #Overbuild.