Введение: где теряется ценность архитектуры

Многие компании в процессе своего развития успешно осваивают начальные этапы TOGAF ADM: формируют видение, разрабатывают целевые модели, создают планы переходов. Но настоящая ценность архитектуры рождается не на слайдах, а в ежедневной работе ИТ-команд. Именно здесь возникает критический разрыв: хорошие архитектурные артефакты остаются невостребованными, потому что непонятно, как их применять в реальных процессах разработки, тестирования и эксплуатации. Стратегические архитектурные решения (принципы, стандарты, целевые состояния) формализованы, но не оказывают реального влияния на операционную деятельность команд. Причина — отсутствие четких механизмов внедрения этих решений в рабочие процессы.

Этот разрыв преодолевается там, где архитектурное мышление интегрируется с методологией управления ИТ-процессами. Коллаборация компетенций корпоративного архитектора и ИТ-методолога превращает ADM из теоретического цикла в работающий механизм трансформации.

ИТ-методолог - движущая сила центральной фазы ADM

В модели TOGAF есть сквозная фаза, от которой зависит успех всего цикла — управление требованиями (Requirements Management). Именно здесь ИТ-методолог играет ключевую роль.

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

Например, архитектурный принцип «все взаимодействия — через API-шлюз» в руках методолога превращается, помимо прочего, в:

• процедуру регистрации нового API в каталоге;

• определение ответственных ролей за проектирование и документирование требований к API;

• определение производственных артефактов, в рамках которых фиксируются решения по API ответственными ролями;

• внесение изменений в производственные регламенты, политики, стандарты и автоматизированные процессы управления производством..

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

Интересно, что в профессиональном стандарте 07.007 "Специалист по процессному управлению" авторы предполагают, что карьерная лестница такого специалиста ведет на высших уровнях квалификации к роли «процессный методолог» (предпоследняя ступень) и «процессный архитектор» (последняя ступень). Возможно это не случайность и авторы стандарта видели связь архитектурной (хоть в данном случае и процессной архитектуры) и методологической функции. Нужно отметить, что в "родственных" профстандартах бизнес-аналитика и системного аналитика не предусматривается связь с архитектурой на высших квалификационных уровнях (на мой взгляд, это упущение, т.к. роли бизнес-архитектора и системного архитектора являются логичным ростом для данных ролей).

Архитектор - владелец жизненного цикла решений

Традиционный корпоративный архитектор фокусируется на проектировании целевого состояния — фазах развития архитектуры в ADM. Однако его истинное влияние начинается, когда он принимает ответственность за полный жизненный цикл своих решений. Это требует методологического подхода.

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

• как будет управляться жизненный цикл этих сервисов?;

• какие процессы коммуникации между командами потребуются?;

• как обеспечить контроль соблюдения стандартов?

Это смещает фокус архитектора с создания статических артефактов на проектирование динамической системы управления. В контексте ADM это означает глубокую вовлечённость в фазы управления реализацией (Governance) и управления изменениями (Change Management). Архитектор определяет не только «что» нужно контролировать, но и «какие механизмы» для этого использовать, часто опираясь на компетенции методолога.

Симбиоз. Архитектор и методолог или архитектор-методолог

Взаимодействие архитектора и методолога — это не последовательная передача задач, а параллельная совместная работа на протяжении всего ADM-цикла.

Архитектор приносит в этот тандем стратегический контекст, понимание бизнес-целей и системное видение. Он отвечает на вопросы «зачем» и «куда». Методолог привносит операционную дисциплину, знание инструментов и умение проектировать рабочие процедуры. Он отвечает на вопрос «каким образом».

Их совместная работа создаёт эффект:

• архитектура становится исполнимой: каждое решение сразу получает «инструкцию по применению» в виде процесса или регламента;

• ИТ-процессы становятся стратегическими: они проектируются не для точечной оптимизации, а как часть реализации общего архитектурного видения;

• управление требованиями становится практическим инструментом, а не бюрократической формальностью.

На практике это может воплощаться в двух форматах. Как тесный тандем двух специалистов в рамках архитектурной команды, где один отвечает за содержание архитектуры, а другой — за механизмы её внедрения. Либо как единая роль архитектора-методолога — особенно эффективная в agile-средах, где нужна скорость и end-to-end ответственность за результат.

Заключение. От разрыва к замкнутому кругу

Ключевой вывод прост: архитектура, не воплощённая в процессах, остаётся теоретической. Процессы, не выстроенные в архитектурном контексте, ведут к локальной оптимизации и созданию новых проблем. При этом, разрыв между архитектурой и операционными процессами — ключевой риск для масштабирования ИТ.

Интеграция методологической компетенции в архитектурную практику является инструментом, который замыкает ADM-цикл и превращает его в работающий контур управления, где успех определяется способностью использовать в качестве базы архитектурные артефакты в рамках формализованных, измеримых и автоматизированных производственных ИТ-процессов. Именно это превращает архитектуру из теоретической дисциплины в практический инструмент управления эффективностью ИТ.

Спасибо, что прочитали до конца. Про архитектуру, методологию и анализ (и не только) я недавно завёл тематический телеграм-канал. Если интересно - заходите, читайте и принимайте участие в обсуждениях: https://t.me/arma_frame, буду рад вас видеть.