Управляемая ИТ-архитектура: как встроить архитектуру в управление изменениями ДИТ

Представим вполне типичную ситуацию.

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

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

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

С технической точки зрения ничего катастрофического не произошло. Архитектуру можно переделать.

С управленческой — произошло.

Компания уже заплатила за несколько месяцев работы разработчиков, аналитиков, DevOps-инженеров, тестировщиков и других специалистов. Часть выполненной работы придется выбросить или существенно переработать. Сдвигаются сроки запуска. Команда демотивирована: вчера решение считалось почти готовым, сегодня выясняется, что его нельзя вводить в промышленную эксплуатацию. И проблема здесь обычно не в плохих разработчиках, чрезмерно консервативной эксплуатации или руководителе информационной безопасности, который решил усложнить жизнь проекту.

Проблема — в архитектурном процессе. Архитектурные решения принимались, но архитектурой как управляемым процессом никто не управлял.

В этой статье разберем, как можно встроить архитектуру в повседневную работу ДИТ: от появления инициативы до промышленной эксплуатации. Поговорим о роли архитектора, комитетах, праве вето, CMDB, Confluence, Git, Archi, каталоге целевых технологий и о том, почему архитектурное управление должно начинаться намного раньше архитектурного рассмотрения.

1. Архитектура — это не диаграммы

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

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

От нескольких архитектурных решений могут зависеть:

• доступность продукта;
• RTO и RPO;
• информационная безопасность;
• соблюдение требований к обработке данных;
• производительность и масштабируемость;
• стоимость инфраструктуры и лицензий;
• требования к компетенциям и количеству персонала;
• сложность эксплуатации;
• скорость внесения изменений;
• зависимость от поставщиков;
• в конечном счете — совокупная стоимость владения системой.

Поэтому архитектура — далеко не исключительно техническая дисциплина. Для CIO это один из механизмов управления ИТ-рисками и стоимостью.

Существуют зрелые методологические основы. TOGAF Standard, 10th Edition остается одним из наиболее известных стандартов корпоративной архитектуры и предлагает системный подход к развитию архитектуры предприятия.

ISO/IEC/IEEE 42010:2022 задает требования к тому, как формально описывать архитектуру и представлять ее с разных точек зрения для различных заинтересованных сторон. Причем стандарт отдельно различает саму архитектуру и ее описание — важное напоминание о том, что диаграмма не является архитектурой сама по себе.

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

Методологий достаточно. Главная проблема обычно заключается не в отсутствии еще одной методологии. Она возникает на стыке методологии и реальной жизни компании.

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

1.1. Один архитектор не может спроектировать современную ИТ-систему

В достаточно крупной корпоративной системе одновременно пересекаются десятки областей экспертизы. Нужны знания в разработке, интеграциях, автоматизации сборки и развертывания, Kubernetes или другой инфраструктурной платформе, сетях, СУБД, хранилищах данных, информационной безопасности, управлении доступом, мониторинге и наблюдаемости, резервном копировании, аварийном восстановлении, лицензировании, производительности и эксплуатации. Можно найти очень сильного архитектора. Но сложно представить человека, который одновременно обладает глубокой актуальной экспертизой во всех перечисленных областях и имеет достаточно рабочего времени, чтобы детально спроектировать каждое решение компании. Отсюда важный вывод:

Архитектура — это коллективная работа ИТ-функций, организованная архитектором в управляемый процесс.

Архитектор не обязан лучше DBA знать устройство PostgreSQL, лучше сетевого инженера проектировать BGP, лучше специалиста SOC понимать SIEM и лучше DevOps-инженера настраивать конвейер сборки и развертывания. Его роль другая.

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

2. На что реально влияет архитектура

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

2.1. Надежность: схема «активный/активный» не всегда лучше схемы «активный/резервный»

Практически любое обсуждение отказоустойчивости упирается в компромисс:

надежность ↔ сложность ↔ стоимость.

Рассмотрим несколько распространенных вариантов.

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

При этом само наличие двух ЦОД или двух Kubernetes-кластеров еще не делает систему отказоустойчивой. Необходимо понимать:

• какие именно отказы мы покрываем;
• какой RTO требуется бизнесу;
• какой RPO допустим;
• что происходит с состоянием приложения;
• как реплицируются данные;
• как работает DNS или глобальная балансировка;
• каким образом определяется отказ;
• кто и как выполняет переключение на резерв;
• как система защищена от ситуации, когда при потере связи несколько узлов или площадок одновременно считают себя активными;
• как система возвращается в штатный режим;
• тестировался ли сценарий восстановления.

Здесь появляется распространенная архитектурная ошибка — считать максимальную техническую надежность безусловным благом. Для платежной платформы схема «активный/активный» между площадками может быть обоснован. Для внутреннего сервиса заказа канцелярии — скорее всего нет. Если бизнес способен пережить четырехчасовой простой системы, построение сложной геораспределенной архитектуры «активный/активный» может оказаться не проявлением высокой инженерной культуры, а необоснованным усложнением решения и источником дополнительных расходов. Правильная архитектура не максимизирует один параметр. Она ищет приемлемый баланс требований.

2.2. Информационная безопасность должна появляться раньше разработки

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

• какие данные хранить;
• где их хранить;
• каким образом сервисы взаимодействуют;
• как организована аутентификация;
• какие внешние программные интерфейсы используются;
• куда пишутся логи;
• где находятся резервные копии.

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

К таким требованиям относятся:

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

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

2.3. Необоснованное усложнение: технологически красивое решение может быть плохой архитектурой

Предположим, команда предлагает использовать новый технологический компонент. Техническое обоснование выглядит убедительно. Для нового сервиса нужна отдельная СУБД. Для обмена событиями — новый брокер сообщений. Для поиска — отдельный Elasticsearch/OpenSearch-кластер. Для кеширования — Redis. Для оркестрации — новый Kubernetes-кластер. Каждое решение по отдельности может выглядеть разумно.

Но CIO должен видеть другую картину. Каждая новая технология почти неизбежно порождает цепочку постоянных обязательств:

инфраструктура → лицензии → мониторинг → резервирование → установка обновлений → настройка безопасности → документация → обучение → экспертиза → дежурства → аварийное восстановление.

И это уже не стоимость проекта. Это постоянная стоимость владения. Архитектурная сложность работает примерно как финансовый процент: принятое сегодня решение продолжает требовать ресурсы годами. Поэтому вопрос архитектурного рассмотрения должен звучать не только:

Можно ли решить задачу этой технологией?

Но и:

Зачем организации еще одна технология, если задача решается существующим стандартным стеком?

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

2.4. Эксплуатационная пригодность — часть архитектуры

Еще одна частая ошибка — считать систему готовой после успешного завершения функционального тестирования. Промышленная эксплуатация задает другие вопросы:

• Кто получит алерт в три часа ночи?
• Как понять, что приложение деградирует?
• Что является нормальным временем ответа?
• Как диагностировать проблему между пятью микросервисами?
• Как восстановить базу после повреждения?
• Сколько времени занимает восстановление?
• Документация достаточна для решения инцидентов и устранения сбоев?
• Есть ли результаты нагрузочного тестирования?
• Какая команда является владельцем системы?
• Кто отвечает за сертификаты?
• Как управляются технические учетные записи?
• Как будет выполняться обновление ПО?

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

2.5. Архитектура и компетенции персонала

Этот вопрос часто недооценивают.

Предположим, в компании уже эксплуатируются PostgreSQL, Kafka и Kubernetes. Для них есть команды, мониторинг, инструкции, резервное копирование, компетенции и процессы поддержки. Новый проект приносит еще одну СУБД, еще один брокер сообщений и еще одну платформу контейнеризации. Инфраструктурная стоимость новых компонентов может оказаться небольшой. Стоимость компетенций — гораздо выше. Нужно:

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

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

Например:

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

3. Где ломается архитектурный процесс

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

Инициатива → анализ → разработка → тестирование → ИБ → эксплуатация → архитектурный комитет → промышленная эксплуатация

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

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

Нужен другой цикл.

Инициатива → архитектурные ограничения → совместная проработка → архитектурное решение → разработка → автоматический контроль → промышленная эксплуатация → эксплуатационная обратная связь

Причем степень контроля не должна быть одинаковой для каждого изменения. Небольшой внутренний сервис и новая платежная платформа требуют разного уровня внимания.

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

Я предлагаю рассмотреть один из практических вариантов такого процесса.

4. Два архитектурных контура

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

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

5. Понедельник: комитет по инициативам

На этом этапе еще не требуется детальная архитектура. Задача комитета — понять, что компания собирается изменить в ИТ-ландшафте и какие ограничения необходимо учесть до начала разработки.

На вход приходит инициатива. Например:

Запустить новое мобильное приложение для клиентов.

Или:

Внедрить систему прогнозирования спроса.

Или:

Перенести сервис из устаревшей платформы в микросервисную архитектуру.

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

• кто бизнес-владелец;
• какую проблему решаем;
• какие системы будут затронуты;
• какие данные обрабатываются;
• есть ли ПДн или другая регулируемая информация;
• ожидаемая нагрузка;
• критичность;
• требования к доступности;
• RTO/RPO;
• ключевые интеграции;
• предполагаемый бюджет;
• есть ли новые технологии;
• потребуется ли изменение инфраструктуры;
• кто будет эксплуатировать решение.

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

6. Не все проекты должны идти через архитектурный комитет

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

6.1. Низкий риск

Решение полностью находится в рамках утвержденных технологий и архитектурных принципов. Нет новых критичных данных. Нет существенного изменения интеграций. Нет влияния на SLA.

Команда действует самостоятельно в рамках опубликованных требований и рекомендаций.

6.2. Средний риск

Есть значимое архитектурное изменение, но оно находится внутри известного технологического ландшафта.

Достаточно асинхронного рассмотрения архитектором и профильными экспертами.

6.3. Высокий риск

Новая технология. Новая критичная интеграция. Высокие требования к доступности. Работа с чувствительными данными. Существенная зависимость от внешнего поставщика. Значимый капитальные и операционные затраты. Изменение корпоративной архитектуры.

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

7. Что происходит между двумя комитетами

Вот здесь и должна создаваться архитектура. Не на пятничном заседании. И не архитектором в одиночку. Для значимого проекта формируется рабочая группа:

Владелец продукта / бизнес-аналитик + разработка + архитектор + инфраструктура и автоматизация + администратор баз данных / команда по данным + сетевой инженер + информационная безопасность + эксплуатация.

Состав зависит от проекта. Если нет данных — не нужен DBA. Если нет инфраструктурных изменений — можно не подключать соответствующую команду.

Но принцип остается:

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

Архитектор организует процесс. Команда разработки предлагает решение. Инфраструктура проверяет реализуемость и стоимость. ИБ проверяет соответствие требованиям защиты. Эксплуатация — возможность сопровождения. Команда по данным — работу с данными. FinOps или финансовая функция — при необходимости оценивает стоимость вариантов.

Именно на этом этапе должны происходить самые интересные архитектурные дискуссии. Например:

«Активный/активный» или «активный/резервный»? Kafka или достаточно существующего RabbitMQ? Собственная СУБД или облачные сервисы? Отдельный Kubernetes-кластер или отдельное пространство имен на существующей платформе? Синхронная интеграция или событийная? Создаем самостоятельно или покупаем решение на рынке?

Это и есть архитектура. Диаграмма появится позже как фиксация результата.

8. Архитектурные решения должны фиксироваться

Через полгода кто-нибудь обязательно спросит:

Почему мы сделали именно так?

Плохой ответ:

Кажется, тогда Петров на встрече предложил.

Еще хуже:

Архитектор так решил.

Для значимых решений стоит использовать запись об архитектурном решении (ADR). Это небольшой документ, фиксирующий как минимум: Контекст — какую проблему решали. Решение — какое решение приняли. Альтернативы — какие варианты рассматривались. Обоснование — почему выбран именно этот вариант. Последствия — какие последствия и ограничения мы принимаем.

Например: ADR-017. Использовать схему «активный/резервный» вместо «активный/активный». Причина: бизнес допускает RTO до 30 минут, поэтому дополнительная стоимость и эксплуатационная сложность схемы «активный/активный» не оправданы. Через два года бизнес может изменить SLA. Тогда команда понимает не только текущее устройство системы, но и исходные предпосылки решения.

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

9. Пятница: архитектурный комитет

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

• существенные компромиссы;
• отклонения от архитектурных принципов;
• новые технологии;
• критичные риски ИБ;
• эксплуатационные ограничения;
• существенное влияние на стоимость;
• зависимость от поставщиков;
• нерешенные разногласия;
• архитектурные исключения.

На выходе должен появиться понятный статус. Например:

Согласовано Решение согласовано.

Согласовано с оговорками Решение согласовано при выполнении перечисленных условий.

Доработка Нужна доработка.

Отклонено Предложенный подход принципиально неприемлем.

Исключение / принятие риска Решение нарушает стандарт, но организация сознательно принимает риск.

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

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

Иначе временное исключение очень быстро превращается в новый стандарт де-факто.

10. Кто должен иметь право заблокировать решение

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

• архитектура;
• информационная безопасность;
• эксплуатация.

Причина достаточно проста. Архитектор отвечает за целостность и соответствие архитектурным принципам. Руководитель информационной безопасности или уполномоченная функция ИБ — за неприемлемый риск информационной безопасности или несоблюдения обязательных требований. Эксплуатация — за способность реально поддерживать решение после запуска. У этих функций должно существовать право заблокировать решение в своей области ответственности.

Но здесь появляется опасность. Если право вето звучит так:

«Мне архитектура не нравится»,

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

Нарушено правило ИБ SEC-07.

Или:

Не выполнено требование эксплуатационной готовности OPS-12.

Или:

Решение использует технологию со статусом "Ограниченная" без утвержденного исключения.

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

11. Правила должны существовать до заседания

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

11.1. Архитектурные принципы

Какие общие правила действуют для архитектуры.

11.2. Принципы информационной безопасности

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

11.3. Требования готовности к эксплуатации

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

11.4. Принципы управления данными

Классификация, владелец данных, НСИ, хранение, качество.

11.5. Интеграционные стандарты

Версионирование и обратная совместимость с предыдущими версиями, принципы построения программных интерфейсов, правила именования.

11.6. Каталог целевых технологий

Предпочтительная, Допустимая, Пилотная, Ограниченная, Выводится из эксплуатации.

11.7. Принципы FinOps

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

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

12. Типовая архитектура лучше десятка согласований

Еще один способ снизить архитектурную бюрократию — подготовить типовые архитектуры.

Например:

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

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

Архитекторы один раз проектируют хороший путь, а десятки команд затем используют его самостоятельно.

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

13. Где хранить архитектуру

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

13.1. CMDB: что реально существует

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

Бизнес-продукт → ИТ-сервис → Приложение → Компонент → Конфигурационная единица инфраструктуры

К этим объектам добавляются:

• владельцы;
• команды;
• критичность;
• SLA;
• площадки;
• зависимости;
• версии;
• статус жизненного цикла;
• лицензии;
• связанные договоры;
• при необходимости — стоимость.

CMDB особенно ценна не красивой карточкой сервера. Ценность появляется в связях. Если завтра нужно вывести из эксплуатации СУБД, архитектор должен понимать, какие сервисы от нее зависят. Если меняется сетевой сегмент — какие системы будут затронуты. Если заканчивается лицензия — какие бизнес-продукты находятся под риском. CMDB отвечает прежде всего на вопрос:

Что у нас есть сейчас и как это связано?

Но делать из нее единственное хранилище архитектуры я бы не стал.

13.2. Confluence: почему и контекст

Не вся архитектурная информация является структурированной моделью. Нужны документы:

• архитектурные принципы;
• стандарты;
• нефункциональные требования;
• описание решений;
• инструкции;
• протоколы;
• требования ИБ;
• эксплуатационные требования;
• материалы для ввода новых сотрудников в работу;
• описание продуктов и сервисов.

Для этого подходит Confluence или аналогичная система управления знаниями. То есть условно:

CMDB знает, что существует.

Confluence объясняет, почему и как с этим работать.

13.3. Git + Archi: архитектура как инженерный артефакт

Для формального моделирования корпоративной архитектуры можно использовать ArchiMate.

ArchiMate — открытый и независимый язык моделирования корпоративной архитектуры от The Open Group. Он позволяет описывать и связывать бизнес-процессы, приложения, информационные потоки и технологическую инфраструктуру.

Archi — инструмент с открытым исходным кодом для создания ArchiMate-моделей.

Но гораздо интереснее сам принцип организации работы. Архитектурная модель по сути является результатом совместной работы всех команд и должна иметь историю изменений. Удобнее всего использовать для этих целей Git. Условно:

Изменение модели → фиксация изменения → предварительное рассмотрение → согласование → включение в основную версию

Тогда появляются знакомые инженерным командам свойства Git:

• контроль версий;
• автор изменения;
• история;
• возможность согласования;
• откат изменений;
• связь с задачей;
• связь с ADR;
• автоматическая проверка части требований.

Архитектура начинает жить не как файл: architecture_final_v7_new_REAL_FINAL.drawio, а как управляемый инженерный артефакт. При этом я бы не пытался хранить исключительно в Git все архитектурное знание. У каждого инструмента своя роль.

Пример:

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

14. Следующий шаг — формализованные архитектурные правила

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

Идея проста:

Люди должны обсуждать решения. Машины должны проверять правила.

Архитектурный комитет имеет смысл тратить на вопрос:

Нужна ли здесь новая технология?

Но нет смысла каждую неделю вручную проверять:

Включено ли шифрование у накопителей?

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

15. Архитектура не заканчивается после выхода в промышленную эксплуатацию

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

• фактическую нагрузку;
• реальные узкие места;
• фактический SLA;
• стоимость инфраструктуры;
• число инцидентов;
• стоимость эксплуатации;
• насколько хорошо работает резервирование;
• какие компоненты создают больше всего проблем;
• какие исходные архитектурные предположения оказались ошибочными.

Поэтому правильный цикл должен быть замкнут.

Именно последний переход часто отсутствует. А без него архитектура превращается в теоретическую деятельность.

16. Архитектура и FinOps должны разговаривать друг с другом

Практически каждое значимое архитектурное решение имеет финансовую составляющую. Схема «активный/активный» обычно дороже схемы «активный/резервный». Управляемая облачная СУБД может стоить дороже инфраструктуры собственной СУБД, но дешевле с учетом ФОТ поддержки. Микросервисная архитектура может дать организационную масштабируемость, но увеличить инфраструктурные расходы. Новый облачный сервис может сократить срок вывода продукта на рынок, но создаст долгосрочные лицензионные затраты и зависимость от поставщика. Поэтому при рассмотрении нескольких допустимых вариантов полезно сравнивать не только технические свойства.

Например:

Это уже другой уровень архитектурного разговора.

Не:

Вариант B технологически круче.

А:

Бизнес-требования не оправдывают дополнительные постоянные расходы варианта Б.

Именно в этой точке архитектура становится частью управления экономикой ИТ.

17. Как понять, работает ли архитектурный процесс

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

17.1. Срок архитектурного согласования

Сколько времени проходит от готовности решения к архитектурному рассмотрению до архитектурного решения. Если согласование длится месяцами, управление превратилось в якорь.

17.2. Доля решений, согласованных с первого раза

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

17.3. Доля поздних архитектурных доработок

Сколько изменений потребовалось после начала разработки или непосредственно перед промышленным запуском из-за архитектурных проблем, проблем информационной безопасности или эксплуатации. Для меня это один из главных показателей зрелости процесса.

17.4. Количество отклонений от технологических стандартов

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

17.5. Количество инцидентов по архитектурным причинам

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

17.6. Количество замечаний при передаче в эксплуатацию

Сколько проектов возвращаются с этапа эксплуатационной готовности.

17.7. Влияние архитектурных решений на стоимость ИТ

Как архитектурные изменения влияют на инфраструктурные и лицензионные расходы.

17.8. Уровень технологического разнообразия

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

18. Чего архитектурный комитет делать не должен

После описания процесса важно отметить несколько неудачных практик.

18.1. Не должен проектировать за команду

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

18.2. Не должен читать документ впервые на встрече

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

18.3. Не должен согласовывать каждую мелочь

Для типовых решений должны использоваться заранее разработанные эталонные архитектуры и установленные архитектурные правила и ограничения.

18.4. Не должен становиться архитектурной полицией

Цель функции — помочь организации принимать более качественные решения, а не максимизировать число отказов.

18.5. Не должен создавать правила постфактум

Если команда могла узнать о требовании только во время комитета, это проблема архитектурного процесса.

18.6. Не должен игнорировать стоимость

Технически идеальное решение может быть экономически плохим.

19. Как выглядит целевая модель целиком

Если собрать описанные элементы в одну систему, получится примерно следующий процесс.

19.1. Появляется бизнес-инициатива

Определяются ожидаемый результат, владелец и основные требования.

19.2. Инициатива попадает в ранний архитектурный контур

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

19.3. Команда получает заранее установленные архитектурные правила и ограничения:

• архитектурные принципы;
• требования информационной безопасности;
• требования к готовности системы к эксплуатации;
• каталог целевых технологий;
• типовые архитектурные решения.

19.4. Решение проектируется совместно

Архитектор, разработка, инфраструктура, ИБ, эксплуатация и другие необходимые эксперты.

19.5. Значимые решения фиксируются в ADR

С контекстом, альтернативами и последствиями.

19.6. Проводится предварительное рассмотрение решения

Проблемы устраняются до вынесения на Архитектурный комитет.

19.7. Существенные решения рассматривает архитектурный комитет

Комитет рассматривает существенные архитектурные компромиссы, отклонения от установленных правил и связанные с ними риски, а не занимается оформлением документов.

19.8. Формализуемые требования проверяются автоматически

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

19.9. Перед промышленным запуском подтверждается эксплуатационная готовность

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

19.10. Фактическое состояние попадает в CMDB и другие системы учета

Архитектура синхронизируется с реальностью.

19.11. Промышленная эксплуатация возвращает обратную связь

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

20. Что в этой модели делает CIO

Директору по ИТ необязательно присутствовать на каждом Архитектурном комитете. Более того, если CIO приходится лично разбирать каждую техническую архитектуру, организационная модель, скорее всего, плохо масштабируется. Задача CIO находится уровнем выше.

Нужно обеспечить наличие:

• архитектурных принципов;
• понятных полномочий;
• владельцев стандартов;
• механизма исключений;
• технологического каталога;
• участия ИБ и эксплуатации;
• архитектурного репозитория;
• CMDB;
• измеримых показателей;
• связи архитектурных решений со стоимостью;
• механизма эскалации для разрешения конфликтов.

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

Вместо заключения

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

Это не означает отсутствия архитектурных конфликтов. Наоборот, они обязательно будут. Один вариант дешевле. Другой надежнее. Третий быстрее выводится на рынок. Четвертый лучше соответствует технологической стратегии.

Задача архитектуры — сделать эти противоречия явными и принять решение в тот момент, когда его еще относительно дешево изменить. Поэтому для меня зрелая архитектурная функция определяется не количеством архитекторов, диаграмм и проведенных комитетов. Она определяется тем, насколько хорошо компания умеет принимать, фиксировать, контролировать и пересматривать значимые технологические решения.

Для CIO ценность такой модели не в усилении централизованного контроля. Она в том, что архитектура становится частью системы управления изменениями: помогает раньше видеть технологические и финансовые последствия решений, распределять ответственность и снижать стоимость поздних переделок.

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

Материалы для дальнейшего чтения

• FinOps: моя статья «Как связать расходы на облако с продуктами, командами и бизнес-результатом», ее первоначальная публикация на vc.ru и официальное описание модели FinOps Foundation.
• TOGAF Standard, 10th Edition: официальная страница The Open Group — методологическая основа корпоративной архитектуры.
• ISO/IEC/IEEE 42010:2022: официальная страница ISO — требования к описанию архитектуры, архитектурным точкам зрения и моделям.
• AWS Well-Architected Framework: официальная документация — практические рекомендации по надежности, безопасности, эксплуатационной эффективности, производительности, стоимости и устойчивому развитию облачных решений.
• ArchiMate 3.2: официальная страница The Open Group; Archi: официальный сайт инструмента с открытым исходным кодом.
• Децентрализованное принятие архитектурных решений: материал Thoughtworks об архитектурном консультировании, при котором решения принимаются ближе к командам при обязательном привлечении затронутых сторон и профильных экспертов.