Arsitektur Dengan Implikasi

Arsitektur DenganImplikasi

    Antipattern Nama: Arsitektur oleh Implikasi
    Disebut Juga Sebagai: Oleh karena itu arsitektur engkau?
    Kebanyakan Skala Sering: Sistem
    Refactored Solusi Nama: Goal Pertanyaan Arsitektur
    Refactored Solusi Jenis: Dokumentasi
    Penyebab root: Pride, Sloth

Angkatan seimbang: Manajemen Kompleksitas, Perubahan, dan Risiko
Anekdot Bukti: "Kami telah melakukan sistem seperti ini sebelumnya!" "Tidak ada risiko, kita tahu apa yang kita lakukan!"

Latar belakang
   Dwight Eisenhower mengatakan bahwa perencanaan adalah penting, tetapi rencana ngawur. Prajurit lain mengatakan bahwa ada rencana bertahan kontak pertama dengan musuh. Budaya perencanaan dalam manajemen modern berutang beberapa kredit untuk Robert McNamara, pendiri RAND Corporation.

    Dalam pendekatan McNamara, rencana yang dihasilkan untuk tujuan spekulasi, untuk menyelidiki potensi manfaat dan konsekuensi dari berbagai tindakan yang berbeda. Mengingat jumlah besar yang tidak diketahui dalam pengembangan sistem, perencanaan untuk sistem IT harus lebih pragmatis dan berulang.

    Salah satu perencana profesional mengatakan bahwa 20 persen dari waktu seorang insinyur harus dialokasikan untuk perencanaan. Seperti kita mendapatkan pengalaman, keyakinan kami dalam pernyataan ini meningkat. Produktivitas dan efisiensi dapat sangat diperkuat ketika pekerjaan baik yang diselenggarakan melalui perencanaan.

    Konsekuensi disayangkan adalah bahwa banyak organisasi berusaha untuk meresmikan terlalu banyak perencanaan. Perencanaan adalah yang paling efektif ketika dimotivasi secara pribadi dan dimanfaatkan. Ahli manajemen waktu mengajarkan bahwa elemen kunci dari pengurangan stres berencana untuk menyeimbangkan prioritas keseluruhan hidup. Bentuk dan penggunaan sistem manajemen waktu menjadi semakin personal sebagai praktek jatuh tempo.

    Sekelompok CEO dari perusahaan integrasi DoD Sistem dibentuk untuk menjawab pertanyaan, "Oleh karena itu engkau arsitektur?" Tujuannya adalah untuk merefleksikan perubahan sifat pengembangan sistem, yang telah berkembang menjadi penggunaan kembali komponen warisan yang ada dan perangkat lunak komersial, dan jauh dari greenfield, pengembangan kode kustom (lihat Menemukan kembali Roda antipattern).
Bentuk umum

    Antipattern ini ditandai dengan kurangnya spesifikasi arsitektur untuk sistem dalam pengembangan. Biasanya, arsitek bertanggung jawab untuk proyek memiliki pengalaman dengan konstruksi sistem sebelumnya, dan karena itu menganggap dokumentasi yang tidak perlu.

Terlalu percaya ini menyebabkan risiko diperburuk di bidang utama yang mempengaruhi keberhasilan sistem. Definisi arsitektur sering hilang dari satu atau lebih dari daerah-daerah:

    Arsitektur perangkat lunak dan spesifikasi yang meliputi penggunaan bahasa, penggunaan perpustakaan, standar coding, manajemen memori, dan sebagainya.
Arsitektur perangkat keras yang meliputi konfigurasi klien dan layanan.
Arsitektur komunikasi yang mencakup protokol jaringan dan perangkat.
Arsitektur ketekunan yang mencakup database dan mekanisme penanganan berkas.
Arsitektur keamanan aplikasi yang meliputi model benang dan sistem dasar terpercaya.
Arsitektur sistem manajemen.

Gejala Dan Konsekuensi

    Kurangnya perencanaan arsitektur dan spesifikasi; definisi cukup arsitektur untuk perangkat lunak, perangkat keras, komunikasi, ketekunan, keamanan, dan sistem manajemen.
Risiko tersembunyi yang disebabkan oleh skala, pengetahuan domain, teknologi, dan kompleksitas, yang semuanya muncul sebagai proyek berlangsung.
Akan datang kegagalan proyek atau sistem gagal karena kinerja yang tidak memadai, kompleksitas berlebih, persyaratan disalahpahami, kegunaan, dan karakteristik sistem lainnya. Sebagai contoh, sekitar 1 dari 3 sistem mengalami masalah kinerja yang serius selama pengembangan dan operasi.
Ketidaktahuan teknologi baru.
Tidak adanya cadangan dan rencana darurat teknis.

Penyebab khas

Tidak ada manajemen risiko.
Terlalu percaya manajer, arsitek, dan / atau pengembang.
Ketergantungan pada pengalaman sebelumnya, yang mungkin berbeda di daerah kritis.
Masalah arsitektur implisit dan belum terselesaikan disebabkan oleh kesenjangan dalam rekayasa sistem.

Dikenal Pengecualian
    Arsitektur oleh Implikasi antipattern diterima untuk solusi berulang, di mana ada perbedaan kecil dalam kode, seperti skrip instalasi. Antipattern ini juga dapat berguna dalam proyek domain baru sebagai upaya penjajakan untuk menentukan apakah teknik yang sudah ada dapat dialihkan ke daerah baru.

Solusi refactored
   Solusinya refactored ke Architecture oleh Implikasi antipattern memerlukan pendekatan yang terorganisasi untuk definisi arsitektur sistem, dan bergantung pada beberapa tampilan dari sistem. Setiap model tampilan sistem dari perspektif stakeholder sistem, yang mungkin nyata atau imajiner, individu atau agregat. Setiap pemangku kepentingan bertanggung jawab untuk prioritas tinggi yang ditetapkan dari pertanyaan dan isu-isu, dan masing-masing mewakili pandangan sistem informasi dan menjawab seluruh pertanyaan-pertanyaan kunci dan isu-isu.

    Pandangan yang terdiri satu set diagram, tabel, atau spesifikasi, terkait untuk konsistensi. Umumnya, pandangan adalah spesifikasi ringan. Tujuan dari dokumentasi arsitektur adalah untuk berkomunikasi keputusan arsitektur dan resolusi masalah lainnya. Dokumentasi harus mudah dipahami dan murah untuk mempertahankan.

    Yang mengatakan, satu-satunya orang yang dapat menentukan dan menerapkan arsitektur yang sukses adalah mereka yang sudah memahami hal itu. Sayangnya, hal ini sering tidak terjadi, karena banyak proyek mengadopsi beberapa teknologi baru yang tidak dipahami dengan baik. Oleh karena itu, pengembangan arsitektur yang baik dari awal merupakan proses berulang dan harus diakui sebagai demikian.

    Arsitektur referensi awal harus memiliki strategi yang kuat yang dapat diimplementasikan dalam jangka waktu pengembangan produk pertama. Setelah itu, ia akan harus secara bertahap disempurnakan oleh versi masa depan dari arsitektur referensi, dan didorong oleh versi baru dari produk pertama atau produk baru.

Langkah-langkah untuk mendefinisikan arsitektur sistem menggunakan sudut pandang adalah sebagai berikut:

    Tentukan tujuan arsitektur. Apa yang harus arsitektur ini mencapai? Stakeholder yang, nyata dan imajiner, harus puas dengan desain dan implementasi? Apa visi untuk sistem? Di mana kita sekarang dan di mana kita akan pergi?

Tentukan pertanyaan. Apa pertanyaan spesifik yang harus diatasi untuk memenuhi isu pemangku kepentingan? Memprioritaskan pertanyaan untuk mendukung pandangan seleksi.
Pilih pandangan. Setiap tampilan akan mewakili cetak biru arsitektur sistem.
Menganalisis setiap tampilan. Detil definisi arsitektur dari setiap sudut pandang. Buat cetak biru sistem.

    Mengintegrasikan cetak biru. Pastikan pandangan menyajikan definisi arsitektur yang konsisten.
Melacak pandangan dengan kebutuhan. Pandangan harus menjawab pertanyaan-pertanyaan yang dikenal dan masalah untuk menemukan kesenjangan tidak ditangani dengan spesifikasi arsitektur. Memvalidasi arsitektur sehubungan dengan persyaratan formal. Prioritaskan isu yang beredar.
Iterate cetak biru. Memperbaiki pandangan sampai semua pertanyaan, masalah, dan kesenjangan diselesaikan. Memanfaatkan proses peninjauan ke permukaan masalah apapun yang tersisa. Jika sejumlah besar masalah yang belum terselesaikan tetap, mempertimbangkan untuk membuat tampilan tambahan.

Mempromosikan arsitektur. Membuat upaya eksplisit untuk berkomunikasi arsitektur untuk pemangku kepentingan utama, khususnya para pengembang sistem. Membuat dokumen (seperti video tutorial) yang berlangsung untuk memberikan informasi yang berharga di seluruh pengembangan dan pemeliharaan siklus hidup.
Validasi pelaksanaannya. Cetak biru harus mewakili "as-built" desain. Menentukan setiap delta antara cetak biru dan implementasi sistem. Memutuskan apakah perbedaan ini harus menghasilkan modifikasi sistem update untuk cetak biru. Upgrade dokumentasi untuk konsistensi.

    Kami menyebut metode ini sebagai arsitektur tujuan-pertanyaan (GQA), analog dengan tujuan-pertanyaan pendekatan metrik di metrik perangkat lunak
Variasi

Sejumlah pendekatan mempertimbangkan arsitektur sistem menggunakan sudut pandang; di beberapa, sudut pandang yang telah ditetapkan. Sebagian besar pendekatan ini terbuka, di salah satu yang dapat memilih sudut pandang tambahan seperti yang dijelaskan.

   Referensi Model Open Proses Terdistribusi (RM-ODP) adalah populer, standar yang berguna untuk arsitektur terdistribusi. RM-ODP mendefinisikan lima sudut pandang standar: perusahaan, informasi, komputasi, rekayasa, dan teknologi ini juga mendefinisikan satu set berguna sifat transparansi untuk infrastruktur didistribusikan melalui sudut pandang rekayasa.

    Pendekatan lain, Kerangka Zachman, analisis arsitektur sistem dari perspektif data, fungsi, dan jaringan Dalam setiap perspektif beberapa tingkat abstraksi, sesuai dengan kebutuhan perencanaan berbagai kelompok pemangku kepentingan. Enterprise Architecture Planning merupakan pendekatan berdasarkan Kerangka Zachman untuk sistem skala besar Tak satu pun dari pendekatan ini disesuaikan dengan berorientasi objek pengembangan sistem.

    Pendekatan ketiga, Komando, Komunikasi, kontrol, Komputer, Intelijen, Surveillance, dan Reconnaissance Arsitektur Framework (C4ISR-AF), digunakan untuk mendefinisikan berbagai perintah dan sistem kontrol arsitektur. Sebuah versi dari C4ISR-AF digunakan untuk jenis lain dari sistem sipil. Pendekatan ini telah sangat bermanfaat dalam memungkinkan komunikasi antara arsitek di seluruh domain yang berbeda

    Sebuah keempat, 4 + 1 Model View, adalah pendekatan arsitektur berbasis sudut pandang didukung oleh alat rekayasa perangkat lunak, seperti Rational Rose The sudut pandang termasuk logis, menggunakan kasus, proses, implementasi, dan penyebaran. Akhirnya, GQA adalah generalisasi dari metode yang mendasari digunakan dalam beberapa pendekatan arsitektur ini

Contoh
    Praktek yang umum tapi buruk adalah pemodelan berorientasi objek tanpa mendefinisikan sudut pandang. Dalam kebanyakan pendekatan pemodelan, ada kabur dari sudut pandang. Banyak dari pemodelan konstruksi mengandung implementasi detail, dan praktek standar adalah untuk berbaur implementasi dan spesifikasi konstruksi.

   Tiga sudut pandang fundamental adalah: konseptual, spesifikasi, dan implementasi Sudut pandang konseptual mendefinisikan sistem dari perspektif pengguna. Hal ini biasanya disebut sebagai model analisis. Perbedaan antara apa yang otomatis dan apa yang tidak biasanya tidak terwakili dalam model; bukan, model ditarik sehingga pengguna dapat menjelaskan dan mempertahankannya untuk rekan-rekan nya.

   Spesifikasi pandang hanya menyangkut interface. ISO IDL adalah salah satu notasi penting yang sangat terbatas untuk mendefinisikan informasi antarmuka dan tidak termasuk spesifik implementasi. Pemisahan interface dari implementasi memungkinkan realisasi banyak manfaat teknologi objek penting, seperti penggunaan kembali, ekstensi sistem, variasi, substitusi, polimorfisme, dan komputasi terdistribusi objek. Sudut pandang akhir, pelaksanaan, yang terbaik diwakili oleh kode sumber.

Struktur pelaksanaan kompleks menguntungkan ditambah dengan model desain berorientasi objek untuk membantu pengembang saat ini dan masa depan dan pengelola memahami kode.

    Contoh lain dari Arsitektur oleh Implikasi antipattern adalah berikut, di mana para pemangku kepentingan kunci tidak memiliki pengalaman kolektif dalam apa yang dibangun. Proyek ini dimaksudkan untuk memberikan Microsoft Distributed Common Object Model (DCOM) solusi berbasis untuk mengambil data warisan mainframe, menyaringnya berdasarkan aturan bisnis, dan menampilkannya pada halaman Web.

Namun, manajer adalah seorang insinyur perangkat lunak yang baik tanpa teknologi objek terdistribusi (DOT) pengalaman dan arsitek adalah "dicelup-in-the-wol" CORBA pecandu yang membantu OMG berasal Object nya Arsitektur Manajemen. Untuk menambah masalah, proyek memiliki beberapa staf DCOM-sadar; kurang dari 10 persen.

    Selain itu, arsitektur dan desain berikutnya didasarkan pada pandangan OMA dari DOT dunia, bukan DCOM. Hal ini menyebabkan upaya untuk memberikan layanan CORBA bawah arsitektur DCOM. Produk yang dihasilkan menderita satu set komponen yang tidak memiliki konsistensi DOT dan berkinerja buruk. Juga, SIS menemukan sangat sulit untuk digunakan, karena kurangnya pendekatan standar. Akhirnya, gagal di pasar.

Solusi terkait
    Arsitektur oleh Implikasi antipattern berbeda dari cerobong asap Sistem antipattern di lingkup; yang terakhir berfokus pada kekurangan dalam arsitektur komputasi. Secara khusus, itu mengidentifikasi bagaimana abstraksi yang tidak tepat dari API subsistem mengarah ke solusi arsitektur rapuh. Sebaliknya, Arsitektur oleh Implikasi antipattern melibatkan kesenjangan perencanaan merupakan beberapa sudut pandang arsitektur.
Berlakunya Untuk Pandangan Dan Timbangan Lainnya

    Antipattern ini secara signifikan meningkatkan risiko bagi manajer, yang menunda keputusan penting sampai kegagalan terjadi; sering, sudah terlambat untuk memulihkan. Pengembang menderita kurangnya bimbingan untuk implementasi sistem.

   Mereka diberi tanggung jawab de facto untuk keputusan arsitektur kunci yang mereka mungkin tidak memiliki perspektif arsitektur diperlukan. Konsekuensi systemwide dari keputusan desain antarmuka harus dipertimbangkan; khususnya: sistem adaptasi, abstraksi antarmuka yang konsisten, ketersediaan metadata, dan pengelolaan kompleksitas.

Hasil penting lain dari antipattern ini adalah penundaan alokasi sumber daya. Alat-alat penting dan komponen teknologi mungkin tidak tersedia saat dibutuhkan karena kurangnya perencanaan.”