— Упевнений, що обрано відповідну архітектуру IT-проєкту?
— Так, з огляду на бізнес-цілі клієнта та озвучені ним бажані строки й бюджет проєкту.
— Подумаймо ще. Потрібна максимальна оптимізація часу і ресурсів для розробки, а також скорочення ризиків до мінімуму.
Це приклад діалогу між Solution Architect і PM-ом, який має технічне розуміння проєкту. Далі обговорюють ключові аспекти архітектури майбутнього застосунку, порівнюють різні варіанти для пошуку найкращого рішення. Детальніше про те, чому це важливо і яка роль проєктного менеджера в цьому процесі, розповімо в статті. Почнемо з бази — що таке software architecture і чому вона важлива.
Роль архітектури в IT
Уявіть, що перед вами стоїть завдання побудувати будинок. Ви можете його зробити в будь-якому стилі та з різних матеріалів, але в основі лежатиме певне архітектурне рішення. Саме воно диктує, які технології застосовувати, як і в якій послідовності виконувати ті чи інші роботи. У розробці IT-рішень відбувається все те ж саме з поправкою на особливості сфери. При цьому зв’язок архітектури та реалізації проєкту простежується на всіх етапах: від оцінки до релізу і подальшої техпідтримки.
Software architecture допомагає:
- визначити базову структуру застосунку, основні та другорядні елементи;
- вибудувати логіку взаємодії між різними компонентами архітектури проєкту;
- врахувати ризики, знайти способи запобігання технічним проблемам у процесі розробки та під час роботи готового ПЗ;
- продумати безпеку і потенційну масштабованість проєкту;
- створити єдину систему для комфортної роботи команди;
- оцінити терміни, вартість і етапи розробки.
Список можна довго продовжувати, але головне — software architecture диктує, як ви «пишете» застосунок, як він працює і який існує потенціал для розширення функціональності в майбутньому. Від цього багато в чому залежить процес девелопменту та управління IT-проєктом загалом, і вплив архітектури на роль менеджера зокрема.
Види software architecture
Будь-який застосунок за своєю суттю — це різні компоненти проєктної архітектури, що об’єднані в одне ціле. Інше питання, яким чином воєдино з’єднані всі системи, модулі та інтерфейси, і як побудована їхня взаємодія. Це багато в чому залежить від виду архітектурного IT-рішення:
- моноліт — в основі функціональні блоки, які перебувають в одній кодовій базі та залежать один від одного;
- мікросервіси — базується на окремих модулях, які взаємодіють між собою за певним алгоритмом і утворюють загальну систему;
- серверлес — альтернативний варіант мікросервісів, який орієнтований на максимальне використання хмарних технологій та завдяки яким автоматизує все розгортання.
Детальніше про кожне з рішень ви зможете дізнатися на курсі для проєктних менеджерів «Архітек» — ArchiTech. На ньому експерти IAMPM діляться власним досвідом і знаннями, які допоможуть вам зрозуміти всю важливість архітектури в проєктах і опрацювати технічні скіли для PM. Ми ж розглянемо основні плюси та мінуси кожного виду software architecture.
Моноліт
| Плюси | Мінуси |
Простота розгортання. Оскільки для моноліту здебільшого існує тільки одна точка входу, розгортання відбувається дуже швидко і відносно просто.
Розробка. Зазвичай виконується швидко — всі компоненти та модулі містяться в єдиній кодовій базі та завжди знаходяться під рукою, що економить час.
Налагодження. Значно спрощується, оскільки всі елементи знаходяться поруч, можна відстежити всі зв’язки з виконанням коду. | Масштабування. Можна розширювати тільки все разом водночас — якщо навантаження зростає на один модуль, масштабувати необхідно весь моноліт.
Надійність і вразливості IT-проєкту. Якщо виходить з ладу, то відразу всі модулі.
Зміна й апгрейд технологій. Дуже складно!
Гнучкість. Моноліт негнучкий — зміна одного модуля практично завжди впливає на інші. |
Мікросервіси
| Плюси | Мінуси |
Гнучкість. Кожен сервіс — окрема система і будь-які зміни в ній не зачіпають інші частини архітектури, якщо в цьому немає потреби.
Масштабування. Можна масштабувати кожен модуль окремо.
Гнучкість технологій. Будь-яка підсистема може бути реалізована власним способом, відмінним від інших.
Надійність і безпека IT-проєкту. Звичайна поламка якоїсь підсистеми рідко виводить з ладу всю систему. | Процес розроблення. Зазвичай вимагає більше часу і ресурсів, ніж під час роботи з монолітною структурою, оскільки потрібно реалізовувати та налагоджувати взаємодію кількох підсистем.
Налагодження. Відбувається складніше, ніж у моноліті — необхідно визначити зламаний сервіс і причини його виходу з ладу.
Розгортання. Кожне додавання нового сервісу вимагає налаштування головних частин IT-проєкту. |
Серверлес
| Плюси | Мінуси |
Гнучкість. Висока завдяки відокремленості модулів один від одного.
Абстракція від операційної системи. Cloud автоматично вирішує, яка операційна система і налаштування необхідні.
Легкий поріг входу. Зазвичай у серверлесів відокремлений простий код, з яким профільний фахівець легко і швидко зможе розібратися.
Надійність. +/- як у мікросервісній структурі за умови правильної побудови проєкту. | Гнучкість. Одночасно плюс і мінус. Недолік у тому, що масштабування залежить від можливостей і налаштувань хмарного сервісу.
Налагодження. Ускладнене через взаємодію між відокремленими компонентами.
Залежність від сервісу. Кожен Cloud має власний алгоритм роботи, тому безболісний перехід з однієї «хмари» на іншу на практиці складно здійснити.
Каскадна відмова. У разі неправильної структури та налаштування окремих модулів можливий їхній взаємний вплив один на одного, що несе потенційні ризики виходу з ладу всієї системи. |
Перераховане добре показує вплив software architecture на розробку IT-продуктів. Також важливо розуміти, що для mobile, web і desktop кожен вид архітектури матиме свою специфіку. Тому важливо з самого спочатку враховувати всі моменти: функціональність і безпеку проєкту, можливості масштабування та інші аспекти. У цьому питанні роль PM-а виходить на перший план.
Роль проєктного менеджера в архітектурі IT-продукту
На ідеальному проєкті у менеджера в команді присутній Solution Architect, який продумує архітектуру застосунку. Для цього йому потрібна, як мінімум, ідея і хоча б базове технічне завдання — ТЗ зазвичай дає Business Analyst або Project Manager. Далі йде процес продумування архітектурного рішення з урахуванням:
- даних щодо бізнес-цілей та потреб клієнта;
- поточних ресурсів: рівня фахівців, бажаних дедлайнів, бюджету, що виділяється;
- ризик-менеджменту тощо.
При цьому менеджер може і зовсім не брати участі в процесі — тільки здійснювати контроль результату з подальшою оцінкою і веденням проєкту за створеною software architecture. На практиці ж часто трапляється ситуація, коли на проєкті відсутній SA і навіть BA — у цьому разі Project Manager стає майстром-універсалом.
Якщо до цього одне із завдань PM-а полягало в організації роботи бізнес-аналітика зі збору даних і складання техзавдання для архітектора, то тепер це лягає на плечі самого менеджера. При цьому розробкою software architecture займається Project Manager самостійно, якщо техскіли дозволяють, або з кимось із девелоперів — той випадок, коли управління проєктом із технічними знаннями про архітектуру дається легше, ніж без них. Утім, при спілкуванні з Solution Architect подібні навички теж будуть у плюс для менеджера.
Переваги глибокого розуміння технічного боку проєкту
Правильно налаштована комунікація та вибудувані процеси — один із найважливіших аспектів успішної роботи команди. Розуміння, що таке software architecture, знання термінів і процесу розробки, необхідні технічні навички допомагають проєктним менеджерам:
- простіше знаходити «спільну мову» з розробниками — скорочує час на прийняття рішень і усунення можливих проблем;
- правильно оцінювати час і бюджет проєкту, зокрема й на розробку software architecture і refactoring — завжди можливі доповнення до поточних бізнес-цілей, зміни застосунку та інше;
- якісніше планувати завантаження команди, описувати завдання і контролювати їх виконання — спрощує управління ризиками та проєктом загалом, знижує відсоток технічного боргу і виникнення проблем у довгостроковій перспективі;
- швидко і доступно подавати клієнту інформацію від фахівців, відстоювати власну пропозицію щодо термінів і ціни — керівництво і замовники таке точно оцінять;
- коректно вести документацію і чітко розписувати функціональність для спрощення подальшого обслуговування застосунку, внесення змін — такий підхід значно оптимізує загальну роботу над проєктом.
Крім перерахованого, знання software architecture дають змогу менеджеру знаходити та пропонувати команді разом із клієнтом найкращі варіанти. При цьому враховувати різні фактори та ризики: від безпеки до потенційного зростання проєкту. Безумовно, багато що приходить із досвідом, але отримати актуальні знання і прокачати свої технічні навички ви можете на курсі з архітектури IT-проєкту ArchiTech. Радимо на нього звернути увагу незалежно від вашого рівня — на ринку високо цінуються PM-и, які добре розбираються в software architecture.
Приклади впливу вибору архітектури на долю проєктів
На старті розробки одна компанія невірно зробила вибір архітектури для масштабування програми — не врахували можливість швидкої зміни функціональності під різні запити користувачів. У підсумку довелося фактично з нуля робити нову версію продукту з усіма наслідками. Досвідчений PM обов’язково сказав би клієнту і команді звернути увагу на масштабованість.
Інший приклад стосується ідентифікації потенційних вразливостей і правильного вибору архітектурних рішень для безпеки. Клієнт замовив бізнес-додаток, який збирав розширені дані користувачів. Оскільки це потенційний фактор ризику, РМ запропонував замовнику посилити захист і виділити для цього додатковий бюджет. Через «плавання» в технічних моментах і слабку комунікацію, Project Manager не зміг домогтися згоди клієнта. Як підсумок, після релізу застосунок швидко взламали та вкрали призначені для користувача дані. З одного боку, провини менеджера немає, але якби в нього були високі hard і soft skills, перемовини із замовником могли мати інший результат.
Бонус: як обговорювати та перевіряти архітектуру
Для конструктивного обговорення software architecture з архітектором або розробниками радимо звертатися до довідника WAF — Well-Architected Framework від Amazon. Тут ви знайдете актуальні рекомендації з оцінки IT-продуктів. Якщо коротко, WAF пропонує оцінювати проєкт за п’ятьма категоріями нефункціональних вимог:
- Operational Excellence.
- Security.
- Reliability.
- Performance Efficiency.
- Cost Optimization.
Якщо все перераховане виконано, то з імовірністю в 99.9% архітектура на проєкті розроблена правильно.