Pernahkah kalian melihat gedung pencakar langit yang megah, lalu bertanya-tanya bagaimana ia bisa tetap berdiri meski diterpa angin kencang atau gempa? Atau mungkin, saat menatap lukisan abstrak, kalian penasaran bagaimana sang seniman memilih warna dan garis untuk menciptakan harmoni? Nah, software architecture, atau arsitektur perangkat lunak, adalah perpaduan keduanya: teknik dan seni. Tapi, jangan salah, ini bukan tentang membuat kode yang "indah", melainkan tentang merancang fondasi yang kokoh sekaligus fleksibel.
Baru-baru ini, saya membaca tulisan Perry dan Wolf (1992) berjudul Foundations for the Study of Software Architecture. Mereka bilang, arsitektur perangkat lunak itu seperti "kerangka yang mempersatukan elemen-elemen sistem". Tapi bagi saya, ini lebih mirip tulang punggung yang menentukan apakah sistem akan bertahan lima tahun atau lima menit. Bayangkan saja: tanpa arsitektur yang jelas, sistem kita mungkin seperti rumah kertas---cantik di awal, tapi hancur begitu ada perubahan kecil.
Elemen, Bentuk, dan Alasan
Menurut Perry dan Wolf, arsitektur perangkat lunak terdiri dari tiga komponen: elements, form, dan rationale. Elements itu sendiri dibagi jadi tiga: processing elements (seperti parser atau lexer dalam kompilator), data elements (token, syntax tree), dan connecting elements (shared memory, message passing). Sederhananya, ini seperti membangun kota: ada pabrik (pemroses), gudang (data), dan jalan tol (konektor).
Tapi yang menarik justru form---bentuk hubungan antar elemen. Perry dan Wolf menyebutnya sebagai "properti dan relasi yang diberi bobot". Ini bukan sekadar flowchart biasa. Misalnya, dalam kompilator sequential, parser hanya bisa mulai bekerja setelah lexer selesai. Bobot di sini menentukan mana aturan yang saklek (load-bearing) dan mana yang bisa diutak-atik (decorative). Kalau di dunia nyata, ini seperti aturan "jangan membangun kamar mandi di atas dapur"---bukan masalah selera, tapi soal pipa yang bocor.
Lalu ada rationale, alasan di balik setiap keputusan arsitektural. Ini bagian yang paling sering dilupakan. Pernah lihat proyek dengan dokumentasi yang hanya berisi "karena bos bilang begitu"? Nah, rationale seharusnya menjawab mengapa kita memilih arsitektur tertentu. Misalnya, memilih shared memory untuk kompilator paralel demi kecepatan, meski berisiko race condition. Tanpa alasan yang jelas, arsitektur hanyalah kumpulan pilihan acak.
Belajar dari Gedung, Jaringan, dan Pipa Air
Perry dan Wolf menarik analogi dari arsitektur bangunan, hardware, dan jaringan. Tapi menurut saya, yang paling relevan justru pelajaran dari tukang ledeng. Bayangkan software architecture sebagai sistem pipa: jika salah merancang jalur air, suatu hari nanti bakal bocor di tempat tak terduga.
Mereka juga bilang, arsitektur bangunan punya multiple views---denah lantai, tata listrik, plumbing. Di dunia software, kita sering hanya punya satu "view": kode. Ini seperti membangun gedung tanpa skin, di semua pipa dan kabel terlihat. Kacau, bukan? Contoh nyatanya adalah Pompidou Center di Paris---gedung dengan struktur dalam yang terbuka. Estetis? Mungkin. Tapi coba bayangkan memelihara sistem seperti itu: setiap perubahan kecil mengharuskan kita membongkar semua lapisan.
Salah satu motivasi utama Perry dan Wolf adalah masalah architectural erosion dan architectural drift. Erosi terjadi ketika developer melanggar aturan arsitektur---seperti memindahkan dinding penyangga tanpa izin insinyur. Drift lebih halus: arsitektur perlahan kehilangan bentuk aslinya karena ketidaksadaran tim. Misalnya, awalnya sistem dirancang modular, tapi lama-lama kodenya jadi spaghetti karena deadline mepet.
Ini mengingatkan saya pada kota-kota tua di Jawa yang tata kotanya berantakan karena tambal sulam. Awalnya direncanakan sebagai pusat perdagangan, tapi sekarang jadi labirin gang sempit. Software pun bisa seperti itu jika tak dijaga arsitekturnya.
Konsep architectural style dalam paper ini menarik. Ini seperti genre musik: jazz punya aturan improvisasi, klasik perlu partitur ketat. Dalam software, gaya arsitektur membatasi jenis elemen dan hubungannya. Misalnya, client-server vs microservices Tapi Perry dan Wolf mengingatkan: garis antara "gaya" dan "arsitektur" itu buram. Apa yang bagi satu tim adalah gaya, bagi tim lain mungkin sudah jadi arsitektur spesifik.
