Perbankan pada transformasi digital yang dipimpin mainframe untuk layanan keuangan

Ini adalah bagian satu dari seri blog lima bagian tentang modernisasi mainframe.

Karena kita sudah membahas bahwa modernisasi mainframe berlaku lebih luas daripada sekadar industri keuangan, mari kita langsung menyinggung isu besar yang sering muncul? Tantangan modernisasi terbesar di dunia terkonsentrasi di industri perbankan.

Sebelum internet dan komputasi cloud, dan sebelum ponsel pintar dan aplikasi mobile, bank melakukan pembayaran melalui gerbang penyelesaian elektronik besar-besaran dan mengoperasikan mainframe sebagai sistem pencatatan.

Perusahaan jasa keuangan dianggap institusi karena mereka mengelola dan pindah aspek inti dari sistem ekonomi global kita. Dan jantung lembaga keuangan yang berdetak adalah mainframe IBM®.

Bank memiliki potensi keuntungan terbesar jika mereka berhasil (dan kerugian terbesar jika mereka gagal) dalam membawa aplikasi serta ekosistem data mainframe mereka ke standar modern dengan fleksibilitas, ketangkasan, dan inovasi layaknya cloud untuk memenuhi kebutuhan pelanggan.

Kami telah mengalami ketidakpastian ekonomi global dalam ingatan baru-baru ini, dari krisis “terlalu besar untuk gagal” 2008 hingga suku bunga tinggi pasca-pandemi kami saat ini yang menyebabkan paparan berlebihan dan kebangkrutan bank-bank deposan besar tertentu.

Meskipun kegagalan bank sering kali merupakan hasil dari keputusan dan kebijakan manajemen yang buruk, ada alasan kuat untuk menyalahkan keterlambatan dalam inisiatif dan strategi modernisasi. Tidak bisakah eksekutif menjalankan analisis yang lebih baik untuk menemukan risiko dalam data? Mengapa mereka gagal meluncurkan aplikasi mobile baru? Apakah ada yang meretas sistem mereka hingga pelanggan tidak bisa masuk?

Semua orang memahami bahwa menunda modernisasi aplikasi mainframe berarti melewatkan peluang, namun banyak yang percaya bahwa mengubah sistem yang masih menjalankan operasional dianggap terlalu berisiko.

Bank komunitas dan regional mungkin kekurangan sumber daya teknis, sedangkan institusi yang lebih besar memiliki sejumlah besar utang teknis, masalah pergerakan data gravitasi tinggi, atau kesulitan dengan kasus bisnis.

Bank besar dan kecil semuanya kemungkinan gagal pada satu atau lebih inisiatif modernisasi atau migrasi. Ketika upaya dibatalkan, para pemimpin TI dalam organisasi ini merasa seperti mereka menggigit lebih dari yang bisa mereka kunyah.

Upaya modernisasi seharusnya tidak memerlukan penulisan ulang kode mainframe secara besar-besaran, atau latihan angkat-dan-geser yang melelahkan dan mahal. Sebaliknya, tim harus memodernisasi apa yang masuk akal untuk prioritas bisnis yang paling penting.

Berikut adalah beberapa contoh penggunaan bank yang melampaui sekadar memulai kembali inisiatif modernisasi untuk secara signifikan meningkatkan nilai mainframe mereka dalam konteks arsitektur perangkat lunak yang sangat terdistribusi dan harapan pengalaman pelanggan yang tinggi saat ini.

Banyak bank takut untuk alamat hutang teknis dalam mainframe mereka yang ada, yang mungkin telah ditulis dalam COBOL atau bahasa lain sebelum munculnya sistem terdistribusi. Seringkali, para insinyur yang merancang sistem asli tidak lagi hadir, dan gangguan bisnis bukanlah pilihan yang baik, sehingga pembuat keputusan TI menunda transformasi dengan bermain-main di tingkat menengah.

Atruvia AG adalah salah satu vendor teknologi layanan perbankan terkemuka di dunia. Lebih dari 800 bank mengandalkan layanan inovatif mereka untuk hampir 100 miliar transaksi tahunan, didukung oleh delapan sistem IBM® z15 yang berjalan di empat pusat data.

Daripada mengganti sistem secara total, mereka memilih merombak struktur aplikasi yang ada dengan menambahkan layanan RESTful berbasis Java di samping kode COBOL yang tetap berjalan di mainframe. Dengan mengganti 85% transaksi inti perbankan mereka secara bertahap menggunakan Java modern, mereka berhasil menghadirkan fitur-fitur baru untuk nasabah dan meningkatkan kinerja beban kerja mainframe hingga 3 kali lebih cepat.

Kebanyakan bank sudah menyiapkan rencana perlindungan data yang mencakup redundansi untuk pemulihan bencana (DR), misalnya salinan utama mainframe produksi di pusat data ditambah cadangan sekunder di lokasi terpisah atau solusi virtual tape yang diperbarui setiap beberapa bulan.

Karena volume data meningkat secara tak terhindarkan dalam ukuran, dengan lebih banyak transaksi dan titik akhir aplikasi, membuat salinan melalui teknologi cadangan lama menjadi semakin mahal dan memakan waktu, dan menyusunnya kembali juga lambat, yang dapat meninggalkan celah waktu henti DR. Ada penting kebutuhan untuk cadangan dan pemulihan yang lebih tepat waktu untuk mengamankan lingkungan komputasi bank modern, termasuk ransomware.

ANZ, bank teratas di Australia, berusaha meningkatkan kapasitasnya untuk cadangan mainframe yang lebih tepat waktu dan kinerja DR yang lebih cepat untuk memastikan ketersediaan tinggi bagi lebih dari 8,5 juta pelanggannya.

Mereka membangun kapasitas ketahanan antar-situs, menjalankan server IBM® zSystem cermin menggunakan fungsi HyperSwap mereka untuk mengaktifkan swap penyimpanan multi-target tanpa memerlukan pemadaman, karena salah satu server yang identik dapat mengambil alih beban kerja produksi jika seseorang sedang menjalani proses cadangan atau pemulihan.

Kepemimpinan TI ANZ mendapatkan ketenangan pikiran berkat ketersediaan sistem yang lebih baik; tetapi lebih dari itu, mereka sekarang memiliki postur pemulihan bencana modern yang dapat disertifikasi untuk memberikan keberlangsungan bisnis bagi pelanggannya.

Bank bergantung pada analitik lanjutan untuk hampir setiap aspek keputusan bisnis utama yang memengaruhi kepuasan pelanggan, kinerja keuangan, investasi infrastruktur, dan manajemen risiko.

Kueri analitis kompleks di atas kumpulan data besar di mainframe dapat menghabiskan anggaran komputasi dan membutuhkan waktu berjam-jam atau berhari-hari untuk dijalankan. Memindahkan data ke tempat lain—seperti gudang datacloud—dapat datang dengan penundaan transportasi yang lebih besar, mengakibatkan data basi dan keputusan berkualitas buruk.

Garanti BBVA, bank terbesar kedua di Turki, menerapkan IBM® Db2 Analytics Accelerator untuk z/OS, yang mempercepat beban kerja kueri sekaligus mengurangi konsumsi CPU mainframe.

Dengan memisahkan beban kerja analitik dari lingkungan produksi mainframe dan biaya yang menyertainya, Garanti dapat menjalankan lebih dari 300 batch job analitik setiap malam. Hasilnya, laporan kepatuhan yang dulu selesai dalam dua hari kini hanya butuh satu menit.

Bank bersaing dalam kemampuan mereka untuk memberikan aplikasi baru yang inovatif dan penawaran layanan kepada pelanggan, sehingga tim devtest yang tangkas terus-menerus menyumbangkan fitur perangkat lunak. Secara alami, kami cenderung menggeneralisasi hal ini sebagai peningkatan front-end pada aplikasi ponsel pintar dan integrasi berbasis API dengan layanan cloud.

Tapi tunggu, hampir setiap fitur baru ini pada akhirnya akan menyentuh mainframe. Mengapa tidak membawa tim mainframe ke depan sebagai peserta kelas satu dalam gerakan DevOps sehingga mereka dapat terlibat?

Danske Bank memutuskan untuk membawa hampir 1.000 pengembang mainframe internal ke dalam gerakan transformasi DevOps di seluruh perusahaan, menggunakan IBM® Application Delivery Foundation for z/OS (AdFZ) sebagai platform untuk pengembangan fitur, debugging, pengujian, dan manajemen rilis.

Bahkan kode COBOL dan PL/1 yang ada dapat dicerna ke dalam pipeline manajemen CI/CD, kemudian dibuka dan diedit secara intuitif di dalam IDE pengembang. Tidak ada lagi repot-repot berurusan dengan layar hijau di sini. Danske Bank sekarang dapat membawa penawaran ke pasar dalam setengah waktu yang dibutuhkan sebelumnya.

Baca studi kasus Danske Bank https://www.ibm.com/id-id/case-studies/danske_bank_as

Bahkan perusahaan fintech “born-in-the-cloud” yang lebih baru akan bijaksana untuk mempertimbangkan bagaimana inovasinya sendiri perlu berinteraksi dengan lingkungan komputasi hybrid rekanan yang selalu berubah.

Transaksi pada aplikasi mobile pada akhirnya masih akan mencapai jaringan pembayaran global, entitas pengatur, dan bank lain—masing-masing dengan sumber daya komputasi mainframe dan penyimpanan di balik setiap pemenuhan permintaan.

Tidak akan pernah ada jalan tunggal ke depan di sini karena tidak ada dua bank yang identik, dan ada banyak kemungkinan transformasi yang dapat dilakukan pada perjalanan modernisasi aplikasi mainframe.

Pemimpin TI perlu memulai dari suatu tempat dan memilih contoh penggunaan yang paling sesuai untuk kebutuhan bisnis mereka dan arsitektur kawasan aplikasi unik yang akan dihuni mainframe.

Untuk mempelajari lebih lanjut, lihat posting lain dalam seri ini:

• Bagian 1: “Modernisasi aplikasi mainframe di luar perbankan”
• Bagian 2: “Menggunakan kolaborasi (bukan migrasi) untuk memodernisasi aplikasi mainframe Anda dengan cloud”
• Bagian 4: “Mainframe dan cloud? Sangat mudah dengan sumber terbuka“