Построение технологического радара для технического планирования и бизнес-витрины
Технологический радар – это инструмент для визуализации и управления портфелем технологий в компании. Он помогает команде понимать, какие технологии активно используются, какие находятся на испытании или оценке, а от чего следует отказаться.
Правильно спроектированный радар может одновременно служить двум целям: во-первых, быть внутренним ориентиром для планирования ИТ-стека (для инженеров и архитекторов), и во-вторых, выступать витриной для бизнеса – демонстрируя, какие ключевые продукты и решения компания применяет или рассматривает.
Такой двойной подход повышает прозрачность: техническая команда осознаёт стратегию технологического развития, а бизнес-стейкхолдеры видят, как ИТ-инициативы поддерживают бизнес-задачи.
В данной статье мы рассмотрим лучшие практики построения технологического радара для указанных целей. Мы определим различия между понятиями «продукт» и «технология» в контексте радара, предложим подход к их моделированию, обсудим рекомендуемые атрибуты и уровни абстракции, а также приведём примеры реализации техрадара в известных компаниях. Наконец, рассмотрим, когда целесообразно разделять радар на технический и бизнес-ориентированный, и как обеспечить их согласованность.
Разграничение понятий «Продукт» vs «Технология»
Прежде всего, важно чётко определить, что именно будет отображаться на радаре, и разграничить продукты и технологии. Эти термины отличаются уровнем абстракции и аудиторией:
Продукт (решение): готовое прикладное решение или система от определённого вендора. Продукт обычно представляет собой крупный программный комплекс или сервис, предназначенный для решения бизнес-задач. Он может включать в себя встроенные технологии или даже состоять из нескольких компонентов. Продукты ориентированы на конечную бизнес-функцию и часто рассматриваются бизнес-стороной как готовые решения для внедрения.
Технология: более низкоуровневый “строительный блок” ИТ-стека. Под технологиями понимаются языки программирования, фреймворки, библиотеки, инструменты разработки, архитектурные паттерны, методологии и т.д. Технология сама по себе не является прикладным решением для бизнеса, но лежит в основе создания таких решений. Примеры: язык Python, фронтенд-фреймворк React, СУБД PostgreSQL, паттерн CQRS, методология DevOps. Технологии ориентированы на инженерное применение и используются разработчиками для построения продуктов.
Ниже сведём отличия в таблице для наглядности:
| Аспект | Продукт (вендорское решение) | Технология (базовый компонент) |
|---|---|---|
| Назначение | Готовое приложение или сервис для бизнес-задач | Технический инструмент для создания систем |
| Пример | CRM-система Битрикс24, платформы 1С, Microsoft Dynamics | Язык Java, библиотека TensorFlow, паттерн MVC |
| Уровень абстракции | Высокий (макроуровень: включает множество компонентов) | Низкий (микроуровень: единичный компонент или метод) |
| Отношение к другим | Может включать несколько технологий внутри | Может входить в состав продукта или платформы |
| Целевая аудитория | Бизнес-стейкхолдеры, продукт-менеджеры | Разработчики, архитекторы, технические специалисты |
Оба типа – и продукты, и технологии – могут присутствовать на техрадаре, но их роль различна. Продукты показывают, какие крупные решения компания планирует использовать или уже использует для реализации бизнес-функций. Технологии же отражают инструментарий и практики, из которых состоит технический стек, и позволяют отслеживать эволюцию именно технической платформы.
Важно отметить, что грань между продуктом и технологией иногда может быть размытой. Например, Kubernetes можно считать продуктом (орchestration платформа) от сообщества CNCF, но одновременно это и технология контейнерной оркестрации. В таких случаях классификация зависит от контекста использования: если рассматриваем Kubernetes как готовое решение для инфраструктуры – это «продукт», если же акцент на его технических деталях – то «технология». Главное – быть последовательными в определениях внутри организации.
Структура технологического радара: ключевые атрибуты и уровни
При построении радара необходимо определить, какие атрибуты будет содержать каждый элемент радара и как организовать уровни абстракции (сегменты, кольца и т.д.). Ниже перечислены рекомендуемые компоненты модели техрадара:
Название элемента: Короткое имя продукта или технологии. Например, “React 18”, “Microservices”, “Postgres”. Название должно быть однозначным и узнаваемым для команды.
Категория / сегмент: Тематическая категория, к которой относится элемент. Обычно категории радара отражают уровень или область технологии. Классический подход – деление на четыре квадранта, охватывающие весь спектр техстека. Например ThoughtWorks Radar, использует квадранты Techniques, Tools, Platforms, Languages & Frameworks, а Spotify в своем инструменте Backstage Tech Radar рекомендует квадранты Languages, Frameworks, Process, Infrastructure.
Можно выбрать свои сегменты, отражающие специфику компании. Например, если компания сфокусирована на данных, можно выделить отдельный сегмент под Data/ML. Главное – охватить и продукты, и технологии в этих категориях. Продукты-вендоры обычно попадают в категории вроде Platforms или Infrastructure, тогда как сугубо инженерные практики – в Techniques/Process.Кольцо (стадия жизненного цикла): Это ключевой атрибут, показывающий степень освоения или рекомендацию по использованию данного элемента. Чаще всего используется 4 кольца по аналогии с радаром ThoughtWorks.
Названия колец могут немного варьироваться, но суть одна:Adopt (Принять / Использовать) – технологии или продукты, которые уже опробованы и рекомендованы к широкому использованию. Они считаются надёжными, хорошо зарекомендовавшими себя. (Например, компания однозначно стандартизирует использование Kubernetes – тогда он в кольце Adopt).
Trial (Пилот / Эксперимент) – элементы, которые прошли первые пилотные внедрения, успешно показали ценность в ограниченном масштабе и могут использоваться шире с оглядкой. Риск немного выше, чем у Adopt, но организация уже имеет позитивный опыт
Assess (Изучение) – многообещающие новые технологии/решения, на которые стоит обратить внимание, провести исследования или прототипы, но пока рано внедрять в критичных продуктах. Higher risk, новизна. (Например, новая библиотека на подходе – стоит оценить, но не факт, что будем использовать)
Hold (Отложить / Воздержаться) – элементы, которые не рекомендуются для новых проектов. Либо устарели, либо не оправдали ожиданий, либо не подходят нам сейчас. В существующих системах их можно продолжать эксплуатировать, но новые инициативы на них строить не стоит.
Примечание: Названия колец можно локализовать или изменить под внутренние стандарты. Например, некоторые организации используют вместо Adopt термин Use (использовать), вместо Hold – Avoid или Retire (избегать / выводить).
Главное – четко определить критерии для каждого уровня и обучить команду ими пользоваться. Кольца – сердце радара, они придают смысл расположению точек. Как отмечают в ThoughtWorks, именно обсуждение того, в какое кольцо поместить технологию, вызывает наиболее бурные дискуссии, тогда как принадлежность к квадранту менее критична. Это логично: стадия влияет на решение “брать или не брать в работу”, а категория – лишь на таксономию.Описание / комментарий: Краткий текст (несколько предложений) к каждому элементу, поясняющий почему он находится в данной категории и кольце, какова его суть и статус в организации. Например: “Новый ORM-фреймворк X включён в Assess, так как обещает упростить работу с БД, но пока не протестирован на нагрузках”. Такие пояснения нужны для контекста и обучения – особенно когда радар демонстрируется бизнес-аудитории, которая может не знать деталей. В публичном Radar ThoughtWorks каждому элементу сопутствует краткий комментарий с обоснованием рекомендации.
Дополнительные атрибуты:
Связанные продукты/технологии: Если элемент – продукт, стоит указывать, какие ключевые технологии он включает (например, продукт “CMS Y” включает “Java” и “Spring Boot”). И наоборот, для технологии можно ссылаться на продукты или проекты, где она применяется.
Ответственная роль/подразделение: Иногда отмечают, какая команда или эксперт отвечает за мониторинг данной технологии, или кто инициировал её добавление. В Zalando Tech Radar, например, ведение радара курируется Principal Engineers, а вклад может вносить любая команда. Указание ответственных повышает актуальность: понятно, к кому обращаться за опытом.
Дата последнего обновления / пересмотра: полезно отслеживать, когда элемент последний раз оценивался или двигался по кольцам. ThoughtWorks, к примеру, помечает новизну или движение элемента (новый, перемещён в другое кольцо или без изменений) специальными значками на радаре. Внутренне можно хранить историю изменений статуса.
Связь с бизнес-целями: опционально, можно привязать технологию к той бизнес-проблеме, которую она решает. Это особенно полезно на бизнес-ориентированной витрине: например, отметить, что продукт “Data Lake Platform” служит достижению цели “Персонализация маркетинга”.
Структура радара суммируется так: сегменты делят пространство по типам (уровням) технологий, кольца отражают приоритет и стадию принятия, точки внутри несут названия и краткие пояснения. Этот формат доказал удобство: «радар» дает гранулярную категоризацию, в которой каждой технологии отводится своё место по критерию инновационности и зрелости. При этом визуально легко понять, какие вещи уже в работе, а какие пока только на горизонте. Как образно пишет Dr. Tassilo Henike, техрадар работает как маяк в тумане неопределённости, помогая бизнесу держать курс на возможности и обходить риски.
Обобщённая примерная схема сегментов и их уровней абстракции может выглядеть так:
| Сегмент (квадрант) | Примеры содержимого |
|---|---|
| Языки и фреймворки | Языки программирования, runtime-платформы, фреймворки разработки. Примеры: Java, Python, Node.js, .NET, Spring, React, Angular. |
| Инструменты и библиотеки | Утилиты, библиотеки, DevOps-инструменты, инструменты тестирования. Примеры: Docker, Terraform, GitLab CI, JUnit, NumPy. |
| Платформы и продукты | Готовые платформы, сервисы и крупные ПО-продукты (в т.ч. коммерческие). Примеры: AWS S3, Kubernetes, Salesforce, Oracle DB, Kafka (Confluent). |
| Техники и методологии | Архитектурные паттерны, методики разработки, процессы. Примеры: Микросервисная архитектура, REST, Event Sourcing, Agile, DevOps, CI/CD. |
Сегменты могут быть и другими – каждая компания адаптирует под себя. Например, некоторые выделяют отдельно Data & AI или разделяют инфраструктуру и приложения и т.д. Главное – логичность и охват.
Каждый элемент радара относится к одному из таких сегментов и находится на одном из кольцев (Adopt/Trial/Assess/Hold). Благодаря этому достигается многомерная классификация: любой элемент можно отнести к определенной категории технологий и понять, насколько он зрел для использования в данной организации. Визуальный радар часто представляет категории как сегменты круга, а кольца – как концентрические окружности. Это позволяет отразить три важные характеристики сразу: тип, актуальность (стадию) и количество/насыщенность элементов в каждой области.
Примеры реализации технологических радаров в компаниях
Рассмотрим, как концепции техрадара реализованы на практике в известных организациях. Они демонстрируют различные подходы к выбору категорий, атрибутов и одновременному удовлетворению технических и бизнес-потребностей.
ThoughtWorks Technology Radar (эталонный пример)
Самым известным примером является Technology Radar компании ThoughtWorks – консультационной фирмы, которая и популяризировала этот формат. ThoughtWorks публикует свой радар ежемесячно два раза в год (раз в полгода) как открытый отчет для индустрии. В их радаре:
Квадранты (категории) фиксированы: Techniques, Tools, Platforms, Languages & Frameworks. Это охватывает и практики, и инструменты, и продукты платформенного уровня, и языки. Такой набор квадрантов рекомендован как базовый шаблон для любого техрадара.
Ринги (rings): Adopt, Trial, Assess, Hold – с указанными выше значениями. ThoughtWorks явно описывает критерии: Adopt – отрасли следует активно использовать эти элементы, Trial – стоит попробовать, Assess – стоит изучить (потенциально ценное), Hold – применять с осторожностью или избегать. Они публикуют подробные описания для каждого элемента, объясняя, почему он в данном кольце.
Наполнение: Radar ThoughtWorks отражает опыт их глобальной команды на проектах по всему миру. Это не внутренний ИТ-стек одной компании, а скорее обзор технологических трендов, подкрепленный практикой. Тем не менее, формат стал образцом для корпоративных техрадаров. Элементы радара не привязаны к одной компании, но дают оценку применимости технологии в Enterprise в целом. Важная черта: ThoughtWorks не включает конкретные коммерческие продукты по просьбе вендоров – всё основано на независимой оценке своих экспертов. Это обеспечивает объективность.
Данные и поддержка: Радар формируется Technology Advisory Board (TAB) – ~20 ведущих техлидов ThoughtWorks, которые собираются и решают, что включить. Они обсуждают «Cool tech» и приходят к консенсусу по кольцу для каждой позиции. Quadrant для конкретного элемента не считается крайне важным – иногда элемент мог бы попасть в два квадранта, и это не критично. Основной упор – на позицию по кольцу (т.е. рекомендацию).
Радар ThoughtWorks служит в первую очередь навигатором для технического сообщества – CTO, архитекторов, разработчиков во внешних компаниях. Однако и бизнес-лидеры следят за ним, чтобы понять, какие технологии набирают популярность. Это пример единый радар для широкой аудитории, где язык достаточно технический, но ценность понятна и в бизнес-контексте (например, появление новой категории решений может подсказать стратегию инвестиций). ThoughtWorks также предоставляет open-source инструменты для создания собственного радара – компании могут брать за основу их модель.
Zalando Tech Radar (внутренний радар с открытой публикацией)
Zalando – крупная немецкая e-commerce платформа – адаптировала идею техрадара для внутренних нужд и делает его публичным. Zalando Tech Radar был запущен около 2015 года, поддерживается и поныне, и код для его визуализации открыт на GitHub. Особенности реализации Zalando:
Цель и аудитория: Радар служит навигационным инструментом для >200 инженерных команд Zalando при выборе технологий для новых проектов. Одновременно компания выкладывает его в открытый доступ, превращая в витрину технологического ландшафта Zalando и демонстрируя внешнему миру, с какими технологиями они работают. Это как раз пример совмещения двух ролей: внутренней (планирование стека) и внешней (брендинг для IT-сообщества, доверие бизнес-партнеров через прозрачность).
Структура: Zalando придерживается классической 4-х кольцевой модели Adopt, Trial, Assess, Hold, с такими же определениями (переведёнными на внутренний язык при необходимости). Квадранты у них слегка изменены по сравнению с ThoughtWorks. В частности, известно, что в одной из версий они использовали сегменты: Datastores, Data Management, Infrastructure, Languages. Судя по этим категориям, Zalando уделяет большое внимание данным – видимо, у них много технологий в этой области, поэтому разбили на хранилища данных и управление данными отдельно. Это хороший пример адаптации сегментов под свой ландшафт. Каждый элемент (technology/framework/tool) размещён в одном из этих сегментов и в одном из 4 колец.
Ведение и наполнение: За поддержание радара отвечают Principal Engineers Zalando (ведущие инженеры) – они собирают предложения об изменении статуса технологий, обсуждают и голосуют за перемещение по кольцам. Любая инженерная команда может предложить обновление – радар краудсорсится внутри компании, что важно для актуальности. Решения об изменении (например, повысить технологию из Assess в Trial) принимаются коллегиально. На радар включены как сугубо технические компоненты (библиотеки, языки), так и продукты (например, вероятно, у них есть позиция для Kubernetes, AWS Athena и т.п.). О каждом элементе известна его устойчивость в продакшене на масштабе Zalando – то есть оценка исходит из реального опыта. Например, они отмечали переход языка Kotlin в кольцо Adopt после успешного использования его многими командами.
Публикация: На сайте Zalando открыт интерактивный радар (секторный график), а в инженерном блоге публикуются статьи об обновлениях техрадара. Таким образом, внешний мир видит, какие технологии Zalando принял или отверг. Это служит витриной для потенциальных соискателей (показывает, с каким стеком им предстоит работать, что ценится – HR используют радар в общении с кандидатами) и для партнеров/клиентов (демонстрирует технологическую продвинутость компании).
Zalando Tech Radar показал, что единый радар может успешно выполнять внутреннюю функцию и быть коммуникационным инструментом вовне. Ключ – в поддержании его актуальности и вовлечении всех нужных сторон. За счет открытости, радар мотивирует команды конкурировать в позитивном ключе (например, продвинуть “свою” технологию в список Adopt). Это способствует осознанному развитию ИТ-экосистемы компании
Spotify и Backstage Tech Radar (инструментальное решение)
Spotify – известна своей инженерной культурой – также использует подход техрадара, особенно для внутреннего ориентирования команд. Их отличительной чертой стало то, что они воплотили техрадар как плагин к собственной платформе Developer Portal (Backstage) и открыли его для сообщества.
Backstage Tech Radar плагин: Spotify разработала плагин Tech Radar для Backstage (своего open-source портала для разработчиков). Этот плагин визуализирует технологические рекомендации компании прямо внутри внутреннего портала. Он настраиваемый, но по умолчанию Spotify предлагает 4 квадранта: Languages, Frameworks, Process, Infrastructure – практически совпадает с классической схемой, только Techniques переименованы в Process (процессы/методологии). Rings также используются (в плагине дефолтные: Use, Trial, Assess, Hold – это аналог Adopt, Trial, Assess, Hold, просто Adopt назван как Use).
Цель: Инструмент предназначен для того, чтобы каждая команда видела, какие технологии одобрены, какие экспериментируются, а какие не рекомендованы. Он централизует технические стандарты, ускоряет принятие решений и онбординг новых инженеров (они сразу видят, какие инструменты в ходу). По сути, это внутренний справочник по технологиям с визуальным представлением.
Настройка под себя: Хотя Spotify задала структуру, они отмечают, что квадранты полностью настраиваются – организация может определить свои области. Таким образом, Backstage Tech Radar стал универсальным решением, уже используемым в других компаниях. Например, Red Hat интегрировала его в свой стек – документально подтверждена возможность снабжать его данными через JSON, Git и т.д. Для нашей темы важно, что Spotify, подобно ThoughtWorks, не разделяет специально “продукт vs технология”, а разносит по категориям. В квадрант Infrastructure у них, вероятно, попадают инфраструктурные сервисы (в том числе внешние продукты типа AWS Lambda и проч.), в Frameworks – фреймворки (например, Angular, Django), в Process – инженерные практики (Continuous Delivery, Code Review guidelines), и Languages понятно.
Согласование с бизнесом: Spotify публикует свой радар или детали о нём не так активно, как ThoughtWorks или Zalando (он скорее внутренний). Однако сам факт наличия категории Process говорит о стремлении увязать не только сугубо софтверные компоненты, но и процессы разработки – это помогает и бизнесу понимать, какие современные практики (например, Machine Learning Operations) компания осваивает. Кроме того, Backstage как продукт ориентирован на улучшение Developer Experience, что опосредованно приносит бизнес-ценность (быстрее релизы, выше качество).
Итак, Spotify’s Tech Radar – пример того, как автоматизировать ведение техрадара и сделать его частью повседневного инструментария. Инженеры видят его в режиме self-service. Это снижает усилия на поддержку актуальности, а рекомендации становятся прозрачной частью корпоративной культуры. Компании, принявшие Backstage, могут быстро развернуть такой радар под свои нужды.
Другие примеры
Помимо указанных, многие крупные организации внедрили собственные версии техрадаров:
Software AG Technology Radar: Примечателен тем, что его категории привязаны к бизнес-архитектуре компании. Радар Software AG разделён на шесть сегментов, сгруппированных в две группы: три сегмента соответствуют бизнес-направлениям ценности (например, Connected Business Experience, Digital Business Excellence, Ecosystem Driven Economy), а три – технологическим базам (Hybrid & multi-cloud infrastructure, Agile DevOps & Continuous Delivery, Platform enabled ecosystems).
Фактически, компания совместила в одном радаре бизнес-видение (какие ценностные области для клиентов важны) и технологическое основание под ними. В каждом из этих шести сегментов перечислены технологии или продукты, оцененные по кольцам. Такой подход хорош тем, что бизнес-ориентированные лица сразу видят технологический ландшафт через призму бизнес-ценностей. Software AG также слегка модифицировала названия колец – например, вместо Hold использовано Hold / Reduce с пояснением, что это значит (технология не рекомендуется большинству, либо рынок не зрел, либо есть лучшие альтернативы). Это пример тесной увязки радара с бизнес-стратегией.Банковский сектор и др.: Известно, что банки (ING, ABN AMRO), ритейл-компании и даже госорганизации создают собственные радары. Например, в России упоминается запуск техрадара для отрасли ритейла Ростелекомом. Обычно они следуют схеме ThoughtWorks, но могут добавлять свои фишки – например, у кого-то 5 колец (добавляют стадию “внедряется” между Trial и Adopt, или “депрекейт” после Hold), или другие визуальные обозначения. В одном из примеров (Swedish Pensions Agency – MinPension Tech Radar) сегменты были: Technology, Employees, Collaboration, Business – то есть тоже смешение человеческих и бизнес-факторов с технологиями. Это свидетельствует, что радар – гибкий инструмент: он может отображать не только технологии, но и, к примеру, компетенции сотрудников или бизнес-тренды, если это сделает картину полезнее.
Итого: хотя визуальный формат “радара” примерно одинаков, каждая компания адаптирует содержание под себя. Общим остаётся принцип кольцевой оценки и сегментации. Реальные примеры показывают, что техрадар способен быть не просто техно-реестром, но и элементом коммуникации стратегии – как технической, так и бизнес.
А что в России?
Российские компании активно перенимают международный опыт и адаптируют технологические радары под свои задачи. Среди наиболее ярких примеров — Тинькофф, Сбер и Ростелеком.
Тинькофф одним из первых российских банков публично представил свой технологический радар, во многом вдохновлённый ThoughtWorks. Он содержит четыре стандартных квадранта («Языки и фреймворки», «Платформы и инфраструктура», «Инструменты», «Методики») и четыре уровня оценки («Используем», «Пробуем», «Изучаем», «Избегаем»). При этом Тинькофф регулярно публикует подробные обновления радара с пояснениями по каждой технологии: почему она была принята, какие преимущества дала командам и как повлияла на продукты. Радар Тинькофф стал эффективным инструментом HR-бренда, помогая привлекать квалифицированных специалистов и формировать образ открытой и технологически продвинутой компании.
Сбер применяет технологический радар в масштабе всей экосистемы. Структурно он также близок к модели ThoughtWorks, но Сбер делает особый акцент на прикладном применении технологий в своих внутренних проектах и продуктах для клиентов. В частности, выделяются сегменты, связанные с AI, Data Science, облачными платформами и инструментами цифровой трансформации. Важно, что радар Сбера встроен в корпоративные процессы и активно используется для стратегического планирования, координации команд и коммуникаций с бизнесом. Это позволяет технологическим инициативам быть максимально прозрачными и понятными для всей организации.
Ростелеком пошёл ещё дальше в адаптации радара, сфокусировавшись на задачах цифровой трансформации различных отраслей российской экономики. Особенностью подхода стало выделение решений, соответствующих требованиям импортозамещения и отечественным стандартам. В радаре Ростелекома заметное место занимают отечественные продукты, платформы и решения по информационной безопасности. Такой подход облегчает взаимодействие компании с государственными заказчиками и крупными коммерческими клиентами, для которых важно соответствие регуляторным требованиям и отраслевым стандартам.
Опыт российских компаний показывает, что технологический радар не только отлично прижился в России, но и стал важным элементом коммуникации: от демонстрации технического лидерства и привлечения талантов до стратегического управления развитием технологий внутри крупнейших организаций страны.