Spesifikasi desain arsitektur beban kerja

Spesifikasi desain arsitektur beban kerja adalah spesifikasi terperinci yang menjelaskan pilihan desain dan disertai dengan diagram. Pilihan desain harus memenuhi persyaratan fungsional dan nonfungsi dan mencakup ketentuan untuk operasi rutin, ad hoc, dan darurat.

Untuk informasi tentang diagram, lihat Diagram desain arsitektur.

Desain arsitektur beban kerja, biasanya ekspansif, dimulai dengan desain aplikasi dan kemajuan pemilihan layanan cloud. Fase-fase ini saling menginformasikan satu sama lain. Aplikasi gabungan dan desain infrastruktur harus memenuhi semua persyaratan.

Mencapai solusi yang memenuhi semua persyaratan adalah upaya kolaboratif antara pemangku kepentingan, pengembang, penguji, tim operasi, dan pemilik produk. Proses desain harus melibatkan persyaratan penghalusan dengan kejelasan dan negosiasi. Prosesnya berulang dan sering memerlukan beberapa tinjauan.

Kami menyarankan agar Anda menyelaraskan desain Anda dengan panduan dasar Azure Well-Architected Framework, yang mencakup prinsip desain dan panduan rekomendasi, dan mengakui tradeoff.

Pada akhirnya, spesifikasi desain arsitektur beban kerja diimplementasikan oleh tim pengembangan beban kerja, sehingga harus jelas dan tidak ambigu. Spesifikasi harus tersedia dan disimpan dengan dokumentasi beban kerja.

Spesifikasi fungsi

Spesifikasi fungsional untuk beban kerja merinci apa dan mengapa sistem atau fitur sedang dikembangkan, tetapi bukan implementasinya. Dokumen ini harus menjelaskan masalah saat ini yang ada dan bagaimana fitur atau sistem ini akan meningkatkan pengalaman tersebut. Dokumen ini menangkap sebagian besar persyaratan bisnis.

Arsitek dapat membantu membentuk dokumen ini, tetapi terutama itu adalah fungsi kepemilikan produk. Arsitek harus membantu merancang data yang diambil dalam spesifikasi ini. Keterlibatan ini memastikan spesifikasi fungsi ini mendorong desain teknis yang efektif dan efisien.

Berikut adalah beberapa contoh topik yang harus dibahas dalam spesifikasi ini.

• Selain merinci apa yang ada dalam cakupan desain ini, juga eksplisit tentang kekhawatiran yang berdekatan yang berada di luar cakupan. Mengatur cakupan yang jelas mengurangi cakupan creep dengan menentukan batas di sekitar fungsionalitas.

• Sangat membantu untuk menyertakan detail tentang bagaimana perubahan ini akan diukur. Pengukuran apa yang perlu dikumpulkan dan tujuan bisnis apa yang didukung pengukuran tersebut.

• Alur pengguna harus dijelaskan dengan jelas. Mockup dengan fedelitas rendah juga dapat membantu. Jika situasi penanganan kesalahan penting untuk alur ini, pastikan perilaku yang diharapkan dijelaskan.

• Selalu sertakan persyaratan khusus untuk aksesibilitas, kepatuhan, performa, privasi, atau keamanan.

• Sertakan strategi peluncuran yang direncanakan. Misalnya, "Fitur ini akan tersedia untuk pengguna beta kami selama dua bulan sebelum memutuskan rilis lengkap."

Hindari detail implementasi teknis tertentu dalam spesifikasi ini. Spesifikasi fungsi ini akan mendorong spesifikasi teknis yang dibuat oleh arsitek.

Spesifikasi teknis

Spesifikasi teknis menjelaskan bagaimana berdasarkan cakupan dan tujuan yang dijelaskan dalam spesifikasi fungsional. Spesifikasi ini dirancang untuk digunakan tim teknik sebagai rencana pencatatan selama implementasi.

Dalam spesifikasi ini termasuk item seperti:

• Keputusan teknologi, termasuk sebagai: membeli, membangun, menggunakan kembali, memperluas, atau menonaktifkan.
• API dan kontrak data (skema), termasuk strategi implementasi kompatibilitas mundur
• Detail implementasi peluncuran dan pembatalan
• Siklus hidup pengembangan aman (SDL) dan implementasi privasi yang unik
• Rencana pengujian
• Sumber sinyal pemantauan dan pemberitahuan utama
• Desain alternatif yang dipertimbangkan

Spesifikasi teknis akan mendorong upaya rekayasa. Item kerja teknik terutama dibuat dari konten spesifikasi ini. Tim implementasi mengacu pada item kerja, spesifikasi teknis, dan spesifikasi fungsional untuk memastikan hasil akhir memenuhi persyaratan fungsional dan nonfungsi.

Rencana pemulihan bencana

Untuk memenuhi persyaratan keandalan untuk beban kerja, arsitek perlu merancang sistem yang dapat pulih dalam tujuan waktu pemulihan target (RTO) dan tujuan titik pemulihan (RPO). Spesifikasi desain arsitektur harus menyertakan rencana pemulihan. Rencana ini harus mencakup komponen arsitektur yang terlibat, mekanisme failover dan dampak terhadap aliran pengguna dan data, dan rekomendasi operasional. Ini harus menjelaskan target pemulihan mana yang terpenuhi oleh desain dan caranya.

Meskipun rencana awal diharapkan berevolusi berdasarkan wawasan dari latihan dan ulasan pasca-insiden, arsitek bertanggung jawab untuk menyampaikan rencana awal untuk semua arsitektur baru.

Dokumentasi keamanan dan kepatuhan

Arsitek bertanggung jawab untuk merancang solusi yang mematuhi batasan keamanan dan kepatuhan yang bersangkutan. Penting bagi artefak desain untuk menyoroti keperluan yang tergabung dalam desain untuk mendukung persyaratan ini, dan untuk mengidentifikasi kontrol kompensasi yang diperlukan ketika persyaratan tidak dapat dipenuhi secara langsung.

Konsistensi

Gunakan templat untuk mendokumen berbagai spesifikasi beban kerja Anda. Konsistensi membantu pemangku kepentingan, pihak yang bertanggung jawab, dan tim implementasi ketika spesifikasi sedang dibaca.

Pastikan spesifikasi memiliki bidang metadata utama seperti:

• Status: Status sebagai Draf, Sedang ditinjau, dan Disetujui.
• Tautan item kerja: Tautan ke item kerja utama di backlog tim.
• Tautan silang kunci: Tautan ke spesifikasi terkait atau dokumentasi lain yang mendukung spesifikasi.
• Individu utama: Tempat untuk mencantumkan nama pembuat keputusan utama yang terlibat. Daftar ini mungkin mencakup peran seperti: analis bisnis, mitra bisnis, prospek teknis, dan pemilik produk atau prospek yang menandatangani spesifikasi.

Langkah berikutnya

Daftar periksa arsitek