Apa Saja Isi Proyek Modernisasi COBOL: Panduan bagi Pembeli

Siapa pun yang bertanya apa saja isi proyek modernisasi COBOL biasanya mendapat jawaban berupa promosi. Panduan ini menyajikan versi yang lugas: pilihan yang tersedia, tahapan proyek yang nyata, apa yang diubah AI, apa yang ditambahkan aturan perbankan Indonesia, dan cara memilih pelaksananya. Menurut angka IBM yang dikutip CIO Dive pada Juli, COBOL menopang 40 persen sistem perbankan daring, 80 persen transaksi kartu kredit secara langsung, dan 95 persen transaksi ATM.

Mengapa organisasi memodernisasi COBOL

Kodenya sendiri biasanya berjalan baik. Tekanannya datang dari sisi manusia dan dari perubahan. Panduan bagi pemimpin perbankan yang diterbitkan Amazon Web Services pada 22 Mei 2026 menyebutkan 71 persen tim mainframe melaporkan kekurangan tenaga dan jumlah insinyur COBOL terus menyusut. Panduan itu juga mengutip FinTech Futures untuk perkiraan bahwa lembaga keuangan besar menghabiskan 70 hingga 85 persen anggaran TI untuk memelihara sistem lama.

Seberapa luas ketergantungan itu berbeda menurut sumbernya. Panduan yang sama mengutip DXC untuk angka 45 dari 50 bank terbesar dunia yang masih mengandalkan aplikasi mainframe; IBM, mengutip lembaga risetnya sendiri, menyebut 43 dari 50 bank terbesar. Angkanya berbeda, arahnya sama.

Lima pilihan, dari perubahan terkecil hingga terbesar

Modernisasi bukan satu hal tunggal. Sebuah ulasan yang diterbitkan pada Juli oleh perusahaan pengembang Mecanik Dev menguraikan lima pendekatan yang dipakai sebagian besar industri.

• Rehost: memindahkan aplikasi ke infrastruktur baru dengan COBOL yang sebagian besar tidak diubah. Biaya terendah, jadwal terpendek, dan risiko rendah, tetapi manfaatnya paling kecil.
• Replatform: menyesuaikan aplikasi untuk platform baru, misalnya mengompilasi ulang COBOL untuk Linux atau cloud, tanpa menulis ulang logika bisnisnya.
• Refactor: menata ulang dan mengonversi kode ke bahasa modern sambil menjaga perilaku luarnya tetap sama. Biaya dan risiko menengah, manfaat tinggi.
• Rearchitect atau rewrite: membangun ulang sistem dengan rancangan baru di atas teknologi modern. Manfaatnya tertinggi, tetapi biayanya juga tertinggi, jadwalnya terpanjang, dan risikonya paling besar.
• Replace atau retire: mengganti dengan produk jadi, atau mematikan fungsi yang tidak lagi dibutuhkan siapa pun.

Ulasan yang sama mengaitkan pilihan dengan pendorong bisnisnya: penghematan biaya mengarah ke rehost, kekurangan keterampilan mengarah ke refactor, kebutuhan kapabilitas baru mengarah ke penulisan ulang, dan fungsi yang bersifat komoditas mengarah ke penggantian. Dalam praktik, lanskap sistem yang besar jarang mendapat satu jawaban tunggal.

Seperti apa proyeknya dalam praktik

Apa pun pilihannya, tahapannya serupa. Garis besar di bawah ini adalah sintesis kami atas sumber-sumber yang ada, bukan sebuah standar.

• Penelusuran: memetakan program, aliran data, dan aturan bisnis yang terkubur di dalam kode. Banyak hal yang dikerjakan sistem tidak pernah dituliskan.
• Keputusan per aplikasi: memilih satu dari lima pilihan untuk setiap bagian lanskap sistem, dengan alasan yang dicatat.
• Irisan pertama yang terbatas: mulai dari satu domain bisnis yang terbatas sebagai pembuktian konsep, dengan ukuran keberhasilan yang disepakati sebelumnya, seperti yang disarankan panduan AWS.
• Membangun dan membuktikan kesetaraan: menguji komponen baru terhadap perilaku komponen lama, biasanya dengan menjalankan keduanya berdampingan dan membandingkan hasilnya.
• Migrasi data dan peralihan: memindahkan dan merekonsiliasi data, beralih secara bertahap, dan menjaga jalan untuk kembali.
• Penghentian: mematikan komponen lama hanya setelah komponen baru terbukti menanggung bebannya.

Alasan untuk bekerja secara bertahap sudah lama mapan. Penulis perangkat lunak Martin Fowler menyebutnya pola strangler fig, dalam artikel bertanggal Agustus 2024: komponen baru tumbuh di samping sistem lama dan mengambil alih bagian demi bagian. Ia berpendapat penggantian total cenderung gagal karena perilaku sistem yang ada sulit dirumuskan secara lengkap, dan karena pengguna tidak dapat menunggu bertahun-tahun sampai penulisan ulang selesai. Kode sementara yang memungkinkan sistem lama dan baru hidup berdampingan tampak boros, catatnya, tetapi itulah yang menurunkan risikonya.

Apa yang diubah AI, dan apa yang tidak

AI adalah alasan utama topik ini kembali ke agenda direksi. CIO Dive melaporkan pada 28 Juli 2026 bahwa perangkat AI menggeser strategi dari membongkar dan mengganti menjadi memodernisasi sistem di tempatnya. Morgan Stanley telah memodernisasi 17 juta baris kode lama dengan platform AI buatan sendiri yang menurut perusahaan itu menghemat lebih dari satu juta jam kerja pengembang. Perangkat dari vendor kini mencakup AWS Transform, IBM watsonx Code Assistant for Z, dan Azure Migrate dari Microsoft.

Laporan yang sama memuat peringatannya. Gartner memperkirakan 70 persen migrasi mainframe yang dimulai tahun ini akan gagal karena organisasi menilai kemampuan AI generatif terlalu tinggi. Mitch Ashley dari The Futurum Group menyebut klaim sebuah vendor AI bahwa perangkatnya mampu memodernisasi sistem COBOL berukuran apa pun sebagai hal yang menggelikan. Pembacaan kami: AI mempersingkat penelusuran, dokumentasi, dan konversi kode. AI tidak menghapus pengujian, migrasi data, atau keputusan bisnis tentang apa yang seharusnya dikerjakan sistem.

Yang perlu diperhitungkan bank di Indonesia

Bagi bank umum di Indonesia, titik awalnya adalah Peraturan OJK Nomor 11/POJK.03/2022 tentang Penyelenggaraan Teknologi Informasi oleh Bank Umum. Dokumen tanya jawab yang diterbitkan OJK menyebutkan peraturan itu mencakup, antara lain, tata kelola TI, arsitektur TI dan rencana strategis TI, manajemen risiko, ketahanan siber, penggunaan pihak penyedia jasa TI, dan penempatan sistem elektronik.

Tiga hal dalam dokumen itu berkaitan langsung dengan rencana modernisasi. Bank dapat menggunakan layanan cloud computing, dan penyedia cloud kemudian diperlakukan sebagai pihak penyedia jasa TI menurut peraturan tersebut. Core banking system tidak termasuk sistem yang dapat ditempatkan di luar negeri, sehingga wajib tetap berada di pusat data dan pusat pemulihan bencana di Indonesia. Selain itu, penempatan sistem yang memenuhi kriteria di luar negeri memerlukan izin OJK, yang diberikan atau ditolak OJK dalam waktu tiga bulan sejak permohonan diterima lengkap. Ini adalah uraian, bukan nasihat hukum; bank sebaiknya memastikan posisinya sendiri kepada pengawasnya.

Siapa yang mengerjakan, dan cara memilihnya

Ada tiga jenis penyedia yang terlibat. Vendor platform seperti AWS, IBM, dan Microsoft menyediakan perangkat dan tempat tujuannya. Perusahaan jasa global menjalankan program besar, sering kali bersama mereka; CIO Dive mencatat Unisys bekerja sama dengan AWS dan Kyndryl dengan Microsoft. Integrator lokal dan perusahaan rekayasa spesialis membawa kedekatan, bahasa, dan pemahaman atas aturan setempat. Bagi bank dengan operasi standar yang lebih mementingkan kecepatan daripada kustomisasi, panduan AWS menunjuk sistem inti siap pakai dari vendor seperti Thought Machine, Mambu, dan Finxact. Lanskap sistem yang sangat besar dengan tenggat ketat mungkin memerlukan skala perusahaan global; sistem yang terbatas, atau irisan pertama, sering kali cocok bagi tim lebih kecil yang tetap dekat dengan kodenya. Siapa pun yang masuk daftar pendek, pertanyaannya sama.

• Bagaimana Anda mengetahui apa yang sebenarnya dikerjakan sistem sebelum mengubahnya?
• Bagaimana Anda menunjukkan bahwa komponen baru berperilaku seperti yang lama, termasuk pada kasus-kasus yang janggal?
• Apa langkah pertama yang paling kecil, dan bagaimana cara membatalkannya?
• Siapa yang memeriksa hasil kerja perangkat AI?
• Bagaimana data direkonsiliasi saat peralihan?
• Apa yang mampu dipelihara tim kami sendiri setelah Anda selesai?

Apa yang perlu dipantau

• Apakah perkiraan kegagalan dari Gartner terbukti ketika migrasi berbasis AI tahun ini memasuki tahap pengujian dan peralihan.
• Penjelasan lanjutan dari OJK tentang penggunaan cloud dan penempatan sistem seiring bank memodernisasi sistem intinya.
• Ketersediaan keterampilan COBOL, yang menentukan harga dari tidak berbuat apa-apa.