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

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

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

Архитектор ПО — это специалист, ответственный за проектирование структуры и организацию системы или продукта. Роль архитектора в 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
24 марта
Автор: Сергей Кушниренко
Среди множества задач, решаемых программистом, одной из самых частых является подумать и добавить новый функционал в приложение. И там уже может быть много похожего функционала, он может быть хорошо написан, хорошо документирован. Искушение заключается в том, поддаться своей лени и...
7 октября 2020 г.
Наем удаленных специалистов – довольно сложная задача о поиске оптимального решения с учетом известных ограничений.С одной стороны, ты ограничен во времени. Учитывая средние зарплаты в ИТ, стоимость простоя каждого такого специалиста крайне высока. Если кандидаты находятся на стадии активного поиска,...
23 июля 2014 г.
Исповедь 1Я — разработчик. От своих работодателей я постоянно слышу, что работаю медленно и часто всё усложняю без веской причины. И что мне пора бы что-то с этим сделать. Во избежание.Весь мой опыт программирования складывается из университетских работ и пары...
13 февраля 2020 г.
Автор: Кирилл Медведев
Выход на новую работу — всегда стресс, особенно когда нужно максимально быстро влиться в коллектив и приступить к задачам. Рассказываем, на что обратить внимание, чтобы не пожалеть о выборе и оказаться «на своём месте».Шаг первый: проведите разведкуПервый рабочий день —...
Send message
Email
Your name
*Message


© 1999–2024 WebDynamics
1980–... Sergey Drozdov
Area of interests: .NET Framework | .NET Core | C# | ASP.NET | Windows Forms | WPF | HTML5 | CSS3 | jQuery | AJAX | Angular | React | MS SQL Server | Transact-SQL | ADO.NET | Entity Framework | IIS | OOP | OOA | OOD | WCF | WPF | MSMQ | MVC | MVP | MVVM | Design Patterns | Enterprise Architecture | Scrum | Kanban