В октябре 2022 года The Open Group официально выпустил Open Agile Architecture™ (O‑AA) — новую версию стандарта, призванного соединить мир «классической» корпоративной архитектуры с реалиями Agile, DevOps и цифровой трансформации. Первая версия документа была опубликована Open Group еще в 2020 году.
Если вы корпоративный архитектор, архитектор решения, бизнес‑ или системный аналитик, и до сих пор считали, что Agile — это «про разработчиков», а архитектура это «про рисунки и бумажки», эта статья для вас. Задача данной статьи, дать краткое содержание стандарта Open Agile Architecture, для того, чтобы вы решили нужно ли его вам изучить подробнее или нет.
Почему появился Open Agile Architecture?
Большинство из нас знают плюсы и минусы TOGAF, знают об этом и в Open Group. TOGAF и ArchiMate, несмотря на мощь, воспринимаются как «тяжёлые» и «проектные» фреймворки, а не «продуктовые». Рынок и бизнес требуют гибкости, при этом гибкость без понимания целевой архитектуры очень скоро превращается в хаос. Поэтому стандарт Open Agile Architecture не возник на пустом месте — это ответ на вызовы времени, ведь компании проходят одновременно цифровую и Agile‑трансформацию, в рамках которых архитекторы всё чаще слышат: «Зачем нам всё это, если мы работаем в двухнедельных спринтах?».
Цифровая трансформация и Agile уже давно не просто модные слова, они стали стратегическими приоритетами для большинства компаний. При этом корпоративная архитектура часто не обладает достаточной степенью гибкости, в результате бизнес получает либо «гибкую анархию» с высокими рисками и стоимостью, либо «твердую архитектуру», которая тормозит инновации.
Open Agile Architecture разработан как независимый стандарт, но создан с учётом совместимости с TOGAF и другими фреймворками. Цель стандарта O‑AA интегрировать принципы Agile разработки с архитектурой предприятия (Enterprise Architecture, EA).
Основные принципы Open Agile Architecture
Стандарт O‑AA базируется на идее, что архитектура — это не препятствие для скорости, а средство её обеспечения, и рамках этого предлагаются следующие подходы:
Гибкая методология создания, развития и поддержки архитектуры.
Снижение бюрократии и увеличение вовлеченности команд.
Фокусировка на быстрых, инкрементальных изменениях и адаптации.
Стандарт O‑AA — это попытка примирить Intentional Architecture (м.б. перевести как преднамеренную, плановую или целевую) архитектуру с Emergent Architecture (м.б. перевести как развивающуюся, возникающую или эволюционирующую), возникающую в самоорганизующихся командах. Стандарт O‑AA — не революция, а эволюционный шаг, и главная мысль стандарта в том, что архитектура не должна тормозить Agile, она должна его направлять.
Если совсем кратко, то архитектура в O‑AA‑ это не про рисунки, а про решения, и особенно — про то, как эти решения согласуются между бизнесом, командами и технологиями. При этом акцент делается на создание бизнес‑ценности, упрощении архитектуры, гибкости и ориентации на клиента. Сразу нужно отметить, что стандарт не является пошаговым руководством, это скорее структурированный обзор того, что важно в современной архитектуре.
Обзор стандарта O‑AA
O‑AA состоит из двух частей:
Ядро O‑AA (Core) — философия, принципы, концепции, ценности.
Строительные блоки O‑AA (Building Blocks) — практики, подходы, техники.
В первой части описываются фундаментальные принципы и ценности, который направляют архитекторов при построении Agile‑архитектуры. Во второй части описываются инструменты, необходимые для архитектурной работы.
В стандарте O‑AA утверждается, что любая крупная компания сегодня живёт в двух измерениях:
Digital Transformation — как мы используем технологии для создания ценности.
Agile Transformation — как мы организуем работу, чтобы быстро реагировать на изменения.
При этом стандарт предлагает р��ссматривать организацию через три «слоя»:
1. Experience
Клиентский опыт, точки контакта
Customer Journey, Touchpoints
2. Work System
Операционная модель, процессы
Value Streams, Capabilities
3. Technical System
IT‑ландшафт, инфраструктура
Микросервисы, Event‑Driven Architecture
Также описываются базовые элементы, на которых строится вся Agile‑архитектура:
Agile Architecture Vision — стратегическое видение, общее понимание чего хочет достичь архитектура.
Architecture Backlog — динамично управляемый список архитектурных задач и инициатив, приоритизированный в соответствии с бизнес‑целями.
Incremental Design — подход к проектированию архитектуры маленькими шагами, с регулярными проверками и корректировками.
Collaboration — активное взаимодействие всех заинтересованных сторон (архитекторов, разработчиков, бизнес‑заказчиков).
При этом стандарт O‑AA придерживается продуктового подхода:
Архитектура решения (Solution Architecture) строится не под проект, а под продукт или портфель продуктов.
При этом архитектура — это живой артефакт, который развивается итеративно, а не разрабатывается раз в пять лет.
Также можно отметить фокус на бизнес‑архитектуру:
Описывается важность организационный дизайна и топологии команд, и утверждается, что структура команд влияет на архитектуру. Стандарт опирается на закон Конвея, согласно которому структура команд влияет на архитектуру систем — и наоборот«. »
O‑AA предлагает использовать архитектурные шаблоны, как проверенные, повторяемые решения для часто возникающих проблем. Основные шаблоны включают:
Microservices Architecture: модульная архитектура, где приложения разбиваются на независимые сервисы с четкими интерфейсами, что облегчает масштабирование и независимое развитие.
Event‑Driven Architecture: модели взаимодействия между компонентами через события, что повышает реактивность и снижает связность.
Domain‑Driven Design: фокус на бизнес‑логике и области применения, с целью лучшего отражения бизнес‑потребностей в архитектуре.
Содержание стандарта по разделам
Введение
Определения
Часть 1: Ядро O‑AAДвойное преобразование (A Dual Transformation)
Разработка архитектуры (Architecture Development)
Преднамеренная архитектура (Intentional Architecture)
Непрерывный архитектурный рефакторинг (Continuous Architectural Refactoring)
Проектирование гибкой трансформации (Architecting the Agile Transformation)
Гибкое управление (Agile Governance)
Аксиомы для практики гибкой архитектуры (Axioms for the Practice of Agile Architecture)
Часть 2: Строительные блоки O‑AAОбзор строительных блоков (Building Blocks Overview)
Гибкая стратегия (Agile Strategy)
Гибкая организация (Agile Organization)
Опыт проектирования (Experience Design)
Архитектура продукта (Product Architecture)
Составление карты пути клиента (Journey Mapping)
Отображение бережливого потока создания ценности (Lean Value Stream Mapping)
Архитектура операций (Operations Architecture)
Информация о данных и искусственный интеллект (Data Information and Artificial Intelligence)
Event Storming
Domain‑Driven Design: Strategic Patterns
Архитектура программного обеспечения (Software Architecture)
Программно‑определяемая инфраструктура (Software Defined Infrastructure)
Ограничения стандарта O‑AA
В отличие от TOGAF или ArchiMate, O‑AA не задаёт строгую модель понятий. Нет единой схемы «что с чем связано». Это плюс (гибкость) и минус (неоднозначность).
Вы не найдёте здесь «как настроить Event‑Driven архитектуру за 5 шагов». Как всегда — это не учебник, а навигатор.
Противопоставления Agile против Architecture, авторы подчёркивают: нет конфликта, есть задача — синхронизировать оба мира.
Главные идеи, которые можно выделить по результатам анализа
Архитектура — это не документ, а живой процесс. Она развивается через непрерывный рефакторинг, автоматизированные проверки соответствия архитектуры целям («fitness functions») и ограничения (guardrails).
Организация должна синхронизировать архитектуру с организационным уровнем. Если вы строите микросервисы, но у вас монолитные команды — то будут проблемы.
Управление это про делегирование ответственности. Agile governance фокусируется на прозрачности решений, а не на контроле через отчеты.
Продукт — это не только софт. Это сочетание сервиса, опыта, процессов и многого другого (качественных характеристик: надежность, безопасность, ма��штабируемость и так далее).
Стоит ли читать O‑AA?
Да — если вы:
Enterprise‑архитектор, уставший от «бумажной» архитектуры.
Solution‑архитектор, работающий в продуктовой среде.
Бизнес‑аналитик, участвующий в трансформациях.
Руководитель, который хочет понять, как связать IT‑стратегию с операционной гибкостью.
Нет — если вы ищете:
Готовую методику внедрения.
Альтернативу TOGAF (O‑AA дополняет, не заменяет).
Заключение
По мне, так стандарт полезен, он все же он ближе к жизни, чем TOGAF, и отражает текущее состояние корпоративной архитектуры, где границы между бизнесом, людьми и технологиями стираются, а корпоративный архитектор выходит из «башни из слоновой кости» и становится синхронизатором согласованности организации.
Open Agile Architecture — это не «ещё один метод», это попытка построить мост между двумя мирами: гибкости и устойчивости, экспериментов и масштаба, бизнеса и технологий. TOGAF предоставляет структуру и методы (Architecture Development Method, ADM), а O‑AA предлагает гибкие принципы и тактики, которые делают ADM более адаптивным и итеративным. Однако стандарт не содержит подробных инструкций по интеграции O‑AA и TOGAF на практике.
Стандарт доступен бесплатно на сайте The Open Group, но только после регистрации (и лучше с почтой на домен com).
Если хочется не только экспериментировать с гибкой архитектурой, но и выстроить системный взгляд на предприятие, обратите внимание на курс OTUS «Enterprise Architect». В нём разбирают TOGAF, ArchiMate и практику цифровой трансформации так, чтобы потом собрать свою «карту изменений» для компании и принимать более взвешенные архитектурные решения.
Если хотите понять формат обучения — записывайтесь на бесплатные демо-уроки от преподавателей курса:
9 декабря. Карта способности, как инструмент планирования и приоритезации инициатив. Записаться
15 декабря. Влияние развития технологий AI на корпоративную архитектуру. Записаться
