Apa
itu Arsitektur Perangkat Lunak?
Orang-orang di
industri perangkat lunak memiliki definisi arsitektur yang berbeda-beda. Namun
beberapa di antaranya tidak cukup untuk mendefinisikannya secara lengkap dan
tepat. Menurut Roy Fielding , pencipta gaya
arsitektur REST dan juga salah satu penulis spesifikasi HTTP, arsitektur
perangkat lunak adalah:
“ …suatu
abstraksi dari elemen-elemen run-time dari suatu sistem perangkat lunak selama
beberapa fase operasinya. ”
Berbagai gaya
arsitektur perangkat lunak (Sumber: Weave.works)
Arsitektur dalam
perangkat lunak itu sendiri bukan hanya struktur dasar untuk menggambarkan cara
kerja sistem, tetapi lebih dari itu. Sebagaimana didefinisikan sepenuhnya
oleh IEEE 1471-2000 , arsitektur perangkat
lunak adalah “ organisasi dasar suatu sistem, yang diwujudkan dalam
komponen-komponennya, hubungan mereka satu sama lain dan lingkungannya, serta
prinsip-prinsip yang mengatur desain dan evolusinya .” Definisi ini
mengungkapkan apa yang sebenarnya termasuk dalam arsitektur perangkat
lunak.
Merancang
sistem adalah langkah pertama dari siklus hidup perangkat lunak apa pun.
Merancang sistem meletakkan fondasi yang kokoh bagi sistem perangkat lunak yang
akan dibangun, dengan mengubah serangkaian atribut (misalnya kinerja, kemudahan
pengelolaan, dan keamanan) menjadi aplikasi yang berhasil yang memenuhi harapan
teknis atau bisnis.
Peran
Arsitektur Perangkat Lunak dalam Menyusun Sistem Perangkat Lunak
Arsitektur
perangkat lunak memainkan peran penting dalam membentuk sistem perangkat lunak.
Arsitektur perangkat lunak mendefinisikan bagaimana suatu sistem terstruktur,
menentukan perilakunya, dan hubungan antara komponen-komponennya. Aspek
penting pengembangan
perangkat lunak ini menawarkan beberapa manfaat utama.
Pertama dan
terutama, arsitektur perangkat lunak menyediakan cetak biru untuk sebuah
sistem. Arsitektur ini mendefinisikan struktur penting yang dibutuhkan untuk
memahami dan menalar perangkat lunak. Kejelasan ini membantu dalam menciptakan
dan memelihara perangkat lunak secara efektif.
Arsitektur
perangkat lunak tidak hanya mencakup struktur, tetapi juga menyelidiki perilaku
sistem. Arsitektur menguraikan perilaku sistem, yang meliputi elemen-elemen
perangkat lunak, hubungan antarelemen, dan properti elemen-elemen dan hubungan
tersebut. Pandangan komprehensif ini memastikan bahwa perangkat lunak berfungsi
sebagaimana mestinya.
Struktur
komunikasi merupakan aspek penting lain yang dibahas oleh arsitektur perangkat
lunak. Struktur komunikasi menjelaskan bagaimana komponen-komponen dalam sistem
berinteraksi dan bekerja sama untuk mencapai tugas-tugas tertentu. Pemahaman
ini sangat penting untuk pengoperasian sistem yang lancar.
Salah satu
kekuatan utama arsitektur perangkat lunak adalah kemampuannya untuk
menyeimbangkan kebutuhan pemangku kepentingan. Hal ini memungkinkan pemangku
kepentingan untuk memahami bagaimana sistem akan memenuhi kualitas penting
seperti kemampuan dimodifikasi, ketersediaan, dan keamanan. Transparansi ini
mendorong kolaborasi dan pengambilan keputusan yang tepat.
Arsitektur
perangkat lunak juga memiliki dampak signifikan pada struktur tim. Arsitektur
perangkat lunak berfungsi sebagai panduan bagi manajemen proyek, yang
memungkinkan mereka mengalokasikan tugas secara efisien kepada tim dan individu
yang terlibat. Penyelarasan ini memperlancar upaya pengembangan.
Terakhir,
arsitektur perangkat lunak yang dirancang dengan baik berfokus pada
elemen-elemen penting, memastikan bahwa sistem dapat beradaptasi dan berkembang
untuk memenuhi kebutuhan di masa mendatang. Fleksibilitas ini penting dalam
lanskap teknologi yang berkembang pesat.
4
Manfaat Arsitektur Perangkat Lunak
Bagi banyak
pemangku kepentingan, arsitektur perangkat lunak tampak sulit dipahami. Namun,
jika tidak ada atau buruknya arsitektur yang dibangun, akan timbul banyak
masalah, karena:
1.
Menyediakan fondasi yang kuat untuk keseluruhan proyek perangkat lunak.
Arsitektur
yang buruk menghasilkan lebih banyak Crufts yang menghalangi pengembang untuk
memahami sistem secara menyeluruh dan bahkan kebutuhan pemangku kepentingan.
Jadi, merancang perangkat lunak dapat membantu memaksakan visi menyeluruh bagi
pengembang untuk memahami sistem dengan lebih baik, kemudian mengetahui dengan
tepat seberapa skalabel platform tersebut, dan atribut serta fungsi kualitas
apa yang diinginkan pengguna dalam struktur TI. Oleh karena itu, hal itu dapat
meningkatkan kinerja, memungkinkan manajemen risiko dan mitigasi biaya, serta
menghindari penipuan kode.
Arsitektur
yang baik dan bebas dari hal-hal yang tidak berguna (Sumber: Martin Flower)
2.
Memberikan dasar untuk menggunakan kembali elemen dan keputusan.
Banyak
pemangku kepentingan sering mengajukan permintaan yang sama untuk perangkat
lunak yang diinginkan. Alih-alih membangun aplikasi yang sama sekali baru,
penggunaan kembali elemen dan keputusan dapat menghemat waktu dan biaya desain,
serta mengurangi risiko kegagalan dan cacat.
3.
Membantu berkomunikasi dengan baik dengan pemangku kepentingan untuk memenuhi
tuntutan mereka dengan lebih baik.
Terkadang,
ekspektasi pemangku kepentingan dapat melampaui kemampuan sistem perangkat
lunak. Arsitektur memastikan bahwa perangkat lunak akan dipahami dengan jelas
dan dibahas dengan baik oleh semua pihak sebelum mencapai konsensus. Dengan
demikian, hal ini membantu pemangku kepentingan untuk mengetahui apa yang
mereka dapatkan setelah perangkat lunak diimplementasikan. Jadi, untuk
menghindari produk yang tidak diharapkan, arsitektur perangkat lunak akan
digunakan.
4.
Membuat pemeliharaan dan perbaikan kode menjadi lebih baik.
Menyelesaikan
perangkat lunak bukanlah langkah terakhir dari siklus hidupnya. Ada yang lebih
dari itu: pemeliharaan dan peningkatan. Arsitektur yang baik memungkinkan
pengembang menemukan bug dan anomali dengan lebih mudah atau mempercepat
perubahan dalam sistem TI. Dengan demikian, arsitektur dapat memenuhi tuntutan
pengguna yang lebih tinggi dari waktu ke waktu dan terhindar dari kekusutan.
2 Karakteristik Arsitektur Perangkat
Lunak
Untuk
mengidentifikasi properti arsitektur, kita perlu menjawab dua pertanyaan
berikut:
1. Terbuat dari apakah Arsitektur
Perangkat Lunak?
Biasanya,
arsitektur perangkat lunak mencakup elemen-elemen dasar seperti komponen,
konektor, dan data (Roy Fielding, 2000). Di antaranya:
- Data adalah informasi yang digunakan dan diubah.
- Komponen (atau dikenal sebagai elemen
pemrosesan) melakukan transformasi data melalui antarmuka.
- Konektor (atau dikenal sebagai elemen
penghubung) memungkinkan komunikasi antara komponen dengan mengirimkan
data dari satu antarmuka ke antarmuka lainnya.
Konfigurasi arsitektur
perangkat lunak (Sumber: Research Gate)
Kita juga
harus mempertimbangkan konfigurasinya. Secara khusus, konfigurasi adalah
"struktur hubungan arsitektural antara komponen, konektor, dan data selama
periode waktu proses sistem" (Roy Fielding 2000). Namun, konfigurasi dapat
dianggap sebagai serangkaian batasan tertentu untuk hubungan komponen.
2. Pertimbangan apa saja yang diambil
saat merancang perangkat lunak?
Beberapa
faktor yang mempengaruhi arsitektur perangkat lunak meliputi:
- Pemangku kepentingan: Perangkat lunak dirancang
untuk melayani para pemangku kepentingan yang memiliki kebutuhan berbeda.
Menyeimbangkan berbagai kepentingan tersebut merupakan prioritas
utama arsitektur perangkat lunak.
- Pemisahan perhatian: konsep ini menunjukkan
perlunya memisahkan perhatian semua pemangku kepentingan dengan melihat
arsitektur dari sudut pandang yang berbeda.
- Atribut kualitas: perangkat lunak yang berbeda
akan memerlukan serangkaian properti yang berbeda (misalnya keandalan,
toleransi kesalahan, skalabilitas, atau keamanan). Bergantung pada
permintaan, atribut kualitasnya dapat bervariasi.
Atribut kualitas arsitektur
(Sumber: Loginext)
- Gaya arsitektur: arsitek akan menggunakan gaya
arsitektur yang berbeda untuk mengatasi masalah yang berulang.
- Integritas konseptual: istilah ini diciptakan
untuk menunjukkan visi menyeluruh tentang apa yang seharusnya dilakukan
perangkat lunak dan bagaimana melakukannya. Ini membantu semua anggota
memahami sistem dan membuatnya mudah digunakan.
- Batasan kognitif: diberlakukan untuk membatasi
apa yang dapat dilakukan perangkat lunak, dan kurangnya batasan tersebut
dapat merusak arsitektur.
Pola Arsitektur Perangkat Lunak Umum
Solusi
perangkat lunak menjadi lebih kompleks karena ekspektasi pengguna yang lebih
tinggi. Hal ini tidak hanya mempersulit pengembangan perangkat lunak tetapi
juga aktivitas pemeliharaan dan peningkatannya setelahnya. Oleh karena itu,
pola arsitektur perangkat lunak tampaknya dapat mengatasi masalah
tersebut.
Secara
khusus, pola arsitektur perangkat lunak didefinisikan sebagai solusi umum yang
dapat digunakan kembali untuk mengatasi masalah yang ada dan umum serta memilih
kualitas yang diinginkan dalam arsitektur perangkat lunak. Seperti yang
dijelaskan oleh Mark Richards, seorang arsitek perangkat lunak yang
berpengalaman, ada lima pola yang ada di mana-mana:
Arsitektur berlapis (n-tier)
Ini
mungkin pendekatan yang paling populer. Banyak kerangka kerja perangkat lunak
terbesar (misalnya Drupal , Java EE atau
Express) dikembangkan berdasarkan pola ini, sehingga berbagai aplikasi yang
dibangun di atasnya juga dikembangkan dalam struktur berlapis.
Pola arsitektur berlapis
(Sumber: Oreilly)
Umumnya
mencakup empat lapisan dasar: presentasi, bisnis, persistensi, dan basis
data. Salah satu manfaatnya adalah pemisahan masalah. Dengan demikian,
permintaan akan berpindah dari lapisan atas ke bawah. Misalnya, data sering
kali berasal dari lapisan presentasi, setelah lapisan ditutup, data tersebut
akan melewati lapisan bisnis, lalu lapisan persistensi, dan akhirnya
lapisan basis data.
Arsitektur
berbasis peristiwa
Struktur ini
bertujuan untuk mengelola semua aktivitas (misalnya produksi, deteksi,
konsumsi, dan reaksi) yang terkait dengan peristiwa. Struktur ini bekerja
dengan menggunakan unit pusat untuk mendapatkan semua data dan kemudian
menugaskannya ke berbagai modul. Misalnya, kita dapat melihat iklan “mobil
dijual” sebagai pesan yang disajikan oleh pengecer; setelah disiarkan di
saluran media, iklan ini dapat menjangkau calon pelanggan. Iklan ini dapat
merangsang “pembelian” dari pembeli tersebut. Perubahan dari “dijual” menjadi
“pembelian” dipandang sebagai suatu peristiwa.
Topologi mediator arsitektur berbasis peristiwa
(Sumber: Oreilly)
Arsitektur
mikrokernel
Struktur ini
sering kali diterapkan untuk menjalankan aplikasi berbasis produk. Struktur ini
memungkinkan pengembang mengunduh paket aplikasi dan menambahkan fitur penting
tambahan yang sesuai dengan permintaan mereka. Fitur tambahan tersebut dapat
dilihat sebagai plug-in untuk rangkaian inti operasi aplikasi, yang
memungkinkan ekstensibilitas dan isolasi fitur.
Pola
arsitektur mikrokernel (Sumber: Oreilly)
Arsitektur
layanan mikro
Bayangkan
saja: Anda adalah kepala sekolah. Satu dekade lalu, sekolah Anda hanya memiliki
sekitar seratus siswa, yang kemudian meningkat menjadi ratusan ribu. Dulu jauh
lebih mudah untuk mengelola sejumlah kecil siswa dan staf, tetapi sekarang
lebih sulit untuk menangani sejumlah besar siswa. Kemudian Anda memutuskan
untuk membagi sekolah Anda menjadi area-area kecil dengan fungsi tunggal untuk
manajemen dan kualitas pendidikan yang lebih baik. Beginilah cara kerja
arsitektur Microservices.
Gaya
arsitektur layanan mikro (Sumber: Microsoft Azure)
Ini mencakup
banyak layanan kecil dan independen; masing-masing layanan berdiri sendiri dan
menjalankan tugas bisnis terpisah.
Arsitektur
berbasis ruang angkasa
Setelah
menerima permintaan dari pengguna, basis data akan memprosesnya. Namun jika
beban meningkat dengan cepat, server basis data hampir tidak dapat mengimbangi
beban tersebut, dan akhirnya seluruh situs web akan kolaps. Untuk menghindari
masalah ini, arsitektur berbasis ruang diterapkan. Dengan demikian, arsitektur
ini mencakup dua komponen utama, yaitu unit pemrosesan dan middleware
tervirtualisasi.
Pola
arsitektur berbasis ruang (Sumber: Oreilly)
Singkatnya,
meskipun masih dalam tahap pertama siklus hidup perangkat lunak, arsitektur
perangkat lunak secara signifikan memengaruhi semua aktivitas, dari penerapan,
pengembangan, hingga pemeliharaan.
Sumber : https://www.designveloper.com/guide/what-is-software-architecture/
