Get best of the week

Agile mengajarkan kita arti sebenarnya dari Arsitektur

gambar

Apa itu arsitektur? Bukan kota atau bangunan, tetapi versi organisasi: arsitektur perusahaan, arsitektur solusi, arsitektur aplikasi, arsitektur perangkat lunak, arsitektur bisnis, arsitektur infrastruktur? Rambut di kepalaku mulai bergerak ketika kami, arsitek, beralih ke topik ini dengan menara gading kami yang menjengkelkan, diciptakan untuk pemikiran yang menghibur kebanggaan kami. Tapi kali ini saya harus menyentuh masalah ini, karena itu merupakan prasyarat untuk mempertimbangkan topik utang (arsitektur, teknis) dan arsitektur, semua bersama-sama akan menjadi kisah tiga artikel.

Agile dan apa yang dia katakan tentang Arsitektur


Arsitektur secara resmi disebutkan dalam Agile Manifesto , yang menyatakan bahwa salah satu prinsip dasar adalah: "Arsitektur, persyaratan, dan keputusan desain terbaik lahir dalam tim yang mengatur diri sendiri."
Arsitektur, persyaratan, dan desain terbaik muncul dari tim yang mengatur diri sendiri.
(Dari: Prinsip Agile Manifesto )

Masalahnya bukan hanya bahwa ia tidak memberikan definisi tentang apa arsitektur itu, tetapi hanya dari mana asalnya, tetapi juga bahwa arsitektur itu agak naif .

Agile tidak hanya memiliki pendukung yang serius (dan saya menganggap diri saya termasuk di antara mereka), tetapi juga bagian yang adil dari para fanatik yang cenderung percaya (dan kadang-kadang memaksa kepemimpinan mereka untuk percaya) bahwa "bekerja dengan gesit" memberi Anda kemampuan tak terbatas untuk berubah dan Anda dapat membuat semua jenis perubahan , termasuk konversi besar. Kami bahkan memiliki kerangka kerja yang cukup besar seperti Scaled Agile Framework (SAFe), yang dapat diterapkan untuk perubahan berdasarkan prinsip-prinsip fleksibel untuk tingkat strategis tertinggi.

Kerangka kerja seperti itu memiliki kesamaan dengan kerangka kerja komprehensif yang dibuat sebelumnya (FEAF, MODAF, TOGAF, dll.). Tidak ada yang benar-benar menggunakan semuanya. Lingkup kerangka kerja biasanya tidak mudah dipahami oleh semua orang yang bekerja dalam konteks sempit mereka. Tampak bagi saya bahwa dasar-dasar praktik kerja saat ini telah diekstrapolasi untuk membuat kerangka kerja yang lengkap. Meskipun "pengisi" belum pernah diuji, namun, semuanya sepenuhnya dijual sebagai "praktik terbaik."

Mari kita lihat TOGAF dan SAFe, mereka dengan kuat didasarkan pada dunia pengembangan aplikasi. Ini terbukti ketika TOGAF mendasarkan salah satu dari dua definisi arsitekturnya pada definisi arsitektur perangkat lunak ISO.
– , , .
(: ISO/IEC/IEEE 42010:2011)

Atau, ketika SAFe memberi tahu kami bahwa ada fitur dan enabler, dan salah satu enabler adalah “infrastruktur” (walaupun Anda bisa, tentu saja, abstrak konsep ini). Kerangka sering agak berat dalam definisi dan detail, mereka mencoba menjadi komprehensif. Oleh karena itu, mereka sering tumbuh dari waktu ke waktu untuk mendefinisikan dan merangkul semakin banyak. Tetapi kerangka kerja besar biasanya hanya digunakan sebagian, karena kerangka kerja penuh di sebagian besar situasi adalah kelebihan birokrasi. Apa yang sering terlihat dalam "penyakit definisi", keinginan untuk membuat definisi yang ketat untuk semuanya, termasuk untuk hal-hal yang akan mengabaikan definisi tersebut dalam kenyataan ( Ludwig Wittgenstein ).

Sementara kerangka kerja besar dapat dilihat dengan mata kritis, konsep Agile sendiri (meskipun bukan baru) memang merupakan jawaban yang sangat praktis (setidaknya sebagian) untuk kompleksitas dan, di atas semua, variabilitas. Agile adalah reaksi terhadap sebagian besar perubahan dan transformasi dalam organisasi yang kompleks saat ini. Kompleksitas karena IT dibiarkan kompleks . Variabilitas, karena dibandingkan dengan pabrik yang penuh dengan alat berat, TI cukup mudah untuk diubah. Masih perangkat lunak , dan bahkan perangkat kerasTidak memiliki masa kerja seperti itu, misalnya, sebagai dinding bangunan Organisasi kompleks saat ini menghasilkan perubahan yang lebih otonom daripada organisasi "kertas" di masa lalu. Air terjun dengan Desain Bagian Depan Besar (BUFD) telah menjadi sangat tidak praktis sehingga di dunia sekarang ini dengan beban IT, menjadi hampir mustahil. Dengan demikian, kami mendapatkan evolusi paralel massal permanen di organisasi kami berdasarkan banyak tim (Agile) yang bekerja secara paralel.
, - . - , , , . - — , — .
( , )



Seperti yang saya katakan di atas, diskusi tentang "Apa itu arsitektur" biasanya merupakan pemborosan energi, lebih baik menghabiskannya untuk mengembangkan solusi desain yang baik untuk organisasi Anda. Ada banyak definisi arsitektur, saya telah menunjukkan yang paling banyak digunakan di atas. Ada definisi lain dalam Mastering ArchiMate, dan saya akui sebagian saya menyukainya:

Arsitektur enterprise adalah tentang memahami semua elemen berbeda yang membentuk sebuah perusahaan, dan bagaimana elemen-elemen ini saling berhubungan.

Ini dari Institute For Enterprise Architecture Developments. Bukannya saya tidak setuju dengan semua yang mereka tulis, tapi tetap saja "O" ini tidak mengatakan "Bagaimana" karena beberapa alasan. Dan "Memahami" adalah kata yang sama licinnya. Jadi semua ini tidak benar-benar membantu Anda. Ada banyak definisi lain, dari MIT, pemerintah AS, dll. Salah satunya dari ArchiMate Foundation: “Keseluruhan prinsip, metode, dan model yang disepakati yang digunakan dalam perancangan dan implementasi struktur organisasi suatu perusahaan, proses bisnis, sistem informasi, dan infrastruktur ".

Tetapi definisi yang cocok dengan perasaan saya sendiri adalah bahwa Martin Fowler, dalam artikelnya yang dikenal luas tahun 2003, " Siapa yang butuh arsitek?"". Di sana, ia menyelesaikan mendefinisikan arsitektur sebagai "hal-hal yang sulit diubah." Ini tidak berbeda dengan definisi Grad Buch, yang mengatakan:

Semua arsitektur adalah keputusan desain, tetapi tidak semua keputusan desain adalah arsitektur. Arsitektur merupakan keputusan penting yang membentuk sistem di mana kepentingan diukur dengan biaya perubahan.

(Catatan: kutipan yang lebih lengkap memiliki poin bagus tentang "sains dan seni"). Saya juga sangat percaya bahwa arsitektur, bagaimanapun, tidak lebih dari keputusan desain, dan bahwa keinginan untuk benar-benar memisahkannya sebagian berasal dari “[keinginan] untuk berbicara tentang keputusan desain, tetapi [keinginan] untuk mengembang mereka sehingga mereka terdengar penting ”(Fowler). Jadi, di kami dunia arsitektur, kita dapat mengatakan:Arsitektur adalah keputusan desain yang sulit diubah . Tentu saja, sangat sulit untuk mengubahnya hanya ketika diterapkan. Makalah ini akan menanggung segalanya, dan surat-surat akan dengan mudah berubah (kecuali jika Anda berada dalam diskusi arsitektur neraka berusia 6 bulan). Tapi arsitektur, sebagai ukuran pentingnya keputusan desain, adalah definisi yang baik, dan jauh lebih baik daripada di ISO, ArchiMate, TOGAF, dll.

Namun, ada kehalusan dengan karakteristik "sulit untuk diubah".

Misalkan Anda memiliki solusi desain yang menjelaskan untuk pengembang Anda bagaimana mereka harus menyusun kode Python mereka. Jika Anda memiliki banyak kode, dibutuhkan banyak pekerjaan untuk mengubah semua kode ini dari satu struktur ke yang lain. Dengan kata lain, sulit. Oleh karena itu, solusi yang dipilih ini adalah "arsitektur", dalam hal ini, arsitektur perangkat lunak. Tetapi satu pengembang dapat dengan mudah mengabaikan keputusan ini dan menulis kode yang melakukan berbagai hal secara berbeda. Pada akhirnya, membuat "perubahan" pada perangkat lunak itu mudah. Meskipun sulit untuk mengubah seluruh arsitektur yang diimplementasikan, seringkali cukup mudah untuk mengubah hanya bagian-bagian individual di dalamnya (lihat Ralph Johnson di atas). Arsitektur, oleh karena itu, adalah sesuatu yang "berat" yang terdiri dari banyak "cahaya". Anda melihatnya di semua tingkatan, misalnya,jika keputusan desain Anda hanya menggunakan database Oracle, dan tiba-tiba, ada database PostgreSQL terpisah yang cukup mudah diatur dan karenanya mudah ditampilkan (yang membuat lanskap Anda lebih kompleks, ini biasanya tidak disetujui). Tapi gantisemua Oracle pada PostgreSQL di lanskap Anda berat (dan ini bahkan mungkin tidak sepenuhnya layak). Oleh karena itu, definisi berikut dibentuk:

Arsitektur - keputusan desain yang sulit untuk sepenuhnya dihapus dari implementasi.

(Meskipun kontraksi Fowler “sulit untuk diubah” dalam banyak kasus). Komentar lain tentang yang “sulit untuk diubah”, mungkin sulit untuk menghapusnya karena bergantung pada orang lain, oleh karena itu makna kata “implementasi” sangat luas, misalnya mengubah produsen dan konsumen layanan. "Berat" harus selalu dipertimbangkan dari perspektif organisasi Anda, contoh yang baik mengapa bidang arsitektur biasanya lebih luas daripada bidang solusi, proyek atau produk.
Catatan: 1) Definisi ini tidak tergantung IT. 2) Dapat dikatakan bahwa dengan cara ini saya mengungkapkan makna kata "fundamental" dalam definisi "Arsitektur" menurut ISO.

Agile dan Arsitektur, ujung berbeda dari skala yang sama


Ternyata hubungan yang sangat menarik antara dunia Agile dan dunia Arsitektur. Agile dirancang untuk membuat perubahan sebanyak mungkin, untuk membuat perubahan mudah (atau setidaknya tidak sulit ). Dan di sisi lain: Arsitektur, seperti yang telah kita perhatikan, adalah tempat perubahan itu sulit . Dengan kata lain, mereka berada di ujung yang berlawanan dari spektrum, mereka adalah ayunan mendasar dalam organisasi Anda.

Saya mendukung Agile, dan menyatakan bahwa ini adalah cara terbaik untuk melakukan perubahan pada lanskap bisnis kompleks yang dimuat oleh IT. Tetapi itu berarti bahwa semua yang kami temukan sulit dicapai dengan menggunakan pendekatan Agile adalah "Arsitektur" de facto. Jadi Agile mengajarkan kita apa itu Arsitektur .

Catatan: Penting untuk dicatat bahwa Agile mengambil banyak hal dari Lean, yang didasarkan pada pendekatan Toyota terhadap pabrik fisik. Toyota ingin membuat produksi lebih fleksibel untuk mengatasi kompleksitas. Tetapi ada banyak aspek dari pengaturan ini yang tidak mudah diterjemahkan ke dalam dunia perangkat lunak flint. Sebagai contoh, Toyota mendukung variabilitas yang sangat terbatas, dan sebagian besar hal tidak dapat berubah. Dalam perangkat lunak, segala sesuatu dapat berubah, dan tidak benar menurut definisi bahwa metode yang (sedikit, tetapi dengan efek besar) sub-dioptimalkan proses produksi fisik dapat menjadi dasar untuk proses produksi lain.

Jadi di mana kita menemukan arsitektur, di mana Agile mendapat masalah? Ada beberapa contoh nyata:

  1. feature/defect «», , . ( , , ESB ), . , . , , ( ), .
  2. Agile , , YAGNI (You Ain’t Gonna Need It) (just in time). SAFe Architectural Runway, features defects. SAFe , . SAFe « Runway», features «». YAGNI ( , «»). – , – . , , Agile , « , DevOps» (DRDC). , , Tomcat, JBoss, Session state storage , File sharing, Redis, MongoDB, MQ, IIS .. Lean ( ) YAGNI, , , «» («muda» « » Lean). , , , , ( «muru» «»). , , Runway , , .
  3. Agile , . , , , . , , Agile ( «muri» «»). , . Agile ( : ...) – .

Saya minta maaf karena menggunakan istilah Jepang secara bebas di sini. Dengan demikian, Agile berfokus pada fakta bahwa Arsitektur adalah objek, bukan praktik, dan pikiran mengatakan bahwa:

Arsitektur adalah setiap keputusan desain yang diterapkan yang membuat Agile sulit.

Pilihan apa yang Anda masukkan ke dalam "rencana ekspansi Runway" Anda tergantung pada seberapa sulit untuk melakukan transformasi: ini adalah pilihan arsitektur. Dan Anda tidak bisa menyerahkannya kepada pemilik produk di bawah tekanan dari pengguna. Pilihannya juga harus dibuat dengan partisipasi para pemangku kepentingan arsitektur, sehingga ada pengecekan dan keseimbangan terhadap "bunker" dan "jangka pendek". Lebih lanjut tentang arsitektur (sebagai praktik) di bagian kedua dari seri artikel mini ini.

Mendefinisikan arsitektur sebagai kombinasi dari "hal-hal berat" bukanlah yang kita butuhkan. Karena selain "keras", kami memerlukan beberapa rekomendasi tentang apa yang harus diperjuangkan dengan arsitektur. Sering dikatakan bahwa ide arsitektur adalah memberikan fleksibilitas dengan menciptakan solusi yang fleksibel. Bahkan, Fowler menyatakan bahwa tugas arsitek adalah menghapus arsitektur. Tapi itu terlalu sederhana. Fleksibilitas biasanya mahal, dan “biaya” ini (waktu dan uang) tidak dapat meningkat tanpa batas waktu (lihat Johnson di atas). Semua orang ingin solusi sepenuhnya fleksibel, tetapi tidak murah (dan tidak ada yang mau membayar tagihan), itu tidak cepat, dan bahkan tidak selalu mungkin. Terkadang situasinya sederhana: Anda harus membuat pilihan yang sulit diubah, Anda tidak bisamendukung semua opsi (misalnya, memilih platform, Anda tidak dapat mendukung semuanya). Tentu saja, jika pilihannya tidak terlalu mahal, maka pilih solusi yang fleksibel atau tunda pilihan selama mungkin (seperti yang disarankan SAFe: jangan batasi pilihan Anda). Tetapi dalam praktiknya kita sering harus membuat pilihan. Pilihan yang sulit diubah adalah pilihan arsitektural. Arsitektur berusaha untuk meminimalkan kelenturan yang tidak perlu, karena naif untuk berpikir bahwa akan ada dunia di mana semua perubahan itu mudah dan tidak ada yang sulit. Ada hal-hal yang tidak kalah pentingnya, dan lebih sering bahkan lebih penting daripada fleksibilitas. Saya pikir ada tiga di antaranya: Keandalan, Efisiensi dan Fleksibilitas - Robustness, Efisiensi, Fleksibilitas (REF).

Pelajari lebih lanjut tentang REF, praktik arsitektur, dan utang.di bagian kedua, tapi saya ingat video "Mengapa arsitektur perusahaan", yang kami buat bertahun-tahun yang lalu, pada saat kami membuat arsitektur yang paling fleksibel di dunia BUFD:


Dengarkan dokter dan pengacara Anda


Dan sebagai kesimpulan, arsitektur (sebagai objek) adalah apa yang "berat", tetapi Anda juga dapat mengatakan bahwa "arsitektur (sebagai praktik) berat". Mereka terkait erat, arsitektur (sebagai praktik) sulit, karena kompleksitas saat ini membuat perubahan sulit, dan ketidakkekalan hari ini membuat perubahan kuat. Itu sebabnya Anda harus membayar arsitek megabita yang baik . Yah, mungkin tidak , tetapi Anda harus mendengarkan arsitek yang baik dan menerima saran mereka dengan sangat, sangat serius. Hanya ada satu pertanyaan sederhana yang tersisa: Bagaimana mengenali arsitek yang baik?

More articles:


All Articles