Membuat pekerjaan perbankan yang dapat dikomposisikan

Ketika saya pertama kali memulai karir saya di bidang teknologi perbankan di tahun 80-an, saya awalnya bekerja dengan mainframe.

Kembali pada masa itu, kami memiliki tim "pengguna bisnis kantor pusat" yang menentukan persyaratan kami. Ini adalah perantara yang mewakili pengguna sebenarnya dari sistem. Kami tidak memiliki kontak langsung dengan pengguna sebenarnya.

Beberapa tahun kemudian, bank ingin mencoba apa yang sekarang disebut agile, tetapi saat itu Rapid Application Development. Tujuannya adalah untuk mempercepat bagaimana kami menyampaikan solusi kami. Kami adalah yang pertama di bidang IT yang dipersenjatai dengan laptop dan bahkan ponsel. Kami dibawa keluar dari kantor IT dan diberikan kantor di salah satu unit bisnis.

Pada saat yang sama, kami diizinkan untuk bekerja dari rumah atau di mana pun kami merasa bisa produktif. Jadwal saya biasanya bangun jam 6 pagi dan kode sampai jam 2 siang, lalu istirahat untuk makan siang dan kip sore. Saya kembali ke meja saya dari sekitar 6/7 dan biasanya akan membuat kode sampai tengah malam. Ini berhasil untuk saya.

Selain itu, perubahan terbesar sebenarnya adalah mendapatkan persyaratan dari pengguna akhir di cabang. Ini membuat perbedaan besar untuk mendapatkan kegunaan dan fungsi solusi dengan benar.

Maju cepat 30 tahun dan ini adalah norma sekarang. Selama 30 tahun terakhir, kami telah melihat peningkatan integrasi pengguna bisnis dan TI. Bahkan penyedia perangkat lunak telah beralih ke model di mana pelanggan sangat terlibat dalam produk baru.

Namun, umumnya untuk persyaratan khusus bisnis, seorang analis mendokumentasikannya dan pengembang menulis kodenya. Ini telah menjadi model selama beberapa dekade.

Ada upaya untuk mengubah ini, untuk memberdayakan pengguna bisnis untuk menulis solusi mereka sendiri menggunakan solusi kode rendah atau tanpa kode. Memang, perusahaan terakhir saya, edgeIPK, adalah pelopor dalam menciptakan platform tanpa kode untuk pengembangan aplikasi web/seluler. Gartner menyebut pengguna alat tersebut sebagai "pengembang warga". Ini mengurangi pemisahan persyaratan dan pengembangan, tetapi saya berani mengatakan itu menghasilkan banyak solusi yang sulit untuk dipelihara dan mendorong sedikit penggunaan kembali. Oleh karena itu, alat tersebut belum benar-benar digunakan di tingkat perusahaan untuk solusi mission-critical.

Namun, ini mungkin berubah dengan perbankan yang dapat dikomposisi, di mana penekanannya adalah untuk mengembangkan, menerbitkan, dan menggunakan blok bangunan dari pasar, dan kemudian mengizinkan orang lain untuk "menyusun" blok ini menjadi solusi lengkap. Tapi jelas tidak sesederhana itu. Yefim Natis, VP analis dan peneliti terkemuka di Gartner, mendefinisikan lima peran berikut dalam composable banking:

1. Arsitek perusahaan (EA): seseorang yang mengatur solusi keseluruhan pada tingkat tinggi, memastikan penggunaan ulang dan konsistensi maksimum. Arsitektur BIAN adalah contoh bagus dari sesuatu yang dapat dibuat oleh EA. BIAN menyediakan model yang bagus untuk penerapan "blok bangunan" yang dapat dikomposisi untuk arsitektur bank yang lengkap.
2. Pembuat: pengembang yang membuat dan menerbitkan blok bangunan komputasi individu, fungsionalitas, atau kemampuan bisnis.
3. Kurator: peran untuk mengelola "perpustakaan" atau pasar blok bangunan. Pustaka ini juga harus menyertakan solusi milik atau pihak ketiga yang diperoleh.
4. Komposer: tim yang menyusun solusi dari blok penyusun, menggunakan platform dan alat komposisi aplikasi, tetapi tidak harus.
5. Konsumen: pengguna aplikasi yang sebenarnya.

Untuk detail lebih lanjut, lihat webinar terbaru Yefim, 'Prinsip Inti Komposabilitas: Berkembang Melalui Perubahan Bisnis'.

Saya hanya mengatakan bahwa "composable banking" bukan hanya masalah TI karena melibatkan pengguna bisnis. Ini bukan hanya pengembangan standar dengan perpustakaan yang digunakan kembali, ini adalah perubahan organisasi, dan perusahaan akan berjuang untuk melihat manfaat penuh tanpa perubahan ini.

Di masa lalu, peran seorang arsitek perusahaan sangat sulit karena diperlukan pengetahuan yang kuat tentang bisnis dan teknologi, untuk dapat menyaring ratusan bahkan ribuan sistem dan memberikan cetak biru untuk lanskap yang lebih baik. BIAN telah membuat ini menjadi sangat mudah, meskipun tugas memetakan sistem yang ada masih tidak begitu mudah.

Seperti yang saya soroti di posting sebelumnya, composable banking dapat memecahkan sejumlah masalah bagi bank, tetapi akan membutuhkan perubahan organisasi dan harus didukung oleh strategi untuk mendidik dan mengadopsi cara kerja baru yang didukung oleh peran baru. Seperti biasa, alat dan teori sudah tersedia, iblis ada dalam detailnya. Ada contoh kuat dari organisasi yang membuat ini berhasil, dan saya berharap untuk segera menulis tentang mereka.

Tentang Penulis

Dharmesh Mistry telah berkecimpung di dunia perbankan selama lebih dari 30 tahun dan telah menjadi yang terdepan dalam teknologi dan inovasi perbankan. Dari aplikasi internet dan mobile banking pertama hingga kecerdasan buatan (AI) dan realitas virtual (VR).

Dia telah berada di kedua sisi pagar dan dia tidak takut untuk berbagi pendapatnya.

Dia adalah CEO dari Tanyakan Homey, yang berfokus pada pengalaman untuk rumah tangga, serta investor dan mentor di bidang proptech dan fintech.

Ikuti Dharmesh di Twitter @armarmmistry dan LinkedIn.

Baca semua renungannya "Saya hanya mengatakan" di sini.