Cara Menemukan Silent Failure Path

Silent failure path adalah istilah untuk kegagalan yang tidak pernah digambar dalam diagram — bukan karena tidak mungkin terjadi, tapi karena pembuat diagram lupa memikirkannya. Diagram jenis ini terlihat lengkap dan rapi, padahal menyembunyikan lubang besar.

Kenapa Ini Berbahaya

Diagram di atas terlihat sempurna: Ajukan Approval → Proses Disetujui → selesai. Tidak ada elemen yang salah gambar, tidak ada gateway yang tidak simetris. Justru di situlah masalahnya — tidak ada satu pun tanda visual bahwa diagram ini salah. Ia hanya tampak "terlalu simpel" untuk proses approval yang realistis.

Kalau diagram ini diimplementasikan apa adanya, sistem tidak akan tahu harus berbuat apa ketika pengajuan ditolak atau tidak direspons dalam waktu wajar — karena kedua skenario itu memang tidak pernah digambarkan.

Cara Berburu Silent Failure Path

Silent failure path tidak bisa ditemukan dengan memeriksa struktur diagram (karena strukturnya valid). Ia hanya bisa ditemukan dengan menanyakan pertanyaan yang tidak dijawab diagram:

1. Untuk setiap Task yang butuh keputusan manusia — apa jalur kalau jawabannya "tidak" atau "ditolak"?
2. Untuk setiap Task yang menunggu input eksternal — apa jalur kalau input itu tidak pernah datang (timeout)?
3. Untuk setiap Task yang memanggil sistem lain — apa jalur kalau panggilan itu gagal atau error?
4. Untuk setiap Exclusive Gateway — apakah kondisi yang ada benar-benar mencakup semua kemungkinan, atau ada Default Flow yang hilang?

Diterapkan ke contoh di atas: Task "Ajukan Approval" jelas butuh keputusan manusia — tapi diagramnya hanya menggambarkan hasil "disetujui". Pertanyaan "apa jalur kalau ditolak?" tidak terjawab sama sekali oleh diagram ini.

Silent Failure Path vs Anti-Pattern Biasa

Bedanya dengan anti-pattern seperti dangling gateway atau orphan task: anti-pattern biasa terlihat saat diagram dibaca (ada elemen yang janggal secara struktur). Silent failure path tidak terlihat — justru ketidakhadirannya yang jadi masalah. Ini sebabnya teknik menemukannya berbeda: bukan memeriksa apa yang ada di diagram, tapi mempertanyakan apa yang seharusnya ada tapi tidak digambar.

:::tip Kebiasaan yang perlu dilatih Setiap kali selesai membaca sebuah Task yang melibatkan keputusan, sistem eksternal, atau ketergantungan pada pihak lain, biasakan bertanya: "Kalau ini gagal, ke mana proses ini pergi?" Kalau tidak ada jawaban di diagram, itu temuan yang harus dilaporkan ke pembuat diagram. :::

---

Lanjut ke Katalog Anti-Pattern Lewat Kacamata Reading Grammar, atau baca dulu dasarnya di Cara Membaca Exception dan Error Handling.