Техрадар в банке: от списка технологий к управляемым решениям

Как мы выбрали решение, адаптировали статусы под внутренний процесс и поняли, что главное - не картинка, а управление рекомендациями

 Привет, Хабр! Меня зовут Алексей Бубликов, я Solution Architect в Банке Уралсиб.

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

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

 Банк Уралсиб ведёт историю с 1988 года. За это время менялись команды, платформы, технологии и подходы к проектированию. Вместе с ними менялись и места, где фиксировались архитектурные решения: документы, Wiki, репозитории, презентации - и, конечно, знания отдельных экспертов.

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

 В чём проблема? Давайте разбираться.

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

Одна команда пишет сервисы на Java, другая предпочитает Kotlin, третья пробует Go.

Где-то уже используется Kafka, где-то - RabbitMQ, а где-то появляется ещё один брокер сообщений, который очень понравился разработчику.

Каждое решение по отдельности может быть абсолютно разумным.

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

«А кто вообще знает, какие технологии мы рекомендуем использовать - и почему именно они?»

И ещё несколько наводящих вопросов:

• какие технологии уже достаточно зрелые для прода;

• какие мы сейчас только исследуем;

• какие лучше не использовать в новых системах;

• почему одна технология предпочтительнее другой;

• кто принимает такие решения;

• где зафиксирован накопленный опыт;

• что делать команде, если она считает, что текущая рекомендация устарела?

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

 Зачем вообще нужен Техрадар

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

Берём табличку, и начинаем ее заполнять: 

Готово.

 Только есть одна проблема: список технологий практически ничего не объясняет.

 Допустим, в нём есть PostgreSQL и Oracle, что это означает?

Что обе технологии разрешены?

Что их можно использовать в любых проектах?

Что PostgreSQL предпочтительнее Oracle?

А если Oracle уже используется в десяти системах?

А если команда хочет использовать новую СУБД, которой в списке вообще нет?

Просто перечень технологий не отвечает на эти вопросы.

Поэтому нам нужен не список, а позиция организации относительно технологий.

 Именно эту задачу хорошо решает техрадар.

Что мы хотели получить

На старте перед нами не стояла задача построить огромную Enterprise Architecture

Platform. Более того, мы сознательно не хотели сразу создавать систему, которую потом придётся несколько лет разрабатывать и сопровождать. Нам нужен был гораздо более простой инструмент. И как архитекторы мы решили предъявить требования к решению.

 Новое решение должно:

• сформировать единое представление о технологическом ландшафте;

• зафиксировать текущие технологические предпочтения;

• отделить зрелые технологии от экспериментальных;

• сделать архитектурные рекомендации видимыми для команд разработки;

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

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

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

Техрадар - это не рейтинг технологий

Если вы раньше сталкивались с Техрадарами, то наверняка видели классическую модель с кольцами.

Например:

Adopt - технологию рекомендуем использовать;

Trial - технологию уже пробуем на реальных задачах;

Assess - технология интересна, но требует исследования;

Hold - технологию не рекомендуем использовать в новых проектах.

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

 Можно посмотреть на кольца и решить:

Adopt - хорошие технологии.

Hold - плохие технологии.

 На самом деле это не так.

Кольцо - не оценка качества технологии.

 Оно отвечает на гораздо более практический вопрос:

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

Например, технология может находиться в Hold и при этом использоваться в десятках существующих систем. И это совершенно нормально.

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

Для новых решений мы предпочитаем другую технологию.

А не:

Немедленно удалите всё, где используется эта технология.

Это принципиальное различие.

К слову, мы переработали классические кольца под наши потребности. Assess превратился в «Прототип»: прежде чем рекомендовать технологию к практическому применению, команда должна показать, как собирается её использовать и какую гипотезу хочет проверить. Trial мы переименовали в «Пилот» - финальный этап испытаний. На этом этапе нужны измеримые результаты и понятная выгода и для технической команды, и для бизнеса: TTM никто не отменял. Такой подход позволяет обсуждать не только перспективность идеи, но и подтверждённый практический эффект.

А что делать с технологиями, которые уже используются?

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

Допустим, сегодня мы решили, что технология X больше не является предпочтительной. Но она уже используется в двадцати системах. Что делать?

 Ответ: Ничего.

 По крайней мере, автоматически ничего переписывать не нужно.

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

Технологическая рекомендация и технологический инвентарь - не одно и то же.

Техрадар отвечает прежде всего на вопрос:

Что нам предпочтительно использовать дальше?

А не:

Что прямо сейчас должно исчезнуть из инфраструктуры?

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

Как мы выбирали инструмент

Когда мы определились с требованиями, мы задались вопросом:

Какой инструмент поможет их закрыть?

Мы рассматривали три варианта:

1. Купить готовую платформу - можно, а зачем?

2. Разработать собственное решение с нуля -см. Пункт 1, выглядит избыточно.

3. Взять существующий open source-проект и адаптировать его под свои процессы - вот наш вариант. Привет, мистер Столлман! 😅

 Для нашего сценария наиболее рациональным оказался третий вариант.

В качестве основы мы выбрали Zalando Tech Radar. Причина достаточно прагматичная. Нужно получить простую цепочку:

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

Самое сложное оказалось не в коде

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

Возник совершенно логичный вопрос:

А что должно происходить с технологией до и после того, как она появляется на техрадаре?

 Допустим, завтра команда приходит и говорит:

Мы хотим использовать новую технологию.

Что дальше?

Архитектор должен сказать «да» или «нет»?

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

А если другая команда считает, что текущая технология не подходит?

А если через полгода появится новая версия?

Получается, что нам нужен не просто техрадар.

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

 Упрощённо он выглядит так:

И вот здесь, на мой взгляд, начинается настоящая ценность техрадара.

Он перестаёт быть картинкой и становится живым процессом.

Как новая технология попадает на техрадар

Инициатором может быть практически любой технический специалист:

• команда разработки;

• архитектор;

• технический лидер;

• другой эксперт.

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

А можем ли мы рекомендовать её другим командам?

Но одного положительного опыта одной команды недостаточно.

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

 Иногда команда обнаруживает существенные ограничения существующего решения и предлагает рассмотреть альтернативу.

Так появляется запрос на изменение техрадара.

Технология проходит экспертную оценку

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

Мы не спрашиваем:

Что сейчас модно? Какие тренды?

Мы пытаемся понять:

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

И здесь появляется несколько критериев:

1.   Зрелость

Насколько технология стабильна и предсказуема в проде именно в нашей сфере?

Одно дело - запустить её как свой локально-домашний проект.

Совсем другое - использовать её в критически важной банковской системе или её компоненте. Здесь нужно учитывать SLA, требования к RPO/RTO и требования информационной безопасности.

 2.   Экспертиза

Есть ли внутри компании люди, которые умеют с ней работать?

Можно выбрать прекрасную технологию, но если специалистов, способных её

сопровождать нет, стоимость такого выбора резко возрастает.

 3.   Экосистема

Насколько развиты:

• community;

• документация;

• tooling;

• библиотеки;

• интеграции;

• инструменты мониторинга и эксплуатации. 

4.   Стоимость владения

И здесь важно смотреть гораздо шире лицензии.

Стоимость владения включает:

• инфраструктуру;

• сопровождение;

• обучение;

• поддержку;

• эксплуатацию;

• миграцию;

• стоимость компетенций.

 5.   Безопасность

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

 6.   Интеграция

Насколько хорошо технология вписывается в существующий технологический ландшафт?

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

 7.   Стратегическая перспектива

стоит ли компании инвестировать в эту технологию на горизонте нескольких лет?

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

В чем польза для компании

На небольшом проекте многие решения можно держать в голове. Команда из десяти человек вполне способна договориться:

Здесь используем PostgreSQL, здесь Kafka, а новые сервисы пишем на Java.

 Но компания растёт, команд становится больше и появляются новые продукты.

Приходят новые разработчики и архитекторы, меняются технологии.

И информация начинает расползаться по локальным источникам.

 У одной команды есть свой Confluence.

У другой - Git repository.

У третьей - презентация пятилетней давности и документ на несколько десятков

страниц в Word.

У четвёртой - «мы всегда так делали».

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

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

 Техрадар позволяет создать общий язык:

Это очень небольшое изменение формулировки. Но оно сильно меняет характер архитектурной дискуссии.

Важный момент: техрадар не должен превращаться в бюрократию.

Здесь легко совершить ещё одну ошибку, создать радар, назначить комитет.

Далее:

• Создать форму на 17 полей.

• Попросить заполнить заявку.

• Провести три согласования.

• Подождать архитектурный комитет. 

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

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

Команды сохраняют возможность предлагать изменения и привносить новый опыт. Эта связь должна работать в обе стороны:

 Architecture → Development

и одновременно:

Development → Architecture

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

Техрадар как договорённость между архитектурой и разработкой

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

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

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

 А мы вообще управляем технологическим ландшафтом или просто нарисовали его?

Техрадар отвечает не на все вопросы

Ещё на этапе сбора требований стало понятно: помимо основных вопросов - «что рекомендовать?» и «на каком основании?» - командам нужны ответы и на другие вопросы:

• Как использовать?

• Где это уже используется?

Например, я вижу RabbitMQ в «Активно».

Но мне хочется узнать:

• в каких системах она уже используется;

• кто владелец;

• какие есть примеры;

• какие архитектурные решения принимались;

• какая документация существует;

• есть ли готовые шаблоны;

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

• какие есть контракты для общения с сервисами.

И здесь одного радара уже недостаточно.

Следующий шаг - Developer Portal

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

 Например, на базе Backstage.

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

И это уже совершенно другая история. Разработчик приходит не просто посмотреть:

Что нам рекомендуют?

Он может пройти весь путь:

В этот момент архитектурные рекомендации начинают действительно работать.

Они перестают жить отдельно в презентациях, Wiki и документах и постепенно становятся частью ежедневного developer experience.

Что я вынес из этого проекта

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

 1. Не нужно начинать с большой платформы.

Для запуска достаточно выполнения базовой функциональности.

Главное - проверить сам процесс.

 2. Техрадар - это не картинка.

Картинку можно сделать за вечер.

Работающий техрадар появляется только тогда, когда вокруг него возникает процесс:

инициатива → оценка → решение → публикация → обратная связь → пересмотр.

 3. Радар не должен превращаться в механизм запретов.

Его задача - дать командам понятное направление и контекст для принятия решений.

 4. Архитектура должна получать обратную связь от разработки.

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

 5. Технологический ландшафт невозможно «закончить».

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

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

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