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

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

James O. Coplien, Lean Architecture

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

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

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

Архитектура системы может либо ускорить, либо затруднить способность организации часто и независимо выпускать инкременты решения для клиентов. 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 Архитекторы Систем выстраивают техническое развитие с помощью Архитектурного Русла, нефункциональных требований, а также дизайн и поддержку конвейера непрерывной доставки (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). Как и все другие требования, NFR постоянно проверяются с помощью автоматизированных тестов для обеспечения качества и соответствия.

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

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

Подготовка архитектуры для PI Планирования

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

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

Координация архитектуры с помощью PI Планирования

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

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

Поддержка Непрерывной Доставки с помощью Выполнения Инкремента Программы

Архитекторы владеют техническими и исследовательскими работами, описанными в Энейблерах на уровнях Программы (Essential/ART) и Решения (Solution). Поэтому именно они направляют работу команд в процессе разработки. Архитекторы могут посещать мероприятия команд «Планирование Итерации» и/или «Обзор Итерации», чтобы отслеживать прогресс выполнения работ, решать проблемы и корректировать направление. Они также обычно выступают в роли коучей и наставников для команд. Это помогает командам быстро решать возникающие проблемы и оперативно получать ответы на технические вопросы. В результате архитектура не становится узким местом в доставке ценности.

Архитекторы следят за тем, что каждый инкремент команды демонстрируют результаты своей работы, включая новые знания, уточнения архитектурного русла и любые дополнения к конвейеру непрерывной доставки. Для крупных решений важную роль играет мероприятие для синхронизации Архитекторов — 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».

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

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

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

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

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

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

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