Шлях від розробника до архітектора

Роль архітектора приваблює багатьох розробників перспективою працювати з новими технологіями, приймати високорівневі рішення, опираючись на власний досвід програмування, а також безпосередньо впливати на долю того чи іншого проєкту. Cпікер вебінару Андрій Рудавко, Solution Architect компанії EPAM, розповів про свій шлях від розробника програмного забезпечення до архітектора рішень та поділився порадами для всіх бажаючих просунутися кар’єрними сходами у сфері ІТ. 

Кожен інженер має безпосередній досвід застосування або роботи з архітектурою загалом, оскільки кожен продукт, програма або сервіс, якими ми послуговуємося, має свою відповідну архітектуру. Зазвичай шлях від розробника до архітектора проходить через посаду тімліда або техліда, на яких розробник прокачує свої лідерські та комунікативні навички, які в подальшому будуть надзвичайно корисними. Оскільки основна частина роботи архітектора полягає у спілкуванні із замовниками та розробниками, йому важливо розвивати комунікаційні та презентаційні навички. Він має вміти правильно визначати потреби стейкхолдера, а також просувати свої ідеї щодо відповідних продуктів чи сервісів. Запропонована архітектура має бути гнучкою до змін, щоб за потреби її можна було адаптувати відповідно до зауважень та побажань клієнта. Гарні презентаційні навички ІТ-спеціалісти можуть розвинути, виступаючи на внутрішніх або зовнішніх заходах, при цьому використовуючи візуальні слайди. Окрім того, спікер порадив нинішнім архітекторам частіше проводити аналіз коду та не втрачати практичний досвід програмування, оскільки часто він є однією з вимог на вищу посаду, зокрема на наступну позицію Solution Architect ІІ. Наразі існує високий попит на архітекторів, які працювали з front-end фреймворком та інтерфейсами користувача. 

Залежно від розміру проєктів, напрямку діяльності та кількості людей у команді архітектори виконують різні завдання з урахуванням проєктних вимог та наявних ресурсів. У разі відсутності делівері-менеджера та/або бізнес-аналітика на проєкті архітектору потрібно буде перейняти ці функції на себе. В його обов’язки також входить вибір того чи іншого фреймворку, зважаючи на кількість розробників у команді, окрім випадків, коли технічні вимоги щодо перформансу фреймворку у конкретному середовищі є чітко визначеними. У деяких випадках може виникнути необхідність застосувати доказ концепції (POC) для тестування ключових функцій проєкту. Окрім цього, архітектор має визначати ризики та шляхи управління ними, а також забезпечувати прозору комунікацію із клієнтом. Для вивчення найкращих практик щодо побудови архітектури та формування оптимальної взаємодії зі стейкхолдерами спікер радить почитати такі спеціалізовані книги: «Software architecture elevator» (автор Грегор Хохпе) та «Software architecture in practice» (автори Лен Басс, Пол Клеменц, Рік Казман). 

Звичайний день архітектора залежить від етапу проєкту, на якому він працює. Після отримання запиту на пропозицію від клієнта, підготовки презентації відповідної  архітектури та виграшу тендеру, архітектор залучений у проведення фази діскавері. Ще до зустрічі з клієнтом він має зрозуміти бізнес-цілі та бізнес-драйвери компанії, на основі яких він визначить засоби для швидкого та ефективного досягнення результату в рамках певного сервісу або проєкту. Під час діскавері-етапу архітектор бере участь у багатьох зустрічах, ознайомлюється з наявною документацією, усіма ключовими стейкхолдерами, а також визначає нефункціональні вимоги та обмеження. Під час побудови архітектури відповідно до вимог замовника необхідно враховувати те, хто і як буде нею користуватися та написати відповідну архітектурну документацію. Сформовані характеристики та архітектуру важливо узгодити з усіма стейкхолдерами, які тим чи іншим чином впливають на проєкт. Наступним етапом роботи є проведення робочої групи з формулювання атрибутів якості, після чого настає пріоритезація та прописування сценаріїв з доступності продукту, а також формулювання тактик, зважаючи на атрибути якості. Архітектуру можна сформувати на основі Excel таблиці чи презентації в PowerPoint. Після її узгодження із командою розробників необхідно внести зміни відповідно до їх порад і рекомендацій. За потреби зміни в архітектурі необхідно узгодити зі стейкхолдерами. Після усіх затверджень архітектор може залишитися на проєкті та здійснювати управління архітектурою, допомагати з формуванням архітектури нових компонентів та інтеграцією. 

Шлях від розробника програмного забезпечення до архітектора є непростим і вимагає значного досвіду програмування, аналізу кодів, розвитку комунікаційних та презентаційних навичок, вміння керувати ризиками, а також навичок формування відповідної документації. На початку роботи на новій посаді архітектор може залучатися підтримкою старшого архітектора проєкту, який може виступити його ментором. Успіх роботи архітектора зокрема залежить від його вміння стати зв’язуючим компонентом між стейкхолдерами і розробниками завдяки прозорій комунікації та професіоналізу. 

Щоб дізнатись більше та отримати порцію надзвичайно корисної інформації, подивіться запис вебінару на YouTube-каналі EPAM.