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

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

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

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

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

Узнайте, что нового!
Никакого спама, никогда!