Современное программное обеспечение имеет довольно сложную структуру. Разработку, как правило, ведет целая команда, в которую входят как непосредственно программисты, так и специалисты по качеству кода, тестировщики и т.д. В результате, важную роль организация работы всех этих специалистов как единой команды. И перед началом разработки нам, прежде всего необходимо перевести требования заказчика, о есть бизнеса на технический язык. То есть, нам необходимо понять, какие компоненты ИТ систем участвуют в каких бизнес процессах и затем, на основании этих требований уже готовить техническое задание на разработку программного продукта. И хотя, за анализ бизнес процессов в команде как правило отвечает бизнес-аналитик или аналитик данных, все остальные задачи, связанные с координацией работы команды разработчиков ложатся на плечи Архитектора программного обеспечения (Software Architect). Именно об этой специализации мы и будем говорить в этой статье.
Кто такой Software Architect?
Итак, архитектор программного обеспечения - это как правило программист или разработчик программного обеспечения, который определяет, какие процессы и технологии должна использовать команда разработчиков. То есть, получая верхнеуровневое ТЗ на работы, именно архитектор решает, какие именно фреймворки, библиотеки и инфраструктурные решения должны использоваться при реализации проекта. Конечно, многие решения, на которых планируется реализовывать проект как правило фиксируются в техническом задании, однако в таком случае архитектор должен принять непосредственное участие в согласовании этого ТЗ, для того, чтобы в него попали действительно нужные технологии с решения, позволяющие реализовать нужный функционал оптимальными средствами.
Таким образом, совершенно очевидно, что архитектор программного обеспечения - это достаточно опытный специалист, который хорошо знаком не только с вопросами разработки, но и имеет широкий технический кругозор и большой опыт в предметной области. Многолетний опыт программирования является одним из необходимых условий, но явно недостаточным, так как помимо разработки необходимо хорошо разбираться в различных технологиях и протоколах, на которых строится работа всей системы в целом.
Конечно, нельзя знать все на достаточно глубоком уровне, поэтому еще одной задачей архитектора программного обеспечения является необходимость взаимодействия со смежными подразделениями и экспертами. Так, при проработке инфраструктурных компонентов решения не лишним будет уточнить к примеру у специалистов по серверам и системам хранения характеристики предполагаемого к использованию оборудования, для того, чтобы избежать появление “узких мест” при работе системы в высоконагруженном режиме.
Таким образом, архитектору программного обеспечения, на начальном этапе разработки проектного решения необходимо взаимодействовать с различными специалистами, для того чтобы избежать появление проблем в дальнейшем.
В процессе разработки
После того, как в ТЗ мы зафиксировали все необходимые требования к создаваемой системе, сформировали команду из специалистов, начинается разработка программного продукта. И здесь происходит самое интересное. В процессе разработки обязательно будут происходит разные скажем мягко “странные” вещи, создающие существенные трудности в работе всей команды.
Примерами таких странностей можно назвать выход новых версий ОС, фреймворков, библиотек и других компонентов, которые используются, или на которых строится наша система. Так, Майкрософт очень любит “радовать” изменениями в функционале системы, после выхода очередного пакета обновлений или новой версии ОС.
Кроме того, неприятным сюрпризом может оказаться изменение “хотелок” заказчика. Да-да, все мы помним про согласованное ТЗ, но иногда возможны такие ситуации, когда, либо то или иное требование в ТЗ прописано не достаточно четко, что дает право на различные толкования этого требования, либо просто заказчик потребовал прописать вместо четких формулировок пространное “уточняется при разработке”. Конечно, в этом месте многие могут возразить, что архитектор сам дурак, раз допустил в ТЗ такие формулировки, но в реальной жизни все не так просто, иногда многое решают личные связи топ менеджмента двух компаний и иные совсем не технические обстоятельства.
В таких ситуациях может возникнуть острая необходимость в оперативной переработке всего согласованного ранее решения. Ну а кроме того, в процессе разработки можно столкнуться с ситуацией, когда что-то работает совсем не так как это ожидалось. Например, в какой-то библиотеке та или иная функция содержит ошибку или уязвимость, в результате чего, по факту ее использовать нельзя. В таких случаях архитектору необходимо совместно с другими участниками проектной команды выработать обходное решение не снижающее общие характеристики разрабатываемого решения.
Кроме технических вопросов не стоит забывать о необходимости регулярного общения с представителями заказчика.
Задачи и обязанности
Итак, давайте подытожим те задачи, которые должен решать архитектор программного обеспечения. Прежде всего это встречи с клиентами, понимание их бизнес-целей, определение их требований и разработка решений для удовлетворения этих потребностей в программном обеспечении. Также это обсуждение общего бизнес-плана с клиентами и того, какие области могут быть улучшены, что могло бы упростить бизнес-процесс или программное обеспечение.
Кроме того, в обязанности архитектора входит выполнение задач по руководству командой по проектированию и сборке спроектированного приложения, и разработка плана создания прикладной платформы, которая наилучшим образом соответствует решению поставленной задачи.
Не лишним будет помнить о сроках. Конечно, во многих компаниях за сроки отвечает руководитель проекта, но в любом случае архитектор должен контролировать сроки сдачи проектов или релизов. И взаимодействие с людьми в разных ролях, такими как тестировщики и бизнес-аналитики.
Как стать Software Architect
Для того, чтобы стать хорошим архитектором программного обеспечения требуется сочетание образования и опыта. То есть, на архитектора нельзя просто выучиться в вузе или на курсах. Обязательно необходим опыт в разработки программных продуктов в течение минимум пяти лет.
Для тех кто уже занимается разработкой можно посоветовать изучать новые технологии и языки программирования, основы DevOps, системный дизайн и методы командной работы. Также не лишним будет наличие сертификата по профильным направлениям.
Заключение
В этой небольшой статье мы поговорили о том, кто такой архитектор программного обеспечения, какие основные задачи он решает и за что несет ответственность в проектах по разработке ПО. Однако, за кадром остались вопросы, связанные со спецификой разработки софта в различных отраслях. Об этом мы поговорим в следующих статьях. А еще больше рассказываем на нашем курсе Software Architect. На странице курса вы также можете зарегистрироваться на бесплатные вебинары, для ознакомления с программой и форматом обучения.