Гибкая Архитектура в SAFe

15 февраля 2023

«Одновременно с принятием спонтанного подхода в создании дизайна и разработке системы, небольшой объем планирования может помочь избежать больших потерь.»

James O. Coplien, Lean Architecture
James O. Coplien, Lean Architecture

Гибкая Архитектура

Что такое Гибкая (Agile) Архитектура?

Гибкая (Agile) архитектура — это набор ценностей, практик и совместных действий, которые поддерживают активный, эволюционный дизайн и архитектуру системы. Этот подход объединяется с DevOps мышлением, что с течением времени позволяет архитектуре системы постоянно развиваться и одновременно с этим поддерживать потребности текущих пользователей.

Развитие параллельно с поддержкой текущих потребностей помогает избежать накладных расходов и задержек, связанных с концепцией старт-стоп-старт и потребностью крупномасштабного редизайна, присущего процессам с жестко определенными этапами (фазовыми воротами) и исчерпывающей предварительной проработкой всего дизайна (Big Up Front Design, BUFD).

Agile архитектура поддерживает методы Agile разработки с помощью совместной работы, простоты дизайна, а также обеспечивая баланс между новым, возникающим (эмерджентным) дизайном и архитектурными намерениями. Как и методы гибкой разработки, Agile архитектура делает возможным разработку дизайна для обеспечения тестируемости, развёртывания и выпуска.

Гибкая архитектура также поддерживается быстрым прототипированием, моделированием предметной области (доменным моделированием) и децентрализованными инновациями.

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

«Доставка ценности в кратчайшие устойчивые сроки» означает, что сроки доставки должны быть не просто кратчайшие, но которые могут многократно демонстрироваться внутри потока ценности без вреда для качества, содержания, самого потока ценности включая людей и организации.»

Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры
Алексей Ионов, Executive Lean-Agile коуч, Ионов и Партнеры

Agile архитекторы управляют этим процессом, поддерживая «ровно столько» архитектурного русла, сколько требуется для поддержки растущих потребностей бизнеса. Они постоянно инвестируют в модернизацию унаследованных устаревающих (legacy) технологий и знают, где провести рефакторинг, чтобы устранить узкие места. Архитекторы транслируют необходимость выполнения текущих технических задач в понятных для бизнеса терминах.

Чтобы поддержать непрерывный поток ценности через конвейер непрерывной доставки, гибкая архитектура:

  • Развивается с течением времени, поддерживая потребности текущих пользователей
  • Избегает накладных расходов и задержек, связанных с фазовыми воротами и BUFD-методами
  • Гарантирует, что «система всегда работает» (без перерывов в доступности)
  • Уравновешивает спонтанно-возникающий (эмерджентный) дизайн и целенаправленность архитектурных намерений
  • Использует системный подход на уровне всего потока ценности

В основе практик Agile архитектуры лежат Lean-Agile Принципы SAFe. Хотя все принципы применимы, три из них особенно актуальны для архитектуры. Прежде чем приступить к конкретному проекту, Agile архитекторы используют быстрые циклы обучения (принцип No 4) для изучения альтернатив (принцип No 3) и нахождения оптимального решения. Они также создают среду для децентрализованного принятия решений (принцип No 9), определяя и сообщая архитектурное видение и стратегию, а затем взаимодействуя с командами, которые разрабатывают решение, и выступая для них в роли коуча.

Роли и Взаимодействия Agile Архитекторов

SAFe выделяет три роли для архитекторов в организации: Архитектор Предприятия, Архитектор Решения и Архитектор Систем. Каждый из них отвечает за решение задач на соответствующем уровне: Портфель, Крупное Решение и Поезд (Базовый уровень). Эти три роли регулярно взаимодействуют на своих уровнях и между ними для обеспечения согласованности в действиях и решения проблем по мере их возникновения.

Как показано на рисунке 1, все три роли должны обладать архитектурными навыками, необходимыми для принятия технических решений. Таким образом, любая роль Архитектора может выполняться не одним человеком, а группой людей. Это позволяет обеспечить достаточные знания в архитектурной группе и предотвратить появление узких мест при поддержке команд со стороны архитектуры.

Рисунок 1. Роли Архитекторов в SAFe охватывают архитектурные домены

 Бизнес-стратегия и техническая стратегия взаимозависимы. Поэтому для реализации целей организации необходимо  взаимодействие между архитекторами и другими ролями SAFe. Это позволит обеспечить соответствие архитектуры текущим и будущим потребностям бизнеса и клиентов, которых она обслуживает. В рамках Agile Release Train Архитекторы Систем выстраивают техническое развитие с помощью Архитектурного Русла, нефункциональных требований (НФТ, NFR), а также c помощью создания дизайна конвейера непрерывной доставки (Continuous Delivery Pipeline, CDP) и его поддержки с течением времени. Архитектура также обеспечивает встроенное качество.

Команда Системы реализует архитектурное видение, создавая поддерживающую инфраструктуру, которая позволяет Agile командам проектировать, разрабатывать, тестировать и доставлять ценность. Архитекторы Систем координируют свои действия с Архитекторами Предприятия и Архитекторами Решения, чтобы обеспечить соответствие своих решений более широкому видению. Наконец, архитекторы в любой роли также являются Lean-Agile лидерами, ответственными за наставничество команд и развитие потенциала участников создания ценности в целом.

Уравновешивание архитектурных намерений и возникающего дизайна

Традиционные архитектурные подходы требуют серьёзной проработки архитектуры на ранних стадиях разработки. В результате этого появляются обильная документация и непроверенные решения. Альтернативным методом проектирования архитектуры является сочетание целенаправленности архитектурных намерений и возникающего дизайна. Такой подход лучше соответствует потребностям бизнеса. Гибкая архитектура уравновешивает целенаправленность и «появление нового»:

  • Архитектурные намерения (Intentional architecture) — определяют набор целенаправленных, запланированных архитектурных стратегий и инициатив, которые улучшают проектирование, производительность и удобство использования решения. Архитектурные намерения также включают в себя рекомендации, как распределить проектирование между командами и как синхронизировать работу.
  • Возникающий дизайн (растущий или развивающийся дизайн, emergent design) — обеспечивает техническую основу для полностью эволюционного и поэтапного подхода к реализации. Это помогает разработчикам и дизайнерам реагировать на насущные потребности пользователей, позволяя дизайну развиваться по мере создания и развёртывания системы.

При таком балансе Agile архитектура представляет собой Lean-Agile подход к созданию сложных и комплексных корпоративных решений. Гибкая архитектура поддерживает текущие потребности пользователей, одновременно развивая систему для удовлетворения интересов клиентов в будущем. Используемые вместе, возникающий дизайн и архитектурные намерения постоянно строят и расширяют архитектурное русло, которое обеспечивает техническую основу для разработки бизнес-ценности в будущем.

Архитектура для DevOps и Выпуска по Требованию

Гибкая архитектура способствует развитию культуры DevOps, гарантируя, что Решения спроектированы для непрерывной доставки. Архитекторы участвуют в проектировании (дизайне) и реализации Конвейера Непрерывной Доставки, а также продвигают и показывают на примерах применение принципов CALMR в SAFe. Таким образом, архитекторы способствуют появлению решений с помощью определения минимально жизнеспособной («минимально достаточной») архитектуры.

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

Для поддержки непрерывного развёртывания гибкая архитектура отделяет развёртывание от выпуска. Функциональные возможности развертываются в рабочей среде непрерывно, но открываются для эксплуатации конечным пользователям только по требованию. Частые развёртывания укрепляют доверие к Конвейеру Непрерывной Доставки (Continuous Delivery Pipeline, CDP) и уменьшают задержки, вызванные более традиционными методами управления (например, управление выпусками). Это доверие позволяет отдельным командам и поездам (Agile Release Train, ART) в целом независимо исследовать и тестировать идеи в настоящей производственной среде.

Конвейер непрерывной доставки (CDP) начинается и заканчивается гипотезой ценности. На шаге «Непрерывное Исследование» (Continuous Exploration) она определяется, а уже на шаге «Выпуск по Требованию» (Release on Demand) измеряется. Архитектура системы обеспечивает необходимую телеметрию для измерения гипотез. Это позволяет командам и Agile Release Train вести учёт инноваций (innovation accounting) и других данных об использовании для проверки своих предположений.

Agile архитектура также поддерживает Конвейер Непрерывной Доставки, рассматривая другие факторы системы как полноценные архитектурные задачи, такие как архитектура тестирования и управление тестовыми данными.

Со-направленность архитектуры с бизнес-ценностью

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

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

Рисунок 2. Системы, сопровождающие размещение заказа клиента и его доставку.

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

Разработка Видения Решения, Интента Решения, Дорожных Карт

Со-направленность архитектуры с бизнес-стратегией ускоряет достижение поставленных бизнес-целей. Архитекторы реализуют задачи бизнеса, переводя стратегию из стратегических тем в решения. Видение Решения, Контекст Решения и Интент Решения определяют создание самого решения. Интент Решения (Solution Intent) включает принятые решения, шаблоны, модели и другую техническую информацию, которая служит минимально достаточной документацией. Solution Intent также содержит ограничения дизайна, включая нефункциональные требования (NFR).

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

Дорожная карта управляет беклогом. Беклог в свою очередь определяет всю работу, которую выполняет Agile Release Train. Архитекторы совместно с Менеджментом Продукта расставляют приоритеты и определяют баланс между разработкой новой функциональности и выполнением технической работы. Архитекторы заранее оценивают ожидаемое негативное влияние технического долга на непрерывность потока доставки ценности (Принцип SAFe #6 — Обеспечить непрерывный поток ценности) и необходимых потребностях архитектурного русла. На основе этой оценки архитекторы со своей стороны обосновывают приоритизацию работ.

Расстановка приоритетов у Фич и Энейблеров для PI Планирования

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

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

Кроме этого, Архитекторы работают с техническими зависимостями за пределами своего Релизного Поезда (Agile Release Train) в рамках Поезда Решения или с другими Agile Release Train в организации. Архитекторы играют ключевую роль в этой координационной деятельности. На мероприятии «PI Планирование» они взаимодействуют с командами и помогают им принимать необходимые решения и корректировки, чтобы уменьшить количество зависимостей между ними.

Координация Agile архитектуры во время PI Планирования

На мероприятии «PI Планирование» архитекторы поддерживают команды, создающие планы на следующий интервал. Выступление архитекторов с вводной презентацией по архитектуре является частью программы PI Планирования. Далее, когда во время прорывов команды приступают к разработке своих планов на интервал, архитекторы курсируют между командами, переходя от одной команде к другой. Это помогает архитекторам убедиться, что команды правильно планируют техническую работу. Кроме этого, они следят за тем, чтобы команды правильно учитывали работу над энейблерами. В рамках прорывов архитекторы помогают решать возникающие сложности и отвечают на вопросы Agile команд.

Во время PI Планирования Архитекторы также участвуют в Обзоре со стороны Менеджмента для решения архитектурных и технических вопросов, связанных с потенциальными корректировками. Они также присоединяются к Владельцам Бизнеса в процессе присвоении ценности целям команд (Team PI Objectives) на Интервал Планирования (Planning Interval, PI). Архитекторы объясняют Владельцам Бизнеса на языке бизнеса, как энейблеры и другая техническая работа влияют на реализацию общих целей, и лоббируют необходимость и важность их выполнения.

Поддержка Непрерывной Доставки

Применение Agile архитектуры играют важную роль для поддержки Релизных Поездов и Поездов Решения при разработке Энейблеров. Поэтому именно архитекторы направляют работу команд в процессе их разработки. Например, архитекторы могут посещать такие мероприятия, как «Планирование Итерации» на уровне команд и «Демонстрация Системы» на уровне всего ART, чтобы отслеживать прогресс выполнения архитектурных работ, решать возникающие проблемы и корректировать направление разработки.

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

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

Для крупных решений важную роль играет мероприятие для синхронизации Архитекторов — Architect Sync. Это событие позволяет архитекторам быть в курсе тактических и стратегических вопросов относительно бизнеса организации и архитектуры, а также обмениваться информацией о прогрессе в достижении поставленных целей на уровне Крупного Решения, как показано на рисунке 3.

 

Рисунок 3. Синхронизация архитекторов (ArchitectSync) происходит во время выполнения Интервала Планирования на уровне Поезда Решения

Поддержка новых стратегических тем и потоков создания ценности

Архитектура должна развиваться, чтобы соответствовать меняющимся потребностям и возможностям бизнеса. В противном случае технология становится узким местом при реализации бизнес-задач. Изменения в бизнес-стратегии отражаются в новых или модифицированных стратегических темах. С помощью Канвы портфеля стратегические темы переводятся в новые или скорректированные решения и/или потоки ценности. Архитекторы Предприятия поддерживают и влияют на этот процесс, предоставляя вводные данные, посещая мастерские «Картирование Потока Создания Ценности» (Value Stream Mapping (VSM) workshop) и формируя ожидания относительно выполнимости решений с точки зрения технологий. Как только новое направление определено, Архитекторы Предприятия работают совместно с Архитекторами Систем и Архитекторами Решений над реализацией нового направления бизнеса. Они сообщают о новой стратегии и показывают, как она меняет видение, интент и дорожную карту Решения.

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

Роль Архитектора в Lean-Agile трансформации

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

Архитекторы являются Lean-Agile лидерами и демонстрируют на собственном примере Lean-Agile способы мышления и операционной деятельности. Таким образом, разработчики учатся на их примере, а сами архитекторы выступают в роли коуча и поощряют применение новых моделей поведения у других. Архитекторы обеспечивают автономию и стимулируют совершенствование и развитие сотрудников. Это позволяет расширить базу знаний и навыки в сообществе разработчиков. Архитекторы SAFe на своём примере показывают новые подходы в работе, участвуют в создании дорожной карты трансформации организации и помогают ускорить внедрение изменений в роли Lean-Agile лидеров.

Статья подготовлена по материалам Scaled Agile, Inc. и не является официальным переводом статьи «Agile Architecture in SAFe». Статья обновлена 27.02.2023.

Обучение для Архитекторов

В портфолио тренингов SAFe есть специализированный продвинутый тренинг для архитекторов — SAFe for Architects.

Архитекторам часто сложно перестроить свою работу на гибкие подходы, так как в Agile подходах и сама архитектура и процесс архитектуры строятся на других принципах. SAFe for Architects затрагивает все аспекты работы архитекторов в SAFe: Enterprise, Solution, System.

В программе обучения много практической информации, которая дает ответы на важные вопросы: как координировать потоки доставки ценности, как выравнивать архитектурный уровень внутри компании, как договариваться с бизнесом об архитектурных инвестициях.

Тренинг помогает хорошо разобраться в использовании конфигурации SAFe «Крупное Решение» (Large Solution), а также содержит уникальную информацию, отсутствующую в других источниках.

После успешной сдачи экзамена участники получают международный сертификат SAFe® Architect (ARCH).

Подробная информация о курсе SAFe for Architects

Другие статьи в блоге

Дисциплины SAFe
В статье приведены дисциплины SAFe и основные компетенции внутри них, которые SAFe выделяет на данный момент.
Использование ИИ для каждой роли в SAFe
Искусственный интеллект (ИИ) может существенно улучшить работу каждой роли SAFe. В статье рассматриваются варианты использования ИИ для повышения эффективности отдельных ролей SAFe.
Изменения в SAFe
Scaled Agile, Inc. анонсировали изменения во фреймворке для еще более эффективного решения бизнес-задач организаций.

Подпишитесь на нашу рассылку и получайте новости и информацию о мероприятиях первыми!