Архитектор ПО — это специалист, ответственный за проектирование структуры и организацию системы или продукта. Роль архитектора в IT-компании включает в себя не только технические задачи, но часто и коммуникационные и организационные обязанности. Также архитектор является промежуточным звеном между бизнес-процессами и технологическими решениями.
Пока что индустрия не может чётко определить эту деятельность как профессию. В классификаторе профессий архитектор встречается скорее ландшафтный, чем программного обеспечения. В вузах вы не сможете найти специальность «Архитектура программного обеспечения».
Границы профессии достаточно размытые, и часто это не профессия и должность, а скорее роль. Задачи разнятся: архитектор должен уметь писать код и документировать его для коллег, в то же время он может коммуницировать с бизнесом и заказчиками, выстраивать стратегию развития компании на годы вперёд.
В этой статье я хочу поделиться своим видением роли архитектора ПО и рассказать:
- Кто такой архитектор ПО и какие они бывают;
- Чем занимается архитектор решений в компаниях разного масштаба;
- Чем отличаются инженеры от архитекторов ПО;
- Какие обычно задачи стоят перед архитектором ПО;
- Конкретно: какие нужны навыки и компетенции;
- Как перейти из инженера на позицию архитектора.
Виды архитекторов ПО
На виды архитекторов можно посмотреть в двух разрезах:
1. Технологический фокус.
2. Стратегический фокус.
Давайте рассмотрим график для наглядности.
Technical Architect, технический архитектор
Начнём с правого нижнего угла — здесь наиболее глубокий технический фокус. Значит, этот архитектор является экспертом в одной или нескольких технологиях. Он действует скорее тактически, чем стратегически, работает над текущими задачами и не смотрит далеко в будущее.
Это может быть техлид или архитектор нескольких выделенных команд. Например, роль архитектора может занимать человек, который долго работал с системой платежей и всё про неё знает. Он разрабатывает архитектурные решения исключительно для небольшого спектра команд — для одной-двух.
Solution Architect, архитектор решений
Если двигаться дальше и добавлять больше стратегического фокуса, получится архитектор решений. Данная роль сочетает в себе технологическую и бизнесовую составляющую и оперирует в широком временном диапазоне. Это значит, что архитектор решений может действовать и тактически, и стратегически: работать над текущими задачами и смотреть в будущее.
При таком сочетании навыков и гибкости фокус смещается, постепенно практические инженерные навыки начинают теряться. Чаще всего архитектор решений работает с большим количеством продуктов и команд.
Enterprise Architect, корпоративный архитектор
Корпоративный архитектор действует на стратегическом уровне, обеспечивая компанию долгосрочным планом. Он помогает компании уверенно оставаться на рынке и развиваться. Типовой горизонт планирования составляет 3—5 лет. Фокус направлен на существующие тренды, фундаментальные основы построения организации и технологического ландшафта, а также на управление архитектурой в целом.
В этой статье мы фокусируемся на архитекторе решений, и наши дальнейшие сравнения и примеры будут даны с учётом этой специализации.
Роли архитекторов ПО в компаниях разного масштаба
Роли архитектора в разных компаниях отличаются — они зависят от условий бизнеса и набора задач. Давайте рассмотрим три типа компаний, отличающихся по масштабу.
Стартап
Стартапом обычно занимается небольшая команда, которая располагает ограниченным бюджетом. Такие компании целятся на проведение небольших экспериментов и обычно мало беспокоятся о том, что в будущем продукт может измениться или резко получить большое количество пользователей. Из-за этого в стартапах редко встретишь архитектора ПО как выделенную роль — чаще вся команда выполняет эту функцию. Это может быть старший разработчик, основатель компании или сотрудник, который раньше всех начал работать с проектом.
Компания на стадии роста
Компании начинают выстраивать процессы, стабилизировать технологический ландшафт, но всё ещё сохраняют гибкость в принятии решений. Организация становится больше и сложнее на этом этапе, поэтому в ней появляется отдельный архитектор ПО или даже отдел архитекторов.
Например, я как-то пришёл на позицию лида команды в момент перехода процессов разработки в in-house. В то время у некоторых команд не было архитекторов решений, и эти функции ложились на тимлида. При этом в распоряжении продуктовых команд были корпоративные архитекторы, и с ними приходилось тесно взаимодействовать.
Среди задач были следующие: коммуникация с отделом корпоративных архитекторов, защита и пересмотр архитектурного плана, планирование ресурсов на реализацию проекта, выбор технологий, согласование бюджета, декомпозиция проекта в дорожную карту, разработка и поддержание архитектурного решения уровня С2 и С3.
Корпорация
В крупных компаниях часто существует отдельный архитектурный департамент. В них появляются архитекторы различных специализаций (system, application, data, network, security и т.д.) и вырабатываются архитектурные практики исходя из потребностей организации. Например, архитектор может работать со стандартами, запускать новые направления, работать с сотрудниками и их профессиональными профилями, планировать наперёд необходимые компетенции сотрудников для развития продуктов.
Отличия между инженерами и архитекторами ПО
Хорошего архитектора от хорошего инженера будет отличать mindset — образ мышления, мировоззрение, набор жизненных установок. Чтобы рассмотреть отличия в mindset’е между инженерами и архитекторами, давайте применим ситуационное мышление и разберём на примерах, как себя будут проявлять эти специалисты.
Реализация vs Дизайн
Инженер обычно работает в одной команде, а архитектор работает на несколько команд. Инженер мыслит в терминах реализации, удобства кода, иногда даже его красоты. Архитектор же фокусируется на выявлении исходной проблемы и формировании решения, чтобы её закрыть. Он рассматривает код как результат работы инженера и инструмент в достижении цели.
Другими словами, инженер что-то делает руками, а архитектор находит решения, которые нужно внедрить.
Код vs Документация
Артефактом инженера чаще всего является код, а артефактом архитектора — документация. Например, если он приходит в какой-то legacy-проект, его задача — понять, что в проекте происходит, и создать документацию на естественном языке. Это значит, что он не использует технический язык — исходный код, а описывает словами, что представляют из себя сервисы, или рисует диаграммы.
Тактик vs Стратег
Инженер работает на локальном уровне и просто выполняет поставленные задачи. Архитектор работает на более высоком уровне и смотрит шире. Его цель — видеть дальние перспективы, другие продукты, разные стеки технологий. Он мыслит на более высоком уровне и, как следствие, создаёт более качественные решения.
Многообразие решений
Инженер реализует конкретное решение: оно будет оптимальным в его ситуации для текущего стека технологий и развития продукта. Хороший архитектор не будет предлагать одного решения, потому что у всех решений есть плюсы и минусы и в каких-то случаях надо идти на компромисс.
Например, архитектор может предложить решение, которое высококвалифицированный сотрудник сделает за короткий срок. Вдруг окажется так, что сейчас в компании таких сотрудников нет или они заняты другими задачами. Значит, обязательно должны быть альтернативные решения. Архитектор всегда предлагает многообразие решений с учётом особенностей и ресурсов компании.
Масштаб
Инженер работает на своём продукте и взаимодействует со смежными специальностями в рамках команды. Архитектор же видит, что происходит в других командах, и постоянно с ними коммуницирует. Он общается со смежными отделами, продуктовыми командами, отделом безопасности, инфраструктуры и другими, поэтому у него более широкое видение и понимание процессов.
Язык коммуникации
Инженеры любят общаться между собой на техническом языке, часто понятном только другим таким же технарям. Архитектор умеет находить общий язык с разными специализациями: с технарями он говорит на техническом языке, с бизнесом — оперирует цифрами, с отделом безопасности — говорит о стандартах и политиках.
Насмотренность
Задача инженера — хорошо владеть своим основным языком, фреймворком и смежными технологиями, которые необходимы для конкретно его задач. Архитектор видит разные технологии, знает больше, чем свой язык программирования. Разбирается в смежных дисциплинах: аналитике, дизайне, инфраструктуре, разработке, фронтенде, бэкенде, бизнесе.
Задачи архитектора
Мы рассмотрели позицию архитектора ПО с разных сторон, посмотрели на наборы навыков, качеств, сравнили его с инженерной позицией. Давайте теперь посмотрим на роли и задачи, которые выполняет архитектор в компании:
Разработка архитектурного решения — это основная задача и артефакт работы архитектора ПО. Причём решение может разрабатываться как с нуля, так и дорабатываться уже существующее. Если смотреть реальности в глаза, то часто бывает и так, что в работающем продукте не существует решения, и нужно его создать исходя из доступных артефактов (текущих сотрудников, существующего кода, его документации).
Анализ требований является первостепенной задачей, которую выполняет архитектор и которая обычно предшествует разработке архитектурного решения. В неё включается сбор требований, таких как функциональные и нефункциональные, их уточнение и приоритизация. Обычно это происходит через коммуникацию с бизнес-аналитиками и другими стейкхолдерами продукта.
Риск-менеджмент необходим, чтобы решение получилось надёжным. Мы всегда находимся в неидеальном мире, и случиться может что угодно. Необходимо предусмотреть разные сценарии развития событий, ожидаемых и негативных, и разработать стратегии, посчитав необходимые ресурсы, время, стоимость их реализации.
Коммуникация со стейкхолдерами. Архитектор общается с большим количеством разных людей на разных уровнях иерархии компании, собирая требования, разрабатывая решение и внедряя его в команду. Пожалуй, весомая часть работы архитектора — это коммуникация. От качества этой коммуникации во многом зависит успех работы архитектора. Как мы говорили выше, результат его работы — это документация и архитектурное решение, а его внедрение происходит другими коллегами.
Группы навыков архитектора
Теперь давайте рассмотрим навыки, необходимые архитектору ПО. В этом списке мы основываемся на мнениях индустрии из EPAM, ассоциации IASA и The Open Group.
Business Acumen, бизнес-проницательность
Это знание о деловой среде, специфике и отрасли бизнеса и организации. Сюда можно отнести знание о конкурентах по конкретному виду продукта, о структуре компаний и их финансовом состоянии.
Technology Expertise, технологическая экспертиза
Это все профессиональные навыки в разных областях, владение инструментами, платформами и методологиями. Сюда можно отнести навыки из разработки: владение языком программирования, базами данных, сборкой и упаковкой сервиса. Навыки из инфраструктуры: релиз сервиса, поддержка, мониторинг, реагирование на инциденты. Также полезны и необходимы знания об облачных технологиях, сетях, безопасности и проектировании API.
Human Dynamics, понимание человеческого поведения
Это умение правильно взаимодействовать с людьми, понимание разных культурных особенностей. В качестве примера: есть такое понятие, как small talk, — это разговор на непринуждённые темы. В нашей культуре это не сильно принято, а на Западе это очень важно: прежде чем поговорить о делах, обязательно говорят «о погоде».
Другой пример: в Google или в других крупных корпорациях за рубежом проводят Behavioral Interview, поведенческое интервью, и делают на этом большой акцент. У нас обычно такого нет: каким бы ты токсиком ни был, тебя возьмут, если ты хорошо кодишь и делаешь свою работу.
Architecture Design, архитектурный дизайн
Это знание о разделении архитектуры на модули, о профилях нагрузки информационной системы, о том, когда и как её масштабировать. Архитектор должен знать, какие есть возможности для масштабирования, чем нужно «закидывать»: деньгами или технологиями. Например, можно закупить дополнительные мощности, а можно изменить стек и доработать архитектурное решение. Архитектор определяет, что менять или переписывать, сколько это будет стоить, нужно ли расширять команду и нанимать специалистов нового профиля.
Architecture Governance, управление архитектурой
В широком смысле это управление ожиданиями. Это мониторинг, который архитектор применяет локально в проектах, когда их настраивает. Если это происходит на уровне компании, должна быть единая система мониторингов, алертов, система реакции на непредвиденные события. Например, в некоторых больших компаниях есть группа реагирования, которая ночью звонит на мобильный телефон разработчику или ответственному за сервис.
Сюда же можно выделить внедрение архитектуры в команду. Это значит, что недостаточно просто разработать архитектурное решение и презентовать команде — она может его отвергнуть. Нужно ещё и убедить её, что архитектурное решение не с потолка взято и есть объективные причины, почему нужно внедрять именно его.
Персональные качества архитектора
Technologist by heart, любовь к технологиям
Человек, имеющий это качество, будет увлекаться технологиями, любить, экспериментировать, что-то пробовать у себя локально. Постоянно делать какие-то проекты, работать с технологиями в свободное время, расширять кругозор.
Internal Entrepreneur, предпринимательское мышление
Архитектор подходит к проекту не только с технической точки зрения, но ещё и с бизнес-подходом. Он понимает, какие сроки реализации проекта, сколько на это нужно денег, как и кого нанимать в команду.
Обычно в IT у нас две основные траты — это персонал и серверные мощности. Что дешевле и лучше: закупить высокие мощности или «закупить» более скиловую команду разработки, которая всё заоптимизирует? Это решает архитектор.
Человек с предпринимательским мышлением смотрит на технологии как на инструмент. Это значит, он не внедряет стильный и модный фреймворк, — он внедряет фреймворк, который решает конкретную задачу бизнеса. Также он всегда пытается сразу посчитать пользователей проекта, сколько денег они будут приносить, сколько денег потратит компания, — сойдётся ли экономика, или проект будет уходить в минус.
Leadership, лидерство
Лидерство — это про ответственность за людей, ответственных за результат. Лидер создает окружение вокруг себя, позволяющее иметь доступ к самой важной и актуальной информации. Вокруг него собираются люди, которые готовы поддержать и которым он со спокойной уверенностью делегирует задачи. Это напрямую влияет на качество принятия решений и на скорость их согласования.
Fast learner, обучаемость
Существует много смежных областей, включая те, которые напрямую к архитектуре не относятся. Архитектору иногда нужно в них погружаться, поэтому он должен уметь быстро загружать в себя знания, чтобы так же быстро начать их применять.
Например, я как-то работал с продуктом, который тесно связан с федеральным законодательством. Мне надо было пойти и изучить, что из себя представляет ФЗ, как отправлять данные в регулятор, зачем это нужно делать. Оказалось, что работать в облаках с таким продуктом невозможно: серверные мощности контролируются надзорными органами, и проект должен быть развернут целиком на выделенных серверах.
Problem solver, умение решать проблемы
Архитектор умеет подходить к задачам нестандартно. Например, не всегда задачу «разработать систему облачных вычислений» нужно решать через реализацию нового сервиса. Если это корпорация со множеством отделов и технологий, может оказаться, что некоторые департаменты разработали такие системы для себя. Кто-то написал с нуля, кто-то внедрил Open Source и допилил. Тогда хорошим решением может быть адаптация и объединение этих сервисов.
Excellent Communicator, коммуникабельность
Архитектор общается с большим количеством других ролей: стейкхолдерами, product-менеджерами, аналитиками, разработчиками и другими. Он со всеми находит общий язык: с технарями общается на техническом языке, с бизнесом — оперирует цифрами, безопасникам рассказывает о том, какие классные стандарты будут внедряться. Под каждую специальность людей у архитектора будет свой язык. Сюда же можно включить культурные аспекты, если мы работаем в международных компаниях: тот же small talk и другие культурные нюансы.
Путь из инженера в архитекторы
Как из инженера построить свой путь в архитектуру и какая трансформация для этого нужна? Чтобы разобраться, давайте посмотрим на диаграмму ниже:
В качестве I, первой фигуры, представлена основная компетенция. Обычно тот, кто идёт в архитекторы, является специалистом в какой-то области: например бэкенд или фронтенд-разработка, DevOps, или любой другой.
Чтобы совершить трансформацию в сторону архитектуры, нужно наработать насмотренность. В насмотренность включаются умение общаться с бизнесом, знание смежных технологий, принципов и методологий разработки, процессов тестирования и так далее. Таким образом I-Shaped-специалист преобразуется в T-Shaped. Но можно на этом не останавливаться и двигаться в ещё более сложные шейпы.
Pi-Shaped и Comb-Shaped — это специалисты с глубокими знаниями в нескольких областях. Например, у фулстек-разработчика скорее всего глубокая компетенция как в бэкенде, так и в фронтенде — это две «ножки» у Pi-Shaped. Если к этому добавить насмотренность других технологий, смежные и дополнительные навыки, получится классный архитектор, который глубоко разбирается в двух узких областях знаний. Чем выше уровень архитектора, тем больше у него глубины в отдельных областях знаний.
Вне зависимости от потенциала у каждого человека есть предел по количеству навыков и знаний, которые актуальны и отточенны. В Comb-Shaped-конфигурации человек редко способен на использование навыков, требующих глубинных знаний, — он больше сосредоточен на делегировании задач другим.