Tidak ada yang menghubungi saya karena sistem lama mereka crash. Mereka menghubungi saya karena penawaran yang seharusnya selesai dalam sepuluh menit malah butuh tiga hari, atau karena kompetitor baru saja meluncurkan fitur yang menurut tim internal mereka sendiri "secara teknis tidak mungkin" dibangun di atas stack yang ada. Itulah wajah sesungguhnya dari risiko sistem legacy: hampir tidak pernah berupa outage yang dramatis. Yang terjadi adalah akumulasi friksi yang membuat setiap hal baru menjadi lebih mahal dari seharusnya, sampai akhirnya pertumbuhan itu sendiri menjadi sesuatu yang tidak bisa lagi ditopang oleh software.
Saya sudah cukup sering duduk di rapat-rapat semacam ini untuk hafal polanya di luar kepala. Sistemnya masih jalan. Invoice masih terkirim. Tidak ada yang panik soal downtime. Tapi setiap inisiatif baru, lini produk baru, kanal penjualan baru, persyaratan regulasi baru, selalu diestimasi tiga kali lipat dari waktu dan biaya yang seharusnya, dan semua orang di ruangan itu diam-diam sudah menerima ini sebagai hal normal. Ini tidak normal. Ini adalah risiko sistem legacy yang muncul tepat di titik yang paling menyakitkan: di ujung ambisi, bukan di pusat operasional harian.
Bisnis yang paling dirugikan bukanlah yang menjalankan kode paling tua. Mereka adalah yang tidak pernah menghitung harga risikonya sama sekali, karena belum ada yang rusak, sehingga tidak ada yang terpaksa melihatnya.
Bahayanya bukan crash, tapi pajak workaround
Sistem lama jarang gagal secara total. Yang mereka lakukan adalah memaksa munculnya workaround, dan workaround itu berlipat ganda seiring waktu. CRM yang tidak bisa menangani tier harga baru ditambal dengan spreadsheet di sampingnya. Spreadsheet itu butuh seseorang untuk direkonsiliasi manual setiap minggu. Enam bulan kemudian, sudah ada tiga spreadsheet, masing-masing menutup celah yang tidak bisa ditangani sistem inti, dan orang yang mengerti bagaimana semuanya saling terhubung tinggal menunggu satu surat pengunduran diri sebelum membawa pengetahuan itu pergi bersamanya.
Di titik itu, workaround sudah menjadi produk sesungguhnya dari bisnis tersebut. Saya pernah melihat pola persis seperti ini di perusahaan multifinance, di mana "memproses pengajuan pinjaman" secara resmi berarti satu hal di sistem inti, tapi secara tidak resmi berarti empat pengecekan silang manual yang tidak pernah didokumentasikan siapa pun. Karyawan baru butuh berbulan-bulan untuk produktif bukan karena pekerjaannya sulit, tapi karena separuh dari proses sesungguhnya hidup dalam folklore workaround, bukan di sistem manapun.
Budaya workaround itu mahal dengan cara yang tidak pernah muncul di satu invoice pun. Ia muncul lewat setiap karyawan baru yang butuh waktu lebih lama untuk onboarding, setiap audit yang makan waktu lebih panjang untuk selesai, dan setiap penawaran "fitur cepat" yang angkanya selalu lebih tinggi dari ekspektasi bisnis, karena penawaran itu harus memperhitungkan workaround-nya juga.
Kenapa setiap inisiatif baru jadi makin mahal
Ini bagian yang paling diremehkan pemilik bisnis. Sistem legacy tidak hanya menghabiskan biaya untuk dipelihara. Ia juga menghabiskan biaya untuk dibangun di sekelilingnya. Setiap permintaan fitur sekarang harus menjawab: apakah ini muat di dalam kemampuan sistem lama, apakah butuh bolt-on tambahan, atau apakah harus menyentuh core yang rapuh yang sudah tidak ada lagi yang benar-benar memahaminya secara utuh?
Opsi ketiga itulah yang membuat estimasi membengkak. Developer memasukkan risiko menyentuh kode tanpa dokumentasi, cakupan testing yang tipis, dan ingatan institusional yang tersebar di tiga orang yang masing-masing hanya ingat bagian berbeda darinya. Kalau Anda pernah menerima penawaran software yang terasa jauh lebih mahal dibanding proyek serupa di tempat lain, ini sering kali penyebabnya. Saya membahas lebih dalam soal bagaimana estimasi sebenarnya bekerja, dan kenapa penawaran bisa bervariasi sejauh itu, di Kenapa Estimasi Software Selalu Meleset (Dan Apa yang Membantu).
Batas pertumbuhan ini nyata dan spesifik: bukannya Anda tidak bisa tumbuh, tapi setiap unit pertumbuhan sekarang butuh effort engineering yang jauh tidak proporsional dibanding saat sistemnya masih baru. Pada titik tertentu hitungannya berhenti masuk akal, dan inisiatif yang seharusnya menguntungkan di sistem yang bersih malah dibatalkan karena tidak menguntungkan lagi di atas pajak workaround tadi.
Kerangka triase: contain, wrap, atau replace
Tidak semua sistem legacy butuh ditulis ulang, dan "ganti semuanya" biasanya jawaban pertama yang salah, karena terlalu mahal sekaligus terlalu berisiko untuk dieksekusi dengan bersih. Saya memakai triase tiga arah ini dengan klien.
Contain. Sistemnya masih menjalankan fungsi intinya secara memadai dan risiko bisnisnya rendah. Hentikan penambahan fitur ke dalamnya. Bekukan cakupannya, dokumentasikan perilaku aktualnya (bukan perilaku yang diasumsikan orang), dan bangun apapun yang baru di luar sistem itu.
Wrap. Sistemnya menyimpan logika kritis yang sulit digantikan (sering kali berupa aturan bisnis yang terakumulasi bertahun-tahun, khususnya di konteks finance dan compliance), tapi masalahnya ada di interface-nya. Bangun lapisan API modern di sekelilingnya supaya tools baru bisa berkomunikasi dengannya tanpa ada yang perlu menyentuh atau memahami bagian dalamnya. Ini biasanya langkah dengan leverage tertinggi, karena mengisolasi risiko tanpa memaksa Anda memigrasikan seluruh edge case bertahun-tahun sekaligus.
Replace. Sistemnya secara aktif menghambat pertumbuhan, pajak workaround-nya tinggi dan terus naik, dan logika intinya sendiri, bukan hanya interface-nya, yang menjadi kendala. Ini opsi paling mahal dan hanya tepat setelah contain dan wrap sudah dicoba dan tidak menggerakkan jarum.
| Situasi | Langkah | Profil biaya umum |
|---|---|---|
| Stabil, risiko rendah, cakupan dibekukan | Contain | Rendah, berkelanjutan |
| Logika kritis, interface buruk | Wrap | Menengah, satu kali |
| Aktif menghambat pertumbuhan | Replace | Tinggi, satu kali, payoff besar bila cakupannya tepat |
Kebanyakan bisnis yang saya temui langsung melompat ke "kita harus ganti semuanya" padahal wrap sudah bisa menyelesaikan 80 persen dari masalahnya dengan sepertiga biayanya. Diagnosis dulu sebelum mengalokasikan anggaran.
Cara menghitung harga risikonya
Ajukan tiga pertanyaan ini di setiap rapat perencanaan, secara terbuka, tercatat.
- Kalau orang yang memahami workaround ini resign besok, berapa lama sebelum kita sadar ada yang rusak?
- Dari lima permintaan fitur terakhir kita, berapa banyak yang diestimasi lebih mahal karena "kompleksitas legacy," dan pernahkah kita menjumlahkan angkanya?
- Adakah langkah kompetitor yang kita putuskan untuk tidak lakukan karena "sistemnya tidak bisa"?
Kalau jawaban untuk pertanyaan ketiga adalah ya, Anda sudah punya batas pertumbuhan yang berlaku, entah ada yang pernah menamainya begitu atau tidak.
Yang perlu dilakukan
Berhenti menunggu sistem legacy crash sebelum memperlakukannya sebagai risiko. Biaya sesungguhnya sudah muncul di penawaran Anda, waktu onboarding Anda, dan fitur-fitur yang diam-diam sudah berhenti Anda pertimbangkan. Jalankan triase contain, wrap, atau replace pada sistem inti Anda kuartal ini, mulai dari yang paling baru membuat inisiatif besar terakhir Anda jadi lebih mahal dari seharusnya. Kalau Anda ingin opini kedua soal sistem mana yang sebenarnya masuk kategori mana sebelum mengalokasikan anggaran ke salah satu dari ketiganya, itu persis jenis assessment yang saya lakukan sebagai technical partner.