Правила жизни Solution-архитектора
Сотрудник отдела Travel Solutions компании EPAM Николай Зенькевич уверен: главное в Solution-архитектуре — это не просто найти решения, но и доказать — самому себе, в первую очередь, — что эти решения наиболее оптимальны для поставленной задачи. Чем руководствоваться и как добиться этого на практике? Николай разложил всё по полочкам.
— Как я пришел в Solution-архитектуру? Просто в один прекрасный момент поймал себя на мысли: мне хочется постоянно решать сложные задачи и при этом ещё и писать код, — вспоминает Николай Зенькевич. — На своих проектах я ежедневно сталкивался с задачками, которые мне проще было решить самому, в силу своего опыта, знаний, тяготы ко всему непростому. С тех пор так и продолжается — занимаюсь архитектурой, бизнес-анализом, моделями данных, контрактами, интеграций и так далее.
Возможно, главная причина этого кроется в психологии личности — мне сложно даётся делегирование трудных вещей кому-то другому. Особенно, если я уверен, что всё равно придётся за кем-то проверять и пересматривать. В таком случае, всегда проще и быстрее сделать самому. И я делаю. Мне приятно прийти на работу и сделать нечто такое, что без меня бы не вертелось, не работало. А Solution Architect — как раз та роль, которая сочетает в себе много пунктиков: ты не оторван от кода, тебе приходится очень глубоко погружаться в бизнес и рассказывать людям не только о том, как этот бизнес уже работает, но и делать так, чтобы этот бизнес работал лучше.
Итак, в чём заключаются основные задачи Solution-архитектора?
1. Уметь мыслить и видеть частности
Многие думают, что главное — это рассказать бизнесу, что ему действительно надо. Нет. На самом деле, это простая задача. Есть у архитекторов более сложная цель — убедить бизнес, что ему что-то не надо. Вот это гораздо сложнее, чем прийти и сказать: ребята, вам надо вот это, вы от этого получите такой-то и такой-то профит. Гораздо сложнее переубедить кого-то со стороны заказчика в том, чтобы сделать что-то по-другому, а не так, как они себе это придумали и видят. Для этого необходимо находить компромиссы. Вот есть люди, которые мыслят сверху-вниз и снизу-вверх. Я мыслю снизу-вверх, то есть докапываюсь до сути, до деталей, разбираюсь в них, потом обобщаю.
Прежде всего, на первых митингах с заказчиком я пытаюсь понять, как работает бизнес. Отлично, говорю, вот мы начали рассматривать кейс — давайте его дороем до конца! Всех жирафов посмотрим потом, а пока найдём и изучим одного конкретного. Впоследствии это поможет нам с лёгкостью понять остальных. Почему? Потому что мы не будем смотреть на них как на нечто новое и непознанное, а сравним с уже изученным. И останется найти только отличия. Если систематизировать, то сначала — вглубь проблемы, до сути, ёще немного рядышком, потом — загрузить в себя, пережить и выдать решение.
2. Быть готовым к обычному дню
3. Уметь говорить, слушать и читать
Читать в прямом смысле слова: быть готовым вычитывать документы по 100-200 страниц. Причём делать это так, чтобы всё закреплялось в твоей памяти, откладывалось на полочках в «хранилище», и ты в любой момент мог достать это и применить. Это очень важно: прочитать документ, пропустить его через себя и осознать. Я преподаю в БГУ на РфиКТ «Прикладное программирование» и «Безопасность корпоративных систем» и вижу, что студенты потеряли этот навык. Почему? Они перестали работать с бумажными документами.
Понятно, что книга в электронном виде – практично. Но есть один минус: когда ты работаешь с электронной версией, ты не воспринимаешь её как книгу. А потом в курсовой или дипломной работе студенты противоречат сами себе, и разницы в этих противоречиях — страниц 10. А всё потому, что не видят общей картины. Это погрешность современного чтения.
Отсюда и ещё одно важное качество — умение правильно работать с текстом: вычленять сущность, складывать стройную картину мира… Текст можно вообще прочитать вслух как бэкграунд — сюжет давно потерян, мысли далеко, но ты всё равно машинально произносишь слова. Мой совет простой: думай о том, что читаешь.
4. Постоянно задавать вопрос «зачем»
Зачем? Три раза задай себе этот вопрос. Очень много вещей, которые хочет реализовать бизнес, разбиваются о него. Например, мы хотим запустить новую программу лояльности. Зачем? Чтобы привлечь больше клиентов. Зачем? Чтобы увеличить продажи. Зачем. И вот когда ты докопаешься, зачем это всё-таки нужно, тогда и ищи решение. А когда нашёл его — умей правильно донести. Отсюда и следующее качество — умение говорить. Не просто говорить, а делать это так, чтобы тебя понимали и понимали однозначно. Это приходит со временем. Ты приучаешься писать документацию, которая максимально однозначна.
5. Уметь читать чужой код
Одно из самых важных качеств не умение писать код, а умение читать чужой код, анализировать чужие данные, готовые контракты. Почему? Мы реже сталкиваемся с созданием чего-то совершенно нового, с нуля. Сегодня много реверс-инжиниринга. Сделаю акцент: не нужно уметь, например, написать новую программу на Коболе, но надо суметь прочитать и работать с ней дальше. Ещё всегда нужно думать и искать альтернативу — а для этого требуется хорошая техническая экспертиза.
Зачем альтернатива? Чтобы убедиться, что найденное решение — оптимальное. Но убедиться в этом самому мало — придётся доказать это команде, бизнесу. А как проще доказать? Правильно — сравнить с чем-то. Вот я, к примеру, при поиске решений всегда строю матрицу: решение — положительные стороны — отрицательные стороны. К слову, это отлично визуализирует работу SA.
6. Проявлять гибкость мышления и находить 5-6 решений
Кстати, как правило, шестым оказывается решение do nothing. Оставь всё как есть. Между прочим, это решение, с которым бизнес часто соглашается. На нашем проекте была ситуация, когда на границе года не очень корректно обрабатывались события: произошло в конце декабря, а обрабатывается в январе. Мы аккуратно прописали варианты её решения, среди которых был do nothing. Из профитов — ничего не нужно делать. Из минусов — какие-то проблемы останутся.
Но был один большой плюс: мы не наделаем других проблем. Ибо все предложенные решения в какой-то мере решали данную задачу, но усложняли логику и создавали почву для появления дефектов в дальнейшем. В результате заказчик принял решение: все варианты технически сложные, оставляем всё как есть, потому что проблема возникает нечасто, и при необходимости её можно решить «руками».
Или вот ещё классический пример. На сайтах многих авиакомпаний ты можешь сделать новый заказ, отменить его, но не можешь его модернизировать. Почему? Потому что это происходит редко. Тот, кому это понадобилось, может позвонить по телефону и решить вопрос. Если же мы начнём делать это онлайн, будет сложно.
Но и это не самый главный аргумент. Вопрос в том, кто из пользователей сможет этим воспользоваться!? Бабушка из Оклахомы? Кнопочки «сделать всё хорошо» не будет. И в результате велика вероятность, что 80 процентов сложностей, которые мы реализуем, понадобятся лишь пятой части клиентов… Поэтому с точки зрения архитектуры, сразу важно вычленить тот минимум, который необходимо оптимизировать.
Кстати, об оптимизации.
7. Не пропустить момент, когда бизнес начинает говорить не требованиями и запросами, а готовыми решениями
Например, приходит запрос добавить страну Карибы в справочник. Как поступит просто девелопер? Все ОК, сейчас добавим. А как должен поступить архитектор? Во-первых, нет такой страны. Во-вторых, чем вызвано такое решение? При более внимательном изучении оказалось, что неудобно каждый раз добавлять эту группу стран. Наш выход: давайте разрешим группировать много стран и ссылаться на целую группу.
Что мы видим? Требование «нам надо быстро добавлять страны Карибского региона» бизнес превратил в техническое решение, причём не самое оптимальное и правильное. Граница между бизнес-требованиями и архитектурными решениями очень тонка. Важно этот момент понять и отследить. И это задача Solution-архитектора.
8. Быть готовым к частым командировкам
Без командировок понять бизнес, донести решения сложно. Командировки очень нужны, чтобы запустить проект, установить связи. Когда у тебя есть связь с человеком не только по работе, то работается легче, и ты его лучше понимаешь во время долгих телефонных переговоров.
Но длительные командировки также не очень хороши — тебе просто не дают работать, забивая всё время не всегда нужными митингами. Нужен здоровый баланс.
К слову, благодаря командировкам, у меня появилось новое хобби — американский футбол. Теперь в сезон по воскресеньям смотрю игры по ночам.
9. Помнить главное
Solution-архитектор — человек, который пишет пользовательские истории, разговаривает с бизнесом, сам рисует спецификации, модели данных в базе и пишет код. И всё это одновременно.
Хотите сообщить важную новость? Пишите в Телеграм-бот.
А также подписывайтесь на наш Телеграм-канал.
Большой гайд по профессии архитектора решений (+список полезных ссылок)
Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.
Начнем с азов: что означает слово «решение» в контексте IT?
Это продукт или комплекс продуктов, который решает конкретную техническую или бизнес-задачу. Решение нужно бизнесу, чтобы увеличить прибыль: оно либо повышает доходы, либо снижает издержки — к примеру, автоматизирует бизнес-процессы и тем самым снижает расходы на оплату труда. Решение встраивается в архитектуру предприятия и связывается с другими ее компонентами. Большинство проектов EPAM направлены на создание решений: разработка от начала и до конца или отдельных компонентов.
Выходит, на каждом проекте по разработке нужен архитектор?
Алексей Кожемякин (Director, Technology Solutions, EPAM Belarus):
«Как только инженер задумался о нуждах бизнеса — он ступил на путь Solution Architect».
Почему раньше обходились и без архитекторов?
Роль архитектора решений на проектах играла вся команда целиком, несколько ее членов или один разработчик с высокой квалификацией. Он мог быть сразу и разработчиком, и проектным менеджером, а заодно и архитектором. Со временем (и опытом) пришло понимание, что создание архитектуры слишком важная и объемная задача, чтобы заниматься ей по остаточному принципу.
В отличие от разработчика, архитектор мыслит абстракциями более высокого уровня. Он размышляет не о взаимодействии классов, а о взаимодействии компонентов решения – приложений, веб-сервисов и так далее. Хотя, если требуется, он должен без проблем «провалиться» в детали кода. Кроме этого, бизнес-сторона решения для архитектора важна так же, как и техническая. Разработчики часто фокусируются на технологиях и новых библиотеках, с которыми хочется познакомиться; архитектор же отталкивается от интересов и потребностей заказчика.
Так кто главнее: архитектор или разработчик?
Архитектура и разработка – разные и равноправные направления карьерного пути. Архитектор мыслит более абстрактно, но при этом реже прикасается к коду. К тому же не всегда продумывает все до мелких деталей. Часто команда разработки реализует архитектурную концепцию самостоятельно. А качественно реализовать дизайн решения – это так же важно, как и придумать этот дизайн.
Конкретнее: какими задачами занимается архитектор решений?
В первую очередь архитектор анализирует бизнес-цели заказчика, связанные с новым продуктом. Фокусируется на требованиях, которые повлияют на архитектуру, на программную часть решения и его компоненты. Затем проектирует решение и продумывает его дизайн. Архитектор определяет, из каких компонентов будет состоять продукт, нужно ли разрабатывать его составляющие с нуля или будет уместнее использовать готовые компоненты «из коробки».
Для некоторых частей решения SA делает proof-of-concept – небольшую экспериментально-исследовательскую задачу, чтобы понять, возможно ли реализовать тот или иной функционал.
Архитекторы участвуют в предпродажах, консультируют клиентов, проводят аудит архитектуры существующего решения – оценивают, насколько она эффективна для поставленных задач, можно ли ее оптимизировать, и если да, то как.
В EPAM, например, у архитекторов есть возможность часто менять проекты, что позволяет поработать в разных областях и сферах, напрямую общаться с людьми, непосредственно вовлеченными в основные бизнес- и технологические процессы в компании.
Владимир Казакевич (Senior Solution Architect, EPAM Belarus):
«Каждый понимает слово «бизнес» по-своему. И задача архитектора решений — вникнуть в бизнес заказчика настолько глубоко, насколько это возможно, а главное — результатом его работы должны быть решения, «заточенные» под конкретных заказчиков и их конкретные бизнес-проблемы».
А есть ли какие-то еще архитекторы?
Помимо архитекторов решений это:
Enterprise Architect – создает и поддерживают архитектуру целого предприятия, которая состоит из множества решений.
System Architect – выстраивает инфраструктурную сторону решения, фокусируясь на инфраструктурных облачных сервисах, на ПО, необходимом для поддержки решения после его развертывания.
Quality Architect – выстраивают стратегию тестирования и определяет подход к управлению качеством создаваемого продукта.
В EPAM, например, архитекторы решений пока в большинстве.
Кто может стать архитектором решений?
Роман Шрамков (Director, Technology Solutions, EPAM Ukraine):
«Для того, чтобы бизнес и менеджмент увидел возможности для применения технологий, нужен настоящий гик, который объяснит им какие в этом преимущества и как это можно сделать».
Помимо разработчиков, попробовать себя в архитектуре решений могут бизнес-аналитики, деливери-менеджеры, проектные менеджеры, ресурсные менеджеры, а также тестировщики-автоматизаторы: для них есть даже специальная поддисциплина — Solution Architecture in Test Automation.
Cтоит отметить, что ожидания от такого специалиста у компании и коллег действительно серьезные. Если ошибку в разработке отдельного компонента можно исправить, то неверное решение и плохая архитектура – могут обернуться огромными потерями для обеих сторон.
Дмитрий Гурский (Lead Solution Architect, EPAM Belarus):
«У того, кто хочет стать архитектором, прежде всего, должно быть желание что-то создавать, строить. И это не навык, который можно прокачать, это внутренняя потребность — либо она есть, либо нет».
Какие образовательные программы для будущих архитекторов есть в EPAM?
Так как Solution Architect, как отдельная должность, появилась на рынке сравнительно недавно, ее понимание в разных компаниях отличается. В EPAM создан центр компетенций по архитектуре, команда которого формирует единое представление об этой роли, основываясь на опыте работы с клиентами, их бизнес-задачах и ожиданиях, лучших практиках, внутренних процессах и системах.
Программа, которую разработали практикующие архитекторы и СTOO компании постоянно обновляется. С одной стороны она учитывает индивидуальный опыт сотрудника, а с другой позволяет выбрать образовательный модуль кастомно.
Для начала можно присоединиться к Architecture Excellence Initiative – глобальному архитектурному сообществу EPAM, чтобы быть в курсе последних новостей и тенденций в области архитектуры. Участники комьюнити еженедельно общаются с архитекторами из более чем 25 стран. Оперативный обмен кейсами, доступ к обширной библиотеке и вебинарам, собранной коллегами – это сюда.
Дальше – обучение в Solution Architecture School. Это уникальная программа, которую в компании создавали с нуля: групповые занятия с лекциями и практикой ведут действующие архитекторы компании. Здесь все как в обычной школе – домашние задания, включающие разработку дизайна, постоянное общение с преподавателями и защита контрольной выпускной работы.
Что делать, если пришел в EPAM уже архитектором?
Архитекторы решений, которые пришли в компанию, могут пройти программу Solution Architecture Basics: это своеобразный помощник архитектора, включающий базовые темы, информацию о возможностях профессионального и карьерного развития, полезные контакты и гайды по инфраструктуре. Все, что поможет быстрее адаптироваться в компании.
Архитекторам буду рады в Global Solution Architecture Team – команде экспертов, которые активно участвуют в развитии дисциплины: разрабатывают лучшие практики в компании, координируют глобальные образовательные программы для архитекторов, консультируют коллег и клиентов.
Ну, а если не хочется останавливаться на достигнутом, можно стать студентом Solution Architecture University — трёхуровневой программы, которая помогает опытным архитекторам синхронизировать знания и заговорить на едином языке. У студентов есть возможность пройти сертификации в Software Engineering Institute, IASA Global и других ассоциациях, с которыми сотрудничает EPAM.
Еще одна инициатива — Solution Architecture Mentoring — менторами в которой выступают опытные архитекторы, технические директора и CTO компании. Менти вовлечены в переговоры с клиентами, вместе с наставниками работают над реальными проектами и задачами. Программа помогает архитекторам «прокачаться» в профессии и даже вырасти до уровня CTO.
Как дорасти до уровня 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. Разберитесь с базовыми практиками в архитектуре. Архитектура — не новая дисциплина, по ней написано много книг. Обязательно познакомьтесь с ними и возьмите на заметку определенные подходы: работа с функциональными и нефункциональными требованиями, рисование понятных диаграмм, грамотное составление технической документации проекта.
Необходимые знания также можно почерпнуть из ряда фундаментальных книг об архитектуре:
Если вы нацелены на построение архитектуры сложных энтерпрайз-проектов, я советую получить сертификацию от американского SEI или европейского Iasa. Тут важна не столько сама «корочка», сколько процесс подготовки — он поможет систематизировать знания. Кстати, у SEI есть целая серия книг, которые описывают ключевые практики, — их тоже можно использовать как базу.
Хочу отметить, что рост в архитектора доступен не только для разработчиков. Например, QA у нас могут развиваться в направлении QA Architect, которые строят систему оценки качества для продукта; DevOps — могут развиваться в System Architects, которые проектируют CICD и различную автоматизацию; бизнес-аналитики могут расти в Product Managers, а проектные менеджеры, которые не против углубиться в техническую часть, — в Delivery Managers.
Каким был мой путь
Конечно же, никто из нас одним прекрасным утром вдруг не просыпается архитектором — развитие происходит постепенно. Человек нарабатывает опыт на разных проектах, учится смотреть на систему и технологии максимально широко, не зацикливаясь на одном стеке или инструменте.
В нашей компании однажды пришли к тому, что для того, чтобы получить хороший проект нужно давать заказчику не просто экспертизу разработчиков, которые умеют писать код, а консультантов, которые смогут посоветовать определенные решения исходя из потребности бизнеса. Мне было интересно вовлекаться в эти активности и принимать участие в формировании первоначальной концепции будущего решения на старте.
Постепенно я понял, что уже могу сам решать большинство вопросов при проектировании будущей системы. Кроме этого, я научился вовлекать других людей в решение технических задач по более узким направлениям, строить архитектурные команды на проектах. Так после 10 лет работы только с кодом у меня появился новый вызов, взять на себя обязанности Software Architect и затем — Solution Architect.
Сейчас я занимаю позицию Director of Technology: выступаю в роли посредника между бизнесом клиентов и техническими командами, но уже не в одном проекте, а на уровне компании. Подробнее об этом я рассказывал в рубрике «Как я работаю» на DOU.
Перспективы карьерного развития
В каждой компании могут быть разные карьерные пути. Сперва расскажу на примере EPAM. У нас есть три карьерных уровня:
Сама по себе позиция Solution Architect — это уже отличный карьерный шаг для инженера: вы попадаете в B-track, где от вас ожидается определенный уровень зрелости и где вас ждет соответствующий уровень задач.
В свою очередь, карьерный путь архитектора состоит из пяти ступенек:
Если вы работаете в менее крупной компании, то позиция Solution Architect хороша тем, что сочетает в себе высокую техническую экспертизу и определенную управленческую компетенцию. С этой позиции вы можете развиваться в разных направлениях. Во-первых, вы можете расти как успешный архитектор решений и быть востребованным на рынке и в компании на ключевых позициях в самых сложных и интересных проектах, особенно на старте. При определенной доле опыта и менеджерских амбициях, вы можете замахнуться на позицию CТO компании и помогать строить правильную технологическую стратегию ее развития. Во-вторых, вы сможете развиваться как консультант или пресейл специалист, который больше работает с клиентами и часто путешествует он-сайт.
Если у вас есть вопросы о позиции Solution Architect, пишите в комментариях, постараюсь ответить.
Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.
