Как перейти в IT-архитектуру и не начинать карьеру заново
Разработчики, аналитики, инженеры и IT-консультанты могут перейти в архитектуру, опираясь на уже накопленный опыт. Лаура Саламат, автор The Tech и Enterprise Architect, объясняет, как выбрать направление, получить первый практический опыт и подготовиться к новой роли без лишних шагов.
Лаура Саламат, город — Алматы, Enterprise Architect, со-основатель сообщества IT-архитекторов Казахстана Arch Connect, со-учредитель, лидер направления Education&Science Women in Tech Kazakhstan
В последнее время ко мне все чаще обращаются люди, которые работают в IT и хотят развиваться в архитектуре, но не знают, как выстроить переход. Многие начинают с курсов, изучают фреймворки и готовятся к сертификации. Обучение помогает систематизировать знания, но архитектором обычно становятся в процессе работы, когда меняется характер задач и расширяется зона ответственности.
Но прежде чем выбирать обучение, я обычно предлагаю посмотреть на текущую работу. Какие решения уже приходится принимать, насколько они выходят за границы одной команды и за что человек действительно отвечает. Так становится понятнее, на какой опыт можно опереться и чего еще не хватает для перехода.
Что меняется при переходе в IT-архитектуру
Если говорить коротко, IT-архитектор связывает бизнес-задачу с техническим решением. Он видит зависимости между его частями, сравнивает возможные варианты и помогает выбрать тот, который можно реализовать, эксплуатировать и развивать с учетом ограничений компании. Архитектор не заменяет разработчиков, аналитиков или инженеров отдельных направлений, он отвечает за то, чтобы их работа складывалась в целостное решение и изменение одной части не создавало проблем в другой.
Переход в архитектуру меняет прежде всего масштаб задач. Вместо ответственности за отдельный компонент, функцию или технологию появляется возможность влиять на решение целиком, работу нескольких команд и развитие IT-ландшафта. В Enterprise Architecture этот масштаб может охватывать трансформацию всей компании. Вместе с масштабом меняется и характер работы. В архитектуре редко бывает единственный правильный ответ. Решения приходится принимать при неполной информации, сравнивая стоимость, сроки, риски и последствия для дальнейшей эксплуатации. Значительную часть времени занимает обсуждение вариантов с людьми, у которых разные цели и ограничения. Поэтому архитектуру стоит выбирать не только ради следующей должности или роста дохода. Эта роль подходит тем, кому интересно работать на пересечении бизнеса и технологий, расширять масштаб влияния и отвечать за последствия принятых решений. При этом архитектура не является обязательным продолжением карьеры для каждого опытного человека в IT. Если интереснее сохранять глубокую техническую специализацию и непосредственно создавать продукт, инженерная или экспертная траектория может подойти больше.
В архитектуру приходят из разных областей IT, поэтому единого маршрута нет. Некоторые уже выполняют часть архитектурной работы, хотя их должность называется иначе. Бывает и обратная ситуация, когда слово «архитектор» в названии роли есть, но человеку сложно определить свое направление и границы ответственности.
Как определить свое направление в IT-архитектуре
При обсуждении перехода я бы начинала не с названия будущей должности, а с двух вопросов — какой уровень решений вам уже знаком и в каком домене накоплена основная экспертиза. Ответ на первый вопрос помогает понять, готовы ли вы пока работать с конкретным решением или уже имеете опыт изменений, затрагивающих IT-ландшафт всей компании.
Когда архитектор отвечает за решение под конкретную бизнес-задачу, это ближе к Solution Architecture. Такая работа редко ограничивается одной IT-системой или командой. Нужно связать требования бизнеса, данные, интеграции, инфраструктуру и ИБ, рассмотреть возможные варианты и выбрать тот, который соответствует срокам, бюджету и возможностям дальнейшей поддержки. Задача Solution Architect не в том, чтобы самостоятельно проектировать каждый компонент и лучше всех разбираться во всех технологиях. Он отвечает за решение в целом, привлекает экспертизу по отдельным направлениям и оценивает, как изменения в одной части повлияют на остальные.
Enterprise Architecture выходит за границы отдельного решения и работает уже на уровне всей компании. В фокусе Enterprise Architect находятся IT-ландшафт, его текущее и целевое состояние, а также переход между ними. Он видит зависимости между инициативами и помогает определить, какие IT-системы и технологии развивать, какие ограничения устранять и от каких решений постепенно отказываться. Особенно важной эта работа становится во время трансформации, когда компания одновременно меняет бизнес-процессы, внедряет новые платформы, пересматривает подходы к данным и модернизирует инфраструктуру. Решение, которое выглядит правильным в рамках одного проекта, может создать ограничения для других направлений или увести компанию в сторону от целевой архитектуры.
Solution Architect и Enterprise Architect не являются обязательными ступенями одной карьерной лестницы. У этих ролей разные зоны ответственности и горизонт планирования. Solution Architect может развиваться в своем направлении и работать с более сложными решениями, не переходя в Enterprise Architecture. Для работы на уровне всей компании потребуется другой опыт, связанный с целевой архитектурой, программами трансформации и зависимостями между несколькими инициативами.
Второй вопрос касается домена, в котором накоплена основная экспертиза. Это могут быть данные, интеграции, инфраструктура, ИБ или бизнес-архитектура. В зависимости от опыта можно развиваться в Data Architecture, Integration Architecture, Infrastructure Architecture, Security Architecture или Business Architecture. При этом один и тот же домен может быть представлен на разных уровнях архитектуры. Например, Data Architect может отвечать за данные внутри конкретного решения, нескольких связанных инициатив или на уровне всей компании. То же относится к интеграциям, инфраструктуре и ИБ, поэтому по одному названию должности сложно понять, чем на самом деле занимается архитектор. Важно смотреть и на область его экспертизы, и на уровень принимаемых решений.
Поэтому при выборе направления не стоит ориентироваться на образ универсального архитектора, который одинаково глубоко разбирается во всех доменах и отвечает за всю архитектуру компании. На практике такая модель не работает. Один человек не может одновременно прорабатывать решения в разных областях, участвовать во всех инициативах и сопровождать их во время реализации. Чем сложнее IT-ландшафт и больше изменений идет параллельно, тем быстрее такой архитектор становится узким местом, а часть решений начинает зависеть от границ его опыта и доступности. Архитектурная ответственность обычно распределяется между несколькими ролями и доменами, поэтому для перехода не обязательно охватывать все сразу. Важно определить уровень решений, с которым вы готовы работать, и область, в которой уже есть сильная основа. Именно на пересечении этих двух параметров и находится наиболее естественное направление дальнейшего развития.
Как перейти в архитектуру из разных IT-ролей
По моему опыту, готовность к переходу зависит не столько от текущей должности, сколько от уровня задач, которые уже находятся в зоне ответственности. Текущий опыт определяет наиболее естественное направление и показывает, каких знаний и практики пока не хватает.
Для разработчика наиболее естественным направлением часто становится Solution Architecture, но одной технической глубины для такого перехода недостаточно. Готовность к этой роли появляется, когда разработчик выходит за границы отдельного компонента или одной команды, участвует в проработке бизнес-задачи, связывает несколько IT-систем и учитывает не только реализацию, но и данные, интеграции, инфраструктуру, ИБ и дальнейшую поддержку решения. При этом переход необязательно начинается с назначения на отдельную архитектурную должность. В рамках текущей роли разработчик может одновременно участвовать и в разработке, и в архитектурной проработке. Например, сравнивать варианты реализации, определять взаимодействие между IT-системами, согласовывать решения с другими командами и сопровождать их до запуска. Постепенно доля таких задач может увеличиваться, а зона ответственности выходить за границы технической работы одной команды и именно так часто и появляется первый архитектурный опыт.
Системный аналитик уже умеет работать с требованиями, связями между IT-системами и потоками данных. Если этот опыт охватывает решение целиком, естественным продолжением может стать Solution Architecture, а глубокая работа с контрактами и обменом данными Integration Architecture. Чаще всего дополнительно требуется техническая глубина, необходимая для оценки производительности, отказоустойчивости, безопасности, инфраструктурных ограничений и эксплуатации.
Business Architecture может быть близка бизнес-аналитику, который участвует в изменении процессов, возможностей бизнеса и операционной модели. Переход в Solution Architecture также возможен, но потребует гораздо более глубокого погружения в техническую сторону решений.
Для тех, кто работает с данными, инфраструктурой, эксплуатацией или ИБ, наиболее естественным продолжением обычно становится соответствующее доменное направление. Однако глубокого знания своей области недостаточно, нужно перейти от выполнения отдельных задач к формированию архитектурных решений и ответственности за их применение.
IT-консультанты, участники команд внедрения и пресейла часто близки к Solution Architecture, поскольку работают с бизнес-задачами, поставщиками и командами заказчика. Подготовка концепции дает опыт архитектурной проработки, но без участия во внедрении он остается неполным. Консалтинг, связанный с целевой архитектурой и программами трансформации, со временем может привести в Business или Enterprise Architecture.
Из тестирования, продуктового и проектного управления прямого перехода обычно нет. Такой опыт может стать частью маршрута, если работа уже включает нефункциональные требования, проектирование, изменение процессов или участие в трансформации. Проверка качества, управление продуктом или координация проекта сами по себе не заменяют опыта принятия архитектурных решений.
Что можно начать делать уже сейчас
На текущей работе стоит найти инициативу, в которой можно взять на себя архитектурную проработку решения или его значимой части. По ней нужно определить границы и связи с текущим IT-ландшафтом, собрать функциональные и нефункциональные требования, зафиксировать ограничения и подготовить несколько вариантов реализации. Для каждого варианта важно оценить технические последствия, стоимость, сроки, риски и дальнейшую эксплуатацию. Итогом должна стать не просто архитектурная схема, а обоснованное решение, в котором понятно, какие варианты рассматривались, от каких пришлось отказаться и почему. Предложенный вариант необходимо провести через архитектурное согласование с теми, чьи области он затрагивает. Цель такого рассмотрения состоит в том, чтобы найти зависимости, противоречия и риски, которые не были учтены изначально, а затем скорректировать решение.
После согласования нужно остаться в проекте и сопровождать реализацию. Именно здесь проверяются первоначальные предположения и появляются отклонения, по которым приходится принимать новые решения. После запуска стоит вернуться к исходной архитектуре и оценить, что подтвердилось на практике, какие ограничения проявились и что стоило бы изменить.
Если переход планируется внутри компании, лучше обсуждать с руководителем или действующим архитектором конкретную инициативу, которую вы готовы взять на себя. При этом важно заранее определить границы ответственности и договориться, кто будет рассматривать предложенные решения и давать обратную связь. Если получить такой опыт внутри компании невозможно, можно рассматривать позиции на внешнем рынке. Для этого понадобятся два-три обезличенных кейса, в которых понятны задача, ограничения, личный вклад, принятые решения и результат после запуска. Вакансию при этом стоит оценивать по реальному содержанию работы, а не только по слову Architect в названии.
Как относиться к сертификации
Один из первых вопросов, с которым ко мне обращаются при обсуждении перехода в архитектуру — какую сертификацию пройти. Часто от нее ожидают подтверждения готовности к новой роли, хотя сама по себе она этого не показывает. Сертификация подтверждает знание определенного подхода или терминологии, но не способность принимать архитектурные решения и отвечать за их реализацию. Поэтому сначала важно получить практический опыт, а затем выбирать программу, которая поможет его систематизировать или подтвердить знания, необходимые для конкретной роли.
Для Enterprise Architecture наиболее известны TOGAF Enterprise Architecture Foundation и Practitioner. Если в работе используется архитектурное моделирование, дополнением может стать ArchiMate Foundation или Practitioner. Для отдельных архитектурных доменов существуют свои программы, но выбирать их стоит под конкретное направление и требования работодателя. Показательно, что программа Open Certified Architect построена не вокруг учебного курса и экзамена. Кандидат подтверждает опыт на реальных архитектурных проектах и проходит экспертное рассмотрение. Этот подход хорошо отражает суть профессии. Знание терминологии можно проверить тестом, а способность работать архитектором подтверждается практикой. Поэтому сертификация может помочь систематизировать опыт или пройти формальный отбор, но не должна становиться заменой задачам, в которых формируется архитектурная ответственность.
Как понять, готовы ли вы к переходу
Попробуйте описать два завершенных рабочих кейса и по каждому ответить на пять вопросов:
- «Какую задачу нужно было решить?»
- «Какие варианты вы рассматривали и почему выбрали один из них?»
- «Какие IT-системы, команды и ограничения затрагивало решение?»
- «За что отвечали лично вы?»
- «Что произошло после реализации?».
Если вы не можете показать два таких кейса, переходить на позицию архитектора пока рано и поэтому сначала нужно получить опыт самостоятельной проработки решений. Если ваши решения пока ограничены одной системой или одной командой, можно начинать брать отдельные архитектурные задачи. Если вы несколько раз самостоятельно прорабатывали решение, затрагивающее несколько IT-систем и команд, обосновывали выбор, сопровождали реализацию и отвечали за результат, у вас есть практическая основа для перехода.
Для более формальной проверки можно использовать рекомендации SFIA, но сравнивать с ними нужно не название своей должности, а реальные задачи и уровень ответственности. Самооценка не всегда бывает объективной, поэтому полезно обсудить свой опыт с практикующим архитектором или обратиться в сообщества, где встречаются, обмениваются мнениями и разбирают именно архитектурные кейсы.