Меня зовут Пелых Виталий, я корпоративный архитектор в «БКС Финтех». Разберу тему, которая звучит просто, но в крупных организациях регулярно «выстреливает» в неожиданных местах: как позиционировать архитектуру так, чтобы она помогала бизнесу и командам, а не превращалась в формальность или «бутылочное горлышко».

Сразу зафиксирую рамку. Под «позиционированием» я понимаю не место на оргсхеме, а то, как устроены правила принятия решений, кто за что отвечает и как мы удерживаем целостность ландшафта, не превращая архитектуру в узкое горлышко. По сути это про архитектурную способность (architecture capability) и архитектурное управление (architecture governance), встроенные в повседневный delivery.

Финтех — среда, где изменения идут непрерывно: продукты, регуляторка, каналы, интеграции. Поэтому архитектура здесь либо помогает меняться быстро и управляемо, либо становится тормозом и источником рисков. Дальше — как это устроено у нас: continuous architecture, около 75% архитектурных решений в командах, корпоративная архитектура как ограничение и контроль. И где у такого подхода границы и риски.

Зачем корпоративная архитектура в финтехе

Корпоративная архитектура (Enterprise Architecture, EA) — это способ описывать организацию как систему: из каких ключевых элементов она состоит и как они связаны. В идеале EA работает мостом между стратегией и операционной реальностью: задаёт принципы и стандарты того, как компания устроена сегодня и как ей безопасно и предсказуемо меняться. Классически EA раскладывают на слои — бизнес, данные, приложения, технологии и сквозные: корпоративную архитектуру и ИБ, — но в этой статье предлагаю рассмотреть не разметку слоёв, а governance.

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

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

Continuous Architecture: как мы это понимаем

Для нас архитектура — это continuous architecture: она не «проектируется один раз наверху», а живёт вместе с продуктом на всём жизненном цикле. В основе — баланс двух режимов:

• Преднамеренная (intentional) архитектура — то, что задаём осознанно и заранее: принципы, стандарты, целевые модели, стандарты и ограничения. Её больше на ранних этапах: стратегия, планирование, выбор курса.

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

Слева направо преднамеренность снижается, а эмерджентность растёт. Корпоративная архитектура работает в основном в преднамеренном режиме — задаёт рамку, внутри которой командам безопасно двигаться быстро. Архитектура решений всё больше уходит в эмерджентный режим и в сами команды. На этой же логике построено наше разделение документации: АР мы заводим там, где осознанно задаём или меняем курс (преднамеренность), а SRS — там, где уточняем реализацию в рамках уже выбранного курса (эмерджентность). Подробно про критерии «АР или SRS» — дальше.

Как у нас распределены функции: корпоративная архитектура и архитектура решений

Переход к гибкой архитектуре (мы для себя называем это Agile / Flexible EA) закономерно меняет распределение функций. Корпоративная архитектура смещает фокус с детального проектирования отдельных решений и централизованного согласования большинства инициатив — к формированию «правил игры» на уровне предприятия. Её задача: закреплять принципы и стандарты, задавать целевые модели на уровне бизнес‑возможностей и доменов, формулировать требования к данным и интеграциям, развивать референсные архитектуры и платформенные подходы, переиспользуемые в разных продуктах и командах. Целевая архитектура при этом задаёт вектор и рамки решений, а не жёсткий план на годы: движемся небольшими итерациями при неизменных стандартах и ограничениях.

Архитектура решений, наоборот, максимально приближается к разработке. У нас эта функция в основном передана прямо в команды — это соответствует принципу end‑to‑end ответственности: команда владеет продуктом целиком, включая проектирование и эволюцию его архитектуры. Вместо отдельной централизованной роли появляется распределённая компетенция внутри команды, и ключевые решения принимаются на месте.

По нашей оценке, порядка 75% типовых архитектурных решений команды разрабатывают самостоятельно, оставшаяся часть — принципиально новые домены, высокорисковые или стандартообразующие вопросы; здесь подключается Архитектор, как правило закреплённый за доменом.

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

АР или SRS: как мы решаем, нужна ли архитектура

Самое частое место, где появляется «тормоз», — документация. Поэтому мы сознательно разделяем случаи, когда нужно архитектурное решение (АР), и когда достаточно SRS (Software Requirement Specification).

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

Решение «АР или SRS» принимаем не интуитивно, а по простым триггерам. Достаточно SRS, если изменение:

• не вводит новых ИТ‑систем и принципиально новых компонентов;

• не меняет ключевые технологические выборы;

• не создаёт нового «источника истины» по данным;

• не ломает интеграционный подход;

• не требует нового security‑паттерна.

В SRS нормально живут решения реализационного уровня: детали контрактов и валидаций, идемпотентность, таймауты и ретраи, требования к логированию и аудиту, feature flags, иногда кэширование — пока это не тянет за собой архитектурную перестройку.

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

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

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

На уровне процесса: SRS остаётся в контуре команды и домена (с обязательным согласованием ИБ там, где затрагиваются доступы, данные или аудит), а АР поднимается на архитектурное согласование в общий governance‑контур и тоже обязательно проходит ИБ. Такой разрез снимает очередь на «архитектуру ради архитектуры», но сохраняет контроль там, где цена ошибки высока. В терминах Open Agile Architecture это облегченное управление — минимально достаточный контроль без потери скорости.

Управляемые исключения

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

Качество архитектуры и что дальше

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

Риски такого подхода

У перераспределения функций есть обратная сторона, и мы стараемся держать её в фокусе.

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

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

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

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

Что это требует от людей

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

Вывод

В финтехе с высокой скоростью изменений архитектура предприятия становится не столько описательной дисциплиной, сколько механизмом управляемой трансформации, который связывает стратегию, продуктовую эволюцию и ИТ‑ландшафт. Ключевой сдвиг: корпоративная архитектура концентрируется на принципах, стандартах и целевых ориентирах, а основная масса решений переходит в команды с end‑to‑end ответственностью. Это повышает скорость delivery и снижает издержки на согласования, но одновременно поднимает требования к качеству governance и зрелости инженерной культуры.

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

А как устроено у вас? Делитесь в комментариях.