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

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

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

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

Модель оценки — это не то, из-за чего всё буксует

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Упорядочивайте рационализацию по зависимостям, а не по оценкам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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