— Уверен, что выбрана подходящая архитектура IT-проекта?
— Да, учитывая бизнес-цели клиента и озвученные им желаемые сроки и бюджет проекта.
— Давай подумаем еще. Нужна максимальная оптимизация времени и ресурсов для разработки, а также сокращение рисков до минимума.
Это пример диалога между Solution Architect и PM-ом, который имеет техническое понимание проекта. Дальше обсуждают ключевые аспекты архитектуры будущего приложения, сравнивают различные варианты для поиска лучшего решения. Подробней о том, почему это важно и какая роль проектного менеджера в этом процессе, расскажем в статье. Начнем с базы — что такое software architecture и почему она важна.
Роль архитектуры в IT
Представьте, что перед вами стоит задача построить дом. Вы можете его сделать в любом стиле и из разных материалов, но в основе будет лежать определенное архитектурное решение. Именно оно диктует, какие технологии применять, как и в какой последовательности выполнять те или иные работы. В разработке IT-решений происходит все тоже самое с поправкой на особенности сферы. При этом связь архитектуры и реализации проекта прослеживается на всех этапах: от оценки до релиза и последующей техподдержке.
Software architecture помогает:
- определить базовую структуру приложения, основные и второстепенные элементы;
- выстроить логику взаимодействия между разными компонентами архитектуры проекта;
- учесть риски, найти способы предотвращения технических проблем в процессе разработки и при работе готового ПО;
- продумать безопасность и потенциальную масштабируемость проекта;
- создать единую систему для комфортной работы команды;
- оценить сроки, стоимость и этапы разработки.
Список можно долго продолжать, но главное — software architecture диктует, как вы «пишите» приложение, как оно работает и какой существует потенциал для расширения функциональности в будущем. От этого во многом зависит процесс девелопмента и управление IT-проектом в целом, и влияние архитектуры на роль менеджера в частности.
Виды software architecture
Любое приложение по своей сути — это различные компоненты проектной архитектуры, объединенные в одно целое. Другой вопрос, каким образом воедино соединены все системы, модули и интерфейсы, и как построено их взаимодействие. Это во многом зависит от вида архитектурного IT-решения:
- монолит — в основе функциональные блоки, которые находятся в одной кодовой базе и зависят друг от друга;
- микросервисы — базируется на отдельных модулях, которые взаимодействуют между собой по определенному алгоритму и образуют общую систему;
- серверлес — альтернативный вариант микросервисов, который ориентирован на максимальное использование облачных технологий, за счет которых автоматизирует все развертывание.
Подробнее о каждом из решений вы сможете узнать на курсе для проектных менеджеров «Архитек» — ArchiTech. На нем эксперты IAMPM делятся собственным опытом и знаниями, которые помогут вам понять всю важность архитектуры в проектах и проработать технические скиллы для PM. Мы же рассмотрим основные плюсы и минусы каждого вида software architecture.
Монолит
| Плюсы | Минусы |
Простота развертывания. Так как для монолита в основном существует только одна точка входа, развертывание происходит очень быстро и относительно просто.
Разработка. Обычно выполняется быстро — все компоненты и модули содержатся в единой кодовой базе и всегда находятся под рукой, что экономит время.
Отладка. Значительно упрощается, так как все элементы находятся рядом можно отследить все связи с выполнением кода. | Масштабирование. Можно расширять только целиком — если нагрузка растет на один модуль, масштабировать необходимо весь монолит.
Надежность и уязвимости IT-проекта. Если выходит из строя, то сразу все модули.
Изменение и апгрейд технологий. Очень сложно!
Гибкость. Монолит негибкий — изменение одного модуля практически всегда влияет на другие. |
Микросервисы
| Плюсы | Минусы |
Гибкость. Каждый сервис — отдельная система и любые изменения в ней не затрагивает другие части архитектуры, если в этом нет необходимости.
Масштабирование. Можно масштабировать каждый модуль по отдельности.
Гибкость технологий. Любая подсистема может быть реализована собственным способом, отличным от остальных.
Надежность и безопасность IT-проекта. Обычная поломка какой-то подсистемы редко выводит из строя всю систему. | Процесс разработки. Обычно требует больше времени и ресурсов, чем при работе с монолитной структурой, так как нужно реализовывать и налаживать взаимодействие нескольких подсистем.
Отладка. Происходит сложнее, чем в монолите — необходимо определить сломанный сервис и причины его выхода из строя.
Развертывание. Каждое добавление нового сервиса требует настройки главных частей IT-проекта. |
Серверлес
| Плюсы | Минусы |
Гибкость. Высокая за счет обособленности модулей друг от друга.
Абстракция от операционной системы. Cloud автоматически решает, какая операционная система и настройки необходимы.
Легкий порог входа. Обычно у серверлесов обособленный простой код, с которым профильный специалист легко и быстро сможет разобраться.
Надежность. Сравнима с микросервесной структурой при правильном построении проекта. | Гибкость. Одновременно плюс и минус. Недостаток в том, что масштабирование зависит от возможностей и настроек облачного сервиса.
Отладка. Усложнена из-за взаимодействия между обособленными компонентами.
Зависимость от сервиса. Каждый Cloud имеет собственный алгоритм работы, поэтому безболезненный переход с одного «облака» на другое на практике сложно осуществим.
Каскадный отказ. При неправильной структуре и настройке отдельных модулей возможно их взаимное влияние друг на друга, что несет потенциальные риски выхода из строя всей системы. |
Перечисленное хорошо показывает влияние software architecture на разработку IT-продуктов. Также важно понимать, что для mobile, web и desktop каждый вид архитектуры будет иметь свою специфику. Поэтому важно изначально учитывать все моменты: функциональность и безопасность проекта, возможности масштабирования и другие аспекты. В этом вопросе роль PM-а выходит на первый план.
Роль проектного менеджера в архитектуре IT-продукта
На идеальном проекте у менеджера в команде присутствует Solution Architect, который продумывает архитектуру приложения. Для этого ему нужно, как минимум, идея и хотя бы базовое техническое задание — ТЗ обычно дает Business Analyst или Project Manager. Дальше идет процесс продумывания архитектурного решения с учетом:
- данных по бизнес-целям и потребностям клиента;
- текущих ресурсов: уровня специалистов, желаемых дедлайнов, выделяемого бюджета;
- риск-менеджмента и так далее.
При этом менеджер может и вовсе не участвовать в процессе — только осуществлять контроль результата с последующей оценкой и ведением проекта по созданной software architecture. На практике же часто встречается ситуация, когда на проекте отсутствует SA и даже BA — в этом случае Project Manager становится мастером-универсалом.
Если до этого одна из задач PM-а заключалась в организации работы бизнес-аналитика по сбору данных и составлении техзадания для архитектора, то теперь это ложится на плечи самого менеджера. При этом разработкой software architecture занимается Project Manager самостоятельно, если техскиллы позволяют, или с кем-то из девелоперов — тот случай, когда управление проектом с техническими знаниями об архитектуре дается легче, чем без них. Впрочем, при общении с Solution Architect подобные навыки тоже будут в плюс для менеджера.
Преимущества глубокого понимания технической стороны проекта
Правильно настроенная коммуникация и выстроенные процессы — один из важнейших аспектов успешной работы команды. Понимание, что такое software architecture, знание терминов и процесса разработки,необходимые технические навыки помогают проектным менеджерам:
- проще находить «общий язык» с разработчиками — сокращает время на принятие решений и устранение возможных проблем;
- правильно оценивать время и бюджет проекта, в том числе и на разработку software architecture и refactoring — всегда возможны дополнения к текущим бизнес-целям, изменения приложения и другое;
- качественней планировать загрузку команды, описывать задачи и контролировать их выполнение — упрощает управлении рисками и проектом в целом, снижает процент технического долга и возникновение проблем в долгосрочной перспективе;
- быстро и доступно преподносить клиенту информацию от специалистов, отстаивать собственное предложение по срокам и цене — руководство и заказчики такое точно оценят;
- корректно вести документацию и четко расписывать функциональность для упрощения дальнейшего обслуживания приложения, внесения изменений — такой подход значительно оптимизирует общую работу над проектом.
Помимо перечисленного знания software architecture позволяют менеджеру находить и предлагать команде вместе с клиентом лучшие варианты. При этом учитывать различные факторы и риски: от безопасности до потенциального роста проекта. Безусловно, многое приходит с опытом, но получить актуальные знания и прокачать свои технические навыки вы можете на курсе по архитектуре IT-проекта ArchiTech. Советуем на него обратить внимание вне зависимости от вашего уровня — на рынке высоко ценятся PM-ы, которые хорошо разбираются в software architecture.
Примеры влияния выбора архитектуры на судьбу проектов
На старте разработки одна компания неверно сделала выбор архитектуры для масштабирования приложения — не учли возможность быстрого изменения функциональности под разные запросы пользователей. В итоге пришлось фактически с нуля делать новую версию продукта со всеми вытекающими последствиями. Опытный PM обязательно сказал бы клиенту и команде обратить внимание на масштабируемость.
Другой пример касается идентификации потенциальных уязвимостей и правильного выбора архитектурных решений для безопасности. Клиент заказал бизнес-приложение, которое собирало расширенные данные пользователей. Так как это потенциальный фактор риска, РМ предложил заказчику усилить защиту и выделить для этого дополнительный бюджет. Из-за «плавания» в технических моментах и слабой коммуникации, Project Manager не смог добиться согласия клиента. Как итог, после релиза приложение быстро взломали и украли пользовательские данные. С одной стороны, вины менеджера нет, но были бы у него высокие hard и soft skills, переговоры с заказчиком могли иметь другой результат.
Бонус: как обсуждать и проверять архитектуру
Для конструктивного обсуждения software architecture с архитектором или разработчиками советуем обращаться к справочнику WAF — Well-Architected Framework от Amazon. Здесь вы найдете актуальные рекомендации по оценке IT-продуктов. Если кратко, WAF предлагает оценивать проект исходя из пяти категорий нефункциональных требований:
- Operational Excellence.
- Security.
- Reliability.
- Performance Efficiency.
- Cost Optimization.
Если все перечисленное выполнено, то с вероятностью в 99.9% архитектура на проекте разработана правильно.