Setiap kali sebuah proyek IT terhenti di tengah jalan—anggaran jebol, tenggat waktu dilanggar, atau sistem yang diluncurkan justru tidak bisa dipakai—ada satu pihak yang hampir selalu menjadi sasaran pertama: tim developer. Mereka dianggap lambat, tidak kompeten, atau tidak mampu memenuhi ekspektasi. Padahal, kalau mau jujur dan mau menggali lebih dalam, masalahnya jarang sekali berasal dari baris kode yang mereka tulis.

Masalahnya sudah ada jauh sebelum itu. Masalahnya ada di meja perencanaan, di dokumen arsitektur yang dibuat terburu-buru, atau bahkan di keputusan desain sistem yang tidak pernah benar-benar diuji sebelum sprint pertama dimulai.

Angka yang Tidak Bisa Dibantah

Sejak 1994, The Standish Group secara rutin menerbitkan laporan yang dikenal sebagai CHAOS Report—salah satu rujukan paling sering dikutip dalam dunia manajemen proyek teknologi. Temuannya konsisten dan, terus terang, cukup mengkhawatirkan.

Pada laporan awalnya, hanya 16,2% proyek perangkat lunak yang selesai tepat waktu dan sesuai anggaran. Lebih dari 31% dibatalkan sebelum rampung. Dan untuk perusahaan berskala besar, angka keberhasilan turun drastis hingga hanya 9% (The Standish Group, 1994).

Laporan CHAOS edisi 2020 menunjukkan bahwa kondisinya belum banyak membaik: hanya 31% proyek dikategorikan berhasil, sementara 50% mengalami hambatan serius dan 19% gagal sepenuhnya (dikutip dalam ACM Queue, 2024). Penelitian yang diterbitkan melalui IEEE Access juga menemukan sesuatu yang menarik—dari 37 akar penyebab kegagalan proyek IT besar yang diidentifikasi, hanya satu yang berhubungan langsung dengan pemrograman (Lauesen, 2020, IEEE Access).

Satu dari tiga puluh tujuh.

Artinya, 36 penyebab lainnya berasal dari luar ranah teknis developer. Dari perencanaan yang buruk. Dari arsitektur yang salah. Dari ekspektasi yang tidak pernah diuji di lapangan.

Tiga Dosa Fatal Desain Sistem

1. Arsitektur yang Dirancang oleh Orang yang Tidak Memahami Bisnisnya

Ini adalah akar dari sebagian besar kegagalan yang paling mahal. Sebuah sistem dirancang oleh arsitek teknis yang cemerlang secara konseptual, tetapi tidak cukup memahami bagaimana bisnis sebenarnya beroperasi—regulasi yang berlaku, alur kerja yang nyata di lapangan, atau kebutuhan pengguna yang berubah setiap kuartal.

Hasilnya adalah sistem yang secara teknis bisa berjalan, tetapi secara fungsional tidak berguna. Atau lebih buruk: sistem yang berjalan dengan baik sampai ada perubahan regulasi kecil, lalu seluruh fondasi arsitekturnya harus dirobohkan.

Penelitian di bidang Enterprise Architecture (EA) yang dipublikasikan melalui ResearchGate menunjukkan bahwa kegagalan inisiatif EA paling sering bermula dari lemahnya pemahaman manajer puncak tentang arsitektur IT dan minimnya keselarasan antara arsitek sistem dengan arah bisnis (Critical Failure Factors in Information System Projects, ResearchGate, 2025). Ini bukan soal kemampuan teknis. Ini soal keselarasan domain.

Analisis ini sering kami temukan saat melakukan penetration testing pada perusahaan di Indonesia—sistem yang dibangun tanpa mempertimbangkan standar keamanan sejak tahap arsitektur justru menjadi pintu masuk yang paling mudah dieksploitasi. Celah bukan muncul karena developer yang ceroboh, melainkan karena desain sistem yang tidak pernah mempertimbangkan skenario ancaman sejak awal.

2. Requirement Dikunci Sebelum Discovery Selesai

Ada kebiasaan yang lazim terjadi dalam proyek IT di banyak organisasi: dokumen spesifikasi kebutuhan (requirement specification) diselesaikan dalam waktu singkat, ditandatangani oleh pemangku kepentingan, lalu diserahkan ke tim developer seolah-olah itulah kebenaran mutlak yang tidak boleh digugat.

Masalahnya, discovery yang terburu-buru menghasilkan requirement yang tidak lengkap atau—yang lebih berbahaya—requirement yang salah sejak awal. The Standish Group sendiri mengidentifikasi bahwa pernyataan kebutuhan yang jelas adalah salah satu dari tiga faktor paling penting penentu keberhasilan proyek. Namun ironisnya, fase ini justru yang paling sering diringkas.

Penelitian dalam International Journal of Project Management (Savolainen, Ahonen & Richardson, 2012) menegaskan bahwa perspektif penyedia layanan dan perspektif pemangku kepentingan bisnis sering kali tidak pernah benar-benar bertemu dalam satu pemahaman yang sama—dan ketidakselarasan ini baru terlihat ketika sistem sudah terlanjur dibangun separuh jalan.

Developer tidak bisa menulis kode yang benar untuk requirement yang salah. Tidak ada satupun teknologi, framework, atau metodologi yang bisa menyelamatkan proyek dari fondasi yang keliru.

3. Tidak Ada Architecture Review yang Serius Sebelum Development Dimulai

Architecture Decision Record (ADR) dan proses tinjauan arsitektur sebelum sprint pertama adalah praktik yang dikenal luas di komunitas software engineering—tetapi jarang benar-benar diterapkan dengan ketat, terutama di lingkungan yang tertekan oleh deadline bisnis.

Apa yang terjadi kemudian sudah bisa ditebak. Tim developer mulai membangun di atas fondasi yang belum divalidasi. Asumsi-asumsi teknis yang seharusnya diuji di awal baru terungkap di tengah jalan—ketika biaya perubahan sudah jauh lebih mahal. Ini yang dalam praktik rekayasa perangkat lunak disebut sebagai technical debt struktural: utang yang tidak muncul dari kemalasan developer, melainkan dari keputusan arsitektur yang tidak dipikirkan matang sejak awal.

Sebuah Skenario yang Terlalu Sering Terjadi

Bayangkan sebuah perusahaan teknologi finansial yang memulai pembangunan platform pinjaman digital. Anggaran ditetapkan, timeline disepakati, tim developer dikumpulkan. Dokumen requirement selesai dalam tiga minggu—padahal discovery idealnya membutuhkan waktu dua hingga tiga kali lipat.

Delapan bulan kemudian, tim baru menyadari bahwa skema database yang dibangun tidak mampu mengakomodasi mekanisme pelaporan yang diwajibkan oleh regulasi Otoritas Jasa Keuangan (OJK)—regulasi yang sudah ada dan bisa dipelajari sejak hari pertama. Seluruh lapisan data harus dirancang ulang. Biaya bengkak. Timeline mundur enam bulan.

Siapa yang disalahkan? Developer, tentu saja.

Padahal tidak ada satupun baris kode yang salah secara teknis. Yang salah adalah tidak ada seorang pun yang duduk bersama dan bertanya: "Apa saja regulasi yang harus dipenuhi sistem ini sebelum kita merancang skema datanya?"

Kontra-Argumen: Apakah Developer Selalu Tidak Bersalah?

Perlu ditegaskan dengan jujur: developer bisa dan memang kadang berkontribusi pada masalah. Pilihan teknologi yang tidak tepat, resistensi terhadap refactoring, atau komunikasi yang buruk dalam tim—semua itu nyata dan tidak bisa diabaikan.

Namun ada perbedaan mendasar antara faktor yang memperburuk masalah dan akar penyebab kegagalan itu sendiri. Penelitian taksonomi kegagalan proyek IT yang diterbitkan dalam International Management Review (Al-Ahmad et al., 2009) memang mengidentifikasi keterbatasan keahlian tim sebagai salah satu faktor, tetapi faktor ini berada jauh di bawah persoalan perencanaan, pengelolaan scope, dan desain sistem dalam hal frekuensi dan dampaknya.

Menyalahkan developer atas kegagalan yang berakar dari desain sistem adalah seperti menyalahkan kontraktor bangunan karena gedung yang mereka bangun runtuh—padahal blueprintnya yang salah sejak awal.

Apa yang Seharusnya Dilakukan Sebelum Satu Baris Kode Pun Ditulis

Tidak ada daftar ini yang dimaksudkan sebagai tips motivasi. Ini adalah keputusan bisnis yang memiliki konsekuensi finansial langsung.

Pertama, lakukan domain-driven discovery yang sesungguhnya. Sebelum tim teknis mulai berbicara tentang stack teknologi, tanyakan: apa proses bisnis yang akan diotomasi? Regulasi apa yang harus dipenuhi? Bagaimana sistem ini akan berubah dalam 12 hingga 24 bulan ke depan? Jawaban atas pertanyaan-pertanyaan ini adalah bahan bakar yang menentukan desain arsitektur—bukan sebaliknya.

Kedua, jadikan Architecture Decision Record sebagai kontrak tim. Setiap keputusan arsitektur yang signifikan—pemilihan database, pola komunikasi antar layanan, strategi autentikasi—harus didokumentasikan beserta alasannya dan konsekuensi yang disadari. Ini bukan birokrasi. Ini adalah perlindungan dari pertanyaan "kenapa dulu diputuskan begini?" yang muncul enam bulan kemudian.

Ketiga, pisahkan antara iterasi desain dan kegagalan. Mengubah arah arsitektur di fase discovery adalah tanda bahwa proses bekerja dengan benar—bukan tanda kelemahan. Pivot yang dilakukan sebelum development dimulai bisa menghemat puluhan kali lipat biaya dibandingkan perubahan yang dilakukan setelah sistem sudah dibangun separuh jalan. Penelitian dalam bidang manajemen proyek secara konsisten menunjukkan bahwa biaya perubahan meningkat secara eksponensial seiring kemajuan fase proyek.

Lalu, Siapa yang Sebenarnya Bertanggung Jawab?

Ini bukan pertanyaan retoris. Ini pertanyaan yang harus dijawab setiap organisasi sebelum memulai proyek IT skala besar.

Jika CTO atau VP Engineering menyetujui dokumen arsitektur tanpa validasi domain yang memadai—itu tanggung jawab kepemimpinan teknis. Jika Product Owner menandatangani requirement yang belum benar-benar diuji bersama pengguna akhir—itu tanggung jawab sisi produk. Jika manajemen menetapkan timeline yang tidak memberi ruang untuk discovery yang layak—itu tanggung jawab pengambil keputusan bisnis.

Developer yang berada di ujung rantai keputusan ini tidak memiliki kendali atas fondasi yang sudah ditetapkan jauh sebelum mereka mulai bekerja. Meminta mereka bertanggung jawab atas kegagalan yang berakar di hulu adalah tidak adil dan—yang lebih penting—tidak akan menyelesaikan masalah untuk proyek berikutnya.

Keamanan Sistem Dimulai dari Desain, Bukan dari Patch

Ada satu dimensi lagi yang sering luput dari diskusi tentang kegagalan desain sistem: keamanan siber. Sistem yang tidak dirancang dengan mempertimbangkan keamanan sejak awal tidak hanya rentan secara fungsional—ia rentan secara keamanan. Celah yang ditemukan dalam proses penetration testing hampir selalu dapat ditelusuri kembali ke keputusan arsitektur yang dibuat di fase awal, bukan ke kode yang ditulis developer di kemudian hari.

Ini adalah alasan mengapa pendekatan Security by Design—mengintegrasikan pertimbangan keamanan sejak fase perencanaan arsitektur—bukan sekadar praktik terbaik, melainkan keharusan bisnis.

Saatnya Mengaudit Desain, Bukan Menyalahkan Developer

Jika proyek IT di organisasi Anda terus mengalami keterlambatan, pembengkakan biaya, atau menghasilkan sistem yang tidak sesuai kebutuhan—berhentilah sejenak sebelum mengarahkan jari ke tim teknis. Tanyakan lebih dulu: kapan terakhir kali arsitektur sistem Anda diaudit secara menyeluruh sebelum development dimulai? Apakah requirement Anda divalidasi oleh pengguna nyata, bukan hanya diasumsikan? Apakah keamanan sudah dipertimbangkan sejak blueprint pertama dibuat?

Kegagalan IT development bukan takdir. Ia adalah konsekuensi dari keputusan-keputusan yang bisa diperbaiki—jika mau diakui dengan jujur bahwa masalahnya ada di sana.

Konsultasikan Keamanan Sistem Anda dengan Fourtrezz

Jika organisasi Anda ingin memastikan bahwa sistem yang sedang dibangun atau sudah berjalan memiliki fondasi keamanan yang kuat sejak tahap arsitektur, Fourtrezz (PT Tiga Pilar Keamanan) hadir sebagai mitra yang tepat.

Fourtrezz adalah perusahaan keamanan siber Indonesia yang berpengalaman dalam layanan Penetration Testing dan Vulnerability Assessment. Fourtrezz membantu perusahaan dari berbagai sektor industri menemukan dan menutup celah keamanan sebelum dieksploitasi pihak yang tidak bertanggung jawab.

Bukan sekadar menemukan masalah—Fourtrezz memberikan laporan terperinci yang dapat langsung ditindaklanjuti oleh tim teknis maupun pengambil keputusan bisnis.

Hubungi Fourtrezz:

• Website: www.fourtrezz.co.id
• Telepon / WhatsApp: +62 857-7771-7243
• Email: [email protected]