Arsitektur Software Tahan Banting

Sebaik apa-pun aktivitas kita melakukan requirement engineering dalam pengembangan perangkat lunak, maka kita akan tidak pernah luput dari perubahan. Perubahan yang paling berisiko tinggi adalah perubahan yang terjadi di tingkat kode. Hal ini dikarenakan kita harus melakukan coding ulang aplikasi yang bukan hanya menghabiskan waktu tetapi juga membuang energi untuk mengubah, membuat baru, bahkan mengabaikan kode yang sudah ada. Dan itu tidak dapat dihindari berapa-pun usaha keras yang Anda lakukan. Hal ini dikarenakan tiga hal.

1. Dunia yang dinamis. Dinamismenya mengubah aturan perusahaan, aturan bisnis, atau bahkan ide bisnis kontemporer yang mendorong sistem informasi yang kita kembangkan akan berubah.
2. Pemaknaan yang berbeda. Maksud kita A, Maksud mereka B. Kondisi seperti itu makin membuat gap pemahaman mendorong perubahan yang tinggi. Komunikasi langsung memang menjadi obat tetapi tidak semua obat tersebut berefek langsung yang berakibat perubahan. 
3.  Pengabaian yang terlewat. Kadang kita mengabaikan sebuah fitur yang sepele. Hal ini setelah dikaji adalah fitur yang membutuhkan waktu lebih lama bahkan biaya yang tidak tercatat.

Lalu jika perubahan tidak terelakkan maka satu-satunya upaya adalah menerima perubahan tersebut dengan meminimalkan risiko. Nah pada artikel ini kita akan membahas satu variabel dari tingkat teknis yaitu arsitektur software. Arsitektur tersebut disebut dengan arsitektur yang resilience atau dikenal juga dengan arsitektur tahan banting. Bagaimana mewujudkan arsitektur tahan banting terhadap perubahan, Berikut adalah lima upaya yang dapat dilakukan secara bertahap.

1. Menyusun kode dengan pendekatan berbasis objek dengan loosely coupled. Gunakan konsep SOLID untuk mewujudkannya.  
2. Menyusun struktur proyek berbasis multi-layer architecture. Pisahkan mana Presentation, Business Layer, dan Data Access Layer 
3. Menyusun model coding terdistribusi bahkan hingga level user story. Hal ini dilakukan dengan memisahkan berkas kode menjadi bagian-bagian terkecil yang dikenal dengan Micro-architecture
4. Membuat arsitektur perangkat lunak yang kecil-kecil dan berbasis API. Artinya komunikasi antar layer didasarkan pada services atau berbasis kontrak misalnya dengan skema web services atau kontrak JSON.
5.  Mendistribusikannya dalam model serverless berbasis platform as a service. Hal ini untuk memudahkan distribusi yang cepat pada saat pengembangan tanpa harus mengupload ulang secara keseluruhan.