Архітектор в ІТ відповідає за дизайн системи або її частини. У зоні відповідальності Solution Architect — розробка, яка зосереджена на задоволенні бізнес-вимог, її якість і продуктово-технічне бачення продукту. Про роль архітектора рішень у компанії та місце в команді, навички та компетенції розповідає Сергій Касянчук, Solution Architect у Solidgate, партнерській компанії Genesis. Він перейшов на цю позицію, попрацювавши техлідом протягом трьох років та архітектором протягом року в іншому продукті. Сергій розповів, як створюється архітектура системи та чому цей спеціаліст має безперервно навчатися та тренувати надивленість.
Роль Solution Architect в команді
Популярна метафора Грегора Хопа порівнює роботу на цій позиції з ліфтом. Уявіть, що ІТ-компанія — це будівля, у якій кожен поверх — окрема команда, а керівництво розміщується в пентхаусі.
«Архітектор — це ліфт, який тримається окремо від усіх команд, але переміщується від одного поверху до іншого. Він отримує продуктові вимоги стейкхолдерів до системи, переводить їх у технічні та транслює відділу розробки. І навпаки — переводить технічні проблеми в потенційний вплив на бізнес і на продукт», — Сергій Касянчук.
У багатьох компаніях Solution Architect — це роль, яка передбачає технічне лідерство всієї команди розробки. Ще не CTO, але і вже не інженер, який лише пише код.
Найближча до архітектора рішень позиція — техлід, але в нього рівень відповідальності значно менший. Як правило, він керує командою до 10 людей, залежно від компанії. Натомість в архітектора часто в розпорядженні кілька команд, у кожної з яких є свій техлід або тимлід, які йому підпорядковуються. Сам архітектор звітує C-level менеджерам, найчастіше — CTO.
Ключові компетенції Solution Architect:
забезпечення технічної якості продукту;
задоволення бізнес-вимог і зобов’язань перед користувачами;
відповідальність за загальний дизайн системи та її стан;
моніторинг системи;
вибір або зміна стеку технологій залежно від того, які проблеми вони вирішують;
аналіз проблем, з якими стикається бізнес, і ретрансляція їх на команду розробки.
Крім Solution Architect в ІТ існує чимало інших видів архітекторів: Application Architect, Enterprise Architect, System Architect, Infrastructure Architect, Quality Architect, Data Architect тощо. Останнім часом набирає популярності Cloud Architect.
Як у компанії зʼявляється архітектор? Найчастіше просто настає етап, коли вирішують, що їм потрібен цей спеціаліст. Зазвичай це відбувається, коли продукт перейшов рубіж у 3–4 роки та продовжує зростати. У цей час у нього зʼявляється потреба змінюватися, нові вимоги, і потрібна людина, яка все це контролюватиме.
Але насправді в кожному проєкті є людина, яка де-факто виконує роль архітектора. Навіть у маленькій компанії з командою в 15 людей хтось збиратиме всю продуктову інформацію, матиме бачення, як побудувати продукт та відповідатиме за розробку загалом. Тому можна стверджувати, що архітектура потрібна всім продуктам, а от архітектор — не всім.
Як стати архітектором рішень
Найкоротший шлях до цієї професії — для Senior Software Engineer, який має лідерські якості або бажання щось змінювати. Також часто архітекторами стають DevOps інженери розробники, адже ця роль також вимагає рішень комплексних та інфраструктурних задач.
Особливість нашого ринку — архітектори акумулюють у собі різні обовʼязки. Це можуть бути архітектори, які багато часу витрачають на код. І навпаки — такі, що займаються переважно документацією, аналізом, дизайном системи, але код уже не пишуть.
Чи працює архітектор із кодом, залежить від стадії розвитку продукту й розміру команди. Якщо в невеликій команді техлід виконує роль архітектора, він може бути повністю зануреним у продукт і роботу з кодом. Але коли команда велика, архітектор відповідає за стратегію і тактику. У такому випадку свій внесок у код він здійснює через код-ревʼю.
«Мій перехід від техліда до архітектора відбувався в межах однієї компанії і одного продукту. Тому він був досить простим. Не потрібно було охоплювати колосальну кількість нової інформації», — згадує Сергій Касянчук. З іншого боку, за його словами, архітектура — це окрема дисципліна зі своїми стандартами та методиками, а також фреймворками (наприклад, SEI, TOGAF тощо). Тому, маючи досвід та навички, ще доводиться освоювати нові вміння саме з дизайну систем. Архітектор має постійно вчитися, охоплювати чималу кількість різних кейсів, ситуацій та рішень.
Хард- і софт-скіли
На певному етапі розвитку спеціаліста хардові скіли стають менш важливими. Чим вище за ієрархічною структурою зростає спеціаліст, тим більше важать софт-скіли. Архітектор — не виняток. Якщо в техліда співвідношення навичок складає 60/40, де переважають хард-скіли, то в архітектора — навпаки. Нижче перераховані деякі з них.
Хард-скіли:
розуміння принципів побудови архітектури та її патернів;
знання етапів розвитку систем;
досвід розробки з використанням різних інструментів та підходів;
знання сучасних найкращих практик розробки.
Софт-скіли:
здатність доносити думки;
вміння презентувати ідеї;
здатність слухати, аналізувати, ретранслювати;
готовність до безперервного навчання.
Чотири міфи про Solution Architect
Стану архітектором і не буду керувати людьми. Може здаватися, що це суто технічна спеціальність, але зазвичай це не так. Архітектор комунікує з усіма командами, найбільше — з технічною та продуктовою.
Стану архітектором і не буду думати про процеси, буду займатися винятково технологіями. Це неправда, часто процеси й будуються із залученням архітектора. Ба більше, є архітектори, які займаються лише побудовою процесів.
Більшість розробників мріють стати архітекторами. Насправді далеко не всі. Бути просто сеньйорним фахівцем — досить комфортно й не вимагає такої кількості ментального ресурсу та відповідальності. Цей шлях саме тому не такий уже й популярний.
Архітектор потрібен на першому етапі запуску продукту. Якщо на першому етапі наймати архітектора, формувати команду, описати всі вимоги, порахувати потенційні витрати, то розробка займатиме не дні або тижні, а місяці. Натомість завдання команди — швидко випустити MVP, щоби протестувати ідею.
Як створюються архітектури
Architecture development lifecycle — це процес створення архітектури систем. Зазвичай він складається із семи етапів:
Визначення стейкхолдерів бізнесу — тих, хто впливає на продукт.
Збір продуктових вимог — функціональних та нефункціональних. У такий спосіб вибудовуються рамки.
Пріоритезація вимог та формування архітектурного плану, з урахуванням даних із попередніх етапів, ризиків та обмежень.
Створення дизайну системи, звʼязків між компонентами, вибір стека технологій та плану розробки. Спираючись на бізнес-вимоги, Solution Architect аналізує, які компоненти системи в нього є, переміщує, компонує їх, створює звʼязки, додає нові та виводить з експлуатації ті, що існують.
Формування команди.
Розробка.
Оцінка, чи задовольняє система вимоги з етапу №2.
Часом у компаніях застосовують нетиповий цикл розробки, спрощуючи деякі етапи. Наприклад, етапу формування команд у продуктових компаніях найчастіше немає, натомість просто створюється роадмап.
Що таке хороша архітектура
Продуктові компанії працюють у нестабільному середовищі. Вимоги можуть змінюватися вже в процесі розробки, а в готові рішення з високою ймовірністю вноситимуться зміни. Архітектор має враховувати це, вміти вчасно пригальмувати та змінити курс, щоб рухатися до скоригованої цілі.
Поняття хорошої архітектури — доволі субʼєктивне. Її завдання — задовольнити певні вимоги. Архітектуру тоді можна вважати хорошою, коли вона дозволяє легко реалізовувати новий функціонал без кардинальної зміни системи. Обовʼязковими складовими є наявність постулатів, осмислених звʼязків між компонентами та найголовніше — документації, яка дозволить іншому архітектору зрозуміти причину ухвалення тих чи інших рішень, щоби цю систему можна було підтримувати.
«Я прийшов у проєкт із готовою архітектурою. Уже чотири місяці я вивчаю її та щодня дізнаюся щось нове. Кожне рішення має причину, підґрунтя та історію, і за короткий проміжок часу неможливо все охопити. Процес знайомства із системою — досить довгий, але водночас дуже цікавий», — Сергій Касянчук.
Як архітектор знаходить рішення
Складність роботи Solution Architect в продуктовому ІТ полягає в тому, що більшість задач — нетипові. Навіть два продукти в одній предметній області розвиватимуться по-різному та матимуть різні челенджі. Отже, не можна просто взяти за основу шаблон і допрацювати його.
«Як би ми не старалися одразу створити гнучку масштабовану архітектуру, нічого не вийде. Головні виклики — постійна готовність шукати нові рішення, аналізувати величезну кількість інформації та визнати, що знати все неможливо. Рано чи пізно всі стикаються з проблемою, яку раніше не вирішували», — каже Сергій Касянчук.
Перше, що має зробити архітектор, чітко визначити, у чому полягає проблема. Пошук рішень починається з ґуґла. Це складна подорож у дивовижний світ чужого досвіду й намагань зрозуміти, чи релевантний це досвід. Адже ніхто не описує, як влаштована його система, кількість мікросервісів, користувачів, трафік. Натомість статті починаються з формулювання проблеми. Такі ресурси як stackoverflow, ютуб, презентації, воркшопи, конференції дають величезну кількість варіацій рішень. Жодне з них не підійде на 100 %, але може дати по пазлику від загальної картини. Його можна адаптувати, поєднати з іншими рішеннями й застосувати до своєї системи.
«У нас ніколи немає 100 % впевненості, що це рішення підійде, але є життєздатна гіпотеза, яку ми можемо реалізувати з мінімальними витратами часу й побачити результат, отримати фідбек від системи. І це в роботі архітектора — найважливіше», — Сергій Касянчук.
Архітектор може зростати за грейдом. У цій сфері майже не зустрічається рівень джуніор, натомість є Solution Architect та Senior Solution Architect. У такому випадку спеціаліст розвиватиметься в замкнутому середовищі, зростатиме та вчитиметься будувати більш гнучкі та стабільні системи. Можна працювати у великих командах, де є Lead Architect і розвиватися там. Часом архітектори займаються консультаційною діяльністю — як технічний радник, який може допомогти в певних ситуаціях.
Якщо є бажання керувати технічними командами, можна зростати до CTO, Vice President of Engineering.
Книги та корисні ресурси:
Microservices Patterns: With examples in Java, by Chris Richardson (автор книги — автор ресурсу microservices.io);
Clean Architecture: A Craftsman's Guide to Software Structure and Design, by Robert C. Martin;
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, Martin Kleppmann;
Fundamentals of Software Architecture: An Engineering Approach, by Mark Richards, Neal Ford;
Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, by Mark Richards, Neal Ford, Pramod Sadalage, Zhamak Dehghani;