Belajar Enterprise Architect - Resilience & Continuity

#Pendahuluan

Setelah di episode 19 regulasi diterjemahkan menjadi kontrol dan bukti otomatis, kita menutup blok keamanan lanjutan dengan pertanyaan paling tua sekaligus paling relevan: apa yang terjadi saat semuanya gagal? Resilience and continuity adalah disiplin memastikan organisasi tetap beroperasi — atau pulih cepat — saat insiden datang: outage cloud regional, ransomware, kegagalan vendor core, bahkan bencana fisik.

Mengapa ini ranah EA? Karena resilience adalah trade-off biaya yang harus diputuskan per kapabilitas, bukan slogan. Availability 100% itu mitos yang mahal; pertanyaan arsitekturnya adalah kapabilitas mana yang butuh pulih dalam hitungan menit, mana yang boleh berhari-hari, dan berapa rupiah kesediaan organisasi membayar untuk tiap derajat kesiapan itu.

#Business Impact Analysis: Titik Awal

Semua angka resilience turunan dari Business Impact Analysis (BIA) — latihan menjawab dua pertanyaan per kapabilitas: berapa kerugian per jam ketika mati (downtime cost), dan berapa banyak data yang boleh hilang (data loss tolerance):

Dua definisi yang wajib presisi karena seluruh desain mengikutinya: RTO (recovery time objective) — target maksimal waktu sampai layanan kembali; RPO (recovery point objective) — usia maksimal data yang boleh hilang saat pulih. RPO nol berarti replikasi sinkron; RPO 24 jam berarti backup harian cukup. Tiap level RTO/RPO punya harga arsitektur yang sangat berbeda — inilah mengapa tier dibuat eksplisit dan disahkan bisnis, bukan diasumsikan engineer.

#DR Architecture: Desain per Tier

Dengan tier terdefinisi, pola DR mengikuti secara alami — dari termurah ke termahal: backup & restore (tier 3), pilot light (core direplikasi tapi idle, tier 2), warm standby (versi scaled-down live, tier 1-2), hot active-active multi-region (tier 1 kritis). Untuk Bumi Niaga:

• Core payment BayarKu: hot standby di zona kedua on-premise/cloud lokal dengan replikasi semi-sinkron; RPO mendekati nol. Batasan regulasi episode 19 berarti region kedua tetap dalam yurisdiksi — cek dulu, rancang kemudian.
• Checkout & order: warm standby di cloud primer; failover terotomatisasi dengan runbook teruji.
• Analitik: restore dari backup cross-region; kehilangan sehari diterima dan sudah disahkan.

Komponen yang hampir selalu terlewat namun menentukan: backup immutable — salinan yang tak bisa dihapus bahkan oleh admin (pertahanan utama ransomware), runbook failover tertulis per layanan dengan kriteria keputusan eksplisit (siapa memutuskan switchover? ambang apa?), dan dependency mapping — layanan tier 1 sering gagal pulih karena dependensinya (DNS, IdP, secrets manager) tidak ikut dalam lingkup DR. Ingat: identitas terfederasi (episode 7) berarti IdP down = semua aplikasi down; IdP sendiri wajib tier 1.

#BCP: Lebih Luas dari IT

Business Continuity Plan melampaui sistem: manusia, tempat, proses, dan pihak ketiga. Struktur minimum yang layak:

Trigger & aktivasi : siapa menyatakan kondisi darurat, kriteria objektif
War room           : komunikasi out-of-band (saat chat korporat ikut down)
Proses alternatif  : cara manual beroperasi terbatas (order offline,
                     settlement deferred) per kapabilitas tier 1-2
Vendor contingency : SLA darurat vendor core; alternatif sementara
Komunikasi krisis  : urutan pesan ke pelanggan/regulator/mitra,
                     template sudah disiapkan, juru bicara tunggal
Return-to-normal   : kriteria dan langkah failback yang aman

Failback layak digarisbawahi: kembali ke environment utama setelah insiden adalah operasi berisiko tersendiri yang butuh rencana — banyak organisasi berhasil failover lalu menciptakan outage kedua saat balik malam tanpa latihan.

#Latihan: Satu-Satunya Bukti

Rencana yang tidak diuji adalah fiksi. Piramida latihan dari murah ke mahal: tabletop exercise (walkthrough skenario bersama owner, per kuarter), component failover test (database switch ke replica di maintenance window), game day penuh (simulasikan kegagalan region di environment staging, tiap semester), dan chaos engineering produksi yang hati-hati (inject failure kecil pada jam tenang, untuk sistem yang sudah matang). Setiap latihan menghasilkan temuan terdokumentasi yang masuk backlog — metrik kesehatan resilience bukan "punya dokumen BCP", melainkan waktu sejak latihan terakhir sukses dan jumlah temuan latihan yang masih terbuka.

Terhubung ke strategy episode 18: Recover adalah fungsi CSF yang biasanya paling matang rendahnya — dan roadmap wave 3 kalian harus menampung program latihan ini sebagai investasi eksplisit, bukan kegiatan sukarela tim ops.

#Kriteria Keputusan Failover

Runbook tanpa kriteria keputusan hanya daftar langkah — saat insiden nyata, pertanyaan "kapan kita memutuskan switchover?" adalah yang paling mahal dijawab improvisasi. Tetapkan eksplisit:

Trigger otomatis : error rate > 50% selama 5 menit ATAU region down
                   -> failover mulai tanpa menunggu rapat
Zona abu-abu     : error rate 20-50% > 10 menit -> war room, keputusan
                   manual oleh incident commander (on-call rota)
Batasan bisnis   : veto CFO untuk switchover di settlement window
                   akhir bulan (risiko rekonsiliasi)
Selama failover  : freeze semua release lintas grup
Setelah pulih    : post-mortem blameless <= 5 hari; temuan masuk
                   backlog DR dengan owner dan tenggat

Latih kriteria ini di tabletop exercise: kasus zona abu-abu justru yang paling berharga dilatih, karena trigger otomatis mudah — keputusan pada 30% error rate dengan settlement window berjalan adalah tempat organisasi menguji kematangan sebenarnya.

#Praktik: Resilience Plan Bumi Niaga

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

1. BIA + tiering — lengkapi tabel BIA minimal 10 kapabilitas; dapatkan "persetujuan" fiktif CFO atas biaya tiap tier.
2. DR pattern per tier — tentukan pola (backup/pilot light/warm/hot) untuk tiap layanan utama beserta estimasi biaya relatifnya; tandai batasan regulasi BayarKu.
3. Dependency map tier 1 — gambar rantai dependensi checkout sampai ke IdP/DNS/secrets; tandai tiga single point of failure.
4. Rencana latihan tahunan — jadwal tabletop/game-day/failover-test dengan scope, partisipan, dan metrik sukses per sesi.

#Penutup

Inti yang harus dibawa pulang:

• Resilience dimulai dari BIA yang menghasilkan tier eksplisit: RTO/RPO per kapabilitas disahkan bisnis karena harganya berbeda tajam antar tier.
• Pola DR dipilih per tier — dari backup restore sampai active-active — dengan komponen wajib yang sering luput: backup immutable, runbook dengan kriteria keputusan, dan dependensi transversal seperti IdP.
• BCP melampaui IT: aktivasi, komunikasi out-of-band, proses manual, vendor contingency, dan failback plan.
• Latihan berjenjang adalah satu-satunya bukti kesiapan; metrik kesehatannya adalah frekuensi latihan sukses dan umur temuan yang belum ditutup.

Fase 4 selesai. Fase 5 dibuka dengan topik yang sedang mengubah seluruh profesi ini: AI enterprise architecture — merumuskan AI strategy tingkat grup, membangun governance model AI yang tidak membunuh inovasi, dan menyiapkan fondasi data-and-platform yang membuat Bumi Niaga siap AI di 2026. Sampai jumpa di episode 21!