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

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

 Привет, Хабр! Меня зовут Алексей Бубликов, я 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-проект и адаптировать его под свои процессы - вот наш вариант. Привет, мистер Столлман!