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

Мене звати Роман Шрамков, я займаю позицію Technology Director в компанії EPAM. Одна з моїх зон відповідальності — ростити архітекторів, які можуть вирішувати будь-які архітектурні завдання і самостійно знаходити свіжі рішення для наших замовників.

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

Виступ Романа Шрамкова на одному з Java Meet-up

Роль архітектора

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

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

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

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

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

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

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

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

Ключові завдання Solution Architect

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

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

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

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

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

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

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

Виступ Євгена Моспана з Java Competence Centre, EPAM і Alex Lomov, Cybergizer, Cloud Foundry Engineer на SEC 2018

Як стати архітектором

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 і потім — System 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 System Architect, як правило є експертом в якійсь великий технологічної або бізнес-області, здатний вести серйозні проекти і представляти компанію на рівні запису;
SA-4, або Director of Technology, відіграє провідну роль, часто відповідає за управління технологічною частиною у великих програмах;
SA-5, або CTO, очолює великі технологічні напрямки глобально, на рівні компанії або великого облікового запису.

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

Якщо у вас є питання про позиції System Architect, пишіть в коментарях, постараюся відповісти.

Опубліковано: 08/05/19 @ 07:56
Розділ Різне

SEO Блог