Search  
Always will be ready notify the world about expectations as easy as possible: job change page
24 марта

Кто такой архитектор ПО и как им стать

Кто такой архитектор ПО и как им стать
Source:
Views:
1614

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

Similar
26 июня
Рекрутер задался вопросом, почему на техсобесах «даже нормальные люди звереют» — да потому что интервьюер превращает собеседование в страшный экзамен или «соревнование» с кандидатом. Мы собрали 10+ историй о том, как айтишники сталкивались с «душнилами» на интервью. Мнение топикстартера: «интервьюеры...
24 марта
Автор: AnimeSlave
Я столкнулся с тем, что я иногда не понимаю код, с которым мне приходится работать. И это сильно сказывается на моей производительности и на качестве конечного результата. Неделю назад я прочитал статью «Плохо девелопмент» за авторством @dalerank (Сергей Кушниренко), в...
Dec 1, 2022
Author: Devyani Borade
Said no manager ever. Money is the one thing every candidate at any job interview is advised never to mention. The salary on offer for the role is treated almost like a *dirty secret. Job advertisements only reveal a band...
10 апреля
Vite.js - это один из инструментов для настройки сред разработки. Чаще всего используется в связке с фреймворками React и Vue. Однако функционал не ограничен только их поддержкой - инструмент способен работать даже с ванильным JavaScript, следовательно, и различными библиотеками, написанным...
Send message
Type
Email
Your name
*Message