11.3 Diagram yang Cukup untuk Dipahami

Dari semua bagian solution architecture, diagram adalah yang paling cepat menyampaikan gambaran solusi. Sebuah diagram yang baik bisa membuat engineer langsung paham alur data, membuat operation melihat komponen yang perlu dimonitor, dan membuat manajer produk melihat batas sistem. Sebaliknya, diagram yang berantakan hanya akan menimbulkan lebih banyak pertanyaan.

Masalahnya, banyak tim tergoda membuat diagram yang terlalu detail atau terlalu abstrak. Ada yang menggambar setiap kelas di kode, ada juga yang hanya menggambar kotak besar bertuliskan “sistem baru” tanpa menjelaskan isinya. Kedua ekstrem ini sama-sama tidak membantu.

Kuncinya adalah memilih diagram yang cukup untuk dipahami oleh semua pihak yang terlibat. Tidak perlu semua jenis diagram. Cukup enam yang paling esensial.

Untuk memudahkan pemilihan, berikut adalah flowchart sederhana yang memandu Anda menentukan diagram mana yang paling relevan berdasarkan pertanyaan arsitektural yang perlu dijawab.

flowchart TD A[Mulai] --> B{Siapa yang berinteraksi?} B -->|Ya| C[Context Diagram] B -->|Tidak| D{Apa komponen besar?} D -->|Ya| E[Container Diagram] D -->|Tidak| F{Bagaimana urutan interaksi?} F -->|Ya| G[Sequence Diagram] F -->|Tidak| H{Dimana data mengalir?} H -->|Ya| I[Data Flow Diagram] H -->|Tidak| J{Dimana komponen di-deploy?} J -->|Ya| K[Deployment Diagram] J -->|Tidak| L{Bagaimana integrasi sistem?} L -->|Ya| M[Integration Map] L -->|Tidak| N[Gunakan diagram lain yang sesuai]

Pertama, context diagram. Diagram ini menunjukkan sistem Anda sebagai satu kotak di tengah, dikelilingi oleh aktor eksternal: pengguna, sistem lain, atau layanan pihak ketiga. Garis panah menghubungkan mereka dengan sistem Anda. Context diagram menjawab pertanyaan paling dasar: siapa yang berinteraksi dengan sistem ini, dan apa yang masuk serta keluar dari sistem? Diagram ini sangat berguna untuk menyelaraskan pemahaman dengan tim produk dan manajemen.

Kedua, container diagram. Ini adalah diagram yang menunjukkan komponen besar sistem Anda: aplikasi web, API backend, database, message queue, atau layanan eksternal. Setiap container adalah unit yang bisa dijalankan atau di-deploy secara terpisah. Engineer perlu diagram ini untuk memahami batas tanggung jawab setiap bagian. Non-engineer cukup melihat bahwa ada aplikasi yang dipakai pengguna, ada server yang memproses data, dan ada tempat penyimpanan.

Ketiga, sequence diagram. Diagram ini menunjukkan urutan interaksi antar komponen untuk satu skenario tertentu. Misalnya, apa yang terjadi ketika pengguna login, atau ketika pesanan dikirim. Sequence diagram sangat membantu saat tim mulai mendiskusikan detail teknis dan menemukan potensi masalah seperti race condition atau timeout. Diagram ini juga berguna untuk operation yang perlu memahami alur request sebelum menyiapkan monitoring.

Keempat, data flow diagram. Diagram ini menunjukkan bagaimana data bergerak dari satu komponen ke komponen lain, termasuk transformasi yang terjadi di tengah jalan. Data flow diagram berbeda dengan sequence diagram. Sequence diagram fokus pada urutan waktu, data flow diagram fokus pada jalur data. Diagram ini penting untuk security review karena memperlihatkan di mana data sensitif disimpan, diproses, dan dikirim.

Kelima, deployment diagram. Diagram ini menunjukkan di mana setiap komponen berjalan: server mana, cloud region mana, atau Kubernetes cluster mana. Deployment diagram menjawab pertanyaan operation: berapa banyak instance yang dibutuhkan, bagaimana network traffic diatur, dan apa yang perlu dipersiapkan infrastrukturnya.

Keenam, integration map. Diagram ini memperlihatkan semua integrasi antar sistem, termasuk protokol yang dipakai, arah data, dan frekuensi sinkronisasi. Integration map sangat penting ketika solusi Anda harus terhubung dengan banyak sistem lama di organisasi. Tim integrasi dan tim keamanan akan menggunakan diagram ini sebagai referensi utama.

Yang perlu diingat, diagram-diagram ini tidak harus sempurna dari awal. Cukup gambar di whiteboard dulu, difoto, lalu disempurnakan secara bertahap. Yang penting adalah semua pihak bisa membaca dan memahami diagram tersebut. Jika ada diagram yang hanya bisa dibaca oleh satu orang, diagram itu belum cukup baik.

Setelah diagram siap, langkah selanjutnya adalah menuliskan trade-off yang muncul dari setiap keputusan arsitektur. Karena diagram hanya menunjukkan apa yang dipilih, belum menjelaskan mengapa pilihan itu diambil dan apa konsekuensinya.