3.6 Modernisasi sistem warisan

Tinjauan dan motivasi

Sistem warisan (legacy) adalah sistem yang menjalankan dunia. Buku besar inti perbankan, mesin pajak dan tunjangan, sistem lalu lintas udara dan pertahanan, administrasi polis asuransi, dan registri pemerintah yang diandalkan masyarakat sering kali berusia puluhan tahun. Banyak yang ditulis dalam COBOL (Common Business-Oriented Language) atau teknologi lama lainnya, dan mereka masih memproses sebagian besar transaksi kritis. “Warisan” bukan penghinaan. Artinya sistem itu cukup berharga untuk bertahan, cukup kritis sehingga kegagalannya katastrofik, dan cukup tua sehingga mengubahnya dengan aman itu sulit. Modernisasi sistem warisan adalah disiplin memperbaiki, memigrasikan, atau mengganti sistem ini tanpa merusak layanan esensial yang disediakannya.

Ini masalah yang tidak proporsional menimpa enterprise dan pemerintah, dan di sinilah kegagalan TI terbesar dan paling publik terjadi. Sebagian besar transaksi utama di seluruh dunia masih menyentuh sistem mainframe. Sebagian besar kode produksi di institusi besar berada dalam bahasa lama yang dipelihara oleh kumpulan spesialis yang menua dan menyusut. Pemerintah memikul beban terberat: kewajiban undang-undang yang dikodekan selama puluhan tahun, siklus pengadaan dan anggaran yang melampaui pemerintahan, dan layanan warga yang tidak boleh terputus. Risiko dominannya bukan bahwa sistem ini tua, karena banyak yang berjalan sangat baik. Risikonya adalah pengetahuan untuk memeliharanya sedang pensiun, platformnya makin mahal dan terbatas, dan godaan untuk “tulis ulang saja” mengarah pada kegagalan paling mahal dalam sejarah bidang ini.

Bab ini membahas pola modernisasi inkremental yang benar-benar berhasil (strangler fig dan branch-by-abstraction), cara menilai dan memprioritaskan risiko warisan, pengelolaan (stewardship) properti mainframe dan COBOL, disiplin migrasi data dan dual-running, dan di atas semuanya cara menolak godaan penulisan ulang besar. Keyakinan pusatnya adalah bahwa modernisasi yang sukses hampir selalu inkremental, berbasis bukti, dan terus menghasilkan nilai. Tidak pernah big bang bertahun-tahun.

Prinsip utama

Warisan berarti berharga dan fondasional, bukan sekadar tua. Hormati apa yang dilakukan sistem sebelum menyentuhnya; ia mengodekan aturan bisnis hasil perjuangan puluhan tahun.
Inkremental mengalahkan big-bang, hampir selalu. Ganti sepotong demi sepotong di balik antarmuka stabil; hasilkan nilai terus-menerus dan jaga risiko kecil.
Penulisan ulang besar adalah mode kegagalan bawaan. Penulisan ulang penuh rutin melampaui jadwal, kurang menghasilkan, dan dibatalkan; perlakukan dorongan itu dengan kecurigaan mendalam.
Anda tidak dapat memodernisasi apa yang tidak Anda pahami. Rekayasa balik dan dokumentasikan perilaku (termasuk aturan tak terdokumentasi) sebelum menggantinya.
Migrasi data adalah tempat proyek mati. Data lebih tua, lebih kotor, dan lebih kusut daripada yang diperkirakan siapa pun; rencanakan sebagai upaya kelas satu.
Jalankan lama dan baru secara paralel untuk membangun keyakinan. Dual-running dan perbandingan menangkap perbedaan sebelum cutover.
Prioritaskan menurut risiko dan nilai, bukan usia. Modernisasi yang paling berisiko dan paling berharga lebih dulu, bukan yang sekadar paling tua.
Jaga lampu tetap menyala saat mengganti mesin. Layanan harus tetap berjalan sepanjang waktu; tidak ada downtime yang dapat diterima untuk sistem warga atau keuangan yang kritis.

Rekomendasi

Modernisasi secara inkremental dengan pola strangler fig

Strangler fig (dinamai menurut tanaman rambat yang tumbuh mengelilingi pohon dan perlahan menggantikannya) adalah kuda beban modernisasi aman. Letakkan lapisan perutean (API gateway, fasad, atau proksi) di depan sistem warisan. Lalu, kemampuan demi kemampuan, bangun penggantinya di sistem modern dan alihkan irisan lalu lintas itu ke sana, membiarkan sisanya di sistem warisan. Seiring waktu sistem baru tumbuh dan yang lama menyusut, sampai dapat dipensiunkan. Ini menghasilkan nilai terus-menerus, menjaga setiap perubahan kecil dan dapat dibalik, menghindari cutover berisiko, dan memungkinkan Anda berhenti atau memprioritaskan ulang kapan saja. Ini kebalikan big bang. Sistem warisan terus berjalan dan terus menghasilkan nilai selagi Anda menggantinya di sekelilingnya.

Gunakan branch-by-abstraction untuk sambungan internal

Di tempat Anda perlu mengganti komponen yang banyak bagian sistem bergantung padanya, gunakan branch-by-abstraction. Perkenalkan lapisan abstraksi (antarmuka) di atas implementasi yang ada, migrasikan pemanggil agar bergantung pada abstraksi, bangun implementasi baru di balik abstraksi yang sama, beralih (sering di balik feature flag, secara bertahap), dan akhirnya buang implementasi lama. Ini memungkinkan komponen besar diganti secara inkremental pada jalur utama pengembangan tanpa cabang berumur panjang, menjaga sistem tetap dapat dirilis sepanjang waktu. Ia berpasangan alami dengan strangler fig: fasad menangani sambungan eksternal, branch-by-abstraction menangani yang internal.

Nilai dan prioritaskan risiko warisan dengan sengaja

Sebelum memodernisasi, bangun inventaris dan penilaian risiko properti yang berpandangan jernih. Untuk setiap sistem, beri skor menurut kekritisan bisnis, risiko teknis (usang, platform tak didukung, paparan keamanan), frekuensi perubahan, dan, yang krusial, risiko pengetahuan (berapa banyak orang yang masih dapat memeliharanya, dan seberapa dekat mereka dengan pensiun). Petakan sistem pada grid risiko-versus-nilai. Prioritaskan memodernisasi yang berisiko tinggi sekaligus bernilai tinggi. Pertimbangkan membiarkan sistem stabil, berubah rendah, dan dipahami baik tanpa disentuh meski tua, karena sistem yang berfungsi dan tak perlu diubah siapa pun bukan keadaan darurat. Penilaian ini mengubah “semuanya tua dan menakutkan” menjadi peta jalan berurutan yang dapat dipertanggungjawabkan.

Kelola properti mainframe dan COBOL, jangan sekadar menggantinya

Tidak setiap sistem mainframe atau COBOL harus, atau dapat dengan aman, diganti dalam waktu dekat. Prioritas jangka dekat sering kali stewardship: tangkap pengetahuan sebelum pensiun. Dokumentasikan aturan bisnis yang dikodekan kode (banyak yang tak terdokumentasi dan tak tergantikan), investasikan pada tes otomatis yang mengunci perilaku saat ini agar perubahan di masa depan aman, rekrut dan latih silang pemelihara, dan modernisasi praktik pengiriman di sekelilingnya (kontrol sumber, integrasi berkelanjutan (CI), pengujian otomatis) meski inti tetap di tempat. Di tempat Anda memodernisasi, pilih mengekspos kemampuan warisan lewat API modern (enkapsulasi) sebagai langkah pertama. Perlakukan penerjemahan otomatis COBOL ke bahasa modern dengan hati-hati, karena menghasilkan kode yang berjalan tetapi sering mereproduksi dengan setia logika yang tak terpahami. Sumber daya paling langka adalah pemahaman, bukan komputasi.

Perlakukan migrasi data dan dual-running sebagai inti proyek

Bagian tersulit dan paling berisiko dari kebanyakan upaya modernisasi adalah data. Ia berjumlah besar, berkualitas buruk dan tidak konsisten, dan penuh makna tak terdokumentasi yang menumpuk selama puluhan tahun. Lakukan profiling dan pembersihan, petakan skema lama ke baru secara eksplisit, dan bangun migrasi yang dapat diulang dan otomatis dengan rekonsiliasi penuh (hitungan, checksum, total bisnis) agar Anda dapat membuktikan tidak ada yang hilang atau berubah. Kurangi risiko cutover dengan dual-running (menjalankan paralel): operasikan sistem lama dan baru berdampingan pada masukan yang sama dan bandingkan keluaran sampai sistem baru cocok dengan yang lama pada ambang keyakinan Anda. Baru kemudian cutover, dan pertahankan kemampuan rollback. Untuk sistem yang benar-benar kritis, migrasikan dan cutover per irisan alih-alih sekaligus.

Kelola godaan penulisan ulang besar

Naluri membuang sistem lama yang berantakan dan membangun yang bersih dari nol itu kuat, dan hampir selalu keliru untuk sistem besar yang kritis. Penulisan ulang penuh meremehkan nilai tersembunyi dalam kode yang “jelek” (kasus tepi, aturan regulasi, perilaku bug-compatible yang diandalkan pengguna nyata), memakan waktu jauh lebih lama dari proyeksi, tidak memberikan nilai sampai akhir, dan sering dibatalkan setelah pengeluaran besar. Jadikan modernisasi inkremental sebagai bawaan. Sisihkan penulisan ulang untuk kasus di mana platform benar-benar tidak berkelanjutan dan jalur inkremental telah habis. Bahkan kemudian, uraikan penulisan ulang menjadi bagian yang dapat dikirim independen lewat pola strangler alih-alih satu rilis big-bang. Ketika pimpinan mendorong penulisan ulang total, desak pertanyaan: nilai apa yang dikirim dalam tiga bulan pertama, dan apa yang terjadi jika program dihentikan di tengah jalan?

Trade-off: kelebihan dan kekurangan

Pendekatan	Kelebihan	Kekurangan
Strangler fig (inkremental)	Nilai terus-menerus, risiko rendah, dapat dibalik, layanan tetap berjalan	Garis waktu keseluruhan lebih panjang, harus menjalankan dua sistem paralel, beban integrasi
Penulisan ulang big-bang	Lembar bersih, tanpa kendala warisan di kode baru	Tingkat kegagalan sangat tinggi, tanpa nilai sampai akhir, biaya besar, aturan bisnis hilang
Enkapsulasi (bungkus dengan API)	Cepat, berisiko rendah, memodernisasi akses tanpa menyentuh inti	Inti tetap warisan; menunda, bukan menyelesaikan, risiko mendasar
Biarkan apa adanya (steward)	Tanpa risiko proyek; termurah jangka pendek	Risiko pengetahuan dan platform terus menumpuk; tindakan paksa pada akhirnya

Trade-off mendasarnya adalah kecepatan transformasi versus risiko kegagalan, dan modernisasi warisan adalah ranah di mana pertukaran itu paling timpang. Penulisan ulang big-bang yang “cepat dan bersih” adalah fatamorgana yang berulang kali menghasilkan hasil paling lambat dan paling mahal dari semuanya: program dibatalkan dan sistem tetap tak termodernisasi. Pendekatan inkremental terasa lebih lambat dan menuntut menjalankan dua sistem paralel, tetapi menghasilkan nilai sepanjang jalan, menjaga risiko kecil dan dapat dibalik, dan merupakan jalur yang andal secara empiris. Penilaian sejati ada di antara mengelola sistem warisan stabil sedikit lebih lama dan memulai penggantian inkremental sekarang. Biarkan lintasan risiko yang menggerakkan keputusan itu, terutama risiko pengetahuan, alih-alih ketidaknyamanan terhadap teknologi lama.

Pertanyaan untuk didiskusikan dengan tim Anda

Apakah Anda punya tempat untuk meletakkan lapisan perutean di depan sistem warisan Anda, dan jika tidak, apa yang diperlukan untuk membuatnya? Strangler fig bergantung pada sebuah sambungan: API gateway, fasad, atau proksi yang melaluinya Anda dapat mengalihkan satu kemampuan sekaligus ke implementasi baru. Banyak sistem lama tak punya sambungan semacam itu, sehingga increment modernisasi pertama sering kali sekadar membangun titik intersepsi, dan pekerjaan itu mudah diremehkan. Bawa peta integrasi saat ini dan tanyakan di mana lalu lintas dapat dicegat per kemampuan tanpa cutover big-bang. Jika tak ada tempat, branch-by-abstraction pada sambungan internal mungkin langkah awalnya. Tanpa lapisan perutean Anda tak punya jalur inkremental, yang persis bagaimana organisasi terdorong kembali ke penulisan ulang yang biasanya gagal.
Sudahkah Anda benar-benar memetakan properti Anda pada grid risiko-versus-nilai, atau peta jalan Anda digerakkan oleh sistem mana yang terasa paling tua? Bab ini menekankan bahwa Anda memodernisasi yang berisiko tinggi dan bernilai tinggi lebih dulu, dan dengan sengaja membiarkan sistem stabil, berubah rendah, dan dipahami baik tanpa disentuh meski kuno. Tanpa grid eksplisit, perhatian mengalir ke keluhan paling nyaring atau teknologi paling tidak modis, dan bom waktu sejati (sistem kritis dengan dua pemelihara yang hampir pensiun) menunggu. Beri skor setiap sistem menurut kekritisan bisnis, risiko teknis, frekuensi perubahan, dan risiko pengetahuan, lalu urutkan dari sudut kanan atas. Bawa grid itu ke rapat sebagai peta bersama. Risiko pengetahuan layak mendapat bobot terberat, karena ia satu-satunya masukan yang hanya memburuk dan tak dapat dibeli kembali begitu orangnya pergi.
Saat cutover, bagaimana Anda akan membuktikan bahwa tidak satu pun catatan hilang atau berubah, dan siapa yang menyetujui bukti itu? Migrasi data adalah tempat proyek ini mati, dan keyakinan datang dari rekonsiliasi: jumlah baris, checksum, dan total kontrol bisnis yang cocok antara lama dan baru, ditambah dual-running yang membandingkan keluaran pada masukan yang sama sampai sepakat pada ambang tinggi. Untuk sistem tunjangan atau buku besar, perbedaan berarti warga kurang dibayar atau sen yang hilang, sehingga bukti harus memuaskan auditor, bukan hanya insinyur. Putuskan sekarang total mana yang akan Anda rekonsiliasi, ambang keyakinan apa yang memicu cutover, dan berapa lama Anda akan menjalankan lama dan baru secara paralel. Pertahankan rollback sepanjang waktu, dan cutover per irisan alih-alih sekaligus. Perbedaan yang Anda temukan selama dual-running biasanya aturan warisan tak terdokumentasi yang harus Anda pertahankan, jadi perlakukan masing-masing sebagai penemuan, bukan sekadar cacat.
Sistem warisan Anda yang mana yang sedang Anda kelola (steward) versus aktif diganti, dan siapa yang memutuskan mana yang mana? Bab ini menarik garis yang disengaja antara sistem yang layak distabilkan di tempat (mendokumentasikan aturan, menambah tes karakterisasi, melatih silang pemelihara) dan sistem yang layak diganti secara inkremental, dan keduanya menuntut pendanaan dan staf yang sangat berbeda. Bagi organisasi besar bahayanya adalah penyimpangan: sistem berlabel “steward untuk sementara” diam-diam menjadi “steward selamanya” sampai pemelihara terakhir pensiun dan pilihan dibuat untuk Anda di bawah krisis. Pertimbangan yang bersaing adalah biaya stewardship dan keusangan platform di satu sisi terhadap risiko dan gangguan penggantian di sisi lain, dan risiko pengetahuan harus menggeser keseimbangan karena ia hanya memburuk. Bawa grid risiko-versus-nilai, jumlah pemelihara dan cakrawala pensiun setiap sistem, dan pemilik eksplisit keputusan steward-atau-ganti. Dalam properti enterprise dan pemerintah, namai irama tinjauan dan pejabat yang bertanggung jawab untuk setiap sistem, karena klasifikasi yang tak pernah ditinjau ulang adalah keputusan yang tak dibuat siapa pun.
Ketika pimpinan meminta penulisan ulang penuh, apa jawaban tetap Anda, dan dapatkah Anda menunjukkan apa yang dikirim jalur inkremental dalam tiga bulan pertama? Penulisan ulang big-bang adalah mode kegagalan bawaan, namun terus didanai karena lembar bersih mudah dijual dan strangler fig tidak. Tim besar membutuhkan respons yang dilatih agar argumen dimenangkan dengan bukti alih-alih oleh siapa pun yang paling senior di ruangan. Ketegangan sejatinya adalah bahwa sebagian platform memang tidak berkelanjutan dan penulisan ulang beralasan, sehingga jawabannya tak bisa penolakan menyeluruh: ia harus menimbang apakah sambungan inkremental masih ada terhadap biaya sebenarnya mempertahankan platform lama tetap hidup. Bawa nilai yang akan dikirim increment pertama yang inkremental, tingkat kegagalan historis penulisan ulang sebanding, dan penguraian setiap penulisan ulang yang diusulkan menjadi bagian yang dapat dikirim independen. Di pemerintah, di mana program multitahun yang dibatalkan membakar uang publik di depan mata, desak agar penulisan ulang apa pun memberikan nilai lebih awal dan selamat dari dihentikan di tengah jalan tanpa kerugian total.
Bagaimana Anda akan menangkap aturan bisnis yang terkunci dalam kode tertua Anda sebelum orang yang memahaminya pergi? Sebagian besar nilai dalam sistem warisan adalah perilaku tak terdokumentasi yang ditumpuk puluhan tahun kasus tepi, regulasi, dan perbaikan bug-compatible, dan ia hidup dalam kumpulan spesialis pensiun yang menyusut alih-alih dalam catatan tertulis mana pun. Bagi organisasi besar ini satu-satunya risiko yang tak dapat dibeli kembali begitu orangnya pergi, sehingga layak didanai mendahului pekerjaan platform yang lebih terlihat. Tarikan yang bersaing adalah bahwa penangkapan pengetahuan (dokumentasi, tes karakterisasi, rekayasa balik, pelatihan silang) terasa seperti beban yang tak mengirim apa pun, itulah mengapa ia ditunda. Bawa inventaris siapa yang memegang pengetahuan kritis, seberapa dekat mereka dengan kepergian, dan cakupan tes apa yang mengunci perilaku saat ini hari ini. Dalam lingkungan yang diatur dan publik, perlakukan aturan undang-undang yang dikodekan dalam kode lama sebagai aset kepatuhan: kehilangannya secara diam-diam bukan utang teknis, melainkan paparan hukum.

Lensa sektor

Startup. Warisan Anda adalah MVP terburu-buru milik sendiri, bukan mainframe: prototipe yang kini membawa pendapatan dan yang ditakuti semua orang untuk disentuh. Jangan tulis ulang. Bungkus modul paling menakutkan di balik antarmuka bersih, tambahkan tes karakterisasi untuk mengunci perilakunya, dan potong fungsionalitas secara inkremental agar setiap rilis kecil mengirim nilai dan mengecilkan risiko. Anda tidak punya landasan untuk pembangunan ulang dari nol, jadi opsionalitas lebih penting daripada keanggunan.

Bisnis kecil. Anda tidak punya tim modernisasi dan anggaran ketat, jadi langkah praktisnya biasanya menjaga sistem yang berfungsi tetap berfungsi: tangkap apa yang diketahui satu orang yang memahaminya, masukkan ke kontrol sumber dengan beberapa tes otomatis, dan bersandarlah pada vendor atau produk paket alih-alih pembangunan ulang pesanan. Bingkai keputusan sebagai beli versus bangun, dan pilih beli ketika kemampuannya komoditas. Belanjakan upaya terbatas Anda pada satu sistem yang kegagalannya akan menghentikan bisnis, bukan pada apa pun yang sekadar tampak paling tua.

Enterprise. Masalahnya skala portofolio: puluhan sistem, banyak tim, dan risiko pengetahuan seluruh properti. Jalankan penilaian risiko-versus-nilai bersama, bakukan pola inkremental (strangler fig dan branch-by-abstraction), dan perlakukan migrasi data dan dual-running sebagai disiplin kelas satu dengan rekonsiliasi yang dipercaya semua orang. Atur modernisasi sebagai portofolio berkelanjutan terhadap lintasan risiko alih-alih sebaran proyek heroik, dan anggarkan stewardship dan penangkapan pengetahuan secara eksplisit agar tak ada sistem kritis bergantung pada satu pemelihara yang pensiun.

Pemerintah. Kewajiban undang-undang yang dikodekan selama puluhan tahun, aturan pengadaan, dan layanan warga yang tidak boleh terputus membuat penggantian big-bang sangat berbahaya. Pilih migrasi strangler fig inkremental dengan cutover irisan demi irisan, buktikan lewat rekonsiliasi dan paralel panjang bahwa tidak satu pun catatan warga hilang atau salah hitung, dan pertahankan rollback sepanjang waktu. Pengadaan harus menuntut portabilitas data dan pengungkapan aturan bisnis alih-alih penerjemahan buram, dan program multitahun apa pun harus memberikan nilai yang dapat diaudit lebih awal dan selamat dari pengawasan publik jika dihentikan di tengah jalan.

Contoh

Startup. MVP asli sebuah startup berusia tiga tahun telah menjadi warisan jenisnya sendiri: prototipe terburu-buru yang kini menangani pendapatan nyata dan yang ditakuti semua orang untuk disentuh. Alih-alih menulis ulang, tim membungkus modul terburuk di balik antarmuka bersih, menambahkan tes karakterisasi untuk mengunci perilakunya saat ini, dan memindahkan fungsionalitas keluar darinya sepotong demi sepotong selama beberapa bulan. Setiap rilis kecil mengirim nilai dan mengecilkan bagian yang menakutkan, sehingga startup mendapat sistem yang dapat dipelihara tanpa mempertaruhkan perusahaan pada pembangunan ulang dari nol yang tak sanggup ditanggungnya.

Enterprise. Sebuah perusahaan asuransi besar menjalankan administrasi polis pada sistem COBOL mainframe yang andal tetapi mahal diubah dan dipelihara segelintir insinyur yang mendekati pensiun. Alih-alih menulis ulang, perusahaan membungkus mainframe dengan API modern dan menerapkan strangler fig: kemampuan beli-dan-penawaran serta layanan mandiri baru dibangun di platform modern dan dirutekan lewat fasad, sementara catatan polis inti tetap di mainframe. Secara paralel, tim mendokumentasikan aturan bisnis dan menambahkan tes karakterisasi di sekitar COBOL. Selama beberapa tahun, kemampuan demi kemampuan berpindah dari mainframe, setiap rilis menghasilkan nilai, sampai inti yang tersisa dapat dipensiunkan menurut persyaratan perusahaan asuransi, bukan di bawah krisis.

Pemerintah. Sebuah lembaga jaminan sosial harus memodernisasi sistem perhitungan tunjangan berusia puluhan tahun yang membayar jutaan warga dan tidak boleh terputus atau salah membayar. Setelah mempelajari program sebanding yang gagal, ia menolak penggantian big-bang. Sebagai gantinya ia melakukan profiling dan pembersihan data, membangun migrasi otomatis dengan rekonsiliasi penuh terhadap total kontrol, dan menjalankan mesin tunjangan baru paralel dengan yang lama selama berbulan-bulan, memberi keduanya klaim yang sama dan membandingkan setiap perhitungan, menyelidiki setiap perbedaan (sering mengungkap aturan warisan tak terdokumentasi yang harus dipertahankan). Baru setelah sistem baru cocok dengan yang lama pada keyakinan sangat tinggi ia cutover jenis tunjangan demi jenis tunjangan, mempertahankan rollback sepanjang waktu. Fasad strangler memungkinkan warga melihat satu layanan berkesinambungan sepanjang transisi.

Kasus bisnis: motivasi, ROI, dan TCO

Modernisasi sistem warisan punya kasus bisnis yang tidak biasa, karena biaya terbesar sering kali biaya ketidakbertindakan dan risiko terbesar adalah proyek modernisasi itu sendiri. Biaya menumpuk karena tidak memodernisasi itu konkret: pemeliharaan dan lisensi yang naik pada platform usang, tenaga kerja spesialis yang makin langka dan mahal, ketidakmampuan memenuhi tuntutan regulasi atau layanan baru dengan cepat, dan paparan yang tumbuh terhadap kegagalan katastrofik tanpa seorang pun tersisa yang memahami sistem. Terhadap itu, biaya modernisasi tinggi, dan bila dilakukan sebagai big bang membawa probabilitas kegagalan yang benar-benar tinggi. Itulah persis mengapa pendekatan inkremental penting bagi ROI: ia mengubah satu taruhan besar menjadi serangkaian taruhan kecil yang masing-masing mengembalikan nilai dan dapat dihentikan.

Ajukan kasus kepada pimpinan dengan membingkai ulang pilihan. Pertanyaannya bukan “modernisasi atau tidak.” Melainkan “modernisasi secara inkremental sekarang, atau bayar biaya stewardship yang meningkat dan menghadapi modernisasi paksa yang lebih berisiko kelak di bawah krisis.” Kuantifikasi TCO status quo (biaya platform dan lisensi, premi untuk keterampilan langka, biaya berbobot risiko dari pemadaman tak terpulihkan) dan bandingkan dengan program bertahap yang mengurangi risiko dan biaya dengan setiap increment sambil menjaga layanan berjalan. Yang krusial, desak agar penulisan ulang apa pun yang diusulkan distrukturkan untuk memberikan nilai lebih awal dan sering. Program yang tidak menghasilkan apa-apa selama tiga tahun dan dapat dibatalkan dengan kerugian total bukan investasi; itu judi. Argumen ROI terkuat untuk pendekatan strangler adalah opsionalitas: nilai dikirim terus-menerus dan organisasi dapat mengubah arah kapan saja.

Anti-pola dan jebakan

Penulisan ulang big-bang. Penggantian semua-atau-tidak-sama-sekali bertahun-tahun yang tidak memberi nilai sampai akhir dan sering dibatalkan dengan biaya besar.
Menulis ulang tanpa memahami. Mengganti kode yang aturan bisnisnya tak pernah didokumentasikan, diam-diam menjatuhkan kasus tepi yang diandalkan pengguna nyata dan hukum.
Meremehkan data. Memperlakukan migrasi data sebagai renungan belakangan padahal ia bagian tersulit dan paling berisiko dari proyek.
Melewatkan dual-running. Cutover ke sistem baru tanpa perbandingan paralel, menemukan perbedaan hanya setelah memengaruhi orang nyata.
Penerjemahan otomatis sebagai solusi. Menerjemahkan COBOL ke bahasa modern dengan mesin dan mengira pekerjaan selesai, menghasilkan kode tak terpahami yang mereproduksi logika lama secara verbatim.
Memodernisasi menurut usia, bukan risiko. Menghabiskan upaya pada sistem tua-tetapi-stabil sementara sistem berisiko tinggi dan berubah tinggi menunggu.
Kehilangan pengetahuan. Membiarkan pemelihara terakhir pensiun tanpa menangkap aturan bisnis dan menambah tes karakterisasi.
Tanpa rollback. Cutover tanpa jalan kembali ketika sistem baru berperilaku buruk di bawah beban dan data nyata.

Model kematangan

Tingkat 1: Memulai. Sistem warisan ditakuti dan dibekukan; perubahan dihindari. Tidak ada inventaris atau penilaian risiko. Modernisasi, bila dicoba sama sekali, adalah penulisan ulang semua-atau-tidak-sama-sekali ad hoc yang digerakkan frustrasi. Pengetahuan hidup di beberapa kepala yang pensiun tanpa apa pun tertulis.
Tingkat 2: Mengembangkan. Beberapa tim punya inventaris dan gambaran kasar risiko, dan beberapa sistem warisan dibungkus API untuk akses. Pola inkremental dikenal namun diterapkan tidak merata, dan pemikiran masih hanyut ke penulisan ulang big-bang. Migrasi data dicoba tetapi diremehkan, dan praktik sangat bervariasi dari tim ke tim.
Tingkat 3: Membakukan. Sistem diprioritaskan menurut risiko dan nilai berdasarkan metode terdokumentasi seluruh organisasi. Pola inkremental (strangler fig, branch-by-abstraction) adalah bawaan yang ditegakkan, dan setiap modernisasi mengikuti playbook standar. Migrasi data adalah upaya terencana dan terekonsiliasi dengan dual-running sebelum cutover, dan penangkapan pengetahuan serta tes karakterisasi adalah praktik wajib, bukan opsional.
Tingkat 4: Mengelola. Modernisasi diukur dan dikendalikan dengan data. Properti membawa garis dasar: jumlah pemelihara dan cakrawala pensiun per sistem, cakupan tes karakterisasi, tingkat lulus rekonsiliasi migrasi, jumlah perbedaan dual-running, dan nilai yang dikirim per increment, semuanya dilacak terhadap target. Keputusan steward-atau-ganti dan keputusan go atau no-go cutover dibuat atas bukti ini, dan sistem yang melewati ambang risiko pengetahuannya memicu tindakan alih-alih menunggu krisis.
Tingkat 5: Mengorkestrasi. Modernisasi berkelanjutan, terintegrasi dengan perencanaan bisnis dan risiko, dan adaptif. Portofolio diseimbangkan ulang terhadap lintasan risiko (terutama risiko pengetahuan) seiring bergeser, penggantian inkremental rutin dan minim drama, setiap increment menghasilkan nilai dan dapat dibalik, dan organisasi mengarahkan lajunya dengan sengaja. Pelajaran dari setiap migrasi mengalir kembali ke playbook bersama sehingga seluruh properti membaik seiring waktu.

Gagasan untuk didiskusikan

Untuk sistem warisan paling kritis Anda, berapa orang yang masih dapat memeliharanya, dan seberapa dekat mereka dengan kepergian?
Di mana Anda tergoda penulisan ulang big-bang, dan nilai apa yang dapat dikirim pendekatan inkremental dalam tiga bulan pertama sebagai gantinya?
Seberapa baik aturan bisnis di sistem tertua Anda terdokumentasi, dan apa yang terjadi padanya jika kode diganti?
Sudahkah Anda melakukan profiling data yang perlu Anda migrasikan, dan tahukah Anda seberapa kotor dan kusutnya sebenarnya?
Sistem tua-tetapi-stabil mana yang energi modernisasinya Anda habiskan padahal dapat dibiarkan dengan aman?
Dapatkah Anda menjalankan sistem baru paralel dengan yang lama dan membuktikan keduanya sepakat sebelum cutover?

Poin-poin utama

Warisan berarti berharga dan fondasional; hormati dan pahami sistem sebelum mengubahnya.
Modernisasi secara inkremental dengan strangler fig dan branch-by-abstraction, menghasilkan nilai terus-menerus dan menjaga setiap perubahan kecil dan dapat dibalik.
Perlakukan penulisan ulang big-bang sebagai mode kegagalan bawaan; sisihkan untuk platform yang benar-benar tidak berkelanjutan dan bahkan kemudian uraikan.
Prioritaskan menurut risiko dan nilai (terutama risiko pengetahuan), bukan usia; sebagian sistem lama paling baik dikelola, bukan diganti.
Migrasi data dan dual-running adalah jantung upaya; lakukan profiling, rekonsiliasi, jalankan paralel, dan pertahankan rollback.
Kasus bisnis terkuat adalah opsionalitas: modernisasi inkremental mengubah satu taruhan besar berisiko menjadi banyak taruhan kecil yang mengembalikan nilai.

Referensi dan bacaan lanjutan

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” dan “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / studi industri tentang ketergantungan mainframe dan COBOL (konteks tentang skala properti warisan)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (anti-corruption layer)
Gregor Hohpe, Enterprise Integration Patterns dan The Software Architect Elevator
Standish Group CHAOS Report (bukti tentang tingkat kegagalan proyek besar dan penulisan ulang)