Як дорости до рівня Solution Architect

Одна з моїх зон відповідальності – ростити архітекторів, які зможуть вирішувати будь-які архітектурні задачі та самостійно знаходити свіжі рішення для наших замовників. У статті я розповім, у чому полягає роль Solution Architect, які ключові задачі виконує цей спеціаліст та як розробнику дорости до цього рівня. 

Я хотів би почати з того, ким не є Solution Architect. Поширена думка, що це найкваліфікованіший розробник або експерт, який найкраще знає технологічний стек проекту. Це не зовсім так.

Безумовно, архітектор повинен добре розбиратися в технологіях проекту і розуміти, що таке хороший код. Але у нього є і особлива функція, яку не виконують розробники і експерти: він відповідає за формування, документування та комунікацію загального технічного рішення для цілої системи.

Щоб краще зрозуміти, що я маю на увазі, звернімося до аналогій з інших індустрій. Наприклад, у чому полягає роль архітектора в будівельній галузі  та що відрізняє його від виконроба, муляра або штукатура? Подивимось на це очима клієнта. Я, як замовник, буду залучати до роботи архітектора тоді, коли мені треба щось побудувати, а я особисто не є експертом у будівництві і розумію, що не зможу самостійно продумати усі деталі на професійному рівні.

При цьому я звертатимусь до архітектора на першому етапі проекту, коли я не тільки ще не почав будувати, але навіть не закладав фундамент. Припустимо, в мене є ідея побудувати спортивний стадіон. І мені цікаво, чи можна взагалі реалізувати мій проект так, як я задумав, і якщо можна, то яким чином.

Коли я звертаюсь до професіонала, я очікую, що він поставить мені правильні питання: «Що саме ви будуєте? Для яких цілей?". Тому що, наприклад, стадіон для футболу і арена для змагань з легкої атлетики матимуть різну форму і різні функціональні зони. Йдемо далі: якщо це футбольний стадіон, то хто там буде грати, національна збірна або шкільна команда? Від цього залежить розмір поля, кількість місць для вболівальників.

Після того, як архітектор з'ясував ключові функціональні і нефункціональні вимоги до проекту, він розробляє концепцію рішення і створює ескіз майбутньої споруди. Потім презентує рішення замовнику, щоб той переконався, що це дійсно те, що потрібно. Це високорівнева (тобто загальна, не деталізована) архітектура рішення. На цьому ж етапі, як правило, обговорюють бюджет: архітектор дає приблизну оцінку вартості проекту.

Після погодження концепції архітектор береться до більш детальних креслень - наприклад, промальовує схему вентиляції або електропроводки. При цьому він не може знати абсолютно всі стандарти і прикладні аспекти, тому на цьому етапі долучає до проєкту профільних інженерів. Вони разом створюють так званий низькорівневий (тобто деталізований) дизайн майбутньої споруди.

В IT розподіл ролей аналогічний, хоча і має свої особливості. Solution Architect з'ясовує потреби замовника, розробляє концепцію програмного рішення, а потім передає проєкт тімлідам різних напрямів для технічної реалізації.

Ключова різниця полягає в тому, що процес, який я описав вище, - дуже вотерфольний. У будівельній галузі спочатку створюють повну проєктну документацію і тільки після цього приступають до зведення об'єкту. В IT ми підходимо до розробки софта гнучко, часто зробити фінальну архітектуру відразу занадто складно. Архітектор разом з командою рухається ітеративно, супроводжуючи проєкт на етапі реалізації, постійно уточнюючи вимоги і вносячи необхідні елементи в архітектуру, допомагає команді вирішувати технічні труднощі, що виникають протягом процесу.

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

Технологічне дослідження і прототипування. Зазвичай на старті проєкту архітектор може не знати деяких нюансів застосування необхідних технологій, тому виникає необхідність глибше вивчити і розібратися в можливостях та обмеженнях тих чи інших рішень. Для цього він розробляє прототипи - маленькі частини системи, роль яких - переконатися, що ідеї, які придумує архітектор, дійсно працюватимуть.

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

Детальну документацію низькорівневого дизайну в сучасному IT роблять рідко. Це пов'язано з тим, що Solution Architect в гнучких проєктах щільно комунікує з командою, пояснює архітектуру, її ідеї, можливості і обмеження. Низькорівневий дизайн робиться в ході розробки і одразу потрапляє в код. У свою чергу, команда дає зворотний зв'язок про архітектуру: чи все вдається реалізувати та які складнощі виникають.

Загальний контекст (helicopter view). У більшості проєктів кожна команда працює над своєю частиною рішення, і для великих систем повинен бути хтось, хто розуміє картину архітектури в цілому, загальні принципи і домовленості.

Саме Solution Architect - та людина, яка споглядає розробку системи згори. Він має чітку картину архітектури майбутнього продукту і всіх її частин, яку він «промальовує» у вигляді різних схем, діаграм і представлень.

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

Solution Architect - логічна наступна сходинка для нинішніх senior розробників або тімлідів, які хочуть розвиватися як інженери. Як правило, на цих ролях люди вже мають глибоке знання хоча б одного технологічного стека, вони залучені до низькорівневого дизайну компонентів і розуміють, що вивід в прод і експлуатація системи вимагають набагато більшого, ніж просто написання коду, який працює.

Для підготовки таких фахівців існують курси (в EPAM є курси двох рівнів - Solution Architecture School і Solution Architecture University). Можна знайти досвідченого архітектора і радитися з ним з питань архітектури та розвитку. Також можна долучитися до ком'юніті архітекторів, щоб дізнаватися про нові технології, брати участь у в architecture katas (вправа на дизайн рішень) та інших корисних заходах.

Якщо ви розвиваєтеся самостійно, вам варто зробити наступні кроки, які допоможуть вирости в архітектора рішень:

1. Розширюйте кругозір. Цікавтеся різноманітними аспектами того, як розробляється і вводиться в експлуатацію система; тим, що відбувається після того, як код вже написаний і система працює. Як система деплоїться на прод, як вона інтегрована з іншими системами замовника; яким чином запланований перехід на нову систему; як система буде підтримувати цей перехід в проміжний період.
2. Працюйте з бізнесом і менеджментом. Беріть участь в обговореннях бізнес-цілей і проблем клієнтів, дивіться на завдання не тільки з точки зору коду і технологій, але й проєкту в цілому. Привносьте в проєктні та бізнес-обговорення технічний погляд, але робіть це з розумінням інтересів і проблем інших учасників проєкту.
3. Прокачуйте комунікативні та презентаційні навички. На відміну від тімлідів, які фокусуються на технології та розробці, архітектор – це одна з ключових фігур у спілкуванні з замовником і проєктним менеджментом. В його зоні відповідальності - перемовини та презентація технічних рішень від ідеї до кінцевої реалізації. Цей фахівець повинен вміти добре пояснювати і відстоювати власну точку зору, а також слухати і розуміти співрозмовника. Звичайно, для цього потрібне досконале володіння англійською.
4. Розберіться з базовими практиками в архітектурі. Ця дисципліна НЕ нова, і по цій темі написано багато книг. Обов'язково перегляньте їх і візьміть на замітку певні підходи: роботу з функціональними і нефункціональними вимогами, малювання зрозумілих діаграм, грамотне складання технічної документації проєкту.

Необхідні знання також можна знайти у низці фундаментальних книг з архітектури:

• «Software Architecture in Practice» by Len Bass, Paul Clements, Rick Kazman;
• «Documenting Software Architectures» by Paul Clements, Felix Bachmann, Len Bass;
• «Software Systems Architecture» by Nick Rozansk;
• «Just Enough Software Architecture» by George Fairbanks;
• «97 Things Every Software Architect Should Know» by Richard Monson-Haefel.

Якщо ви сфокусовані на побудові архітектури складних ентерпрайз-проєктів, я раджу отримати сертифікацію від американського SEI або європейського Iasa. Важлива не стільки сама «корочка», скільки процес підготовки - він допоможе систематизувати знання. До речі, у SEI є ціла серія книг, які описують ключові практики, - їх теж можна використовувати як базу.

Зазначу, що ріст в архітектора доступний не тільки розробникам. Наприклад, QA у нас можуть розвиватися в напрямку QA Architect, які вибудовують систему оцінки якості для продукту; DevOps можуть розвиватися в System Architects, які проектують CICD і різноманітну автоматизацію; бізнес-аналітики можуть рости в Product Managers, а проєктні менеджери, що не проти заглибитися в технічну частину, - в Delivery Managers.

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

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

Згодом я зрозумів, що вже можу сам вирішувати більшість питань під час проєктування майбутньої системи. Крім того, я навчився залучати інших людей до рішення технічних завдань за більш вузьким напрямами, формувати архітектурні команди на проєктах. Так після 10 років роботи виключно з кодом у мене з'явився новий виклик -  взяти на себе обов'язки Software Architect, а потім - Solution Architect.

Нині я обіймаю позицію Director of Technology: виступаю в ролі посередника між бізнесом клієнтів і технічними командами, але вже не в одному проєкті, а на рівні цілої компанії. Детальніше про це я розповідав в рубриці «Як я працюю» на DOU.

В кожній компанії можуть бути різні кар'єрні сходинки. Спершу розповім на прикладі EPAM. У нас є три кар'єрних рівня:

• A-track - це розробники, девопси, тестувальники та інші технічні фахівці;
• B-track - менеджмент, в тому числі й Solution Architect як «технічний менеджер» проєкту;
• C-track - топ-менеджери, які виконують ключові функції на рівні компанії.

Власне позиція Solution Architect - це вже чудовий кар'єрний крок для інженера: ви переходите на B-track, де від вас очікують певного рівня зрілості і на вас чекає відповідний рівень завдань.

У свою чергу, кар'єрний шлях архітектора складається з п'яти сходинок:

• SA-1 знає базові практики архітектури і має високу експертизу як мінімум в одному технологічному стеку;
• SA-2 має практичний досвід роботи архітектором, працює вже в декількох технологічних стеках, може самостійно вести середні за розміром проєкти;
• SA-3, або Senior Solution Architect, як правило є експертом у будь-якій великій технологічній або бізнес-площині, здатний вести серйозні проєкти і представляти компанію на рівні еккаунту;
• SA-4, або Director of Technology, відіграє провідну роль, часто відповідає за управління технологічною частиною у великих програмах;
• SA-5, або CTO, очолює великі технологічні напрямки глобально, на рівні компанії або великого еккаунту.

Якщо ви працюєте у невеликій компанії, то позиція Solution Architect приваблива тим, що поєднує в собі високу технічну експертизу і певну управлінську компетенцію. З цієї позиції ви можете розвиватися в різних напрямах. По-перше, ви можете рости як успішний архітектор рішень і бути затребуваним на ринку і в компанії на ключових позиціях у найскладніших і найцікавіших проєктах, особливо на старті. За наявності певного досвіду і менеджерських амбіцій, ви можете замахнутися на позицію CТO компанії і допомагати будувати правильну технологічну стратегію її розвитку. По-друге, ви зможете розвиватися як консультант або пресейл фахівець, який більше працює з клієнтами і часто подорожує он-сайт