ИТ архитектор: виды и задачи. Расскажем о сложном простым языком
Приходилось ли вам когда-либо искать IT архитектора? Не такая это простая задача, как кажется на первый взгляд. Разобралась в теме и подготовила материал Елена Меркулова, эксперт IT подбора Atsearch Crowd Recruitment.
В названии вакансии часто пишут просто «системный архитектор» или «IT архитектор», и понять очень сложно, для каких ролей нужен кандидат, и чем же все-таки он будет заниматься. Да и резюме не всегда красноречиво.
Давайте попробуем разобраться.
IT архитекторы бывают разных типов:
Разберем каждый тип на примере строительства дома. Итак, строим дом.
На примере строительства: процесс начинается с человека, который поможет выбрать нам стиль, спланирует количество этажей, расположение квартир, окон, количество подъездов.
В IT: он решает стратегические проблемы – делает анализ ключевых требований, анализ потоков данных и пишет «IT Конституцию» проекта. Разрабатывает архитектурные стандарты и требования.
На примере строительства: человек, который поможет нам на основании проекта предшественника рассчитать необходимые тепловые мощности для отопления дома, определить расположение узлов для подачи воды и канализации в квартирах, на основании расчетов разметить положение проводки.
В IT: выбирает фреймворки, формулирует альтернативные варианты IT решений в рамках бюджета, обозначает риски, решает спорные ситуации среди разработчиков. Ему также необходимо уметь анализировать тесты производительности, безопасности. Этот специалист должен четко представлять практическую реализацию идеи и уметь ее донести до команды.
Данные решения требуют высокой степени ответственности исполнителя. Если что-то будет спроектировано неверно, исправить это будет крайне сложно, придется многое кардинально менять.
На примере строительства: теперь нам нужен специалист, который наклеит обои и положит ламинат. Этот человек подскажет, какие обои выбрать по качеству, какой ламинат подойдет, исходя из выбранного архитектурного стиля.
В IT: эту роль выполняет разработчик.
Эти роли очень тесно связаны между собой и зачастую в компаниях нужен специалист: Enterprise архитектор + Solution архитектор или разработчик + Solution архитектор или Enterprise архитектор + Solution архитектор + разработчик. Чем крупнее компания, тем чаще данные роли разделяют на самостоятельные, в небольших же стартапах – это, как правило, три в одном.
В строительстве: выполняют особую, связующую роль для всех систем предприятия. Например, осуществляют проектирование стояков водоснабжения, канализации, отопления, установки электрощитов, закупку оборудования, заключают договоры с поставщиками ресурсов для удовлетворения потребностей жильцов. То есть формируют целостную систему на основе предыдущих архитектурных проектов.
В IT: занимаются серверным оборудованием (серверы приложений, серверы поддержки), корпоративными сетями уровня предприятия, СУБД, архитектурой безопасности (авторизация, аутентификация), операционными системами, системами хранения предприятия, облачными сервисами и др.
Иногда часть ролей инфраструктурного архитектора выделяется в самостоятельные единицы:
Security architect — занимается вопросами безопасности 2 типов: Первый тип — это закрытие доступов на уровне оборудования, шифрование каналов передачи данных – нижний уровень. Второй — прикладная защита на уровне приложений, которые работают поверх оборудования, например, почта или корпоративные приложения – верхний уровень.
У бизнеса есть необходимость быстро анализировать большие объемы данных (Data Lake) и доставать нужную информацию (сформировать отчетность, сделать статистику, рассчитать KPI).
Чтобы лучше понять процессы в данной области, приведем такую аналогию.
Представим, что мы переезжаем в новую квартиру и привозим с собой кучу вещей. Сортировать их у нас нет времени и сил. Мы все складываем в большую кладовку. Это и будет Data Lake (озеро данных) нашей квартиры. Эти данные — «сырые», необработанные. Часть вещей из кладовки мы можем достать и поместить в шкаф (в IT корпоративное хранилище или DWH) – то есть здесь данные уже будут в едином формате, с четкой структурой, и достать их будет легко и быстро. Сам процесс переноса в «шкаф вещей» в IT происходит с помощью ETL-средств (в переводе извлечение, трансформация, загрузка), этим процессом занимаются data – аналитики. Чтобы все вещи перераспределить по шкафам, нужно много времени и денег, а может часть вещей нам и не потребуется, поэтому иногда хранить в кладовке общей кучей дешевле.
За что отвечает Data архитекторы:
Как организовать регулярный сбор данных из многочисленных систем-источников, как их систематизировать в озере данных, какие данные поместить в корпоративное хранилище и определить модель их размещения, понять для чего нам нужны данные и как достать требуемые данные.
В реальной же жизни границы между видами архитекторов нечеткие. Иногда, когда начинаешь проект (например, строительства дома), не знаешь, что нужно несколько архитекторов. И только в процессе поиска нужного человека, а может быть и в процессе реализации проекта, — приходишь к тому, какие именно специалисты нужны.
Как дорасти до уровня 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, пишите в комментариях, постараюсь ответить.
Архитектура и архитекторы
Относительно давно посетил семинар посвященный управлению архитектурой и ее контролю и все хотел описать полученные знания, так как информации было много, и большая ее часть была весьма полезна. Могу сказать, что представления мои об архитектуре сильно расширились, и тема оказалась более глубокой и широкой, нежели я себе ее представлял. Но это и хорошо, есть отправные точки, которые можно будет самостоятельно проработать в будущем. Итак, заканчивая с лирикой, хочу предоставить краткий конспект по архитектуре.
Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии. Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.
Отличия Enterprise Architect от Solution Architect
EA разрабатывает глобальный план работы приложения, взаимодействия его с другими приложениями. SA работает над конкретным ПО. При этом EA постоянно следит за тем, как именно развивается приложение и может вносить коррективы в концептуальные части приложение.
Например, в какой-то момент появляется потребность в новом приложении Х, которое использует данные, которые генерирует приложение А. В таком случае ЕА принимает решение о выделении части приложения А в отдельный сервис, который будет поставщиком данных для приложения Х. Таким образом может быть заметно сокращена работа по реализации нового приложения.
Из представленного примера легко прийти к заключению о том, что EA должен очень хорошо прорабатывать, анализировать и следить за тем, как работают все приложения вместе, иметь всю информацию в наглядном и структурированном виде, для того, чтобы можно было принимать описанные решения. Повторное использование сервисов и данных, помнить или знать специфику данных и сервисов, все это входит в ответственность EА.
На мой взгляд, SA должен быть практикующим программистом, так как требуется знать достаточно хорошо продукты и фреймворки с которыми предстоит работать, знать ограничения и сильные стороны технологий которые будут использованы. В свою очередь EA точно так же не оторван от мира технологий, так как надо знать концептуальные различия в общих технологиях, быть в курсе тенденций их развития. Так как принятые решения в глобальном плане развития ПО могут похоронить все последующие проекты, либо сделать их разработку долгой и трудной, если выбор будет не соответствовать технологической структуре бизнеса.
Уровни ответственности и влияния
На данной, схеме показаны зависимости и отношения между разными уровнями архитектурного планирования. Влияние их друг на друга. Комментировать не стоит, я думаю.
Про каждый элемент из списка можно погуглить отдельно, но в целом понятно, что они означают. Остается наверно выбрать наиболее удобный формат представления.
Работа архитекторов
Некоторые люди высказывались о том, как построен процесс принятия решений в их компаниях. Например, при утверждении плана на год обязательно участие архитекторов, которые стараются сделать анализ возможности реализации в необходимые сроки. Определяют какие проекты потребуют наибольшего вложения сил, какие могут стать потребителями только и не потребуют много ресурсов.
Определенных средств для разработки и контроля никто не называл. Так или иначе, используется компиляция средств из Visio, SharePoint, Wiki.
Для меня остаются открытыми вопросы того как оценивать тенденцию в росте данных, механизмы управления данными. Лучшие практики по миграции архитектур, как идет работа систем при модернизации. Много, много вопросов возникает практического характера, которые я постараюсь выяснить у практикующих людей, с которыми познакомился на семинаре. Если будет результат, то напишу дополнительно.
Из дополнительного материала можно порекомендовать TOGAF9 и блог Nick Malik.
Как дорасти до уровня 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, щоб не пропустити найважливіші статті.