Современное программное обеспечение имеет довольно сложную структуру. Разработку, как правило, ведет целая команда, в которую входят как непосредственно программисты, так и специалисты по качеству кода, тестировщики и т.д. В результате, важную роль организация работы всех этих специалистов как единой команды. И перед началом разработки нам, прежде всего необходимо перевести требования заказчика, о есть бизнеса на технический язык. То есть, нам необходимо понять, какие компоненты ИТ систем участвуют в каких бизнес процессах и затем, на основании этих требований уже готовить техническое задание на разработку программного продукта. И хотя, за анализ бизнес процессов в команде как правило отвечает бизнес-аналитик или аналитик данных, все остальные задачи, связанные с координацией работы команды разработчиков ложатся на плечи Архитектора программного обеспечения (Software Architect). Именно об этой специализации мы и будем говорить в этой статье.

Кто такой Software Architect? 

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

Таким образом, совершенно очевидно, что архитектор программного обеспечения - это достаточно опытный специалист, который хорошо знаком не только с вопросами разработки, но и имеет широкий технический кругозор и большой опыт в предметной области. Многолетний опыт программирования является одним из необходимых условий, но явно недостаточным, так как помимо разработки необходимо хорошо разбираться в различных технологиях и протоколах, на которых строится работа всей системы в целом.

Конечно, нельзя знать все на достаточно глубоком уровне, поэтому еще одной задачей архитектора программного обеспечения является необходимость взаимодействия со смежными подразделениями и экспертами. Так, при проработке инфраструктурных компонентов решения не лишним будет уточнить к примеру у специалистов по серверам и системам хранения характеристики предполагаемого к использованию оборудования, для того, чтобы избежать появление “узких мест” при работе системы в высоконагруженном режиме.

Таким образом, архитектору программного обеспечения, на начальном этапе разработки проектного решения необходимо взаимодействовать с различными специалистами, для того чтобы избежать появление проблем в дальнейшем.

В процессе разработки

После того, как в ТЗ мы зафиксировали все необходимые требования к создаваемой системе, сформировали команду из специалистов, начинается разработка программного продукта. И здесь происходит самое интересное. В процессе разработки обязательно будут происходит разные скажем мягко “странные” вещи, создающие существенные трудности в работе всей команды.

Примерами таких странностей можно назвать выход новых версий ОС, фреймворков, библиотек и других компонентов, которые используются, или на которых строится наша система. Так, Майкрософт очень любит “радовать” изменениями в функционале системы, после выхода очередного пакета обновлений или новой версии ОС.

Кроме того, неприятным сюрпризом может оказаться изменение “хотелок” заказчика. Да-да, все мы помним про согласованное ТЗ, но иногда возможны такие ситуации, когда, либо то или иное требование в ТЗ прописано не достаточно четко, что дает право на различные толкования этого требования, либо просто заказчик потребовал прописать вместо четких формулировок пространное “уточняется при разработке”. Конечно, в этом месте многие могут возразить, что архитектор сам дурак, раз допустил в ТЗ такие формулировки, но в реальной жизни все не так просто, иногда многое решают личные связи топ менеджмента двух компаний и иные совсем не технические обстоятельства.

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

Кроме технических вопросов не стоит забывать о необходимости регулярного общения с представителями заказчика.

Задачи и обязанности

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

Кроме того, в обязанности архитектора входит выполнение задач по руководству командой по проектированию и сборке спроектированного приложения, и разработка плана создания прикладной платформы, которая наилучшим образом соответствует решению поставленной задачи.

Не лишним будет помнить о сроках. Конечно, во многих компаниях за сроки отвечает руководитель проекта, но в любом случае архитектор должен контролировать сроки сдачи проектов или релизов. И взаимодействие с людьми в разных ролях, такими как тестировщики и бизнес-аналитики.

Как стать Software Architect

Для того, чтобы стать хорошим архитектором программного обеспечения требуется сочетание образования и опыта. То есть, на архитектора нельзя просто выучиться в вузе или на курсах. Обязательно необходим опыт в разработки программных продуктов в течение минимум пяти лет.

Для тех кто уже занимается разработкой можно посоветовать изучать новые технологии и языки программирования, основы DevOps, системный дизайн и методы командной работы. Также не лишним будет наличие сертификата по профильным направлениям.

Заключение

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

Комментарии (1)


  1. hlogeon
    25.05.2023 11:54

    Что-то на мой взгляд у вас тут полная каша написана....

    все остальные задачи, связанные с координацией работы команды разработчиков ложатся на плечи Архитектора программного обеспечения (Software Architect).

    Не соответствует действительности. Координацией работы занимается проджект-менеджер.

    Таким образом, архитектору программного обеспечения, на начальном этапе разработки проектного решения необходимо взаимодействовать с различными специалистами, для того чтобы избежать появление проблем в дальнейшем.

    А какому специалисту не нужно взаимодействовать с различными специалистами для того, чтобы избежать проблем в дальнейшем? А еще эта фраза у вас повторяется аж 2 раза с интервалом в одно предложение.

     Прежде всего это встречи с клиентами, понимание их бизнес-целей
    Также это обсуждение общего бизнес-плана с клиентами и того, какие области могут быть улучшены, что могло бы упростить бизнес-процесс

    Вы это точно про архитектора говорите? Для чего тогда нужен бизнес-аналитик?

    Кроме того, в обязанности архитектора входит выполнение задач по руководству командой по проектированию

    Руководством любой командой занимается менеджер(от глагола "to manage" - управлять, руководить, организовывать). Проектированием занимается архитектор. У вас архитектор занимается руководством, но не занимается непосредственно проектированием.

    Обязательно необходим опыт в разработки программных продуктов в течение минимум пяти лет.

    Это кто сказал? А если у меня опыт непосредственной разработки 3 года? Невозможно стать архитектором? Интересно... Мерить опыт разработки годами вообще странноватая затея в этом контексте. Можно и 10 лет формы шлепать и не копать в сторону архитектуры ПО, а можно сфокусироваться именно на архитектурных решениях и за 2-3 года добежать до Junior Architect.

    То есть, на архитектора нельзя просто выучиться в вузе или на курсах.

    А еще больше рассказываем на нашем курсе Software Architect

    :) ну это вообще достойный финал, я считаю :)


    Удивительно, кто и как у вас пропускает такие статьи. Статья написано ни о чем. Кому она адресована не понятно. Суть работы не раскрывает. Зачем она здесь?