Введение: почему архитектура работает «в стол»

В своей практике я часто вижу одну и ту же проблему. Корпоративные архитекторы проектируют схемы целевой архитектуры (в лучшем случае — в репозитории в ArchiMate, но чаще просто в PowerPoint) , Solution и Software-архитекторы принимают тактические решения, а итоговая архитектура реализованного решения всё равно «плывёт» и не соответствует задуманному.

Стратегия остаётся слайдами в PowerPoint. Принципы — просто слова на виртуальной доске. Команды разрабатывают «как удобно» (или «как быстрее), а не «как задумано».

Почему так происходит? Потому что между стратегией и реализацией есть разрыв, т.к. между ролями участников ИТ-производства нет чётких процессов взаимодействия на уровне конкретных объектов управления и зон ответственности. Преодоление этого разрыва — зона ответственности архитектора-методолога.

В этой статье я разберу несколько ключевых концепций, которые помогают этот разрыв закрыть: Discovery и Delivery, TOGAF ADM и Change Management. А в финале покажу, как они агрегируются в IT-Governance — и почему архитектор-методолог (такую роль можно встретить очень редко в виде чётко сформулированного запроса) находится в центре этого агрегатора.

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

Данная статья в бОльшей мере теоретическая, при этом её можно воспринимать в качестве продолжения статей, где были приведены практические материалы и схемы:

https://habr.com/ru/articles/976934/ (Роль, оживляющая архитектуру: почему именно методолог должен замыкать ADM-цикл TOGAF);

https://habr.com/ru/articles/965318/ (Избавляемся от хаоса в проектировании ИТ-решений: формируем команду с помощью ArchiMate);

https://habr.com/ru/articles/953794/ (Исполняем желания заказчика: бизнес-требования на автоматизацию и их связь с корпоративной архитектурой организации).

Часть 1. Discovery — зона ответственности корпоративного архитектора

Discovery — это процесс исследования, поиска проблем и проверки гипотез. Он отвечает на вопрос: «НАДО ли делать?» и «ЧТО делать?».

Корпоративный архитектор (enterprise architect, EA) работает именно в этом пространстве неопределённости. Его задачи:

• исследовать бизнес-способности компании (про этот инструмент писал здесь https://habr.com/ru/articles/959556/), стратегические цели, рыночный контекст;

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

• формировать целевую архитектуру (target architecture), принципы и стандарты;

• оценивать жизнеспособность (viability) и техническую реализуемость (feasibility) крупных инициатив;

• создавать «архитектурный бэклог» — что нужно сделать для перехода из текущего состояния в целевое

Результат: стратегические документы, карты способностей, архитектурные принципы, дорожные карты, схемы целевых архитектур, и т.п. Если на этом всё заканчивается, архитектура остаётся «слайдами в PowerPoint». Решения не доходят до разработки, принципы не соблюдаются.

Часть 2. Delivery — зона ответственности solution-архитектора

Delivery — это процесс разработки, реализации и поставки ценности. Он отвечает на вопрос: «КАК сделать?».

Solution-архитектор (solution architect, SolA) работает в пространстве конкретной реализации. Его задачи:

• проектировать конкретную архитектуру для конкретной задачи или продукта;

• разбивать архитектурный бэклог на реализуемые куски;

• выбирать технологии, паттерны, определять интеграции;

• обеспечивать, чтобы команды разработки двигались в едином техническом русле;

• отвечать за реализуемость, тестируемость и поддерживаемость решения.

Результат: архитектурные схемы (прикладные, как часть постановки задачи на разработку) решений, ADR, технические задания, в некоторых случаях — код (через команды). Если SolA работает в отрыве от стратегии, возникают тактические решения, которые «оптимальны здесь и сейчас», но противоречат общей архитектурной картине.

Часть 3. Разрыв: куда исчезает архитектура?

Между этими двумя «зонами ответственности» — пропасть. В типовой ситуации:

EA выдал стратегию и принципы — SolA получил задачу и спроектировал решение — команды разработки его реализовали — через полгода выясняется, что реальная архитектура системы не имеет ничего общего с целевой.

Почему так происходит? Потому что никто не ответил на вопросы (этот список может быть гораздо длиннее):

• как архитектурный бэклог превращается в задачи для команд?

• где определены роли и зоны ответственности, а также артефакты проектирования?

• как проверяется соответствие реализации целевой архитектуре?

• кто и когда принимает решение об отклонении от архитектурных принципов?

• как архитектурные решения документируются и доводятся до команд?

• как измерить, соблюдается ли архитектура в ежедневной работе?

Часть 4. TOGAF ADM Phase H — управление архитектурными объектами

TOGAF ADM (The Open Group Architecture Framework — Architecture Development Method) — это стандарт разработки архитектуры. Его финальная фаза, Phase H (Architecture Change Management), устанавливает процедуры для управления изменениями в уже реализованной архитектуре.

Phase H отвечает на вопрос «Что меняется?» в в части архитектуры, например:

объекты управления: архитектурные артефакты: принципы, стандарты, компоненты, интеграции, технологии, целевая архитектура;

процессы: классификация изменений (simplification, incremental, re-architecting), управление через Architecture Board, мониторинг соответствия;

выходы: решение «обновить документацию», «запустить новый цикл ADM», «отклонить запрос»;

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

Это инженерный, формализованный подход. Он работает с объектами, которые можно нарисовать, задокументировать, измерить.

Часть 5. Change Management (OCM) — выравнивание смыслов

Change Management (Organizational Change Management) — это дисциплина об управлении человеческим фактором изменений. Её цель — помочь людям адаптироваться к новым процессам, ролям и технологиям.

OCM отвечает на вопрос «Как сделать, чтобы люди это приняли?», например:

объекты управления: смыслы, установки, страхи, мотивация, уровень вовлечённости;

процессы: коммуникация, обучение, вовлечение, кооперация, работа с сопротивлением;

выход: люди понимают «зачем», принимают новые правила, действуют в соответствии с изменениями;

метрики: уровень сопротивления, скорость адаптации, качество обратной связи.

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

Часть 6. Связь: объекты vs смыслы

TOGAF и Change Management не конкурируют, а дополняют друг друга. Агрегация двух подходов даёт управляемость архитектурой:

• TOGAF даёт прикладной, конкретный смысл с точки зрения объектов управления; 

• Change Management — обеспечивает работу с этими объектами через выравнивание смыслов в головах исполнителей и участников.

Без первого у нас нет языка и системы координат. Без второго — есть карта, но никто по ней не ходит. TOGAF (архитектура) работает «в стол».

Часть 7. Лучшая практика CM — автоматизация операционных процессов

Здесь появляется ключевое звено. Лучший способ сделать изменения необратимыми — встроить их в операционку через автоматизацию на основе ролевой производственной модели.

Почему это работает:

• снимает когнитивную нагрузку — людям не нужно «помнить» про новые правила — правила уже вшиты в инструмент;

• делает изменения необратимыми — откатиться назад сложнее, если процесс зашит в Jira или CI/CD;

• создаёт единую точку правды — все видят одни и те же статусы, шаги, ответственных.

Пример: вместо того чтобы просить «ребята, не забывайте согласовывать архитектуру», мы:

• создаём в Jira workflow, где задача не может перейти в статус «Ready for Dev», пока не заполнен ADR;

• настраиваем автоматическую проверку: если в репозитории нет ADR-файла, пайплайн не запускается;

• вводим роли: «Архитектор» автоматически подтягивается в assignee на этапе ревью

Это и есть автоматизация Change Management на основе ролевой производственной модели.

Часть 8. IT-Governance, TOGAF, Change Management

Согласно определению Института корпоративного управления ИТ (IT Governance Institute), IT Governance — это «руководство, организационная структура и процессы, обеспечивающие поддержку и развитие стратегий и целей организации за счёт ИТ».

Сформулирую вывод статьи:

База для IT-Governance — это агрегация:

• инженерного подхода TOGAF (как структуры, задающей полное восприятие организации через свою метамодель (например, ArchiMate));

• принципов Change Management (как инструмента, без которого TOGAF работает «в стол», потому что всем без разницы, что там придумали)

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

При автоматизации CM в контексте управления архитектурой нужно, в свою очередь, агрегировать использование классических инструментов бизнес-анализа, таких как BPMN, BABOK, CBOK, с архитектурными инструментами — ArchiMate, репозиторий, а также отраслевые стандарты по архитектурным слоям (например, DAMA-DMBOK «Свод знаний по управлению данными» в качестве основы для управления доменом архитектуры данных).

Заключение: место архитектора-методолога

Архитектор-методолог находится ровно в центре этой базовой для IT-Governance конструкции:

• он владеет объектной моделью — знает, какие артефакты нужны, какие процессы, как это описывается в ArchiMate, BPMN, TOGAF;

• он понимает, что без работы со смыслами эти объекты останутся «мёртвыми» — никто не будет ими пользоваться;

• он переводит изменения с языка «объектов» на язык «смыслов» и обратно. Он говорит:

   — «Вот архитектурный объект, который мы внедряем» (TOGAF, ArchiMate, BPMN);

   — «А вот почему это важно для вас лично и для команды» (Change Management).

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

EA без методолога — стратег без последующей реализации стратегии на практике. SolA без методолога — проектировщик практики без стратегии. Архитектор-методолог — это тот, кто соединяет структуру и смыслы, объекты и людей, Discovery и Delivery, TOGAF и Change Management. Другими словами, такая роль позволяет создать управляемость архитектурой.

 Вопросы для размышления читателям:

• есть ли в вашей компании процесс перехода от стратегии к реализации?

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

• как вы измеряете, насколько реальная архитектура соответствует целевой?

• где в вашей структуре находится «архитектор-методолог» (даже если он так не называется)?

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

Мой ТГ-канал, если Вам интересна данная и около тема: https://t.me/arma_frame