Совещание по оптимизации приложений начинается в 9 утра. К 11 утра команда классифицировала двенадцать из четырехсот приложений, находящихся в сфере действия. Три из этих двенадцати классификаций уже были оспорены, пересмотрены и снова оспорены. Пакетная программа на COBOL, отвечающая за расчет заработной платы, явно не подлежит исключению, но подлежит ли она терпимости или инвестированию? Устаревшая система выставления счетов, которую все признают технически неадекватной, явно подлежит миграции, но на что именно мигрировать, и что произойдет с семнадцатью программами, которые от нее зависят? Совещание запланировано до полудня. В полдень кто-то предлагает продолжить на следующей неделе. К следующему месяцу инициатива незаметно перестала приносить результаты.
Модель Gartner TIME — наиболее широко используемая система управления портфелем приложений в корпоративных ИТ-системах. Она распределяет каждое приложение в портфеле по одному из четырех уровней: «Терпеть», «Инвестировать», «Мигрировать», «Устранить», используя два критерия оценки: бизнес-ценность и техническое соответствие. Эта система логически обоснована, широко применима и упоминается в руководстве по рационализации приложений Федерального совета CIO США как рекомендуемая методология. Однако на практике она чаще терпит неудачу, чем добивается успеха, по причине, которую сторонники системы упоминают, но редко развивают: классификация хороша лишь настолько, насколько хороши лежащие в её основе доказательства. Без структурных доказательств, реального количества зависимостей, реальных измерений сложности, реальных данных о бизнес-ценности, полученных из трассировок выполнения, а не из интервью с владельцами, классификация TIME превращается в организационную политику. Споры о размещении начинаются на уровнях «Мигрировать» и «Устранить», где на кону стоит чьё-то любимое приложение, и они никогда не разрешаются.
Dead Code Changes Classifications
SMART TS XL’s dependency mapping confirms whether an Eliminate candidate is truly standalone or carries hidden dependencies that block decommission.
УЗНАТЬ БОЛЬШЕ…Модель: две оси, четыре положения
Модель TIME отображает каждое приложение на матрице 2×2. По горизонтальной оси откладывается техническая пригодность, то есть насколько хорошо текущая техническая реализация приложения поддерживает его предполагаемую функцию: качество архитектуры, удобство сопровождения, возможности интеграции, уровень безопасности, операционная надежность. По вертикальной оси откладывается деловая ценность, то есть насколько важна функция приложения для бизнес-операций организации, получения дохода, соблюдения нормативных требований или стратегических целей.
| Высокая техническая пригодность | Низкий уровень технической посадки | |
|---|---|---|
| Высокая коммерческая ценность | инвестиция Профинансируйте его. Приложение имеет как стратегическое значение, так и техническую обоснованность. Инвестируйте, чтобы сохранить его лидирующие позиции. | МИГРАЦИЯБизнесу это нужно, технология не подходит. Замените платформу, а не функциональность. |
| Низкая коммерческая ценность | ТЕРПИТЬПока оставьте его в покое. Приложение полезное, но не стоит дополнительных инвестиций. | УСТРАНИТЬОтправьте его на пенсию. Низкая ценность, низкое качество, нет смысла его хранить. |
Простота выбрана намеренно. TIME не предназначен для детального планирования инвестиций, он разработан для принятия однозначных решений о направлении инвестиций для каждого актива в портфеле. Актив, который невозможно однозначно классифицировать, требует дополнительной информации для определения его категории.
Четырехквадрантные операционные модели
Каждый вариант использования TIME — это не просто метка, это операционная модель, определяющая, как организация будет управлять приложением в дальнейшем.
Инвестиции: извлечение максимальной выгоды
Инвестиционные приложения — это жемчужина портфеля: высокая коммерческая ценность, высокая техническая пригодность. Они оправдывают самые агрессивные инвестиции в новые функции, оптимизацию производительности, расширение интеграции и поддержание технической актуальности. Инвестиционное приложение, которое отстает по технической актуальности, имеет устаревшую среду выполнения, неактуальную систему безопасности или накапливает долги по зависимостям, рискует перейти в стадию миграции еще до того, как это будет замечено.
Операционные обязательства Invest:
- Специализированные инженерные ресурсы для разработки новых функций и технического обслуживания.
- Первоочередное обновление системы безопасности и соответствие нормативным требованиям.
- Освещение деятельности архитектурно-экспертного совета по каждому значительному изменению
- Проактивный мониторинг с целевыми показателями SLA на уровне Tier 1.
Миграция: замена платформы, сохранение функциональности.
Миграция приложений позволяет выполнять бизнес-функции, действительно необходимые организации, но на технической платформе, которая больше не является адекватной, слишком дорога в обслуживании, слишком ненадежна для расширения и слишком изолирована от современной интеграционной среды. Бизнес-ценность оправдывает инвестиции в миграцию; техническое состояние делает дальнейшие инвестиции в текущую платформу нерентабельными.
Решение о миграции отвечает на конкретный вопрос: стоит ли сохранять эту функцию? Если да, то следует осуществить миграцию. На что именно мигрировать и как — это отдельное решение, которое классификация TIME не принимает, она лишь устанавливает, что текущая платформа не является оптимальным вариантом.
Наиболее распространенный сценарий миграции в устаревших средах: пакетная программа на COBOL, реализующая критически важную бизнес-логику, сложные расчеты в соответствии с нормативными требованиями, собственные правила ценообразования, налоговую логику, специфичную для каждой юрисдикции, размещается на платформе, расширение, тестирование и интеграцию которой обходятся дорого. Логика незаменима; проблема в платформе. Необходимо перейти на современную платформу, которая сохранит логику, обеспечивая при этом необходимые бизнесу операционные характеристики.
Терпимость: преднамеренное бездействие с ограниченным сроком действия.
Наиболее часто неправильно понимают квадрант «терпимость». Это не означает «это приложение в порядке». Это означает «техническое качество этого приложения не оправдывает инвестиций в его изменение прямо сейчас, а его коммерческая ценность не оправдывает его удаление». Это осознанный выбор принять существующее положение дел на определенный период, а не бессрочная отсрочка.
«Допустимость» — это временная приостановка, а не постоянное состояние. Каждое приложение, находящееся в квадранте «Допустимость», должно иметь четко определенную дату проверки, как правило, от 12 до 18 месяцев, и определенные условия, которые приведут к досрочной переклассификации: уязвимость безопасности, которую невозможно устранить, вывод из эксплуатации зависимостей, требующий смены платформы, увеличение бизнес-ценности, делающее приложение достойным инвестиций, или изменение бизнес-функции, которое делает его непригодным для использования.
Организации, которые рассматривают концепцию «терпимого уровня» как необратимую, накапливают именно тот технический долг, предотвращению которого была призвана служить модель TIME. Программа на COBOL, прошедшая «терпимый уровень» в 2019 году и остающаяся в квадранте «терпимый уровень» в 2026 году, получила еще семь лет отложенного технического обслуживания, которое в конечном итоге ей потребуется, либо в экстренном случае при поломке, либо в результате принудительной миграции, когда платформа больше не может поддерживаться.
Исключить: решение, которое принимают все, но никто не исполняет.
Исключение — наиболее прямолинейная классификация и наименее реализованный вариант. Приложение имеет низкую коммерческую ценность и низкую техническую пригодность, нет оснований для его сохранения. Его следует вывести из эксплуатации.
Неудача в реализации хорошо задокументирована: пункт «Исключить» заполняется с энтузиазмом, но практически никогда не предпринимается никаких действий. В ходе анализа портфеля крупного финансового учреждения в 2024 году было выявлено 87 кандидатов на включение в список «Исключить». Спустя восемнадцать месяцев 71 из них все еще оставались в списке. Именно в промежутке между классификацией и выводом из эксплуатации программы рационализации теряют свою динамику.
Три конкретных препятствия мешают реализации концепции «исключения»:
Скрытые зависимости. Приложение было классифицировано как «Не подлежит исключению» на основании его кажущейся автономности. После классификации структурный анализ показал, что двенадцать других программ генерируют выходные данные, которые обрабатывает кандидат на классификацию «Не подлежит исключению», или что три внешние системы передают ему данные через недокументированный файловый интерфейс. Приложение не является автономным; это скрытая инфраструктура для других систем. Классификацию необходимо пересмотреть.
Препятствия для миграции данных. Приложение хранит данные, которые нельзя уничтожить, нормативные документы с обязательными сроками хранения, данные клиентов, которые необходимо перенести в систему-преемника, а также исторические записи транзакций, которые ежегодно проверяются в рамках аудиторских процессов. Миграция данных должна предшествовать выводу системы из эксплуатации, а миграция данных — дорогостоящий процесс.
Нормативно-правовые обязательства. Некоторые приложения нельзя вывести из эксплуатации, даже если их коммерческая ценность равна нулю, поскольку нормативные рамки требуют наличия предоставляемых ими возможностей. Приложение для отчетности, которое формирует ежеквартальную отчетность перед регулирующими органами, имеет нормативно-правовую ценность, которая не отражается ни в одном исследовании коммерческой ценности. До тех пор, пока нормативное обязательство не будет передано другой системе, приложение должно продолжать работу.
Проблема доказательств: почему TIME терпит неудачу без структурных данных.
Наиболее существенный недостаток в реализации TIME точно описан в документации Catio: споры о размещении начинаются с вариантов «Миграция» и «Устранение», где на кону стоит любимое приложение. Без объективных доказательств каждая классификация превращается в переговоры. Владелец приложения выступает за «Инвестирование». ИТ-команда выступает за «Миграцию». Финансовая команда хочет «Устранить». Встреча заканчивается выбором «Терпимость», потому что это наименее спорная позиция.
Структурные данные разрешают эти споры, заменяя субъективное мнение измерениями.
Для оценки соответствия техническим требованиям важны следующие данные:
| Технический индикатор соответствия | Источник | Движется классификация в сторону |
|---|---|---|
| Цикломатическая сложность на программу (в среднем) | Статический анализ кода | Низкий уровень = более высокая посадка, Высокий уровень = более низкая посадка |
| Процент мертвого кода | Анализ достижимости | Высокий уровень мертвого кода = более низкая пригодность |
| Входящий поток (количество входящих зависимостей) | Картографирование зависимостей | Высокий коэффициент усиления эффекта «веера» повышает терпимость, а не устраняет ее. |
| Широта распространения копибука | Анализ зависимостей COPY | Высокая степень совместного использования = более высокая степень взаимосвязи = более низкая совместимость |
| Время с момента последнего значимого изменения | Журнал управления изменениями Git | Длительный период бездействия может указывать на неработающий код или нестабильность. |
| количество уязвимостей безопасности | SAST-сканирование | Большое количество = худшая посадка |
Для оценки ценности бизнеса важны следующие доказательства:
| Индикатор деловой ценности | Источник | Движется классификация в сторону |
|---|---|---|
| Объем транзакций за период | Журналы выполнения JCL, записи планировщика. | Большой объем = более высокая ценность |
| Веерное распространение в нисходящем направлении | Картографирование зависимостей | Высокая степень разветвления = более высокая ценность (от этого многое зависит). |
| Флаг регулирующей функции | Классификация данных, реестр соответствия | Текущее значение = минимальный пороговый уровень независимо от других показателей. |
| Соседство доходов | Анализ потока данных в системы выставления счетов/учета доходов | Прямая смежность = более высокое значение |
| Количество пользователей или количество вызовов API | Журналы доступа, сетевой трафик | Большое количество = более высокая ценность |
Ключевой вывод: для устаревших систем COBOL большинство этих показателей недоступны из записей CMDB, интервью с владельцами приложений или анализа сетевого трафика. Они доступны из структурного анализа исходного кода, журналов выполнения и расписания заданий JCL, которое документирует, что фактически выполняется в производственной среде и когда.
Оценка технической пригодности для COBOL и устаревших систем.
Стандартные критерии оценки технической пригодности, совместимость с API, готовность к облачным технологиям, поддержка контейнеризации, микросервисная архитектура — все это не имеет значения для пакетных программ на COBOL. Программа на COBOL не может быть контейнеризирована; оценка по критериям облачной совместимости дает нулевой балл технической пригодности для каждой устаревшей программы, что не дает организации никакой полезной информации.
Для систем на COBOL и мэйнфреймов оценка технической пригодности требует применения критериев, специфичных для COBOL:
Показатель сложности (вес: 30%): Средняя цикломатическая сложность абзацев и разделов программы. Программы со средним показателем CC ниже 10 имеют управляемую сложность; программы с показателем CC выше 20 имеют структурную сложность, которая делает поддержку дорогостоящей и рискованной.
Показатель поддерживаемости (вес: 25%): совокупный показатель процента мертвого кода, ширины совместного использования копибуков и уровня дублирования. Программа с 40% мертвого кода, 15 общими копибуками и значительным дублированием кода имеет низкую поддерживаемость независимо от ее функциональной корректности.
Оценка риска зависимости (вес: 20%): количество входящих зависимостей, взвешенное по критичности входящих зависимостей. Программа с 50 входящими зависимостями от программ первого уровня имеет высокий риск зависимости, изменения в ней требуют координации 50 нижестоящих программ.
Оценка актуальности (вес: 15%): актуальность диалекта COBOL и версии компилятора, современность синтаксиса JCL и интерфейс базы данных (устаревший встроенный SQL, VSAM против DB2, пакетная обработка против пакетной обработки + CICS). Программы, написанные на синтаксисе COBOL-85 со встроенным SQL DB2, более актуальны, чем программы, написанные на COBOL-74 с доступом к файлам только через VSAM.
Оценка уровня безопасности (вес: 10%): наличие жестко закодированных учетных данных, незащищенный доступ к файлам, отсутствие проверки состояния файла и уязвимость к SQL-инъекциям при построении динамических SQL-запросов.
Technical Fit Score = (100 - complexity_score) × 0.30
+ maintainability_score × 0.25
+ (100 - dependency_risk) × 0.20
+ currency_score × 0.15
+ security_score × 0.10
Where each component is scored 0-100, with 100 being best.Данная формула оценки выдает оценку технической пригодности от 0 до 100, основанную на анализе строительных норм, а не на качественной оценке. Два приложения с идентичными функциями, но различными структурными характеристиками, дадут разные оценки технической пригодности, и эти оценки будут точно отражать разные инвестиции, необходимые для обслуживания и расширения каждого из них.
Проблема допустимого дрейфа: управление в холдинговом квадранте
«Толерантность» — это квадрант, в котором со временем накапливается «долг» в каждой организации, использующей TIME без явного управления «Толерантностью». Механизм прост: приложение попадает в «Толерантность», потому что его не стоит менять, и остается в ней неопределенно долго, потому что изменение никогда не является самым срочным приоритетом.
Принципы управления, основанные на терпимости, предотвращают бессрочную отсрочку:
Триггеры переклассификации на основе состояния здоровья:
- Выявлена уязвимость безопасности, которую невозможно устранить в течение 30 дней → рассматривается возможность переноса или удаления.
- Поставщик объявляет о прекращении поддержки компонента платформы, от которого зависит приложение → обзор для Migrate
- Показатель ценности бизнеса превышает пороговое значение (новое нормативное требование, изменение бизнес-модели) → рассмотрение вопроса об инвестировании или миграции.
- Удаление зависимостей вынуждает изменить интерфейс → рассмотреть возможность миграции или удаления
- Анализ неработающего кода показывает, что приложение фактически неактивно → проверка на предмет исключения
Периодичность проведения обзоров в зависимости от времени:
- Заявки поступают в Tolerate с датой рассмотрения через 12 месяцев.
- По истечении 12 месяцев рассмотрение заявления явно переклассифицируется или явно подтверждается как допустимое с новой 12-месячной датой.
- Для повторного применения механизма терпимости требуется письменное обоснование, в котором документально подтверждается, почему условия не изменились.
- Заявка, которая была повторно одобрена более двух раз без переклассификации, приводит к передаче дела на рассмотрение архитектурной комиссии.
Реестр Tolerate: постоянно обновляемый список всех приложений Tolerate с указанием даты классификации, даты проверки, владельца и набора условий, которые могут привести к переклассификации. Этот реестр пересматривается на каждом заседании совета по архитектурному обзору, а не только на ежегодном обзоре портфеля.
Превращение концепции "ликвидировать" в исполнительную: преодоление разрыва в процессе вывода из эксплуатации
Разрыв между «классифицировано как подлежащее ликвидации» и «успешно выведено из эксплуатации» — это то, где программы рационализации заходят в тупик. Для преодоления этого разрыва необходимо рассматривать каждое решение о ликвидации как проект с определенным масштабом, зависимостями и критериями успеха, а не как завершение.
Контрольный список действий по устранению недостатков:
- Проверка зависимостей завершена: Статический анализ подтверждает отсутствие входящих производственных зависимостей (не просто отсутствие задокументированных зависимостей, а структурно подтвержденное их отсутствие).
- План утилизации данных утвержден: Определены нормативные требования к срокам хранения данных, утвержден план миграции или архивирования данных юридическим и нормативным отделами.
- Уведомление от нижестоящего поставщика завершено: Владелец каждой системы-потребителя уведомил и подтвердил отсутствие активных зависимостей.
- Проверка на соответствие нормативным требованиям завершена: В зависимости от заявки, никаких активных требований к подаче документов в регулирующие органы, проведению аудитов или соблюдению нормативных требований не требуется.
- Назначен ответственный за вывод из эксплуатации: Назначить ответственное лицо для осуществления вывода из эксплуатации, а не только для принятия решения о классификации.
- План отката определен: Процедура восстановления работы сервиса в случае обнаружения ранее не выявленной зависимости при выводе его из эксплуатации.
- Дата вывода из эксплуатации определена: Конкретная дата в ИТ-календаре, а не "когда до этого дойдём".
Этап структурного анализа: Решение об исключении не переходит к планированию вывода из эксплуатации до тех пор, пока структурный анализ не подтвердит отсутствие входящих зависимостей от путей выполнения в производственной среде. Наиболее распространенная причина сбоя выполнения решения об исключении — обнаружение зависимости после объявления о выводе из эксплуатации, которая приводит к откату. Анализ структурных зависимостей до объявления предотвращает это.
Цикл переоценки TIME
Классификация TIME не является постоянной. Бизнес-ценность меняется по мере развития стратегии организации. Техническая пригодность меняется по мере поддержки, расширения или устаревания приложения. Модель представляет собой моментальный снимок; портфель требует постоянно меняющейся картины.
Ежегодная полная переоценка: каждое приложение в портфеле оценивается по критериям текущей деловой ценности и технической пригодности. Классификации, которые не менялись в течение трех последовательных лет, рассматриваются отдельно, либо потому, что приложение действительно стабильно (с указанием причин), либо потому, что оценка не отражает происходящие изменения.
Переоценка по событию: Конкретные события инициируют немедленный пересмотр классификации:
- Слияние или поглощение (новое объединение портфелей)
- Изменения в законодательстве, затрагивающие обязательства по соблюдению требований.
- Объявление о прекращении поддержки крупной платформы (базы данных, операционная система, среда выполнения).
- Значительные изменения в бизнес-модели (новая линейка продуктов, выход с рынка, организационная реструктуризация)
- Инцидент безопасности, связанный с приложением.
Журнал изменений: Каждое изменение классификации регистрируется с указанием: предыдущей классификации, новой классификации, даты, оснований для изменения и утверждающего лица. История классификации каждого приложения представляет собой аудиторский след, демонстрирующий активное управление портфелем, а не его классификацию и забывание.
Как SMART TS XL Предоставляет доказательства классификации по времени.
Классификационные решения модели TIME зависят от имеющихся доказательств. Для современных приложений с покрытием CMDB, мониторингом API и документированной архитектурой эти доказательства доступны. Для устаревших COBOL-приложений, где CMDB неполна, владельцы ушли на пенсию, а структура зависимостей не документирована, доказательства должны быть получены путем структурного анализа самого кода.
SMART TS XLАвтора статический анализ кода Программа генерирует необходимые для оценки соответствия техническим требованиям входные данные, которые требуются для COBOL-тестирования: цикломатическая сложность программы, процент мертвого кода, обнаруженные шаблоны безопасности (жестко закодированные учетные данные, незащищенный доступ к файлам) и актуальность диалекта COBOL. Эти метрики получены из исходного кода, а не из оценок разработчиков, и не зависят от того, помнит ли кто-либо, что делает приложение.
Сопоставление зависимостей приложения позволяет получить данные о входящих зависимостях, которые предотвращают преждевременные решения об исключении, и данные о исходящих зависимостях, которые поддерживают оценку бизнес-ценности. Приложение с 45 входящими зависимостями от производственных программ не является надежным кандидатом на исключение, независимо от того, как его владелец оценивает его бизнес-ценность. Количество зависимостей — это структурный фактор, который перевешивает аргумент классификации.
Анализ модернизации устаревших систем позволяет составить перечень неактивного кода, который меняет классификацию: программы, которые отображаются в CMDB как активные приложения, но не имеют входящих производственных зависимостей, являются кандидатами на статус неактивного кода и переклассифицируются из категории «Допустимо» в категорию «Устранить» на основе структурных данных, а не на основе оценки владельцем бизнеса программы, о существовании которой он, возможно, никогда и не знал.
Возможность анализа воздействия делает выполнимым контрольный список выполнения задачи по устранению зависимостей: структурный анализ, подтверждающий отсутствие входящих производственных зависимостей до начала планирования вывода из эксплуатации. Это тот самый контрольный пункт, который предотвращает наиболее распространенную ошибку при выполнении задачи по устранению зависимостей — необнаруженную зависимость, которая всплывает после объявления.
Функция корпоративного поиска позволяет запрашивать данные о процессе классификации TIME на протяжении всего цикла переоценки: найти все заявки, классифицированные как «Допустимо» с датой проверки в течение следующих 30 дней, все заявки, классифицированные как «Исключить» без указанной даты вывода из эксплуатации, и все заявки с оценкой технической пригодности ниже 30, которые по-прежнему классифицируются как «Инвестировать». Эти запросы являются инструментом управления, который поддерживает модель TIME как активный инструмент управления, а не как разовую процедуру классификации.
Качество методологии определяется только имеющимися в ней доказательствами.
Двухосевая структура модели TIME верна. Бизнес-ценность и техническая пригодность — это правильные параметры для принятия решений по портфелю приложений. Четыре параметра — это правильные варианты. Проблема не в самой структуре, а в доказательной базе, которую организации предоставляют для ее применения.
Классификации, основанные на данных интервью и оценках CMDB, порождают организационные дискуссии. Классификации, основанные на структурном анализе, измеренной сложности, подтвержденном количестве зависимостей и технической пригодности, полученной на основе кода, приводят к обоснованным решениям. Владелец приложения, утверждающий, что его COBOL-программа нуждается в «инвестировании», а не в «миграции», имеет более веские основания, когда структурный анализ показывает цикломатическую сложность в среднем 35, 40% мертвого кода и 12 нарушений безопасности. ИТ-команда, утверждающая, что программу можно исключить, имеет более слабые аргументы, когда анализ зависимостей показывает 45 входящих производственных зависимостей.
Модель TIME работает, когда доказательства подтверждают необходимость ее применения. Структурный анализ портфеля приложений — это способ, с помощью которого организации собирают доказательства необходимости рационализации устаревших приложений, которые в наибольшей степени нуждаются в оптимизации и для которых наименее вероятно наличие документации, облегчающей принятие таких решений.
