Просто о сложном. Архитектура для РМов
Архитектура приложения — часто используемый термин в разработке. Всеобъемлющий, многозначный и, на первый взгляд, — сложный. Давайте попробуем посмотреть на него глазами не-разработчика и ответить на часто задаваемые вопросы.
- 1. Ключевые составляющие понятия архитектуры программного обеспечения.
Принято считать что архитектура ПО — это набор технических решений по организации программного продукта. Очень часто, когда команда говорит об архитектуре, вы слышите слова: monolithic, microservices, выбор frameworks. Но это только технические решения, а не архитектура в целом.
На самом деле весь набор технических решений является прямым следствием Business Architecture и Information Architecture.Business Architecture — отвечает на вопрос «что мы получим в результате работы» и «какие проблемы необходимо решить» в ходе работы продукта. Иными словами мы очерчиваем круг задач которые решает будущая система.Результат Information Architecture — описание доменов (сущностей) системы и их взаимодействие на основе описанной ранее концепции.
Формирование архитектурных решений стартует со сбора требований и описания бизнес сущностей. В этом процессе качественно собранные требования и описанные сущности и их взаимодействия — основа для принятия оптимальных технических решений.Еще одна полезность Business Architecture и Information Architecture — у вас всегда под рукой аргументы для решения спорных ситуации с клиентом на тему «почему это не учли ранее при форматировании архитектуры приложения». - 2. Архитектурные решения принимаются в ходе выполнения задачи.
Архитектура ПО условно делится на уровни: high и low.
High level architecture описывает структуру системы, способы взаимодействия, разворачивания составляющих. Принимают подобные решения на старте проекта и ситуативно в ходе эволюции проекта.Low level — это тот самый дизайн кода или насколько качественно программист пишет код.Есть объективный минимум оценки качества кода — принцип SOLID.
Необходимость в контроле low level architecture очевидна — минимизация рефакторинга и стабилизация скорости разработки. Контролируется это все в помощью практики соde review и анализаторов кода. Особенно важно следить за low level architecture на старте проекта и в фазе active development. Это заложит хороший фундамент для масштабирования разработки в будущем. - 3. Смена архитектурного решения.
Часто встречающийся болезненный вопрос на протяжении жизненного цикла продукта.
Как отличить необходимость изменений от технического перфекционизма разработчиков?
Первый признак необходимости работы с архитектурой — понижение скорости разработки при постоянном составе команды.Да, возможно ребята устали. Но если это не так — это первый колокольчик обратить внимание качество архитектурных решений.Индикатор номер 2, характерен для legacy проектов, он заключается в попытках увеличить скорость разработки за счет увеличение команды.
На практике скорость разработки остается прежней либо снижается, что вызывает массу непонимания со стороны заказчика. На самом деле причина очевидна — пришло время вкладывать силы и средства в перепроектирование системы. - Что делать и с чего начинать?
Если вы прониклись пожеланиями от команды поменять архитектуру, то у вас возникнет вопрос как это сделать? Начать стоит с анализа качества кода — т.е с low level architecture. Ведь это мероприятия менее дорогостоящее чем изменение high level решений.Для начала добавьте в ваш командный DoD (definition of done) практику соde review и использование анализаторов кода. Потом составьте с командой план рефакторинга, по которому можно будет постепенно улучшать архитектуру.Не помогает? Тогда необходимо переходить к дорогостоящим изменениям high level решений. Тут необходимо будет привлечь solution architect для разработки концептов, планов, сроков и аргументации, утвердить все это с менеджментом. И постепенно начинаем миграцию миграцию high level решения. Например, с monolithic на SOA.При этом всем стоит отметить — с эволюционной точки зрения продукта смена архитектурных решения это нормальные процессы, которые стоит понимать и аргументировать необходимость клиенту и менеджменту. Ведь время идет, задачи продукта меняются, поэтому логично, что и инструменты их достижения будут уже другими. Более детально об архитектуре приложений и других технических навыках для РМ и ВА мы будем поговорим на нашем тренинге Technical skills for Project Managers and Business Analysts.