14.6 Mulai dari Meja Kerja: Cara Berpikir Arsitektural

Kembali ke pertanyaan di akhir subbab sebelumnya: jika label tidak menjamin kemampuan, lalu bagaimana seseorang bisa mulai berpikir seperti arsitek dari pekerjaan hariannya? Jawabannya sederhana: mulai dari meja kerja sendiri, tanpa menunggu promosi jabatan atau proyek besar.

Bayangkan Anda sedang mengerjakan fitur baru: form pendaftaran pengguna. Tugas yang terlihat biasa. Sebagai programmer, Anda akan menulis kode untuk menerima input, validasi, dan menyimpan ke database. Sebagai engineer, Anda akan memastikan validasi berjalan di semua skenario, koneksi database tidak putus di tengah jalan, dan response time masih wajar. Tapi bagaimana dengan cara berpikir arsitektural?

Coba tambahkan satu pertanyaan sebelum menulis baris pertama: “Apa yang terjadi jika fitur ini gagal?” Bukan sekadar error handling di kode, tapi benar-benar bayangkan skenarionya. Server down saat pengguna menekan tombol daftar. Data setengah masuk. Pengguna mengulang pendaftaran dan mendapat dua akun. Siapa yang akan membersihkan data kotor itu? Berapa lama waktu yang dibutuhkan? Apakah tim support tahu cara menanganinya? Pertanyaan-pertanyaan ini mengubah cara Anda melihat fitur: dari sekadar kode yang berfungsi, menjadi keputusan yang membawa konsekuensi.

Misalnya, Anda bisa mencoba simulasi sederhana dengan curl untuk merasakan sendiri bagaimana server yang lambat atau down memengaruhi pengalaman pengguna:

# Simulasi server down: timeout koneksi setelah 3 detik
curl --connect-timeout 3 --max-time 5 -X POST https://api.example.com/register \
  -H "Content-Type: application/json" \
  -d '{"email":"user@example.com","password":"secret123"}'

# Respons yang mungkin muncul:
# curl: (28) Connection timed out after 3001 milliseconds

Lalu tanyakan: “Siapa yang terdampak?” Form pendaftaran tidak hanya menyentuh database. Tim marketing butuh data pengguna baru untuk campaign. Tim legal butuh persetujuan pengguna yang tercatat dengan benar. Tim customer service butuh tahu apakah pengguna sudah terdaftar atau belum saat mereka menelepon. Jika fitur ini gagal, semua pihak itu ikut terdampak. Anda mulai melihat bahwa satu fitur adalah bagian dari sistem yang lebih besar, dan sistem itu melayani manusia.

Pertanyaan ketiga: “Bagaimana ini dirawat setahun lagi?” Kode yang Anda tulis hari ini mungkin akan dibaca oleh orang lain, atau oleh Anda sendiri, enam bulan mendatang. Apakah struktur datanya masih masuk akal jika jumlah pengguna naik sepuluh kali lipat? Apakah logika bisnisnya mudah ditemukan dan diubah tanpa merusak bagian lain? Apakah ada dokumentasi yang menjelaskan kenapa keputusan tertentu diambil? Arsitek tidak hanya memikirkan bagaimana sistem bekerja hari ini, tetapi bagaimana sistem itu tetap bisa dirawat dan dikembangkan di masa depan.

Tiga pertanyaan ini—apa yang terjadi jika gagal, siapa yang terdampak, bagaimana dirawat nanti—adalah awal dari cara berpikir arsitektural. Anda tidak perlu menunggu diberi tanggung jawab atas sistem besar. Mulai dari fitur kecil di meja kerja. Setiap kali selesai menulis kode, luangkan lima menit untuk menjawab tiga pertanyaan itu. Catat jawabannya, diskusikan dengan tim, dan lihat bagaimana keputusan Anda berubah.

Berikut diagram alur yang merangkum tiga pertanyaan tersebut dan bagaimana masing-masing membuka pertimbangan lebih dalam:

flowchart TD A[Fitur Baru: Form Pendaftaran Pengguna] --> B{Apa yang terjadi jika gagal?} A --> C{Siapa yang terdampak?} A --> D{Bagaimana dirawat nanti?} B --> B1[Server down saat submit] B --> B2[Data setengah masuk] B --> B3[Duplikasi akun] C --> C1[Tim Marketing: butuh data campaign] C --> C2[Tim Legal: butuh persetujuan tercatat] C --> C3[Customer Service: cek status registrasi] D --> D1[Logging & monitoring memadai?] D --> D2[Dokumentasi keputusan desain?] D --> D3[Skalabilitas jika pengguna 10x lipat?]

Seiring waktu, kebiasaan ini akan membentuk pola pikir yang melihat setiap keputusan teknis sebagai bagian dari sistem yang lebih besar. Anda tidak lagi hanya bertanya “apakah kode ini berfungsi?”, tetapi “apakah keputusan ini baik untuk sistem dan orang-orang yang menggunakannya?” Di sinilah perbedaan antara programmer, engineer, dan architect mulai terlihat bukan dari label, tetapi dari cara bertanya dan cara memutuskan.

Dan ketika Anda sudah mulai terbiasa dengan pertanyaan-pertanyaan ini, AI bisa menjadi alat yang mempercepat kemampuan Anda. Bukan hanya menulis kode lebih cepat, tetapi membantu Anda memikirkan skenario, dampak, dan konsekuensi lebih dalam. Itu menjadi arah pembahasan berikutnya: bagaimana AI menjadi pengungkit untuk memperluas cara berpikir dan kualitas keputusan.