Архитектор Систем (System Architect)

Архитектор Систем отвечает за определение и коммуникацию единого технического и архитектурного видения для решения, которое разрабатывает Agile Release Train. Это помогает со-направить команды внутри Agile Release Train и обеспечить, что разработка решения или системы движется в правильном направлении в соответствии со стратегией.

Архитекторы Систем сотрудничают со своими командами, чтобы:

• Разработать архитектуру системы
• Проверить технологические гипотезы
• Оценить альтернативные варианты реализации
• Создать Конвейер Непрерывной Доставки (Continuous Delivery Pipeline)

В Релизных Поездах (Agile Release Trains, ART), не входящих в состав Поезда Решения (Solution Train), Архитекторы Систем также выполняют многие обязанности Архитекторов Решения.

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

С кем сотрудничают Архитекторы Систем?

Архитектура системы существенно влияет на решение, команды, которые его разрабатывают, и на экосистему организации в целом. Следовательно, важнейшей обязанностью Архитектора Систем является сотрудничество с различными ролями, командами и заинтересованными лицами внутри и за пределами Agile Release Train.

Основная цель этих взаимодействий заключается в том, чтобы гарантировать, что ART развивает архитектуру системы, которая поддерживает растущие потребности бизнеса и способствует быстрой и надежной реализации новых решений. Основные взаимодействия Архитектора Систем показаны на рисунке 1.

Рисунок 1. Основные взаимодействия Архитектора Систем

• RTE и Менеджмент Продукта (управление движением ART)
  Менеджмент Продукта определяет бизнес-приоритеты, Архитектор следит за тем, чтобы архитектура соответствовала потребностям бизнес-решений и дает необходимые рекомендации поезду с технической точки зрения, а RTE отвечает за основные процессы реализации решения со стороны Релизного Поезда (Agile Release Train, ART).
• Архитектор Предприятия и Архитектор Решения (выравнивание относительно Архитектуры Решения/Предприятия)
  Архитектор Систем взаимодействует с Архитектором Предприятия и обеспечивает, что ART выполняет работу в соответствии с технологическим ландшафтом организации. Если поезд работает над более крупным решением, в котором участвуют другие ART и поставщики, Архитектор Систем взаимодействует с Архитектором Решения (а также с другими Архитекторами Систем из Поезда Решения): определение и поддержка реализации Энейблеров, выбор и использование технологий, соответствие нормативным требованиям, стандартам и нефункциональным требованиям более высокого уровня (NFR).
• Agile Команды (развитие Архитектуры Систем)
  Архитектор Систем регулярно взаимодействует с Agile командами, чтобы обеспечить, что дизайн системы развивается в соответствии с общим архитектурным намерением и практическим применением решения.
• Команда Системы и Общие Сервисы
  — Цель взаимодействия с Командой Системы — создание оптимальных архитектур и процессов для интеграции и тестирования системы. Часто Команда Системы принимает активное участие в разработке критически важных архитектурных элементов, что приводит к активной совместной работе с Архитектором Систем.
  — В зависимости от контекста взаимодействие с Общими Сервисами может включать в себя: помощь в проектировании конвейера развертывания, разработке информационной архитектуры, обеспечении соответствия нормативным требованиям, информационной безопасности и т.д.

Основные обязанности

Обязанности Архитектора Систем состоят из 5 областей, как показано на Рисунке 2.

Рисунок 2. Области ответственности Архитектора Систем

Далее в статье мы рассмотрим каждую из этих областей.

Выравнивание архитектуры в соответствии с бизнес-приоритетами

Основная задача архитектуры решения – поддержка разработки и доставки бизнес-ценности. Архитекторы Систем отвечают за выравнивание архитектуры относительно стратегии бизнеса.

Что входит в эту область ответственности:

• Определение Энейблеров и Архитектурного Русла
  Архитектор Систем формулирует Энейблеры (Фичи и при необходимости Истории), а Релизный Поезд (ART) постепенно строит архитектурное русло для поддержки реализации запланированных фич. Архитектор на постоянной основе определяет, корректирует и поддерживает направление движения поезда. Определение новых Энейблеров и развитие архитектурного русла происходит поступательно, с важными контрольными точками на каждой границе Интервала Планирования (PI).
• Участие в определении решения
  В рамках дизайн-мышления Архитектор Систем часто принимает непосредственное участие в определении Решения. Чтобы идея решения была эффективной, она должна соответствовать реальным технологическим возможностям поезда и возможностям реализации. Архитектор предоставляет необходимую технологическую информацию для определения Решения.
• Определение нефункциональных требований системы
  Архитектор Систем определяет нефункциональные требования (НФТ/NFR) для Решения и обеспечивает, что архитектура будет поддерживать требуемые NFR. Архитекторы Систем также помогают поезду в определении конкретных показателей и необходимых инструментов для защиты и мониторинга NFR.
• Выделение ёмкости для реализации Энейблеров
  Создание архитектурных возможностей требует времени и усилий команд. Во время PI Планирования и при подготовке к каждому Планированию Интервала Архитектор Систем взаимодействует с Менеджментом Продукта, чтобы зарезервировать достаточный объем ёмкости команд для работы над архитектурой.

Определение и коммуникация Архитектурного Видения

Сложность и комплексность современных технологических решений может быть ошеломляющей; Чтобы уменьшить негативное влияние сложности на команды и поддерживать их производительность, архитектор берет на себя важную роль в донесении до команд четкого технологического намерения. Это позволяет со-направить дизайн системы и стратегию реализации, что в конечном итоге приводит к ускорению потока доставки ценности для клиентов.

Что входит в эту область ответственности:

• Представление командам архитектурного видения на мероприятии «PI Планирование»
  Архитектор Систем обновляет архитектурное видение перед каждым Планированием Интервала. В начале PI Планирования Архитектор Систем представляет архитектурное видение и остается доступным для команд на протяжении всего мероприятия. Архитектурное видение постоянно обновляется и учитывает новые и важные технические аспекты, имеющие отношение к предстоящему Интервалу.
• Сопровождение реализации архитектурного видения
  Во время выполнения Интервала Планирования Архитектор Систем синхронизируется с командами и дает рекомендации по мере необходимости. Как правило, первоначальное видение архитектуры изменяется по мере появления новых идей, возникающих в процессе реализации. Архитектор следит за тем, чтобы все проблемы проектирования системы, с которыми сталкиваются команды во время разработки, были решены.
• Обеспечение гибкости архитектуры и возможности внесения изменений (опциональности)
  Чтобы эффективно реагировать на изменения и учитывать новые факты, возникающие в процессе разработки, дизайн системы должен обеспечивать гибкость. К полезным инструментам, позволяющим сохранить опциональность, относятся сбалансированное использование абстракции при проектировании систем и инжиниринг на основе множественного дизайна (Set-based engineering).

Развитие дизайна системы совместно с командами

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

Что входит в эту область ответственности:

• Поддержка проведения архитектурных экспериментов и исследований (спайков)
  Архитектор Систем работает с командами над определением и проведением экспериментов для проверки архитектурных идей с минимальными усилиями по разработке. Это позволяет сократить количество доработок, так как непроверенные архитектурные предположения, которые оказываются неверными, могут быть чрезвычайно дорогостоящими.
• Совместная работа с командами по оптимальному дизайну системы
  Архитектор часто взаимодействует с командами, чтобы предоставить новые вводные данные и получить обратную связь относительно текущего архитектурного намерения. Такое сотрудничество происходит во время следующих мероприятий: PI Планирование, Демонстрация Системы и Инспект-Адапт. При значительной архитектурной разработке Архитектор может участвовать в мероприятиях отдельных команд. Архитектор Систем выступает коучем для команд, помогает им получить более полное представление о дизайне системы и повысить свои знания и навыки в процессе разработки. Для использования единого архитектурного подхода и технологий Архитекторы Систем создают технические сообщества практиков (CoP).
• Выравнивание архитектурного намерения с реалиями реализации
  Архитектор следит за тем, чтобы не было существенного разрыва между ожиданиями, выраженными в архитектурном видении, и реальностью: возможности команды, навыки, инструменты и т. д. Чтобы обеспечить со-направленность на постоянной основе, Архитектор должен поддерживать тесный контакт с командами и организовывать технологические активы. Для этого Архитектор Систем участвует в создании ресурсов решения или обзорах со стороны коллег (peer review). Кроме того, архитектору желательно принимать участие в архитектурных исследованиях, которые проводят команды.

Содействие встраиванию качества и обслуживанию НФТ/NFR

Архитектура во многом определяет, насколько будет легко или сложно реализовать новые фичи решения, поддерживающие стандарты качества для новой функциональности, при этом не нарушая старую. Аналогичным образом, архитектура существенно влияет на способность ART реализовывать и соблюдать нефункциональные требования решения.

Что входит в эту область ответственности:

• Продвижение дизайна системы, поддерживающего встроенное качество
  Архитектор Систем определяет архитектуру, которая помогает ART смещать обучение влево и выявлять проблемы на ранней стадии или изначально предотвращать само их появление. Слабо связанная архитектура, неукоснительное следование стандартам проектирования и кодирования, а также постоянный рефакторинг помогают поддерживать систему в работоспособном состоянии. Это приводит к улучшению тестируемости и сопровождению кода и других ресурсов решения.
• Внимание к нефункциональным требованиям системы
  NFR существенно влияют на жизнеспособность и устойчивость решения. Если им не уделять должного внимания на протяжении всей разработки, они могут привести к большому объему доработок или даже свести на нет всю работу по разработке решения. Архитектор Систем постоянно направляет движение поезда, чтобы помочь инкрементально создавать и поддерживать NFR. Архитектор часто помогает командам в разработке эффективной стратегии реализации новых NFR и помогает создавать стандарты для поддержки существующих.

Поддержка DevOps и Конвейера Непрерывной Доставки (CDP)

Архитектура системы неразрывно связана с доставкой ценности для клиента. Это обусловлено тем, что архитектура может либо сделать доставку ценности быстрым, инкрементальным процессом, который команда и заинтересованные лица могут контролировать, либо «постоянной катастрофой» с непредсказуемыми сроками и тяжелыми последствиями для клиента и бизнеса. Кроме того, структура Конвейера Непрерывной Доставки (CDP) должна наилучшим образом соответствовать потребностям ART.

Что входит в эту область ответственности:

• Участие в управлении процессом релиза
  Архитектор Систем помогает ART разрабатывать архитектуру системы таким образом, чтобы она поддерживала инкрементальную доставку ценности. Кроме того, Архитектор Систем предоставляет ценную информацию для доставки решения с технологической точки зрения и оценивает влияние технологии на конкретный выпуск.
• Поддержка дизайна Конвейера Непрерывной Доставки (CDP)
  Архитекторы Систем продвигают идеи непрерывной доставки и DevOps. Они также помогают командам определить конкретную архитектуру конвейера развертывания, сред, их закупку и необходимые инструменты. В рамках этой работы Архитектор Систем помогает ART определить подходящие конфигурации инфраструктуры. Это часто включает в себя использование облачных архитектур для повышения масштабируемости и гибкости CDP.
• Обеспечение инструментария для измерений (метрик)
  Архитектор Систем содействует дизайну системы, который поддерживает сбор всех необходимых показателей. Для этого нужны специальные платформы и инструменты, подходящие под задачу, и правильная интеграция с решением. Кроме того, Архитекторы Систем часто берут на себя ответственность за поддержку экспериментов и измерение поведения пользователей в LeanUX путем проектирования прототипов или создания определенных возможностей в самом решении.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «System Architect».

Дополнительно почитать:

статья «Гибкая архитектура в SAFe»

статья «Типы Энейблеров в SAFe»

статья «Стратегия построения архитектуры решения»

Обучение:

тренинг «SAFe for Architects»