Belajar Principal Engineer - Legacy & Modernization

#Pendahuluan

Setelah di episode 23 kalian memperluas pengaruh ke luar organisasi — konferensi, OSS, standar industri — pada episode ini kita kembali ke pekerjaan dalam yang paling mahal dan paling sering gagal: memimpin modernisasi org-wide. Migrasi monolit, penggantian platform data, pensiunan sistem mainframe — program yang biayanya jutaan dolar dan reputasi principal yang memimpinnya.

Mengapa ini begitu sulit? Karena modernisasi adalah satu-satunya jenis proyek yang harus mengganti mesin saat pesawat terbang — bisnis tidak berhenti sehari pun. Dan karena motivasinya sering salah dari awal: "teknologi barunya lebih menarik" bukan alasan; "biaya perubahan kita tiga kali lipat industri" baru alasan.

#Keputusan: Modernisasi, Toleransi, atau Isolasi

Tidak semua sistem tua layak disentuh. Kerangka keputusannya:

Kesalahan paling umum org: menulis ulang kategori kedua (yang seharusnya diisolasi) sambil menunda pensiunan kategori ketiga (yang seharusnya dimusnahkan). Uji penentu untuk kategori pertama — apakah layak modernisasi? — pakai angka:

Biaya tahunan sistem lama:
- Insiden terkait:        1.800 jam engineer + churn pelanggan
- Perubahan fitur lambat: lead time 6x rata-rata org
- Skill risk:             3 orang pegang 90% kode, 2 mendekati resign
- Infra & lisensi:        $420K/tahun (naik 12%/tahun)
Modernisasi:              9 engineer-bulan + co-existence 2 kuartal

Kalau kolom status quo tidak bisa diisi angka, kalian belum siap memulai — kalian baru ingin memulai.

#Strangler Fig dalam Skala Org

Strategi migrasi yang hampir selalu menang atas big-bang rewrite: strangler fig — bangun pengganti di sekitar sistem lama, alihkan trafik sedikit demi sedikit, biarkan yang lama mengerut sampai mati.

Aturan-aturan yang membuatnya bekerja di skala org (bukan sekadar satu service):

1. Routing terpusat dulu: tanpa kontrol trafik di satu titik, alihkan-perlahan tidak mungkin dilakukan.
2. Kontrak data eksplisit selama co-existence: dual-write dengan reconciler, atau event bridge — sinkronisasi diam-diam adalah sumber bug migrasi nomor satu.
3. Satu kapabilitas per gelombang: "auth" bisa dialihkan utuh; "semua order processing" tidak boleh.
4. Rollback path per gelombang: setiap pengalihan trafik harus bisa dibalik dalam hitungan menit — warisan one-way vs two-way door episode 8.

#Gelombang Migrasi Org-Wide

Program multi-tahun disusun seperti roadmap episode 12 tapi dengan karakter migrasi:

Gelombang 0 sering dilewati dan itu fatal: tanpa baseline metrik, kalian tak akan pernah bisa membuktikan program ini berhasil — dan program tanpa bukti akan dipotong budget di kuartal sulit pertama.

#Manajemen Risiko Selama Co-Existence

Periode dua sistem hidup bersamaan adalah masa paling rawan. Daftar pantauannya:

1. Konsistensi data: reconciler berjalan rutin + alert selisih; selisih kecil yang dibiarkan menjadi utang yang membunuh gelombang akhir.
2. Keamanan ganda: permukaan serangan dobel — sistem lama tetap patch sampai hari pemakamannya (jangan biarkan jadi zombie tak terawat).
3. Kelelahan tim: migrasi menyita engineer terbaik; rotasi antar gelombang dan rayakan tiap kapabilitas yang selesai.
4. Beban operasi dobel: on-call dua sistem sekaligus — kompensasi kapasitas eksplisit di roadmap, jangan diam-diam.

#Saat Program Mulai Dipertanyakan

Bulan ke-8-12 adalah titik krisis klasik: hasil belum terlihat penuh, biaya sudah kelihatan, dan eksekutif bertanya kenapa tidak berhenti saja. Persiapkan jawabannya sejak awal:

• Dashboard kemajuan publik: kapabilitas dialihkan, trafik lama tersisa, insiden terkait tren turun.
• Biaya berhenti sekarang vs lanjut: sunk cost dihitung jujur — kadang jawaban benar memang berhenti, dan kill switch episode 8 sudah menetapkan kondisinya.
• Cerita satu kalimat: "kita sudah memindahkan 14 dari 20 kapabilitas; berhenti sekarang berarti membayar dua sistem permanen."

Principal yang datang ke rapat itu tanpa angka siap akan kehilangan programnya — bukan karena programnya buruk, tapi karena ceritanya dikalahkan oleh keraguan.

#Praktik

Di workspace kalian:

1. Petakan sistem-sistem org ke tabel keputusan (modernisasi/isolasi/pensiun).
2. Pilih satu kandidat modernisasi; isi model biaya status quo dengan angka nyata.
3. Rancang rencana strangler: titik routing, kapabilitas per gelombang, rollback path.
4. Tulis definisi "selesai" yang tertulis + dashboard kemajuannya.

#Penutup

Inti yang harus dibawa pulang:

• Keputusan modernisasi per sistem: modernisasi / isolasi / pensiunkan — didukung model biaya status quo bernomor.
• Strangler fig skala org: routing terpusat, kontrak data eksplisit, satu kapabilitas per gelombang, rollback selalu siap.
• Gelombang 0 (baseline) wajib; nilai ekonomis baru muncul saat sistem lama benar-benar dimatikan.
• Kelola risiko co-existence dan siapkan pertahanan program berbasis angka untuk kuartal keraguan.

Di episode 25 selanjutnya kita membahas legacy & succession — sisi manusia dari warisan engineering: membangun penerus yang sanggup mengambil alih peran dan sistem kalian, transfer knowledge yang tidak bergantung pada heroik individu, dan merancang legacy yang bertahan melebihi masa jabatan kalian sendiri. Sampai jumpa di episode 25!