Isi Minimum yang Harus Ada

11.2 Isi Minimum yang Harus Ada

Setelah memahami tujuan dokumen, kita perlu tahu isi minimal yang harus ada di dalamnya. Bayangkan Anda adalah solution architect yang baru ditugaskan menangani aplikasi baru itu. Tim produk sudah punya daftar fitur. Engineer sudah mulai bertanya tentang database apa yang dipakai. Operation ingin tahu cara deploy-nya. Security ingin review sebelum kode masuk produksi. Manajemen ingin tahu kapan selesai dan berapa biayanya.

Anda harus menulis satu dokumen yang menjawab semua pertanyaan itu. Tapi Anda juga tidak punya waktu menulis novel setebal 200 halaman. Yang Anda butuhkan adalah struktur minimum yang mencakup semua informasi penting, tanpa membuat dokumen terasa seperti template kaku yang diisi asal-asalan.

Struktur minimum itu terdiri dari sembilan bagian. Masing-masing punya fungsi spesifik, dan bersama-sama mereka membentuk cerita yang utuh tentang solusi yang akan dibangun.

Bagian pertama adalah context. Ini menjelaskan situasi yang mendorong pembuatan solusi. Bukan visi besar perusahaan, tetapi masalah konkret yang harus diselesaikan. Misalnya: "Saat ini proses permintaan layanan membutuhkan waktu 14 hari karena verifikasi dokumen masih manual. Aplikasi baru ini akan memangkas waktu menjadi 3 hari dengan otomatisasi verifikasi." Context membuat semua pembaca dokumen memahami mengapa solusi ini ada.

Kedua, scope. Bagian ini mendefinisikan batas solusi: apa yang masuk dan apa yang tidak. Scope mencegah ekspektasi yang meluas. Jika aplikasi baru hanya menangani refund produk digital, tuliskan dengan jelas bahwa komplain pengiriman tidak termasuk. Tanpa scope, tim produk bisa tiba-tiba meminta fitur baru yang seharusnya tidak ada di rilis pertama.

Ketiga, requirement. Ini adalah kebutuhan fungsional dan non-fungsional yang harus dipenuhi. Requirement non-fungsional sering dilupakan padahal paling berdampak: berapa pengguna bersamaan, berapa response time yang bisa diterima, bagaimana data disimpan, dan berapa uptime yang dijanjikan. Requirement inilah yang menjadi dasar keputusan teknis di bagian selanjutnya.

Keempat, option. Di sinilah arsitek menunjukkan pekerjaannya. Untuk setiap keputusan besar, tuliskan opsi yang dipertimbangkan. Misalnya untuk database: opsi A adalah PostgreSQL, opsi B adalah MongoDB. Jangan hanya menulis opsi yang dipilih. Tuliskan semua opsi yang serius dipertimbangkan, lengkap dengan alasan mengapa opsi lain tidak dipilih. Bagian ini yang akan di-review oleh engineer senior dan arsitek lain.

Kelima, decision. Setelah opsi, tuliskan keputusan yang diambil dan alasannya. Setiap keputusan harus bisa dilacak kembali ke requirement. Jika memilih PostgreSQL karena kebutuhan transaksional yang ketat, tuliskan itu. Decision log ini akan menjadi referensi ketika di masa depan ada yang bertanya "kenapa pakai database ini?"

Keenam, diagram. Satu diagram context, satu diagram container atau komponen, dan satu diagram urutan untuk alur kritis. Diagram harus cukup jelas sehingga engineer bisa mulai coding dan non-engineer bisa memahami alur data. Diagram yang baik menyampaikan informasi yang tidak bisa ditangkap oleh teks.

Ketujuh, mitigation. Setiap solusi punya risiko. Bagian ini mendokumentasikan risiko utama dan cara menguranginya. Misalnya risiko data center down dimitigasi dengan multi-AZ deployment. Atau risiko performance lambat dimitigasi dengan caching dan load testing. Mitigation bukan daftar ketakutan, tetapi rencana aksi.

Kedelapan, dependency. Solusi tidak berdiri sendiri. Bagian ini mencatat apa saja yang harus tersedia sebelum solusi bisa berjalan: API dari sistem lain, persetujuan dari pihak tertentu, lisensi software, atau data migrasi dari database lama. Dependency yang tidak tercatat adalah sumber keterlambatan paling umum.

Kesembilan, open issue. Tidak semua pertanyaan bisa dijawab di awal. Open issue adalah daftar hal yang belum diputuskan, lengkap dengan siapa yang harus memutuskan dan kapan batas waktunya. Bagian ini jujur dan transparan. Tim tidak perlu menebak-nebak apakah suatu keputusan sudah diambil.

Sembilan bagian ini bukan template mati. Anda bisa menyesuaikan urutan atau kedalaman sesuai kebutuhan proyek. Tetapi jika satu bagian hilang, dokumen Anda akan memiliki celah yang nantinya akan muncul sebagai pertanyaan berulang dari tim. Dan pertanyaan berulang adalah tanda bahwa solution architecture belum cukup membantu.

Setelah struktur minimum ini jelas, tantangan berikutnya adalah bagaimana menyajikannya dengan diagram yang cukup untuk dipahami semua pihak.