Управление корпоративной архитектурой (Enterprise Architecture, EA) в российских компаниях переживает бум. Однако на практике далеко не все идет гладко: инвестиции в EA часто не окупаются, а сама архитектура не влияет на ключевые бизнес‑метрики — EBITDA и Time‑to‑Market.

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

1. Инструмент вместо системы управления

Кейс. В одном из проектов первым делом купили дорогой инструмент и начали рисовать в нем модели. Но само управление архитектурой в организации «не прижилось» — бизнес оказался не готов к таким изменениям. В итоге инструмент забросили, а инвестиции списали.

Проблема. Управление корпоративной архитектурой часто воспринимается как программное обеспечение для рисования схем. Внедрение начинают с покупки инструмента, а не с выстраивания процессов. Появляется архитектурный репозиторий, но нет процесса принятия решений, нет связей ИТ‑ландшафта с целями, продуктами, процессами и финансами. И главное — нет ответственных за объекты корпоративной архитектуры. Через год инструмент становится «кладбищем диаграмм», которые никто не обновляет.

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

2. Попытка описать всю компанию до атомарного уровня

Кейс. На старте архитектурного проекта ставится задача описать всю архитектуру с максимальной детализацией. Создается множество диаграмм без четкого понимания, кто и какие решения будет на их основе принимать.

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

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

3. Разговор с бизнесом на техническом языке

Кейс. В одной организации внедрение управления корпоративной архитектурой тормозилось из‑за сопротивления бизнеса. Но стоило на обучении объяснить суть архитектуры простыми словами, как противодействие снизилось. Выяснилось, что бизнес просто не понимал терминологию архитекторов и их сложные диаграммы.

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

Решение. Говорите с бизнесом на его языке. Показывайте влияние архитектуры на EBITDA, Time‑to‑Market, стоимость изменений, TCO и снижение операционных рисков. Диаграммы и нотации остаются внутренним инструментом архитекторов, а не способом коммуникации с заказчиком.

4. Архитектурный совет как «полиция»

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

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

Решение. Архитектурный совет должен быть сервисом. Его задача — помогать принимать решения быстрее, предлагать альтернативы, оценивать компромиссы и снижать неопределенность. Совет должен ускорять изменения, а не тормозить их.

5. Излишняя детализация при создании целевой архитектуры

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

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

Решение. Целевой ландшафт — это ориентир (вектор), а не догма. Планируйте ровно на тот срок, на который возможно. Уровень детализации должен соответствовать горизонту планирования: чем дальше горизонт, тем крупнее мазки. Архитектура управляет направлением, а не каждой деталью.

6. Отсутствие Architecture as Code

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

Проблема. Архитектурные требования живут в документах и презентациях. Нет автоматической проверки их исполнения в процессе разработки. В итоге архитектура не влияет на реальные изменения, превращаясь в «бумажного тигра».

Решение. Внедряйте Architecture as Code, когда архитектурные правила проверяются автоматически, ограничения встроены в процесс разработки ИТ‑решений, а несоответствия выявляются до попадания функциональности в эксплуатацию. Архитектурные требования становятся исполняемыми. 

7. Копирование TOGAF без адаптации

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

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

Решение. Упрощайте методологию под текущую зрелость компании, отбрасывайте лишние фазы и артефакты. Фокус должен быть на принятии решений, а не на генерации документации.

8. Создание артефактов и диаграмм «для галочки»

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

Проблема. Создаются диаграммы, которые никто не читает, не обновляет и не использует. Корпоративная архитектура превращается в фиктивную отчетность.

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

9. Игнорирование Agile

Кейс. В одной организации время на принятие архитектурных решений стало занимать почти 20% от общего Time‑to‑Market.

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

Решение. Интегрируйте управление корпоративной архитектурой в Agile. Используйте архитектурные эпики в бэклоге, привлекайте архитекторов к продуктовому планированию, перейдите к итеративной эволюции архитектуры и обеспечьте непрерывную обратную связь.

10. Разделение бизнес‑ и ИТ‑архитекторов

Кейс. Большинство департаментов управления корпоративной архитектурой в российских компаниях управляют исключительно ИТ‑ландшафтом, не касаясь бизнес‑архитектуры. А бизнес‑архитектурой (целеполаганием, оргструктурой, процессами) занимаются совсем другие подразделения.

Проблема. Разделение ролей создает разрыв. Бизнес‑архитектура уходит в абстрактную стратегию, ИТ‑архитектура — в «железо и код». Теряется сквозная логика создания ценности.

Решение. Единая архитектурная ответственность. Необходима общая метамодель корпоративной архитектуры, единый язык ценности для бизнеса и фокус на скорости изменений в организации.

Выводы

Управление корпоративной архитектурой начинает работать только тогда, когда перестает быть просто системой создания архитектурных артефактов, а становится системой управления изменениями бизнеса. Ценность корпоративной архитектуры измеряется не количеством диаграмм в архитектурном репозитории, а ее реальным влиянием на скорость, деньги и риски компании.

Коллеги, а какая из этих ошибок встречается в ваших компаниях? Или, может быть, хотите добавить еще одну ошибку?

Корпоративная архитектура не заканчивается на создании моделей и схем — важно понимать, как встроить её в управление изменениями, разработку продуктов и стратегию бизнеса. Разобраться в современных подходах к архитектуре помогут бесплатные занятия OTUS:

• 4 августа, 19:00 — «Будущее корпоративного архитектора: навыки, тренды, технологии». Записаться
  _{Как меняется роль архитектора в эпоху новых технологий и какие компетенции становятся ключевыми.}

• 11 августа, 19:00 — «Модели организации разработки: продуктовые команды и архитектурное управление». Записаться
  _{Как связать архитектурное управление с продуктовыми командами и ускорить принятие решений.}

• 18 августа, 19:00 — «Строим идеальную бизнес‑архитектуру». Записаться
  _{О подходах к построению бизнес‑архитектуры, целевым состояниям и объектам управления компанией.}

Больше открытых уроков июля смотрите в дайджесте.