Как работа с архитектурой в IT встраивается в рабочий процесс
О себе: занимаюсь разработкой уже более 15 лет. Поймал себя на мысли, что когда что-то могу описать и показать другому, то заодно получается и хорошо структурировать мысль и систематизировать знания. Поэтому начал делать для себя заметки, которыми делюсь.
Многие не раз слышали про архитектора, архитектуру системы, архитектурные документы и стили архитектуры. Но как понять, что на вашем проекте работа с архитектурой ведется системно? Как сопоставить рабочую систему с требованиями и правилами?
Базовые определения
Архитектура — это сочетание
- архитектурного стиля, в котором реализована система
- нефункциональных требований или архитектурных свойств, которые будущая система должна поддержать
- архитектурных решений или правил, по которым система должна выстраиваться
Архитектор - роль в разработке, которая отвечает за
- выявление архитектурных свойств
- выбор архитектурного стиля на основе этих свойств
- определение архитектурных решений и контроль их соблюдения
- регулярный аудит и пересмотр выбранных решений
Архитектурные документы — артефакты, фиксирующие решения, принимаемые архитектором, аналитиком и разработчиком, которые отражают структуру и принципы работы система
Жизненный цикл (ЖЦ) архитектурных документов - процесс выработки архитектурных документов на основе требований
Проектирование/дизайн и реализация — планирование того, как будет реализована кодовая база и сама реализация на основе функциональных требований. Стек технологий, как правило, не рассматривается на этапе архитектуры и относится к следующему этапу проектирования
Ревью архитектуры — проверка соблюдения принимаемых разработчиком решений относительно выбранного стиля и архитектурных решений
Работа с архитектурными рисками — выявление риска того, что архитектура недостаточно поддерживает конкретные нефункциональные требования
Надеюсь, получилось не перегрузить терминами и дать примерное представление о том, из каких деталей складывается пазл под названием Архитектура ПО. Далее рассмотрим, как элементы этого пазла складываются в общую картину🧩
Работа с архитектурой на разных этапах
На примере ЖЦ большой стори (User Story, фичи, новой функциональности), рассмотрим, кто, как и на каких этапах взаимодействует с архитектурой системы.
Проработка
- У продакта появляется потребность в новой фиче и он описывает сторю в Tracker
- Решения в архитектуре редко применимы за пределами узкого пространства конкретной проблемы. Потребность продакта является триггером к созданию подзадачи на проработку архитектуры
- Если это доработка вида «перекрасить кнопку», то вмешательство архитектора не требуется и задачу можно закрывать. Такое решение принимает архитектор
- Если же это задача, которую еще не решали, либо которая приводит к использованию новых технологий или протоколов взаимодействия, либо не понятно, к какому микросервису ее отнести, тогда подключается архитектор - Архитектор общается с продактом и бизнес-аналитиком, чтобы понять нефункциональные требования по сторе и фиксирует их в задаче на проработку архитектуры. Необходимо определить самые важные из этих требований! Многие из них могут противоречить друг другу и необходим баланс
- На основе выявленных требований архитектор формирует архитектурное решение (АР) и отправляет его на согласование всем заинтересованным. Как правило, это разработчикам, чьи сервисы затрагивает решение и системному аналитику
- На этапе системного анализа аналитик смотрит АР и учитывает его при проработке системных требований
Разработка и тестирование
- На грумминге разработчик анализирует АР и системные требования
- Затем он формирует схемы архитектуры — диаграммы классов и взаимодействий, объектную модель и контракты. Цель схем — описать требования к архитектуре и показать, как она должна быть реализована с учетом АР. Эти артефакты в виде схем могут храниться рядом с кодом в git. Если есть компетенции и договоренность с разработкой, то такие схемы может готовить аналитик. Ревью схем проводит архитектор
- После окончания разработки, на этапе тестирования архитектор фиксирует изменения в описании архитектуры. Версии схем TO BE из предыдущего пункта переходят в состояние AS IS. Изменения согласуются разработчиком
Часто этого бывает достаточно и работа с архитектурой на проекте ограничивается перечисленными шагами. Но есть ряд практик, которые качественно дополняют работу с архитектурой. О них расскажу далее
Все в разработке пропитано циклами обратной связи и архитектура тут не является исключением! Оценка соблюдения принятых решений, адаптация под непрерывно изменяющийся контекст — все это упаковывается в третий этап работы с архитектурой
Ревью
- Если на этапе ознакомления разработчика и аналитика с АР выявляются несоответствия между описанием и в реализацией, они устраняются архитектором в описании
- Эти несоответствия заносятся в отдельный Backlog архитектуры, который является архитектурным техдолгом системы
- Для контроля за соблюдением нефункциональных требований могут использоваться метрики (производительность, доступность, …) и функции пригодности (fitness functions), которые проверяют степень соответствия заявленному уровню и могут подсветить деградацию при очередных изменениях в системе — это практики эволюционной архитектуры
- Для контроля за связанностью кода можно использовать различные метрики: абстрактность, нестабильность, расстояние от главной последовательности, выбросы с точки зрения размеров компонентов (мы не используем)
- Система развивается, меняются требования бизнеса, вносятся изменения в код. В этом нестабильном контексте важно регулярно проводить переоценку архитектурных рисков, чтобы вовремя уделить им должное внимание! Архитектор может сформировать рабочую группу для проведения практики риск-штурма.
- В соответствии с законом Конвея, целевая архитектура соответствует структуре команды. Тогда такую архитектуру проще будет построить. Работает и обратное — структуру команды можно подстроить под архитектуру системы. Важно проводить ревью соответствия архитектуры и структуры команд и вовремя внедрять необходимые изменения! Для анализа можно посмотреть, как часто команде для реализации стори приходиться прибегать к помощи других команд или дорабатывать чужие сервисы.
- С ростом системы и, как следствие, ростом команды один архитектор может перестать справляться с поставленными задачами, тогда на помощь могут прийти архитектурный комитет, который будет помогать рассматривать и принимать решения. Так же моет потребоваться дробление обязанностей архитектора и введение новых ролей (дата-архитектор, архитектор сетей, …)
Получился большой список и каждая практика требует значительных ресурсов как на внедрение, так и на поддержание нового процесса! Стоит добавлять их только по мере необходимости и всегда взвешивать пользу и затрачиваемые ресурсы. Так мы в свое время ввели, а потом отказались от архитектурного комитета, когда он решил поставленные задачи и перестал приносить ощутимую пользу. Не исключаю, что в будущем с ростом системы он снова станет необходим и мы его вернем.
Разработку ПО и управление командами разбираю в своем Telegram канале. Буду рад вашим вопросам!