Pada tanggal 5 September, Moskow menyelenggarakan Round Table “IT Project Architect” di HSE. Penyelenggara meja bundar, Maxim Smirnov, adalah
blog tentang arsitektur dan
saluran Facebook .
Saya sangat senang bahwa acara semacam itu diadakan. Menjadi arsitek yang keren adalah dan tetap menjadi impian saya. Untuk waktu yang sangat lama saya tidak mengerti bagaimana arsitek umumnya mendapatkan, bagaimana mengembangkan dan arah apa yang harus dipilih sehingga mereka mengarah pada arsitektur, dan, saya pikir, pertanyaan seperti itu muncul tidak hanya untuk saya. Sangat menyenangkan bahwa ada komunitas tempat Anda dapat datang dan mengajukan pertanyaan kepada arsitek.
Di meja bundar, 4 laporan 15-20 menit disajikan, setelah itu ada pertanyaan dari audiens dan diskusi.
Laporannya singkat dan to the point, dan diskusi itu sangat hidup dan luas.
Selanjutnya, catatan saya selama laporan.
Laporan 1
Keterampilan kunci arsitek keputusan dalam proyek dari awal
Gennady Kruglov
Arsitek SOA Bersertifikat, ctn
Sebagai bagian dari presentasi, tahapan utama proses arsitektur tersentuh:
- Keterlibatan bisnis.
- Insinyur yang terlibat.
- Prototyping.
- Pilihan gaya arsitektur dan tumpukan teknologi (microservices, monolith, SOA).
- Pengembangan konsep arsitektur.
- Demonstrasi kepada pelanggan.
- Desain Solusi.
- Mendokumentasikan solusi lengkung.
- Pengawasan arsitektur.
Sorotan kinerja:
Dianjurkan untuk membuat prototipe untuk menunjukkannya kepada bisnis. Kapan pun memungkinkan, perlu melibatkan pihak yang berbeda ketika memilih gaya arsitektur - pengembang, keamanan, operasi. Saat merancang sketsa, Anda perlu membuat bagian arsitektur yang berbeda - bisnis, teknologi, keamanan.
Jika mungkin, perlu untuk menarik orang yang kemudian akan langsung bekerja dengan bagian sistem ini.
Setelah berdiskusi dengan pihak-pihak yang berkepentingan, sebuah prototipe ditunjukkan. Jika proyek dimulai, studi yang lebih rinci dari setiap tingkat arsitektur dilakukan.
Selama pengembangan, sinkronisasi dengan arsitek diperlukan untuk memverifikasi bahwa prosesnya mengikuti jalur yang dipilih.
Keterampilan yang, menurut pembicara, dibutuhkan oleh arsitek:
- Keterampilan komunikasi (persuasi, negosiasi)
- Presentasi
- Brainstorming dan workshop
- Pengetahuan tentang gaya arsitektur
- Cakrawala luas dari teknologi modern (penting untuk memahami kekuatan dan kelemahan)
- Keterampilan Desain dan Aplikasi
- Keterampilan pengembangan menggunakan berbagai kerangka kerja, produk, dan bahasa pemrograman
- Pengetahuan tentang kerangka kerja dokumentasi keputusan
- Memahami berbagai jenis SDLC (siklus hidup pengembangan sistem)
- Jaringan koneksi profesional yang luas
- Keterampilan dalam mengelola tim pengembangan
Laporan 2
Dukungan arsitektur untuk proyek-proyek TI
Dmitry Romanov, ITSK
Merancang solusi IT, dukungan arsitektur proyek, sekitar 80 proyek setahun, sekitar 50 arsitek terlibat dalam proses tersebut.
Layanan kepala arsitek TI menentukan kebijakan teknis di bidang TI, yang diterapkan oleh arsitek proyek TI. Menjawab pertanyaan di mana arsitek biasanya mengumpulkan keahlian yang diperlukan, Dmitry menunjukkan sumber-sumber berikut:
- Pengalaman - menciptakan sistem serupa
- Kolega - seseorang di dalam perusahaan atau di perusahaan lain
- Vendor - konsultasi dengan pengembang
- Forum Tematik
- Technopark - persetujuan atau kotak pasir berdasarkan Technopark
Mempertimbangkan perlunya peran arsitek dalam ITSK, Dmitry menunjukkan bahwa arsitek proyek TI diperlukan sehingga, misalnya, tidak ada situasi di mana proyek telah selesai selama 1 tahun, maka mereka telah bekerja selama enam bulan dan menyadari bahwa tidak ada penskalaan, dan kemudian diperbaiki selama 2 tahun. Pemahaman yang jelas adalah penting agar arsitektur yang diusulkan dapat diimplementasikan. Bergantung pada metodologi manajemen proyek, dalam ITSK arsitek dapat masuk ke dalam tim (jika gesit) atau masuk ke dalam kelompok ahli proyek.
Laporan 3
Arsitektur dalam proyek TI organisasi: fokus utama
Ivan Lukyanov, Departemen Teknologi Informasi Moskow, produk "Layanan negara dan MFC"
Biografi profesional pembicara: pengembang di Diasoft, kepala tim pengembangan (BSC Praha), konsultan terkemuka (Neoflex), kepala departemen arsitektur dan strategi di Alfa Bank, kepala departemen pengembangan arsitektur (DIT).
Ivan merekomendasikan dimulai dengan deskripsi arsitektur yang ada (sebagaimana adanya), membuat arsitektur target (menjadi), dan menganalisis perbedaan antara titik "di mana organisasi sekarang" dan "di mana organisasi ingin pergi" menggambarkan langkah-langkah untuk membawa sistem ke status target.
Fokus utama proyek TI dalam arsitektur:
- Pernyataan masalah bisnis yang harus dipecahkan: arsitek harus memastikan bahwa tugas bisnis dilakukan dengan baik, dijelaskan dalam bentuk yang sesuai untuk desain, disetujui oleh orang yang bertanggung jawab untuk bisnis
- Visi: dengan upaya arsitek dalam organisasi, arsitektur target organisasi harus dikembangkan untuk kebutuhan spesifik bisnis. Arsitektur target harus dipecah menjadi langkah konkret (proyek) untuk mencapainya.
- Desain: semua solusi dirancang dengan mempertimbangkan arsitektur target yang dikembangkan. Arsitektur target diimplementasikan secara bertahap dari proyek ke proyek. Arsitek menyetujui keputusan tentang arsitektur.
- Proses implementasi proyek: organisasi harus memiliki proses yang mencakup analisis dan deskripsi tugas bisnis, pengembangan arsitektur target dan proses desain (pengembangan dan operasi tidak tercakup dalam laporan). Proses tersebut harus disetujui oleh semua pihak yang terlibat dan didukung oleh manajemen.
- Dukungan metodologis untuk proses implementasi proyek: seringkali arsiteklah yang menjadi figur di pundaknya terletak pengembangan metodologi untuk mengimplementasikan proyek-proyek TI dalam suatu organisasi, dengan mempertimbangkan perumusan tugas dan desain bisnis. Sebagai bagian dari pekerjaan ini, penyesuaian dapat dilakukan pada proses implementasi proyek TI yang ada di organisasi (jika ada sebelumnya) atau pembuatan proses baru dari awal (jika tidak ada). Hasil dari pekerjaan metodologis adalah proses yang dijelaskan dan dokumen pendukung, diformalkan dalam bentuk templat.
Perusahaan kini telah mengembangkan metodologi sendiri, termasuk template yang digunakan dalam pekerjaan dokumen. Prinsip-prinsip
TOGAF dan Gartner digunakan.
Prinsip-prinsip arsitektur disetujui, dokumen "Solusi arsitektur dan teknologi" dikembangkan, yang menggambarkan persyaratan bisnis untuk solusi dan proyek untuk implementasinya.
Fitur arsitek:
- Kemasyarakatan. Komunikasi dengan manajemen, dengan pemain, dengan dukungan, dengan manajer dan penguji adalah penting. Arsitek harus memainkan peran penerjemah - menerjemahkan dari bahasa bisnis ke teknis dan sebaliknya.
- Prasyarat adalah pengalaman pengembang (baik, jika juga analitik).
- Menghormati kolega.
- Pengembangan berkelanjutan.
Arsitektur bukanlah monumen tak bergerak yang dilemparkan ke dalam granit, tetapi pandangan yang hidup dan berkembang tentang apa yang ingin kita capai dalam hal dukungan bisnis.
Laporan 4
Arsitek proyek TI: salah satu sudut pandang yang memungkinkan
Evgeny Aslamov Aslamov, Arsitek Utama, Grup Perusahaan Lanit.
Jalur Eugene ke peran arsitek: pengembang, analis, manajer proyek. Selama cerita pendek, penulis mengangkat beberapa masalah yang berkaitan dengan peran arsitek dalam pengembangan adat: apa yang mengelilinginya, apa yang dia lakukan dan bagaimana dia melakukannya.
Menurut pendapat Eugene, berbicara tentang arsitek dalam pengembangan kustom, kami bergantung pada berbagai faktor - waktu, anggaran, tim, kompleksitas dan volume tugas. Sebagai aturan, dalam proyek kompleks (beberapa ribu skenario pengguna, integrasi dengan beberapa lusinan sistem, volume data besar, persyaratan parah untuk Ketersediaan Tinggi & Pemulihan Bencana), tugas arsitektur ditutup oleh tim arsitek. Pada proyek yang lebih sederhana, satu orang dapat mengatasi tugas-tugas ini dan arsitek tidak selalu didedikasikan untuk tugas - perannya dapat dikombinasikan dengan peran lain - pengembang utama atau analis.
Seorang arsitek, seperti halnya anggota tim, bekerja dalam konteks tertentu. Satu garis besar dari konteks seperti itu:
Pelanggan- manajemen tertinggi (dalam hal apa pun, cukup tinggi untuk keputusan kunci) dari pelanggan yang bertanggung jawab atas proyek;
- komite pelanggan (arsitektur, desain, operasi, dll. - sering terjadi);
- layanan atau departemen spesialis keamanan informasi;
- karyawan pelanggan yang membutuhkan sistem yang "membakar" proyek;
- realitas - rutinitas yang agak dangkal, faktor manusia, masalah prosedural, ketidaksepakatan kecil, dll.
Tim- Manajer
- Analis
- pengembangan;
- DevOps
- layanan berkualitas;
Kontrak- tenggat waktu;
- anggaran
- kutipan hukum;
- teknologi, pendekatan, chip baru yang benar-benar ingin saya terapkan;
- tradisi: itu bekerja dan itu baik, semuanya baik-baik saja dengan kami - apa yang harus diubah dan sejenisnya.
Sebagai bagian dari konteks, seorang arsitek atau kelompok arsitek melakukan hal berikut:
- Ini membentuk batas-batas untuk tim di mana proyek akan dikembangkan dan hidup. Pertama-tama, kita berbicara tentang batas-batas yang timbul dari persyaratan non-fungsional.
- Bentuk, dukungan, dan pembaruan solusi arsitektur dengan mempertimbangkan pandangan para pemangku kepentingan utama.
- Bekerja sebagai penerjemah - menerjemahkan dari bahasa teknis ke bahasa Rusia dan sebaliknya. Sebenarnya untuk pelanggan dan tim. Arsitek harus memahami semua aspek proyek (bersama dengan analis terkemuka dan manajer proyek) dan dapat menjelaskan hubungan mereka dengan bagian-bagian teknis.
- Mengajukan banyak pertanyaan tidak menyenangkan. Kebetulan beberapa keputusan dibuat tanpa partisipasi satu atau anggota tim yang lain. Ini normal. Jika sesuatu telah dilakukan dan mempengaruhi atau dapat mempengaruhi arsitektur sistem, maka Anda perlu mencari tahu alasannya, untuk mencari tahu apakah Anda perlu mengubah sesuatu sekarang, menyediakan beberapa langkah untuk masa depan, atau Anda dapat merekam dan membiarkannya sampai waktu yang lebih baik.
Menjawab pertanyaan "Bagaimana dia melakukan ini?", Eugene pertama-tama menyentuh masalah pengembangan solusi arsitektur. Beberapa komponen diidentifikasi yang membantu dalam tugas ini:
- Pengalaman dan analogi. Ini adalah salah satu aset terpenting arsitek. Dan itu perlu terus ditingkatkan - jangan mandek dalam satu proyek, teknologi, dll.
- Cakrawala. Anda tidak dapat menggunakan pengalaman Anda sendiri - pengalaman rekan kerja, pengalaman komunitas, standar.
- Prototipe. Dalam hal menggunakan yang baru, belum teruji atau dengan risiko yang terlihat, prototyping diperlukan. Pada saat yang sama, penting untuk merumuskan dengan tepat dan akurat pertanyaan-pertanyaan yang harus dijawab oleh prototipe, jika tidak hanya akan memperburuk situasi.
- Melindungi keputusan Anda. Sebelum tim proyek, sebelum komite arsitektur (milik Anda atau pelanggan), di depan Anda. Sebagai salah satu solusi dapat menjadi pengantar (elemen penuh atau individu) dari ATAM - Metode Analisis Tradeoff . Di sejumlah proyek kami, misalnya, perlindungan keputusan diimplementasikan sebagai presentasi keputusan kunci kepada kolega di luar proyek untuk pendapat dan komentar alternatif.
Alih-alih kesimpulan: salah satu tugas informal seorang arsitek, dan setiap spesialis yang mencintai pekerjaannya, adalah mempopulerkan pengetahuan, teknologi, pendekatan, dan keterampilan yang akan memungkinkan tim untuk memecahkan masalah pada suatu proyek lebih efisien dan dengan kenyamanan yang lebih besar.
Artikel Eugene tentang habr “
Kami sedang mempersiapkan
proyek di Sparx Enterprise Architect. Resep kami . "
Tanya Jawab
Berikutnya adalah bagian pertanyaan dan jawaban, yang paling diingat bisa dibaca di bawah.
Dari mana arsitek berasal?
Gennady:Arsitek perangkat lunak - mantan pemimpin tim atau pemimpin atau pengembang utama.
Dmitry:Arsitek diambil dari pengembang dari konsultan, dengan keahlian luas.
Pengembang dapat berbicara dan menggambar presentasi - arsitek solusi.
Eugene:Secara umum, dari bagian mana pun - dari pengembangan, pengujian, manajemen proyek, dll. Tetapi bagaimanapun juga, beberapa spesialisasi teknis membantu - mereka tidak harus dikembangkan dari awal.
Sebuah contoh dari pengalaman pribadi: seorang mahasiswa dari departemen mekanika Universitas Negeri Moskow, orang yang cerdas, mudah bergaul tanpa penyakit bintang, dibawa ke perusahaan Lanit. Dia bekerja sedikit dalam bidang analitik, pengembangan, komunikasi dengan pelanggan. Akibatnya, ia menjadi arsitek terapan di perusahaan kami.
Ivan:Dari para pengembang. Jika ada pengembang yang baik, maka ia dapat terus mempelajari bahasa pemrograman, mengembangkan lebih dalam. Tetapi jika, pada suatu waktu, dia ingin tahu bagaimana tugas teknis lahir, siapa yang menganalisis, siapa yang membuat keputusan apakah ini harus dilakukan atau tidak, maka ini adalah sinyal bahwa spesialis telah memulai di jalur seorang arsitek pemula. Tingkat keingintahuan berikutnya adalah bagaimana sebuah solusi dilahirkan secara keseluruhan, di tingkat bisnis. Bagaimana Anda bisa menunjukkan kepada kepala organisasi bahwa ia membutuhkannya dan apa yang tidak. Dalam menggambarkan peran arsitek,
Gregor Hohpe menggunakan metafora lift . Setiap lantai tempat elevator berhenti adalah level tertentu dalam organisasi: lantai pertama - ruang mesin - ini adalah pengembang, produksi; lantai atas - manajemen organisasi. Membawa arsitektur hidup, arsitek berkomunikasi di setiap lantai (dari yang pertama ke yang terakhir) dan di setiap lantai ia harus menghadapi berbagai kesulitan - teknologi, politik, komunikasi.
Arsitek mampu mengumpulkan informasi yang diperlukan dan menyampaikannya ke setiap tingkat. Bahkan, dia bertindak sebagai mediator antara pihak-pihak yang terlibat.
Bagaimana seharusnya wewenang dibagi antara manajer proyek dan arsitek?
Harus ada keseimbangan antara otoritas. Wewenang arsitek terletak pada bagian teknis, dan manajer proyek di bagian organisasi.
Jika keseimbangan dialihkan ke RP - Anda bisa mendapatkan proyek tepat waktu, tetapi tidak berfungsi atau tidak dapat diskalakan. Dan, jika menuju arsitek, maka Anda bisa mendapatkan proyek yang luar biasa ketika tidak ada yang membutuhkannya. Ini adalah bagaimana menjawab pertanyaan "Siapa yang kamu cintai lebih - ibu atau ayah?"
Bagaimana menjadi arsitek perusahaan yang memiliki aliran besar proyek yang berbeda?
Ivan:Dalam organisasi besar, lebih dari 2.000 orang membuat satu arsitektur perusahaan dan hampir mustahil untuk mengikutinya. Dalam DIT, sebuah divisi dibuat menjadi produk (layanan), setiap produk memiliki tumpukan teknologinya sendiri, arsitekturnya sendiri. Adapun arsitektur perusahaan, pemegang saham lebih membutuhkannya sehingga mereka memahami ke mana arah organisasi dalam hal pengembangan arsitektur. Untuk tujuan ini, peran kepala arsitek TI sering disorot dalam organisasi, tugas utamanya adalah menentukan lanskap arsitektur perusahaan secara keseluruhan.
Bagaimana interaksi antara arsitek proyek dan arsitek perusahaan dibangun?
Komunikasi itu penting. Anda perlu membangun komunikasi dan berkomunikasi. Seorang arsitek proyek mungkin tidak memerlukan pengetahuan arsitektur perusahaan, tetapi penting untuk mengetahui dengan siapa integrasi akan terjadi dan apa dampaknya. Penting untuk membuat komite arsitektur, dimungkinkan untuk mengetahui tidak hanya arsitek perusahaan, tetapi juga yang mendesain.
Anda dapat melihatnya dari segi nilai - siapa yang membawa nilai lebih. Jika solusinya bekerja, maka ada nilai. Arsitektur enterprise itu sendiri tidak membawa nilai, tetapi membawa nilai melalui solusi arsitek yang sudah mengimplementasikan tugas tertentu.
Tidak ada yang membutuhkan generalis - semakin sedikit orang yang tidak tahu apa-apa tentang segalanya. Lebih baik untuk dapat menjawab pertanyaan-pertanyaan spesifik, misalnya, apakah RabbitMQ cukup di sini atau diperlukan Kafka.
Bagaimana repositori arsitektur enterprise diorganisasikan?
Apakah ada model rumit yang dapat dihitung, diverifikasi, dll.?
Eugene: kami memiliki repositori arsitektur, tetapi tidak ada otomatisasi untuk menghitung metrik apa pun. Hubungan antara model dan model itu sendiri memungkinkan kita untuk mempertimbangkan arsitektur sebagai sesuatu yang tidak terpisahkan, daripada satu set gambar. Salah satu tugas repositori adalah memberikan analisis dampak. Atas dasar ini, Anda dapat membuat estimasi nilai perubahan.
Kata penutup
Senang sekali Anda bisa datang dan mendengarkan para arsitek, mengenal komunitas. Pertemuan seperti itu selalu merupakan kesempatan bagi saya untuk memahami di mana menggali untuk menemukan pengetahuan yang diperlukan. Selain itu, Anda dapat mendiskusikan kasus kerja dan mendapatkan rekomendasi.
Terima kasih kepada Maxim Smirnov dan HSE karena telah mengatur meja bundar para arsitek!
Juga banyak terima kasih kepada penulis laporan (Eugene Aslamov, Gennady Kruglov, Ivan Lukyanov) untuk persiapan teks ini , karena catatan asli ditulis selama laporan dan berisi kesalahan dan ketidakakuratan yang dikoreksi.
Dalam foto, Puri
Chambord di Prancis , kata mereka, setiap pemilik membangun menara. Terkadang, arsitektur proyek terlihat seperti itu. Menurut pendapat saya, seorang arsitek diperlukan agar semuanya indah dan sesederhana mungkin, sehingga bahkan dengan sekelompok menara dalam gaya yang berbeda, Anda masih akan mendapatkan kastil yang indah.