Hampir setiap strategi modernisasi sistem legacy yang diminta persetujuannya ke saya dimulai dengan kalimat yang sama: "kali ini kita bangun ulang saja dari nol, yang benar." Saya paham daya tariknya. Codebase lama itu jelek, sudah tidak ada yang benar-benar memahaminya, dan rewrite bersih terasa seperti pilihan engineering yang bertanggung jawab. Tapi kenyataannya hampir tidak pernah begitu.
Saya sudah melihat rewrite total menghabiskan 18 bulan dan dua kali anggaran, sementara bisnis tetap berjalan di sistem lama yang "sementara" itu, karena sistem baru tidak pernah benar-benar siap dan memang tidak bisa siap, sebab requirement terus bergeser mengejar target yang bergerak tanpa ada feedback dari produksi. Kuburan proyek rewrite penuh dengan proyek yang secara teknis benar tapi secara komersial mematikan.
Strategi modernisasi sistem legacy yang lebih baik adalah pendekatan strangler: bungkus sistem lama, ekstrak satu bagian yang paling menyakitkan pada satu waktu, jalankan sistem lama dan baru secara paralel, dan baru cutover setelah ada bukti bagian baru itu benar-benar bekerja di bawah beban nyata. Lebih lambat untuk diumumkan, tapi jauh lebih cepat untuk benar-benar selesai.
Kenapa rewrite big-bang gagal
Rewrite total punya tiga masalah struktural yang tidak bisa diselesaikan dengan perencanaan sebanyak apa pun:
- Requirement tersembunyi di dalam kode lama. Tidak ada yang mendokumentasikan edge case, aturan pembulatan pajak dari 2019, atau workaround untuk format invoice aneh milik satu klien tertentu. Semua ini baru terungkap saat sistem baru dijalankan dengan data nyata, dan rewrite menunda tahap ini sampai paling akhir.
- Bisnis tidak berhenti selama Anda membangun. Setiap bulan waktu rewrite berarti requirement baru terus mendarat di sistem lama, yang kemudian harus disesuaikan ulang oleh tim rewrite ke dalam sistem yang scope-nya sudah dibekukan enam bulan sebelumnya.
- Tidak ada nilai parsial. Rewrite itu biner: jadi atau tidak jadi. Kalau di bulan ke-14 progresnya 80%, Anda belum mengirimkan apa pun dan masih membayar penuh untuk menjalankan sistem lama.
Pola strangler dalam bahasa bisnis
Dinamai dari tanaman strangler fig yang tumbuh mengelilingi pohon inang dan perlahan menggantikannya, pola ini bekerja seperti berikut untuk software:
- Bungkus sistem legacy di balik API atau interface layer sehingga tidak ada pihak luar yang perlu tahu apa yang ada di baliknya.
- Pilih modul dengan tingkat kesakitan tertinggi lebih dulu, bukan yang paling mudah. Tujuannya adalah meredakan bottleneck terburuk lebih awal supaya bisnis merasakan manfaatnya dan terus mendanai tahap berikutnya.
- Bangun modul pengganti dan alirkan sebagian trafik nyata ke sana, sering kali satu cabang, satu lini produk, atau satu segmen pelanggan saja.
- Jalankan keduanya secara paralel dan bandingkan hasilnya sebelum cutover penuh.
- Ukur sebelum lanjut ke tahap berikutnya. Baru pindah ke modul selanjutnya setelah modul saat ini stabil di produksi, bukan sekadar lolos pengujian.
Ini disiplin yang sama dengan memetakan proses sebelum mengotomasinya: Anda tidak menyentuh bagian berikutnya sampai benar-benar memahami apa yang dilakukan bagian saat ini dan punya bukti bahwa penggantinya sudah sesuai.
Memilih modul pertama yang diganti
Saya menilai kandidat modul dari dua sisi: seberapa besar kesakitan yang ditimbulkannya sekarang, dan seberapa bersih modul itu bisa diisolasi.
| Sifat modul | Ganti dulu | Ganti belakangan |
|---|---|---|
| Menyebabkan workaround manual harian | Ya | |
| Terikat erat dengan lima modul lain | Ya | |
| Punya batas input/output yang jelas | Ya | |
| Jarang berubah, berjalan baik-baik saja | Biarkan saja |
Modul reporting yang butuh tiga hari bagi tim finance untuk rekonsiliasi setiap akhir bulan adalah target pertama yang lebih baik dibanding halaman login yang jelek tapi berfungsi sempurna. Kesakitan dan kemudahan isolasi yang menentukan urutan, bukan tampilan.
Menjalankan sistem lama dan baru secara paralel tanpa menggandakan biaya
Bagian yang paling dikhawatirkan pemilik bisnis adalah menjalankan dua sistem sekaligus. Dalam praktiknya ini bisa dikelola asal ruang lingkupnya dijaga ketat:
- Alirkan sebagian kecil trafik (satu cabang, satu wilayah, 10% dari order) ke modul baru.
- Catat output sistem lama dan baru berdampingan selama jangka waktu tertentu, biasanya 2-4 minggu.
- Tetapkan kriteria cutover yang jelas sejak awal (misalnya, nol selisih selama 14 hari berturut-turut), bukan sekadar perasaan "kelihatannya sudah oke."
- Sediakan saklar rollback. Kalau ada satu hal yang benar-benar dibeli dari pola strangler, itu adalah kemampuan untuk membatalkan satu modul tanpa menyentuh sisa sistem.
Saya menjalankan pendekatan persis ini untuk klien yang memigrasikan rekonsiliasi inventarisnya dari sistem on-premise berusia 12 tahun. Kami mengganti modul rekonsiliasi lebih dulu, membiarkan modul order-taking dan invoicing tidak tersentuh selama dua kuartal berikutnya, dan bisnis tidak pernah mengalami satu hari pun downtime karena sistem "lama" dan "baru" tidak pernah sepenuhnya live bersamaan untuk seluruh bisnis dalam satu waktu.
Ekspektasi anggaran dan timeline
Tetapkan ekspektasi sejak awal: modernisasi dengan pola strangler memakan waktu kalender total yang lebih panjang dibanding rewrite dalam skenario optimis, tapi jauh lebih hemat dalam skenario realistis, karena Anda tidak akan pernah terjebak menatap proyek 14 bulan yang progresnya 80% tanpa ada yang bisa dikirimkan. Anggarkan per tahap, evaluasi setelah setiap tahap, dan perlakukan ini seperti item dalam review anggaran teknologi kuartalan: danai tahap berikutnya berdasarkan bukti dari tahap sebelumnya, bukan berdasarkan rencana awal.
Kesimpulan
Jangan bertanya "apakah kita perlu membangun ulang sistem ini," tapi tanyakan "modul mana yang sekarang menyebabkan kesakitan paling besar, dan bisakah kita mengisolasinya." Bungkus sistem legacy, ekstrak satu modul itu, jalankan secara paralel dengan bukti sebelum cutover, lalu ulangi. Ini memang kurang menarik dibanding mengumumkan rebuild total, tapi ini strategi yang benar-benar selesai, menjaga bisnis tetap berjalan sepanjang waktu, dan memungkinkan Anda menghentikan proyek di tahap mana pun kalau prioritas berubah. Opsi itu saja sudah lebih berharga dibanding sensasi bersih dari sebuah rewrite.