Просто о сложном. Архитектура для РМов

Архитектура приложения – часто используемый термин в разработке. Всеобъемлющий, многозначный и, на первый взгляд, – сложный. Давайте попробуем посмотреть на него глазами не-разработчика и ответить на часто задаваемые вопросы.

• 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.