Как дорасти до уровня Solution Architect
Меня зовут Роман Шрамков, я занимаю позицию Technology Director в компании EPAM. Одна из моих зон ответственности — растить архитекторов, которые могут решать любые архитектурные задачи и самостоятельно находить свежие решения для наших заказчиков.
В статье я расскажу, в чем заключается роль Solution Architect, какие ключевые задачи выполняет такой специалист и как разработчику дорасти до этого уровня.
Выступление Романа Шрамкова на одном из Java Meet-up
Роль архитектора
Я бы начал с того, кем не является Solution Architect. Часто думают, что это самый квалифицированный разработчик или эксперт, который лучше всех знает технологический стек проекта. Это не совсем так. Безусловно, архитектор должен хорошо разбираться в технологиях проекта и понимать, что такое хороший код. Но у него есть и особенная функция, которую не выполняют разработчики и эксперты: он отвечает за формирование, документирование и коммуникацию общего технического решения для всей системы.
Чтобы было более понятно, что я имею в виду, рассмотрим аналогии из других индустрий. Например, в чем заключается роль архитектора в строительной сфере, чем он отличается от прораба, каменщика или штукатура? Посмотрим на это глазами клиента. Я как заказчик буду привлекать к работе архитектора в том случае, если мне надо что-то построить, а я сам не являюсь экспертом в строительстве и понимаю, что не могу сам продумать все детали на профессиональном уровне.
При этом я обращусь к архитектору на самом первом этапе проекта, когда я еще не начал что-то строить и даже закладывать фундамент. У меня есть идея — к примеру, построить спортивный стадион. И мне интересно, можно ли вообще реализовать мой проект так, как я задумал, и если можно, то каким образом.
Придя к такому профессионалу, я ожидаю, что он задаст мне правильные вопросы: «Что именно вы строите? Для каких целей?». Потому что, например, стадион для футбола и арена для соревнований по легкой атлетике будут иметь разную форму и разные функциональные зоны. Идем дальше: если это футбольный стадион, то кто там будет играть, национальная сборная или школьная команда? От этого зависит размер площадки, количество посадочных мест для болельщиков.
Когда архитектор выяснил ключевые функциональные и нефункциональные требования к проекту, он разрабатывает концепцию решения и делает эскиз будущей постройки. Затем — презентует решение заказчику, чтобы тот убедился, что это действительно то, что нужно. Это высокоуровневая (то есть общая, не детализированная) архитектура решения. На этом же этапе, как правило, обсуждают бюджет: архитектор дает примерные оценки стоимости проекта.
После того, как концепцию согласовали, архитектор берется за более детальные чертежи — например, прорисовывает схему вентиляции или электропроводки. При этом он не может знать абсолютно все стандарты и прикладные нюансы, поэтому на этом этапе привлекает к проекту профильных инженеров. Они вместе создают так называемый низкоуровневый (то есть детализированный) дизайн будущей постройки.
В IT распределение ролей аналогичное, хотя и имеет свои особенности. Solution Architect выясняет потребности заказчика, разрабатывает концепцию программного решения, а затем передает проект тимлидам разных направлений для технической реализации.
Ключевая разница заключается в том, что процесс, который я описал выше, — очень вотерфольный. В строительной сфере сначала создают полную проектную документацию и только после этого приступают к возведению объекта. В IT мы подходим к разработке софта гибко, часто сделать финальную архитектуру сходу слишком сложно. Архитектор вместе с командой двигается итеративно, сопровождая проект на этапе реализации, постоянно уточняя требования и внося необходимые элементы в архитектуру, помогает команде решать технические сложности, возникающие по мере движения.
Ключевые задачи Solution Architect
Прояснение требований к проекту и коммуникация с заказчиком. Чаще всего это происходит на этапе пресейла или дискавери. Архитекторы помогают составить коммерческое предложение заказчику — для этого много общаются с ним напрямую, часто ездят в командировки, чтобы посмотреть на работу бизнеса изнутри. Иногда, если нужно, к этому добавляется еще и консультирование заказчика по техническим вопросам или технический аудит существующих решений.
Технологическое исследование и прототипирование. Обычно на старте проекта архитектору могут быть неизвестны некоторые нюансы применения необходимых технологий, поэтому возникает необходимость глубже изучить и разобраться в возможностях и ограничениях тех или иных решений. Для этого он разрабатывает прототипы — маленькие части системы, которые нужны для того, чтобы убедиться, что те идеи, которые придумывает архитектор, действительно являются рабочими.
Архитектура конечного продукта. Сформировав техническое решение, Solution 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 и затем — 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 компании и помогать строить правильную технологическую стратегию ее развития. Во-вторых, вы сможете развиваться как консультант или пресейл специалист, который больше работает с клиентами и часто путешествует он-сайт.
Если у вас есть вопросы о позиции Solution Architect, пишите в комментариях, постараюсь ответить.
