Зачем ИТ-компании несколько технологических радаров

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

Ловушка единого радара

Представьте технологический радар крупной ИТ-компании. В одном списке находятся Java и Spring, Angular и React, Kubernetes и Terraform, базы данных, системы мониторинга, инструменты тестирования и десятки других технологий.

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

С одной стороны технологии на радаре можно пометить тегами (например для React вполне себе подойдет тег Frontend), тогда отображаемые технологии можно будет фильтровать. С другой - в большой компании множество подразделений, и в каждом из них одна и та же технология может находиться в разных статусах жизненного цикла.
Результат - дублирование технологии на радаре или частичное сокрытие технологической картины.

Множественность контекстов

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

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

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

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

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

Кейс 1. Разделение по инженерным слоям

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

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

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

Кейс 2. Публичный и приватный радар

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

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

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

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

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

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

Вместо попытки найти единственный статус технологии на всю компанию можно определить статус в рамках конкретного контекста.

Как подойти к настройке нескольких радаров

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

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

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

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

Один инструмент — множество радаров

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

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

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

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

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