Get best of the week

Daftar periksa untuk seorang arsitek

Dari artikel ini Anda akan belajar bagaimana mengatur proses membangun pengembangan yang efektif di perusahaan digital terdistribusi, bagaimana melakukan ini melalui komunikasi ahli, dan bagaimana ini terjadi dengan contoh MTS.

MTS, seperti banyak perusahaan modern lainnya, telah mengalami apa yang disebut transformasi digital. Secara sederhana, peluncuran proses dan produk digital telah menjadi prioritas kami.

Bagi saya, sebagai seorang teknisi, ini berarti bahwa arah bisnis di perusahaan sepenuhnya bergantung pada kualitas sistem TI dan kemampuan mereka untuk berkembang pesat.

Tentu saja, ini adalah definisi yang salah, dan pemasar dapat berdebat dengan saya - dan bahkan berdebat! Tetapi untuk semua yang Anda baca di bawah ini, itu sudah cukup.



Kurang birokrasi - pengembangan lebih mudah


Apa yang telah berubah: pertama-tama, model manajemen perusahaan. Jika sebelumnya orang-orang dari arsitektur perusahaan terpusat (arsitektur perusahaan) memverifikasi setiap proyek, sekarang mereka menerbitkan kebijakan teknis (dokumen yang besar dan cerdas) dan melatih arsitek. Dan bagaimana cara menerapkannya sudah menjadi masalah pribadi setiap arsitek produk dari lebih dari seratus tim.
 
Di satu sisi, ini bagus - kurang birokrasi, yang sangat menyederhanakan pembangunan. Di sisi lain, semua produk berinteraksi satu sama lain dalam satu atau lain cara, dan kesalahan dalam salah satu dari mereka dapat mempengaruhi yang lain.

Misalnya, dalam Arsitektur Sistem Perangkat Lunak: Bekerja dengan Pemangku Kepentingan Menggunakan Sudut Pandang dan Perspektif, Eoin Woods dan Nick Rozanski menulis tentang prinsip keamanan dasar, mengamankan tautan terlemah. Ini berarti bahwa jika lansekap TI Anda memiliki setidaknya satu sistem TI yang terlindungi dengan lemah, maka seluruh lanskap TI berisiko. Hanya karena penyerang hipotetis dapat bekerja dengan impunitas atas nama sistem ini.

Ada banyak lagi contoh di mana berguna untuk memiliki kualitas dan konsistensi yang terjamin dalam desain dan pengembangan sistem TI.

Ahli Introvert


Apa yang kami hasilkan: menciptakan komunitas untuk berbagi pengetahuan dan menyebarkan praktik terbaik. Idenya bukanlah hal baru dan tidak terlalu revolusioner, tetapi memenuhi persyaratan dan spesifikasi pengembangan produk digital.

  • — DevOps- support-;
  • , . , , ;
  • - , — . . -, ; -, ; -, ;
  • , ;
  • Organisasi rotasi dalam tim "auditor" sehingga sebanyak mungkin perwakilan tim memiliki kesempatan untuk berbagi pengetahuan dan pengalaman.

Untuk memulai proses, kami mengumpulkan tim penggemar, mengembangkan daftar topik diskusi untuk masing-masing peran, dan melatih tim auditor dadakan kami. Ngomong-ngomong, pelatihan adalah tahap yang paling sulit, karena seringkali spesialis yang sangat bagus di bidang kita juga introvert yang sangat baik :-)

Apa hasilnya?




  • Proses meneliti tim produk agak santai. Rata-rata, dibutuhkan sekitar 31 hari untuk satu tim. Selama waktu ini, kami berhasil berkomunikasi dengan perwakilan dari semua bidang kegiatan tim, menyusun laporan memo dan menjelaskannya kepada pemilik produk sehingga ia dapat merencanakannya untuk tindakan;
  • Hasil pekerjaan sangat tergantung pada ahli. Karena itu, penting ada beberapa peran untuk setiap peran: dua analis, dua arsitek, dll. di mana satu telah melakukan serangkaian wawancara, dan yang lainnya hanya terlibat dalam komunikasi;
  • Penting juga untuk terus-menerus mengadaptasi metodologi wawancara, karena beberapa topik kehilangan relevansinya, dan sebagai gantinya ada pertanyaan yang belum pernah dipikirkan sebelumnya.

Sebagai contoh, mari kita lihat hasil studi ke arah "Arsitektur".
 
Apa yang telah kita lakukan:

  • Berkomunikasi dengan 20 tim;
  • Masing-masing menghabiskan rata-rata 31 hari. Mengingat fakta bahwa kami secara bersamaan berinteraksi dengan beberapa tim, seluruh proses memakan waktu enam bulan;
  • Mengungkap 180 risiko yang terkait dengan arsitektur.

 Dalam tim kami, risikonya dibagi sebagai berikut:


Risiko 1: desain

Penting untuk dipahami bahwa semua sistem perangkat lunak yang kami teliti melalui kontrol kualitas keluaran yang cukup ketat (misalnya, sistem telekomunikasi memiliki periode pemantauan yang lebih lama daripada periode pengembangan), tetapi tidak ada batasan untuk kesempurnaan dan efisiensi. .

Untuk memahami apa yang kita anggap sebagai risiko, mari kita lihat TOP-3 dengan contoh.

Untuk tim produk muda, situasinya cukup normal ketika arsitektur perangkat lunak dikembangkan berdasarkan residual. Pada awalnya tampaknya semuanya sederhana, dan pemilihan waktu proyek jarang memberikan kesempatan untuk serius memikirkan organisasi arsitektur. Dan kemudian metode desain bottom-up ikut bermain - ketika kita mengembangkan komponen individual dari solusi, setelah itu kita merakitnya menjadi satu kesatuan tunggal.

Sebagai contoh, kami memutuskan untuk membuat produk digital untuk telemedis. Apa yang dibutuhkan untuk ini?

  • Kami mungkin membutuhkan komponen untuk panggilan video antara pasien dan dokter - kami membuat komponen untuk panggilan;
  • Terkadang Anda memerlukan obrolan biasa - itu artinya kami membuat komponen untuk obrolan;
  • Kita perlu mengambil riwayat medis dari sistem medis otomatis - kita membuat komponen yang sesuai;
  • Kita perlu menjaga jadwal dokter yang bertugas - kita membuat komponen untuk ini juga.

Dll

Segalanya tampak sederhana sampai kita mulai menyatukan semuanya. Dan di sini ada masalah dengan duplikasi fungsi - misalnya, obrolan dan panggilan video adalah aplikasi yang sangat dekat dalam dirinya sendiri (setidaknya dari sudut pandang konteks interaksi dokter-pasien). Itu risikonya adalah kita harus mengulang aplikasi kita secara signifikan karena banyaknya kode duplikat.

Atau masalah dengan model data. Setiap komponen secara default menyediakan antarmuka dalam model itu, yang nyaman untuk menyimpan dan memproses komponen khusus ini, dan bukan aplikasi secara keseluruhan.
 
Karena itu, perlu diingat sejumlah aturan sederhana:

  • Metode desain bottom-up baik untuk proyek-proyek kecil dengan kompleksitas teknis yang rendah, tim kecil dan persyaratan yang tidak stabil;
  • Untuk proyek dan tim besar, metode desain adalah top-down, yaitu, ketika kami pertama kali merancang gambar secara keseluruhan, dan kemudian melanjutkan ke pengkodean.

Karena itu, sebelum terjun langsung ke proyek baru, tanyakan pada diri sendiri pertanyaan: apa jenisnya?
 

Risiko 2: Keamanan

Tampaknya keamanan sedang dipikirkan dengan sangat serius belakangan ini. Semua orang mengingat hal-hal sepele seperti itu sebagai kebutuhan:

  • Otentikasi pengguna
  • beri wewenang kepada mereka untuk melakukan tindakan;
  • mematuhi prinsip hak istimewa minimal;
  • menjaga kerahasiaan data;
  • menyimpan catatan audit tindakan pengguna.

Tapi ini kejutan! Untuk tim yang melakukan layanan untuk otomasi internal, ini tidak sejelas untuk semua orang. Tampaknya jika aplikasi sudah berjalan di jaringan internal perusahaan, lalu mengapa melindunginya? Bahkan, perlu, terutama jika data yang digunakan aplikasi diklasifikasikan sebagai data pribadi. Ya, kemungkinan penyusup menembus jaringan internal sangat kecil, tetapi tidak ada banyak perlindungan.
 
Dan dengan aplikasi eksternal, nuansa juga bisa muncul. Pertimbangkan aplikasi web contoh sederhana, murni hipotesis, yang mengotentikasi pengguna dengan kata sandi. Masalah apa yang mungkin ada:

  • Aplikasi ini memungkinkan Anda untuk memasukkan kata sandi yang terlalu sederhana, yang kemudian mudah diambil;
  • Aplikasi mungkin tidak dilindungi dari kata sandi brute force sendiri (tidak ada captcha atau yang seperti itu);
  • . , - ;
  • URL- HTTP- ;
  • -, . , MD5 ;
  • - ;
  • - , . , , -;
  • - : , ..;
  • - HTTP-:

  1. - session tokens , ;
  2. - session fixation- (. . session token );
  3. - HttpOnly Secure browser cookies, session tokens;
  4. - .


Jadi, risikonya di sini adalah seseorang akan mendapatkan akses ke data yang tidak dimaksudkan untuknya. Dan ini dapat menyebabkan masalah dalam aplikasi. 
Ini hanya contoh dari apa yang dapat Anda bicarakan di bidang keamanan. Tentu saja, opsi yang ideal adalah menerapkan proses Siklus Hidup Pengembangan yang Aman, misalnya, seperti yang direkomendasikan oleh Microsoft .


Risiko 3: kinerja
 
Salah satu tantangan untuk menciptakan tim produk dengan cepat adalah kata tiga huruf. Ini adalah MVP atau produk bernilai minimal. Tim semacam itu berupaya membuat aplikasi sesegera mungkin, yang akan mulai menghasilkan pendapatan bagi perusahaan, dan karena akan ada sangat sedikit pengguna di awal aplikasi, mereka biasanya memikirkan parameter kinerja pada saat terakhir. Tetapi jika aplikasi yang dibuat tiba-tiba menjadi populer, maka Anda harus memikirkan apa yang harus dilakukan selanjutnya.

Rekomendasi di sini sederhana: kinerja aplikasi berbanding terbalik dengan jumlah permintaan sumber daya yang lambat. Dengan demikian, semua taktik ditujukan untuk mengurangi jumlah permintaan, atau mempercepat sumber daya itu sendiri. Dalam hal ini, sumber daya dipahami sebagai prosesor, memori, jaringan, disk; Terkadang juga nyaman untuk mempertimbangkan database atau server aplikasi sebagai sumber daya.
 
  • Pertama, kita melihat apakah mungkin untuk membuat cache klien dalam aplikasi terdistribusi sehingga setiap kali kita tidak meminta / menghitung data yang kita butuhkan. Jika ini memungkinkan, maka kami menghemat permintaan jaringan, memuat sumber daya server dan semua yang dia lakukan di sana.
  • Tetapi itu sangat jarang beruntung, jadi kami ingin melihat apakah kami dapat membuat cache server. Dengannya, prinsipnya sama dengan klien, tetapi peningkatan kinerja sedikit kurang, karena permintaan jaringan akan tetap berjalan;
  • , . , , , , (load balancer);
  • , . — My SQL Cluster Grid Edition Apache Ignite (Gridgain).

Yah, tentu saja, kita harus ingat bahwa cache itu sendiri memecahkan masalah akses ke data, tetapi menciptakan masalah baru dengan algoritma untuk pembatalan dan preloadnya. Dan dalam beberapa sistem, caching bisa sama sekali tidak berguna. Sebagai contoh, dalam sistem CRM (Customer Relationship Management), sangat jarang dimungkinkan untuk melakukan cache data pelanggan secara efektif. Seorang spesialis yang bekerja di kantor dengan sangat cepat berpindah dari satu klien ke klien lain dan cache sama sekali tidak digunakan.

Jadi, risikonya di sini adalah bahwa tanpa terlebih dahulu memikirkan strategi bagaimana kita akan "meng-overclock" aplikasi kita, kita mungkin berakhir dengan biaya yang sangat tinggi untuk menulis ulang aplikasi di masa depan.

Meringkas


Dalam artikel ini saya mencoba untuk berbicara tentang bagaimana Anda dapat mengatur proses membangun pengembangan yang efektif di perusahaan digital terdistribusi melalui komunikasi ahli. Di zaman kita saat ini perkembangan jarak jauh, proses seperti itu menjadi sangat relevan. Mereka memungkinkan Anda untuk menghancurkan hukum Conway , atau setidaknya menguranginya.
 
Jika Anda memutuskan untuk membuat daftar periksa sendiri, maka saya akan merekomendasikan untuk tidak melakukan semuanya dari awal, tetapi untuk mengambil sesuatu dari literatur yang ada. Sebagai contoh, pada arsitektur, materi tinjauan Handbook Arsitek Perangkat Lunak oleh Joseph Ingeno ISBN sangat berguna: 9781788624060

Laporan saya dapat ditemukan di sini.

Penulis artikel: Dmitry Dzyuba, Kepala Pusat Litbang
 

More articles:


All Articles