Всем привет! Меня зовут Виктор Василенко, я техлид и Solution-архитектор. Я работал в Яндексе и X5 Group и уже не первый год сотрудничаю с Практикумом. Раньше я делился опытом на курсах «Алгоритмы и структуры данных» и «Асинхронное программирование на Python», а теперь занимаюсь курсом «Архитектура ПО».

Архитектор ПО — это специалист, ответственный за проектирование структуры и организацию системы или продукта. Роль архитектора в 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-конфигурации человек редко способен на использование навыков, требующих глубинных знаний, — он больше сосредоточен на делегировании задач другим.

В этой статье мы рассмотрели, кто такой архитектор ПО, какие задачи он решает, а также узнали, как совершить трансформацию в эту роль. Используйте эту статью как чек-лист для развития своих навыков или обращайтесь за помощью к курсам Практикума. 

На курсе «Архитектура ПО» вы научитесь решать проблемы бизнеса путём решения инженерных задач и осмыслять бизнес-контекст, в котором эти задачи живут. Вы сможете определиться, как и куда двигаться в личном развитии, чтобы стать той прослойкой между бизнесом и технарями, которая превращает производственный хаос в подобие гармонии. Но помните, что никакой курс не заменит вам многолетнего опыта, поэтому самое сложное и интересное всегда впереди!