Belajar Enterprise Architect - Application Portfolio Management

#Pendahuluan

Setelah di episode 5 kalian menyelesaikan fragmentasi data pelanggan lewat EDM, MDM registry-first, dan platform data grup, sekarang kita bergerak ke domain yang paling terlihat kekacauannya di hampir setiap enterprise: application architecture. Temuan episode 3 masih menggantung — dua CRM, tiga sistem notifikasi, dua BI tool di satu grup usaha.

Domain ini penting karena anggaran TI terbesar biasanya habis bukan untuk inovasi, melainkan untuk memelihara aplikasi yang sudah ada. Tanpa pengelolaan portofolio yang sadar, biaya pemeliharaan merayap naik tiap tahun dan ruang investasi baru menyempit. Alat kerjanya: application portfolio management (APM) dengan siklus inventaris, penilaian, rasionalisasi, dan roadmap.

#Inventaris: Fondasi yang Sering Dilewati

Sebelum menilai apa pun, kalian butuh daftar yang benar. Pengalaman lapangan: pertanyaan sederhana "berapa aplikasi kita?" hampir selalu dijawab beda oleh tiga orang berbeda — karena definisi "aplikasi" tidak pernah disepakati. Tetapkan dulu unit hitungan:

• Aplikasi = perangkat lunak yang dikelola sebagai satu unit lifecycle (deployed, licensed, upgraded bersama), punya owner organisasi dan user nyata.
• Bukan aplikasi: library internal, script sekali pakai, environment dev-only, SaaS gratis tanpa data bisnis (tapi waspadai shadow IT).

Atribut minimum per aplikasi yang layak dikumpulkan:

Untuk ~40 aplikasi Bumi Niaga, spreadsheet cukup; di atas ratusan, EA repository komersial seperti LeanIX layak dipertimbangkan (kita siapkan di episode 10).

#Penilaian dengan Matriks TIME

Matriks standar industri adalah TIME — dua sumbu: nilai fungsional/bisnis saat ini dan kelayakan teknologi (health). Persilangannya memberi empat disposisi:

Empat disposisinya:

• Tolerate — bernilai, sehat; biarkan, jaga saja. Jangan rombak tanpa alasan bisnis.
• Invest — bernilai tapi rapuh; ini kandidat modernisasi dengan argumen terkuat.
• Migrate — nilainya sedang, healthnya buruk; ganti atau konsolidasikan saat momentum tepat.
• Eliminate — tak bernilai dan bermasalah; matikan, jangan tunggu proyek besar.

Dua kesalahan penilaian yang paling sering: pertama, semua aplikasi dinilai "strategis" karena tiap owner membela sistemnya — solusinya gunakan data (biaya, insiden, jumlah user aktif) sebagai pemberat diskusi. Kedua, matriks dipakai sebagai keputusan final dalam satu rapat — padahal ia alat percakapan; disposisi awal akan berevolusi setiap review kuarteran.

#Rasionalisasi: Menutup Celah Duplikasi

Rasionalisasi adalah proses mengurangi redundansi dan kompleksitas portofolio. Untuk Bumi Niaga, target jelas dari episode 3: dua CRM, tiga sistem notifikasi, dua BI tool. Pola keputusan yang saya pakai:

Terjemahkan ke kasus konkret. CRM: di bawah operating model Coordination (episode 4), proses penjualan tiap lini otonom — maka memaksa satu CRM untuk retail dan fintech adalah over-standardization. Keputusan yang lebih tajam: pertahankan dua CRM dalam jangka pendek, tetapi wajibkan keduanya bicara ke Customer Registry lewat kontrak API seragam, dan tetapkan arah konsolidasi jangka panjang begitu vendor contract renewal memberi momen negosiasi. Notifikasi: tiga sistem untuk email/SMS murni pemborosan — satu service notifikasi terpusat dengan template dan consent check, dipakai ketiga lini. BI: satu platform analitik di atas data platform grup (episode 5), sandbox bebas di atasnya.

#Dari Penilaian ke Roadmap Aplikasi

Hasil TIME dan rasionalisasi diterjemahkan menjadi urutan gerakan 18-24 bulan. Format ringkas yang efektif:

Wave 0 (kuarter ini)   - Notifikasi service terpusat v1 (BayarKu pilot)
                       - Customer Registry live: CRM BelanjaKu + wallet BayarKu
Wave 1                 - Migrasi notifikasi KirimKu; matikan 2 sistem lama
                       - BI tool lini digabung ke platform analitik grup
Wave 2                 - CRM fintech evaluation di momen contract renewal
                       - Legacy warehouse BelanjaKu dimusnahkan (data sudah di lakehouse)
Prinsip                - Tidak ada fitur baru pada sistem bertanda Eliminate
                       - Setiap proyek baru wajib integrasi via registry/API, bukan DB langsung

Perhatikan prinsip terakhir: disposisi hanya berguna jika memengaruhi perilaku harian — permintaan fitur pada aplikasi Eliminate harus bisa ditolak dengan rujukan formal. Mekanisme formalnya adalah governance yang kita bangun di episode 9.

#Praktik: Portfolio Map Bumi Niaga

Kerjakan di ea-lab/case-study/application/:

1. Inventaris — daftarkan ±40 aplikasi (beri nama fiktif realistis) dengan atribut tabel di atas; lengkapi kolom kapabilitas dari capability map episode 4.
2. Penilaian TIME — tempatkan semua aplikasi ke empat kuadran; tulis justifikasi singkat untuk 10 aplikasi terbesar berdasarkan biaya.
3. Rencana rasionalisasi — detail keputusan CRM/notifikasi/BI sesuai pola di atas, plus satu temuan duplikasi tambahan hasil analisis kalian sendiri.
4. Roadmap wave — susun tiga wave dengan aturan mainnya; tandai dependensi ke Customer Registry dan platform data dari episode 5.

#Penutup

Inti yang harus dibawa pulang:

• Portofolio dikelola lewat siklus: inventaris dengan definisi "aplikasi" yang disepakati, penilaian TIME, rasionalisasi, lalu roadmap ber-wave.
• Matriks TIME adalah alat percakapan yang diberi bobot data — biaya, insiden, user aktif — bukan verdict sekali jalan.
• Rasionalisasi cerdas menghormati operating model: Coordination tidak memaksa satu CRM, tetapi memaksa kontrak API seragam ke Customer Registry.
• Disposisi portofolio baru bernilai jika memengaruhi keputusan harian — aturan "tidak ada fitur baru di sistem Eliminate" adalah contoh pagarnya.

Portofolio aplikasi sudah punya arah. Di episode 7 selanjutnya kita turun ke domain paling dasar: technology architecture — strategi infrastruktur dan cloud untuk ketiga lini yang tersebar AWS/GCP/on-premise, penetapan technology standards, dan penyusunan tech roadmap termasuk kelola obsolescence. Sampai jumpa di episode 7!