Управление технологиями

~ 40 минут
Когда в предыдущем уроке рассматривалось построение технического роадмапа, мы говорили в том числе о повышении эффективности через работу с технологиями и инновациями. Ведь ситуация, когда в компании никто не следит ни за стеком, ни за версиями этого стека, не такая редкая. Это приводит к проблемам наподобие уязвимости Log4J в старых версиях.
Но уследить в условном экселе или Wiki за стеком трудно, а ещё труднее начать это делать. И если для систем были придуманы методы инвентаризации типа TIME, то для управления стеком Throughworks был придуман подход с использованием технического радара. Он является частью технической стратегии и позволяет в том числе формировать роадмап.
✏️ Технический, или технологический, радар — это визуальное представление, которое классифицирует технологии по таким критериям, как зрелость, актуальность и потенциальное влияние.
Подход преследует несколько целей:
  • стратегическое управление технологиями,
  • осознанное изучение трендов,
  • развитие сотрудников,
  • управление знаниями.
В этом уроке посмотрим, в чём суть метода, и сделаем свой.

Методология

Скриншот с сайта Zalando Tech Radar.
Технический радар использует два элемента классификации — квадранты и кольца.
Квадранты представляют различные виды точек. Кольца указывают, на какой стадии находится жизненный цикл внедрения той или иной технологии.

Квадранты

Квадранты представляют собой классификацию по различным граням технического ландшафта:
  • Языки программирования и фреймворки — это инструменты, которые мы используем для написания программ. Например, Python или React.
  • Инструменты — дополнительные «помощники», которые помогают в работе. Например, базы данных (PostgreSQL), системы для написания кода (Visual Studio Code), системы управления версиями (Git) или инструменты автоматизации (Jenkins для CI/CD).
  • Платформы — то, на чём создаётся и работает программное обеспечение. Например, мобильные платформы (Android), виртуальные машины (JVM) или облачные сервисы (AWS, Azure).
  • Методы — к ним относятся элементы процесса разработки программного обеспечения, такие как микросервисы или Data Mesh.
Важно понимать, что такое разделение — это оригинальная, базовая, версия. Никто не мешает сделать свою классификацию, которая будет лучше отражать ваш ландшафт.
Например, для компании, которая в основном работает с данными и ML, актуальней будут:
  • языки программирования и фреймворки,
  • ML-инструменты,
  • архитектура данных,
  • интеграции.

Кольца

Суть колец — отразить жизненный путь технологий от появления до вывода из эксплуатации. Кольца подразделяются на следующие:
  • Adopt — устоявшиеся технологии. Они используются в проде, имеют низкий уровень риска и рекомендуются к широкому применению.
  • Trial — «пробные» технологии или «технологии на подъёме», которые успешно работают и проверены на реальной проблеме, но у которых, возможно, выявлены ещё не все ограничения. У таких технологий степень риска пока выше в силу небольшого применения.
  • Asset — «оценочные» технологии, которые являются многообещающими и имеют явную потенциальную ценность для организации — те самые инвестиции. Они подходят для создания прототипов в целях выявления ограничений и возможностей.
💡Технологии asset сопряжены с более высокими рисками — они часто являются совершенно новыми и практически непроверенными даже в масштабах сообщества и требуют накопления знаний по ним перед применением для решения реальных проблем.
  • Hold — по факту технологии, которые больше нежелательны для применения в новых проектах. Они с большой вероятностью будут постепенно выводиться из ландшафта.
Как и квадранты, кольца можно адаптировать под себя. Например:
  • Стратегические технологии — технологии, которые активно применяются в проектах и приносят пользу. По ним много экспертизы и специалистов.
  • Потенциальные — те, что уже опробованы, но по которым пока мало специалистов и применений.
  • Инновационные — технологии, в которые команда верит и которые готова пробовать.
  • Устаревшие — технологии, от которых команда хочет избавиться при первой возможности.
Дополнительно технология в том или ином кольце помечается как «новая», «без изменений», «двигающаяся вперёд/назад» — это тренды движения.
Источник: Languages & Frameworks компании Thoughwokrs.

Технический радар

Технический радар — это постоянно обновляемый инструмент. Необходимо на регулярной основе актуализировать как знания по технологиям (важные ссылки, основные эксперты и так далее), так и их движение. Делать это рекомендуется не реже чем раз в полгода, но на самом деле частота зависит от категории инструментов.
Например, фреймворки и языки могут обновляться сильно чаще, чем подходы и практики. Поэтому для каждого квадранта ещё важно определить горизонт пересмотра. Этим обычно занимаются ответственный за архитектуру, старшие инженеры и разработчики.
Сам процесс движения достаточно простой, нужны:
  • Драйвер — инженер, который управляет переходом технологии или метода на радар.
  • Потребность или проблема, то есть причина, по которой происходит движение. Обычно это потребность в улучшении существующей системы или решение технической или продуктовой проблемы. Примерами могут служить отказ от какой-нибудь технологии в силу внешних причин, переход на решение с открытым исходным кодом для снижения затрат или внедрение новой технологии для создания конкретной системы или функции, необходимой в продукте.
  • Документ с техническим решением. Это документ, описывающий проблему, требования и детали предлагаемого решения. Он служит не только для фиксации принятых решений, но и для получения обратной связи и предоставления подробной информации о причинах, по которым были приняты те или иные технологические решения. Можно использовать RFC (Request for Comments, запрос на комментарии) или знакомый вам ADR.
  • Сам переход — движение по кольцам. На самом деле это довольно сложная в плане ресурсов задача: на неё может потребоваться время и деньги, чтобы начать изучать что-то новое.
Иногда путь чуть короче, если технология уже достаточно зрелая вне компании.
Самая большая проблема формирования технического радара — собрать эту базу знаний. И тут возможно только постепенное накопление через инвентаризацию приложений и опросов разработчиков.

Сергей

Как этот процесс выглядит в целом?

Общий подход к формированию

  1. Сделать структуру
Разделите технологии на соответствующие категории, которые обеспечат общую структуру для анализа технологических изменений. Это те самые языки, инструменты и прочее.
  1. Определить уровень зрелости и горизонт пересмотра
Можно воспользоваться уровнями технологической готовности — TRL и определить, в каком состоянии применения и зрелости технология в вашей компании.
Концепт — это начальная стадия, где появляется идея и видение, формируется базовая версия продукта или услуги (MVP), которая становится ключевым активом (asset) для оценки потенциала.
Разработка — это следующий этап, на котором концепт тестируется и дорабатывается через применение в нескольких пилотных проектах (trial), чтобы подтвердить его работоспособность и выявить слабые места.
Внедрение — это финальная стадия, когда продукт или услуга уже готовы для масштабного использования и активно адаптируются (adopt) широким кругом пользователей или организаций.
  1. Оценить риски и воздействие
Оцените потенциальное влияние каждой технологии на организацию, включая преимущества, риски и стратегическую согласованность. 
Например, стратегия некоторой компании диктует использовать только open-source решения или решения от российских IT-компаний. Если компания очень хочет продолжать использовать привычный SQL Server, есть риски потерять лицензии из-за санкций, получить штрафы, если это государственная компания, и другие. Значит, пока технологию убрать невозможно, но нужно запретить дальнейшее использование — статус hold.
Предлагаем посмотреть, как это выглядит на практике.

Практика

Классический вариант — это небольшое SPA-приложение, но есть и варианты полноценных порталов разработчика типа Backstage от Spotify.
  1. Возьмём за основу технический радар от AOE. Создадим директорию tech_radar и файл package.json внутри.

JSX

{
  "name": "practicum-techradar",
  "version": "1.0.0",
  "license": "MIT",
  "scripts": {
    "build": "techradar build",
    "serve": "techradar serve"
  },
  "dependencies": {
    "aoe_technology_radar": "^4"
  }
}
  1. Устанавливаем. Версия NodeJS, который используется в примере — v23.7.0, npm — 10.9.2.

BASH

npm install
  1. Поменяем логотип.

BASH

mkdir public
cd public
wget https://code.s3.yandex.net/main-page-v5/Logo.svg
mv Logo.svg logo.svg
  1. Создадим файл config.json для настроек в корне проекта и добавим туда пока одну настройку.

JSON

{
    "basePath": "/"
}
  1. Проверим, что получилось.

BASH

npm run build
npm run serve
  1. Открываем localhost:3000.
  1. Немного кастомизируем. Меняем настройки в config.json.

JSON

{
    "basePath": "/",
    "baseUrl": "",
    "editUrl": "",
    "logoFile": "logo.svg",
    "jsFile": "",
    "toggles": {
      "showChart": true,
      "showTagFilter": true,
      "showQuadrantList": true,
      "showEmptyRings": false
    },
    "sections": ["radar", "tags", "list"],
    "colors": {
      "foreground": "#fcf2e6",
      "background": "#113521",
      "highlight": "#d4a373",
      "content": "#fff",
      "text": "#575757",
      "link": "#bc6c25",
      "border": "rgba(255, 255, 255, 0.1)",
      "tag": "rgba(255, 255, 255, 0.1)"
    },
    "quadrants": [
      {
        "id": "languages-and-frameworks",
        "title": "Языки и Фреймворки",
        "description": "",
        "color": "#a3b18a"
      },
      {
        "id": "methods-and-patterns",
        "title": "Практики и Паттерны",
        "description": "",
        "color": "#588157"
      },
      {
        "id": "platforms-and-operations",
        "title": "Платформы",
        "description": "",
        "color": "#3f633e"
      },
      {
        "id": "tools",
        "title": "Инструменты",
        "description": "",
        "color": "#40713f"
      }
    ],
    "rings": [
      {
        "id": "adopt",
        "title": "Активно используем",
        "description": "",
        "color": "#588157",
        "radius": 0.5,
        "strokeWidth": 5
      },
      {
        "id": "trial",
        "title": "Пробуем",
        "description": "",
        "color": "#457b9d",
        "radius": 0.69,
        "strokeWidth": 3
      },
      {
        "id": "assess",
        "title": "Изучаем",
        "description": "",
        "color": "#bc6c25",
        "radius": 0.85,
        "strokeWidth": 2
      },
      {
        "id": "hold",
        "title": "Выкидываем",
        "description": "",
        "color": "#d62828",
        "radius": 1,
        "strokeWidth": 0.75
      }
    ],
    "flags": {
      "new": {
        "color": "#f1235a",
        "title": "Новое",
        "titleShort": "N",
        "description": "Новое в этой версии"
      },
      "changed": {
        "color": "#40a7d1",
        "title": "Изменено",
        "titleShort": "C",
        "description": "Недавно менялось"
      },
      "default": {
        "description": "Нет изменений"
      }
    },
    "chart": {
      "size": 800,
      "blipSize": 12
    },
    "social": [
    ],
    "imprint": "",
    "labels": {
      "title": "Учебный технический радар",
      "imprint": "",
      "quadrant": "Технические области",
      "quadrantOverview": "Подробнее",
      "zoomIn": "Приблизить",
      "filterByTag": "Отфильтровать по тегу",
      "footer": "Учебный радар в рамках курса Архитектор ПО от Яндекс Практикума",
      "notUpdated": "Давно не менялось",
      "notFound": "404",
      "pageAbout": "Как пользоваться",
      "pageOverview": "Обзор технологий",
      "pageSearch": "Поиск",
      "searchPlaceholder": "Что ищете?",
      "metaDescription": ""
    }
  }
  1. Предлагаем убрать чудесный болотный цвет — его можно поменять на любой, который кажется симпатичным. Сделаем это в config.json.

JSON

{
    ....
    "colors" : 
        "foreground": "#fcf2e6",
      "background": "#808080",
    ....
}
  1. Перезапускаем.

JSON

npm run serve
  1. Теперь наполним радар чем-нибудь более показательным, чем текущие Demo. Для этого в директории radar в корне проекта удалим всё и создадим директорию 2024-12-27. Внутри создадим пару md-файлов.
datalakehouse.md

MARKDOWN


title: "Iceberg"
ring: adopt
quadrant: platforms-and-operations
tags: [new]


Apache Iceberg
И, например, datamesh.md.

MARKDOWN


title: "Data Mesh"
ring: adopt
quadrant: methods-and-patterns
tags: [new]


Data Mesh

![stub](/images/logo.svg)
  • title — название технологии;
  • ring — кольцо (идентификатор из config.json);
  • quadrant — квадрант (идентификатор из config.json);
  • tags — произвольно для быстрого доступа.
  1. Можно вставить изображение, которое предварительно положим в images директорию в public (images нужно создать).
Получится вот такая структура (файл about.md можно создать и написать там — это отразится в «Как пользоваться радаром»).
  1. Перезапускаем.

MARKDOWN

npm run server
Поменялась версия, так как у нас осталась одна директория в папке radar. При пересмотре номер версии растёт по мере появления новых дат. У нас появились технологии.
  1. Можно выбрать и открыть.
Отображается та самая картинка из datamesh.md.
  1. Можно прилинковать ADR и положить его в public/adr.

MARKDOWN


title: "Data Mesh"
ring: adopt
quadrant: methods-and-patterns
tags: [new]


Data Mesh

![stub](/images/logo.svg)

[ADR](/adr/datamesh.md)
  1. Если добавить ещё несколько версий (например, три), как настроено в исходниках техрадара, то некоторые технологии начнут отображаться уже не точками, а треугольниками. Это знак того, что их давно не пересматривали.
А самые свежие будут отображаться как N внизу (меняется в config.json).
💡 В базовой версии техрадар готов и при регулярном использовании и пересмотре помогает следить за зоопарком. Его можно улучшить — сделать его as code — править файлы и через CI/CD разворачивать новую версию с отправкой в чат всем заинтересованным.
Желательно построить процесс архитектурного ревью также as code, удобно связывать решения и технологии в обе стороны и не терять знания.

Исходники

tech_radar

Задание 1

Компания Thoughtworks разрабатывает и обновляет свой технический радар, чтобы следить за трендами и улучшать управление технологиями. Недавно специалисты добавили в категорию Trial новую CI/CD-платформу для оптимизации процессов доставки ПО. Однако некоторые разработчики считают, что эту технологию можно сразу перевести в Adopt, чтобы ускорить внедрение. Компания обсуждает, как поступить.
Что должна сделать Thoughtworks с технологией из категории Trial, прежде чем переводить её в Adopt?

Задание 2

Какие шаги должны предпринять инженеры Thoughtworks для успешного внедрения новой CI/CD-платформы?

Задание 3

Что произойдёт, если Thoughtworks решит перевести технологию из Trial в Adopt без полного тестирования?

Что почитать про технический радар

Итоги

  • Управлять технологическим стеком через Excel или Wiki сложно, поэтому Thoughtworks разработал технический радар — визуальный инструмент для классификации технологий по зрелости, актуальности и влиянию. Радар позволяет осознанно выбирать и внедрять технологии, отслеживать их жизненный цикл и поддерживать стратегическое развитие технического стека, используя классификацию по квадрантам (виды технологий) и кольцам (стадии их внедрения).
  • Квадранты технического радара классифицируют технологии по категориям: языки программирования и фреймворки, инструменты, платформы и методы. Это базовое деление, которое можно адаптировать под нужды компании.
  • Кольца технического радара отображают жизненный цикл технологий: Adopt — проверенные и рекомендуемые к широкому применению; Trial — перспективные технологии, успешно протестированные, но с некоторыми рисками; Asset — многообещающие, но ещё непроверенные технологии для экспериментов; Hold — устаревающие технологии, которые не стоит использовать в новых проектах и которые постепенно выводятся из стека.
  • Формирование технического радара включает разделение технологий на категории, оценку их зрелости с использованием подходов вроде TRL и анализ рисков и влияния. Технологии должны быть согласованы со стратегией компании, несоответствующие же могут быть переведены в статус Hold, чтобы ограничить их дальнейшее использование.