Рационализация портфеля приложений: как решить, что модернизировать в первую очередь

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

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

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

Модель оценки — это не то, что тормозит процесс

Матрица 2x2, ранжирующая приложения по стоимости и бизнес-ценности, — это не то место, где умирают проекты по рационализации. Оценка — это механика; режим отказа здесь организационный. У каждого приложения в списке есть владелец, который будет его защищать, и этот владелец обычно является единственным источником данных, необходимых для честной оценки.

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

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

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

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

Рационализация — это не модернизация.

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

Gartner формализовала классификационный словарь — tolerate (терпеть), invest (инвестировать), migrate (мигрировать), eliminate (устранить) — как модель TIME в 2015 году, и она остается сокращением, которое до сих пор используют большинство обзоров портфелей. При правильном подходе это ежеквартальный цикл обзора, встроенный в управление, а не разовая проверка, которая устаревает к следующей реорганизации.

Почему модель оценки редко тормозит проект рационализации

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

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

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

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

Пять измерений для оценки приложений

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

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

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

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

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

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

Почему матрица 2x2 дает обоснованный ответ, а не решение

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

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

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

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

Мы видели, как два подхода прямо противоречат друг другу. Матрица стоимости/ценности ранжирует систему как чистого кандидата на вывод из эксплуатации (низкая ценность, высокая стоимость эксплуатации), пока карта зависимостей не показывает, что это вышестоящий сервис идентификации, к которому обращаются дюжины других приложений при каждом запросе. Матрица сказала «вывести из эксплуатации». Граф сказал: «это приложение переносится последним, если вообще переносится».

Получение честных данных для оценки, когда владелец системы — ваш единственный источник

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

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

Используйте триангуляцию вместо опросов. Частота неудачных изменений (change-failure rate) — показатель надежности, установленный исследовательской программой DORA в качестве ключевого операционного сигнала, — показывает, насколько на самом деле хрупко приложение, независимо от отчетов его владельца. Элитные и низкоэффективные команды находятся в совершенно разных точках этой шкалы. Бенчмарки частоты неудачных изменений: элитные — 0-15%, высокие — 16-30%, средние — 31-45%, низкие — 46-60% (IBM (со ссылкой на фреймворк DORA), 2024).

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

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

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

Что означают TIME и 6R и где искать полную модель

Модель TIME присваивает каждому приложению одну из четырех меток: Tolerate (терпеть), Invest (инвестировать), Migrate (мигрировать) или Eliminate (устранить). Gartner представила TIME как сокращение для результата упражнения по рационализации приложений, а не как метод его достижения. Оценка приложения по критичности для бизнеса, стоимости изменений и радиусу поражения показывает его место в матрице. TIME просто дает название квадранту.

Словарь 6R (rehost, refactor, rebuild и другие) отвечает на другой вопрос: как именно перенести приложение, если оно помечено как Migrate или Invest? Это дерево решений, включая то, когда достаточно простого переноса (rehost), а когда нет, описано в нашем руководстве по модернизации устаревших систем.

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

Последовательность рационализации по зависимостям, а не по оценке

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

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

Типичный сценарий сбоя: устаревший промежуточный сервис (middleware) занимает место в топе квадранта «устранить» по всем осям, кроме радиуса поражения, а граф зависимостей показывает, что нижестоящие сервисы все еще вызывают его напрямую, что не задокументировано в CMDB.

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

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

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

Как часто следует проводить обзор рационализации?

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

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

Триангулируйте ежеквартальное обновление с операционными данными, которые у вас уже есть: частотой неудачных изменений, объемом тикетов и нагрузкой на дежурных. DevOps Research and Assessment (DORA) рассматривает частоту неудачных изменений как ключевой показатель надежности именно потому, что он выявляет системы, чей реальный профиль риска расходится с тем, насколько стабильными они выглядят на бумаге. Ежеквартальный цикл позволяет поймать этот дрейф до того, как он превратится в очередную презентацию для консультантов.

Успех здесь зависит от отслеживания правильных инженерных метрик, а не «тщеславных» цифр, которые хорошо смотрятся в отчетах о статусе.

Когда не стоит проводить упражнение по рационализации?

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

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

Если решение о выводе из эксплуатации или переносе на новую платформу требует пересборки, привлеките опытного партнера по разработке до того, как оценивать объем работ.

Этот порог — не жесткое правило, и его превышение не обязательно увеличивает ваши расходы. Портфель из 25 тесно связанных приложений с общей базой данных может нуждаться в рационализации больше, чем 60 слабо связанных. Сигнал заключается в том, понятны ли владение и бизнес-ценность без формального обзора; если да, проведите сессию по определению объема работ вместо полноценного упражнения по портфелю.

Рационализация против модернизации: В чем разница?

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

Рационализация — это решение о фундаментальном состоянии: сохранено, удалено или консолидировано. Стоимость эксплуатации и стоимость изменений являются входными данными для этой оценки, а не сам бэклог модернизации; дешевое в эксплуатации приложение все равно может быть плохой инвестицией, если оно дублирует систему с меньшим радиусом поражения.

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

Сначала проведите рационализацию как общепортфельный этап, а затем передайте сохраненный набор для модернизации. Мы рассматриваем этот второй шаг, включая компромиссы между переходом на другую платформу (rehost), рефакторингом (refactor) и перестройкой (rebuild), в статье «Что такое модернизация приложений?», а эта статья посвящена решению о том, что вообще следует затрагивать.

Часто задаваемые вопросы: Рационализация, оценка и сроки анализа

Чем рационализация отличается от инвентаризации приложений?

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

Как вы оцениваете портфель приложений?

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

В чем разница между рационализацией и модернизацией?

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

Сколько времени занимает оценка портфеля приложений?

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

Получите второе мнение по оценке вашего портфеля

Картирование зависимостей выявляет то, что упускает матрица стоимости/ценности: приложение, от которого ничего не зависит, редко является тем, которое ваша оценка рационализации отметила первым. Взгляд со стороны на этот график, прежде чем вы выделите квартал на последовательность действий, часто является самым дешевым риском, который вы устраняете в этом цикле.

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