6.3 Membaca Siklus Hidup Aplikasi

Setelah data terkumpul, kita bisa mulai melihat siklus hidup setiap aplikasi. Anda akan menemukan bahwa tidak semua aplikasi dalam kondisi sehat. Beberapa berjalan dengan baik, beberapa sudah tua dan rewel, beberapa ternyata duplikat dari aplikasi lain, dan beberapa hampir tidak pernah dipakai.

Bayangkan Anda membuka spreadsheet hasil inventarisasi. Di baris pertama ada aplikasi pengelolaan pengaduan pelanggan yang sudah berjalan tujuh tahun. Setiap bulan tim IT menerima tiket karena aplikasi ini lambat. Tapi pengguna tetap memakainya karena sudah terbiasa. Aplikasi ini masuk kategori legacy. Masih berfungsi, tapi teknologinya usang, sulit diubah, dan semakin mahal dirawat.

Di baris lain, Anda melihat aplikasi absensi yang dibangun tiga tahun lalu oleh vendor berbeda. Setelah ditelusuri, ternyata fungsinya tumpang tindih dengan modul HR yang sudah ada di sistem ERP. Ini duplicated. Organisasi membayar dua aplikasi untuk pekerjaan yang sama. Siapa yang tahu? Tidak ada yang pernah memetakan aplikasi secara utuh.

Ada juga aplikasi yang tercatat dengan nama menarik, tapi setelah dicek ke pemilik bisnis, ternyata hanya dipakai oleh dua orang di satu cabang. Pemakaiannya sebulan sekali. Biaya lisensi dan maintenance per tahun cukup besar. Ini underused. Aplikasi seperti ini perlu dipertanyakan: apakah masih layak dipertahankan?

Yang paling menyita perhatian biasanya adalah fragile application. Aplikasi ini sering bermasalah. Setiap kali ada perubahan kecil, tim harus ekstra hati-hati karena takut rusak. Dokumentasinya tidak ada. Orang yang membangunnya sudah pindah. Aplikasi seperti ini sebenarnya sudah dalam kondisi kritis. Tapi karena masih dipakai untuk proses utama, tidak ada yang berani menyentuhnya.

Dari sini Anda bisa mulai mengelompokkan aplikasi ke dalam kategori siklus hidup. Active adalah aplikasi yang berjalan normal, dipakai sesuai fungsi, dan biaya perawatannya wajar. Legacy adalah aplikasi yang masih berfungsi tapi sudah usang. Duplicated adalah aplikasi yang tumpang tindih. Underused adalah aplikasi yang pemakaiannya rendah. Fragile adalah aplikasi yang rapuh dan berisiko tinggi.

Berikut adalah contoh tabel yang merangkum hasil klasifikasi aplikasi dari inventaris.

Nama Aplikasi Kategori Ciri-ciri Tindakan yang Disarankan
Pengelolaan Pengaduan Pelanggan Legacy Berjalan 7 tahun, lambat, teknologi usang, biaya maintenance tinggi Modernisasi atau ganti dengan sistem baru
Aplikasi Absensi Vendor X Duplicated Fungsinya tumpang tindih dengan modul HR di ERP Retire, alihkan ke ERP
Aplikasi Laporan Cabang Underused Hanya dipakai 2 orang, sebulan sekali, biaya lisensi besar Evaluasi kebutuhan, retire jika tidak kritis
Sistem Permintaan Pelanggan Lama Fragile Sering error, dokumentasi hilang, pengembang asli sudah pindah Modernisasi jika masih dibutuhkan, atau retire jika ada pengganti

Berikut adalah diagram state yang merangkum siklus hidup aplikasi berdasarkan kondisi yang ditemukan saat inventarisasi.

flowchart TD D[Discovered] -->|berjalan normal| H[Healthy] D -->|teknologi usang| L[Legacy] D -->|tumpang tindih fungsi| Dup[Duplicated] D -->|jarang dipakai| U[Underused] D -->|rapuh dan berisiko| F[Fragile] L -->|fungsi masih dibutuhkan| M[Candidate for Modernization] F -->|fungsi masih dibutuhkan| M Dup -->|fungsi tercakup aplikasi lain| R[Candidate for Retirement] U -->|fungsi tercakup aplikasi lain| R F -->|ada pengganti| R

Lalu ada dua kategori keputusan. Candidate for modernization adalah aplikasi yang fungsinya masih dibutuhkan, tapi kondisi teknisnya sudah tidak mendukung. Aplikasi ini perlu diperbarui, bukan diganti total. Candidate for retirement adalah aplikasi yang sebaiknya dimatikan. Mungkin karena sudah tidak dipakai, atau fungsinya sudah tercakup oleh aplikasi lain.

Contoh nyata: sebuah perusahaan logistik menemukan aplikasi pencatatan permintaan pelanggan yang dibangun lima belas tahun lalu. Aplikasi ini masih dipakai oleh tim operasi, tapi setiap kali ada perubahan aturan regulasi, tim IT butuh waktu berminggu-minggu untuk mengubah kode. Biaya maintenance tahunan mencapai ratusan juta. Aplikasi ini jelas fragile dan mahal. Tapi karena masih dipakai, manajemen ragu mematikannya. Setelah diinventarisasi, ternyata ada modul permintaan pelanggan di sistem baru yang bisa menggantikannya. Maka aplikasi lama masuk candidate for retirement.

Klasifikasi ini bukan sekadar label. Fungsinya untuk membantu Anda dan organisasi mengambil keputusan. Tidak semua aplikasi perlu diselamatkan. Tidak semua aplikasi perlu dimodernisasi. Beberapa cukup dirawat apa adanya. Beberapa harus segera dipensiunkan agar biaya tidak terus mengalir.

Setelah Anda membaca siklus hidup setiap aplikasi, langkah selanjutnya adalah membongkar aplikasi-aplikasi itu menjadi bagian yang lebih kecil. Karena aplikasi bukanlah satu kesatuan yang monolit. Di dalamnya ada modul, layanan, data, dan integrasi yang bisa dipahami secara terpisah.