Каждая организация, использующая устаревшие системы, сталкивается с одним и тем же фундаментальным противоречием. Эти системы слишком ценны, чтобы от них отказываться, слишком дороги в обслуживании в их нынешнем состоянии и слишком рискованны для единовременной замены. Мейнфреймы на COBOL обрабатывают 95% транзакций банкоматов в мире. Восемьдесят процентов федеральных ИТ-бюджетов США идут на поддержание систем, которые следовало модернизировать много лет назад. Устаревшие системы не терпят неудачу, они преуспевают, и именно поэтому их так сложно изменить.
Цена бездействия накапливается. Технический долг растет с каждым годом, пока модернизация откладывается. Уязвимости в системе безопасности накапливаются в кодовых базах, которые больше не получают исправлений. Интеграция с современными системами становится сложнее по мере того, как увеличивается разрыв между устаревшей архитектурой и облачными шаблонами. А число разработчиков, понимающих устаревшие языки программирования, сокращается, поскольку люди, которые их создавали, уходят на пенсию. Организации, которые преуспевают в модернизации, — это не те, которые ждут, пока давление станет невыносимым. Это те, кто методично планирует, выбирает правильный подход для каждой системы и выполняет модернизацию поэтапно, а не ставит всю программу на кон одним крупным переходом.
Ознакомьтесь со своим наследственным портфелем в полном объеме.
SMART TS XL определяет, что можно вывести из эксплуатации до того, как будет определен объем модернизации.
ПодробнееЧто такое модернизация устаревшей системы?
Модернизация устаревших систем — это процесс преобразования устаревших программных систем, часто монолитных, требующих частого обслуживания и сложной интеграции, в современные, гибкие и масштабируемые архитектуры. Это не обязательно замена. Модернизация охватывает спектр подходов: от переноса существующего кода в облачную инфраструктуру с минимальными изменениями, через поэтапный рефакторинг, до полной реархитектуры или замены современными альтернативами.
Отличие от простого технического обслуживания: техническое обслуживание поддерживает систему в рабочем состоянии. Модернизация изменяет ее фундаментальные возможности, архитектуру или операционную среду, чтобы продлить срок ее службы, снизить эксплуатационные расходы, обеспечить интеграцию с современными системами или подготовить организацию к будущему развитию возможностей, включая рабочие нагрузки в области искусственного интеллекта.
Почему устаревшие системы не могут ждать бесконечно
Ряд факторов в совокупности приводит к тому, что стоимость отсрочки платежей в 2026 году будет выше, чем три года назад:
Готовность к ИИ. Рабочие нагрузки генеративного ИИ выявляют все слабые места в корпоративной информационной инфраструктуре: фрагментированные источники, непоследовательную семантику, неконтролируемый доступ — всего за несколько недель после пилотного внедрения. Организации не могут запускать эффективные рабочие процессы ИИ на основе разрозненных, недокументированных устаревших систем. Модернизация является необходимым условием для развития возможностей в эпоху ИИ.
Дефицит квалифицированных кадров. Найти разработчиков для COBOL, PL/I и Java, которой уже пятнадцать лет, становится действительно сложно. Средний возраст разработчиков COBOL сейчас составляет около пятидесяти пятидесяти лет. Каждый год, в течение которого модернизация откладывается, сужает окно для передачи знаний, прежде чем накопленные знания «уйдут на покой» вместе с теми, кто ими владеет.
Уязвимость в системе безопасности. В устаревших системах, которые больше не получают обновления безопасности от поставщиков, накапливаются неустраненные уязвимости CVE. Чем дольше система работает в таком состоянии, тем больше площадь известной уязвимой поверхности.
Сложность интеграции. Современные API-ориентированные архитектуры, микросервисы и облачные платформы предполагают схемы подключения, которые устаревшие монолитные системы изначально не поддерживают. Каждое новое обходное решение для интеграции увеличивает технический долг, что затрудняет последующую модернизацию.
«7 R»: основная концепция принятия решений о модернизации
Концепция «7 R», разработанная на основе оригинальной концепции «5 R» компании Gartner и расширенная с учетом отраслевой практики, предоставляет организациям структурированный способ принятия решений о том, что делать с каждым приложением в их инфраструктуре. Ключевой принцип заключается в том, что ни один подход не подходит для всех систем. Программа модернизации на уровне портфеля применяет различные стратегии к различным системам в зависимости от их сложности, важности для бизнеса и стратегической ценности.
| Стратегии | Что это значит | Когда это использовать | Типичный график | Уровень риска |
|---|---|---|---|---|
| Уход на пенсию | Система выводится из эксплуатации, она больше не нужна. | Избыточные, неиспользуемые или полностью устаревшие системы | Немедленная | Низкий |
| сохранить | Оставьте как есть, внеся минимальные изменения. | Система работает, затраты на модернизацию превышают выгоду. | Постоянный | Низкий |
| Повторный хост | Перенос в облако без изменений кода. | Некритичные рабочие нагрузки, быстрые результаты, снижение затрат на инфраструктуру. | 1 – 3 месяцев | Низкий |
| Реплатформа | Переходите на новые платформы при целевых изменениях (например, использование управляемых баз данных). | Требуется умеренная степень сопряжения, оптимизация удельных характеристик или стоимости. | 2 – 6 месяцев | Средний |
| Рефакторинг | Реструктуризация кода без изменения внешнего поведения. | Сокращение технического долга, повышение удобства сопровождения, увеличение тестового покрытия. | 3 – 12 месяцев | Средний |
| Реархитектор | Перепроектирование для облачной архитектуры, микросервисов или новой архитектуры. | Значительные требования к масштабируемости, стратегическое изменение платформы. | 12 – 24 месяцев | Высокий |
| Замените | Откажитесь от собственной системы, перейдите на SaaS или современные альтернативы. | Функциональность товаров массового потребления лучше обеспечивается существующими продуктами. | 6 – 18 месяцев | Средне-высокая |
Самое важное решение в любой программе модернизации — это строгое применение этой концепции, а не использование одной стратегии для всего. Организации, которые применяют подход «переноса и обновления» ко всему, в итоге получают счета за облачные услуги выше, чем были затраты на их центры обработки данных, без той гибкости, которая их оправдывает. Организации, которые применяют подход «перепроектирования» ко всему, в итоге получают многолетние программы, которые приносят пользу слишком медленно, чтобы поддерживать поддержку заинтересованных сторон.
Восемь подходов к модернизации подробно
1. Перенос на другой сервер (Lift-and-Shift)
Перенос приложения в облако или современную инфраструктурную среду осуществляется без изменения кода приложения. Приложение работает на другой платформе, но ведет себя идентично. Это самый быстрый путь в облако, с наименьшим риском и наименьшими трансформациями.
Наилучший вариант для: Некритичных приложений, где основной целью является снижение затрат на инфраструктуру, консолидация центров обработки данных или подготовка к будущей модернизации. Перенос системы на облачную инфраструктуру часто используется в качестве первого этапа: система размещается в облаке, а затем происходит поэтапная рефакторизация.
Что она не решает: технический долг, проблемы с поддержкой, сложность интеграции или архитектурные ограничения. Система работает в облаке, но архитектурно остается неизменной. Монолитная система, поддержка которой была дорогостоящей при локальном развертывании, остается дорогостоящей и после переноса на облачную инфраструктуру.
2. Переплатформирование
Перенос платформы предполагает целенаправленную корректировку платформы или среды выполнения для использования преимуществ облачных сервисов без реструктуризации архитектуры приложения. Типичными примерами переноса платформы являются миграция с самостоятельно управляемой базы данных на облачную управляемую базу данных или с самостоятельно управляемого сервера приложений на управляемую контейнерную платформу.
Наилучший вариант для: Приложений, где для конкретных компонентов существуют четкие облачные аналоги, снижающие операционные издержки, и где затраты и риски полной перестройки архитектуры не оправданы выгодой для бизнеса.
3. Рефакторинг
Рефакторинг — это перестройка существующего кода для улучшения его внутреннего качества без изменения внешнего поведения. Он устраняет технический долг, улучшает тестируемость, снижает сложность и делает код более понятным и расширяемым. Это не миграция платформы, система работает в той же среде, что и до и после рефакторинга.
Рефакторинг является наиболее подходящим подходом в следующих случаях: основная функциональность системы исправна и по-прежнему необходима, но её внутренняя структура делает внесение изменений медленным и рискованным. Программа на COBOL с накопленной за десятилетия условной логикой, которая корректно выполняет критически важную бизнес-функцию, но требует нескольких дней тщательного анализа перед любыми изменениями, является кандидатом на рефакторинг.
4. Перепроектирование архитектуры
Реархитектура предполагает перепроектирование фундаментальной структуры приложения, декомпозицию монолита на микросервисы, переход от синхронного к событийно-ориентированному взаимодействию, внедрение шаблонов CQRS или Event Sourcing. При правильном выполнении это стратегия с наибольшими затратами и наибольшей отдачей, а при неправильном — с наибольшим риском.
Основной тип ошибок, на который следует обратить внимание, — это «антипаттерн распределенного монолита», когда команды внедряют новые сервисы, но не обеспечивают разделение уровня данных, создавая операционную сложность микросервисов с тесной взаимосвязью монолита. Этот паттерн работает, когда границы данных четко определены до выделения сервисов.
Наилучший вариант для: систем, где требования к масштабируемости, отказоустойчивости или архитектурной гибкости не могут быть удовлетворены в рамках существующей структуры, и где организация обладает достаточной инженерной зрелостью для эксплуатации распределенных систем.
5. Узор «Душитель инжира»
Паттерн «Душитель фиг» — это подход к модернизации, при котором существующие функции устаревшей системы постепенно заменяются новыми приложениями и сервисами до тех пор, пока новая система в конечном итоге не заменит все старые или ключевые части устаревшей системы.
Вместо единовременной замены устаревшей системы, новая функциональность создается параллельно со старой, постепенно вытесняя ее по мере внедрения современных компонентов. Прокси-сервер или фасадный слой маршрутизирует запросы, первоначально отправляя все в устаревшую систему, а затем постепенно перенаправляя больше запросов к новым компонентам по мере их проверки. Устаревшая система «душится» постепенно, пока ее можно будет безопасно вывести из эксплуатации.
Самый рискованный путь: масштабная миграция. Создание полноценной системы замены в отрыве от существующей, а затем ее одновременный отказ, имеет документально подтвержденный высокий процент неудач в масштабах предприятия.
Почему Strangler Fig теперь является рекомендуемым решением по умолчанию для критически важных систем: он исключает самый распространенный вид отказа при модернизации устаревших систем — резкий переход на новую систему. Каждый новый компонент проверяется в производственной среде перед извлечением следующего. Откат всегда возможен, поскольку устаревшая система продолжает работать. Непрерывность бизнес-процессов обеспечивается на протяжении всего процесса.
Применение в реальных условиях: Финансовое учреждение, заменяющее свою основную банковскую систему, выделяет функцию запроса информации о счете в качестве первой новой услуги. Новая услуга обрабатывает запросы, в то время как устаревшая система обрабатывает все остальное. После стабилизации работы услуги выделяется следующая функция — инициирование транзакций. Этот процесс продолжается до тех пор, пока устаревшая основная система не будет выведена из эксплуатации без простоев и с непрерывной проверкой на каждом этапе.
6. Инкапсуляция API (обертывание)
Обертывание API создает современный API-слой вокруг устаревшей системы без изменения ее внутреннего кода. Внешние потребители взаимодействуют с современным API; API преобразует запросы в собственный интерфейс устаревшей системы и конвертирует ответы в современные форматы. Устаревшая система становится внутренней деталью реализации, скрытой за чистым интерфейсом.
Лучше всего подходит для: систем, которые должны оставаться на месте неопределенно долго (из-за нормативных требований, стоимости или сложности), но нуждаются в участии в современных моделях интеграции. API-обертывание — это способ, которым многие организации делают программы COBOL доступными для современных веб- и мобильных приложений, не затрагивая код COBOL.
Ограничение: не учитываются ограничения базовой системы, ее производительность, масштабируемость и удобство сопровождения. Использование API-оберток улучшает интеграцию, не улучшая при этом саму систему, которую они обертывают.
7. Восстановление с нуля
Перестройка предполагает отказ от существующей реализации и создание новой с нуля, ориентированной на современную архитектуру, язык программирования и платформу. Она целесообразна, когда существующая система действительно не подлежит экономически целесообразному ремонту и когда бизнес-требования достаточно хорошо понятны, чтобы с уверенностью определить замену.
Риск: Каждая организация, пытавшаяся масштабно перестроить критически важную систему, обнаруживала, что существующая система содержала недокументированную бизнес-логику, которую новая система не воспроизводила. Миграция ИТ-инфраструктуры британского банка TSB в 2018 году привела к тому, что 1.9 миллиона клиентов на несколько недель оказались заблокированы от своих счетов. Проект ФБР «Виртуальное дело» был заброшен после разработки стоимостью 170 миллионов долларов. Замена системы расчета заработной платы в системе здравоохранения Квинсленда привела к тому, что 35 000 сотрудников больницы получали недоплату или переплату в течение нескольких месяцев. В каждом случае сложность существующей системы, встроенные в нее бизнес-правила, ее граничные случаи, ее операционное поведение в условиях, которые никогда не были явно указаны, превосходили понимание команды, занимавшейся заменой системы, до начала проекта.
8. Модернизация с помощью ИИ
Модернизация с помощью ИИ использует большие языковые модели и специализированные инструменты ИИ для ускорения наиболее трудоемких этапов модернизации устаревших систем: понимания кода, генерации документации, перевода кода и генерации тестов.
Инструменты перевода COBOL в Java используют языки программирования с низким уровнем сложности (LLM), оптимизированные для обоих языков, для создания первоначальных переводов программ COBOL, которые затем проверяются и дорабатываются инженерами. Перевод устраняет большую часть механических усилий по преобразованию, но не исключает необходимости в понимании человеком того, что должен делать переведенный код.
Автоматизированная генерация документации анализирует устаревший код для создания структурированной документации, описывающей функции каждой программы, реализуемые ею бизнес-правила, читаемые и записываемые данные, а также условия, при которых происходит ветвление. Эта документация необходима для проверки переведенного кода инженерами-программистами и для сохранения знаний организацией после выхода на пенсию экспертов по COBOL.
Генерация тестов использует искусственный интеллект для создания модульных тестов для устаревших программ на основе анализа их поведения при вводе/выводе, обеспечивая тестовое покрытие, которое не было написано во время первоначальной разработки и которое необходимо перед безопасным проведением любой рефакторизации.
Критическое ограничение модернизации с помощью ИИ: инструменты ИИ ускоряют преобразование кода. Они не устраняют необходимости понимать бизнес-логику, реализованную в коде. Правильно переведенная программа все равно будет считаться неудачной, если перевод был корректным, а бизнес-правила были неправильно поняты. Инструменты ИИ снижают стоимость механической работы, а не стоимость работы по пониманию.
Выбор правильного подхода: структура принятия решений
Правильный подход к модернизации любой системы зависит от четырех факторов, оцениваемых в совокупности: критическая важность для бизнеса, техническая сложность, стратегическая ценность, а также имеющийся бюджет и сроки.
| Профиль системы | Рекомендуемый подход |
|---|---|
| Низкая критичность для бизнеса, низкая сложность | Уйти на пенсию или перевести на другое место жительства |
| Высокая критичность для бизнеса, низкая сложность, фактор, определяющий стоимость инфраструктуры. | Перенести или перенести на другую платформу. |
| Высокая критичность, умеренная сложность, основной проблемой является технический долг. | Рефакторизация поэтапно. |
| Высокая степень критичности, высокая сложность, критически важная задача, требование нулевого времени простоя. | Узор «Фигура душителя» |
| Система тесно связана с устаревшей платформой. | Перенос платформы или перепроектирование |
| Функциональность, доступная по модели SaaS (SaaS). | Замените |
| Помимо экономически целесообразного ремонта, существуют хорошо известные требования. | Восстановить (с предельной осторожностью) |
| Большой портфель языков COBOL или устаревших языков программирования. | Перевод с помощью ИИ + проверка человеком |
Самая распространенная ошибка: применение одного и того же подхода ко всем системам в портфеле, потому что так проще объяснить заинтересованным сторонам. Программа модернизации, которая переносит все системы на новые платформы независимо от их характеристик, приведет к результатам, варьирующимся от приемлемых (для некоторых систем) до неоправданных затрат (для систем, которые следовало бы вывести из эксплуатации) и опасного чрезмерного упрощения (для систем, которые на самом деле нуждались в перепроектировании).
Проблемы модернизации устаревших систем: что срывает программы?
Понимание причин провала программ модернизации так же важно, как и понимание доступных подходов. Причины неудач однообразны:
Недокументированная бизнес-логика. Устаревшие системы содержат бизнес-правила, которые существуют только в поведении кода. Программа на COBOL, модифицированная двенадцатью разработчиками за тридцать лет, кодирует решения, которые никогда не были задокументированы и которые ни один из ныне живущих членов команды полностью не понимает. Любой подход к модернизации, который не извлекает и не документирует эту логику до внесения изменений в систему, рискует создать новую систему, которая будет вести себя иначе, чем старая, и это будет обнаружено только при возникновении бизнес-последствий.
Попытки масштабного перехода. Наиболее серьезные неудачи в модернизации терпят те организации, которые пытаются заменить всю систему сразу, внедрив ее в определенный срок. Все хорошо задокументированные крупные провалы модернизации — TSB Bank, FBI VCF, Queensland Health — демонстрируют эту закономерность. Постепенная модернизация с непрерывной проверкой на каждом этапе — это подход, который приносит успех.
Расширение масштаба проекта и обнаружение проблем в процессе выполнения. Команда по модернизации обнаруживает сложности, которые не были видны на этапе планирования. Система, которая казалась ограниченным приложением, оказывается использующей общие данные с двадцатью другими системами через недокументированные файловые интерфейсы. Функция, которая казалась простой, оказывается реализацией бизнес-правила, на разработку которого ушло три месяца переговоров с регулирующими органами и которое нигде не задокументировано. Решение заключается в структурном анализе до начала планирования, а не в планировании без структурного анализа.
Риск концентрации знаний. Люди, которые лучше всего понимают устаревшую систему, часто находятся на пороге выхода на пенсию. Когда они уходят до того, как их знания будут переданы и задокументированы, команда модернизации работает с неполным пониманием того, что делает система.
Измеряют не те вещи. Команды, которые оценивают успех модернизации по проценту миграции кода или соблюдению сроков, а не по бизнес-результатам, снижению затрат, надежности сервисов, времени внедрения функций, оптимизируют процесс, ориентируясь на активность, а не на результаты.
Оценка, которая должна предшествовать любому решению о выборе подхода.
Самое важное, что может сделать любая организация перед выбором подхода к модернизации, — это понять, с чем она имеет дело. Оценка, включающая анализ документации и интервью с разработчиками, неадекватна по двум причинам: документация неполна и устарела, а знания разработчиков распределены, непоследовательны и сосредоточены у людей, которые часто недоступны или находятся на пенсии.
Структурная оценка, включающая анализ исходного кода каждого приложения и построение модели зависимостей на основе фактического функционала кода, формирует доказательную базу для каждого последующего решения:
Инвентаризация программ. Сколько программ фактически существует, включая те, которые не указаны в документации. В крупных устаревших системах фактическое количество обычно превышает задокументированное на 20–30%.
Сопоставление зависимостей. Какие программы вызывают другие, какие обмениваются данными через файлы или базы данных, какие задания JCL вызывают какие программы и в какой последовательности. Структура зависимостей определяет последовательность миграции: компоненты с высокой степенью зависимости, от которых зависят многие другие, мигрируют последними.
Выявление мертвого кода. Программы, которые никогда не вызываются ни одним из путей выполнения в производственной среде, могут быть полностью исключены из области модернизации. В типичных портфелях устаревшего программного обеспечения мертвый код составляет 10–25% от общего объема, что позволяет существенно сократить объем работ на этапе оценки.
Классификация сложности. Какие программы обладают наибольшей цикломатической сложностью, наибольшим количеством зависимостей типа copybook, наибольшим числом вызывающих функций и наибольшим числом взаимодействий с базами данных? Именно эти программы потребуют наибольших усилий и сопряжены с наибольшим риском, и к ним следует приступать в последнюю очередь, после того как команда приобретет опыт работы с менее сложными компонентами.
Извлечение бизнес-логики. Какие решения реализует каждая программа, по каким условиям она переходит, какие вычисления выполняет. Данная документация является спецификацией, на основе которой должна быть проверена модернизированная система.
Как SMART TS XL Поддерживает модернизацию устаревших систем.
Описанная выше структурная оценка — это именно то, что нужно. SMART TS XL Автоматизирует. Путем одновременного анализа каждой программы COBOL, потока заданий JCL, книги копирования, модуля PL/I, программы RPG, схемы SQL и связанного компонента, он строит полную модель зависимостей, что делает планирование модернизации основанным на фактических данных, а не на предположениях.
Анализ модернизации устаревших систем позволяет составить полный перечень программ, включая те, которые не были учтены в документации, с предварительной оценкой сложности каждого компонента. Сопоставление зависимостей приложений формирует граф межъязыковых зависимостей, определяющий последовательность миграции: какие компоненты могут быть модернизированы на ранних этапах, поскольку от них ничего не зависит, а какие должны подождать, пока их зависимые компоненты не будут готовы.
Функция анализа влияния позволяет оценивать риски каждого предлагаемого изменения до его реализации: когда команда предлагает модернизировать COBOL-код, используемый в 300 программах, анализ влияния перечисляет каждую из этих 300 программ, определяет объем работ по проверке и выявляет наиболее рискованные зависимости до внесения изменений.
Функция статического анализа кода выявляет мертвый код, программы и абзацы, не имеющие входящих ссылок ни на один из путей выполнения в производственной среде, что позволяет исключить их из области модернизации до начала любых работ по преобразованию. Для организаций, переходящих в облако, отказ от миграции мертвого кода является одним из наиболее прямых способов снижения затрат, достижимых на этапе оценки.
Возможность корпоративного поиска позволяет запрашивать структурную модель на протяжении всей многолетней программы модернизации: за считанные секунды можно найти каждую программу, которая считывает данные из определенного набора данных, каждую книгу правил, определяющую определенное поле, каждое задание JCL, которое вызывает определенную программу, в миллионах строк кода на любых комбинациях языков.
SMART TS XLАвтора визуализация кода Создает диаграммы зависимостей и блок-схемы программ, которые делают недокументированную структуру системы понятной для всей команды модернизации, включая инженеров, которые никогда не видели COBOL и которым необходимо понимать, что на самом деле делают заменяемые ими программы.
Поэтапная модернизация: принцип, лежащий в основе каждой успешной программы.
Наиболее устойчивый вывод, сделанный как в успешных, так и в неудачных программах модернизации, заключается в роли поэтапного подхода. Лучшая практика: поэтапная модернизация с использованием модели «душителя» или составных дорожных карт снижает риски за счет миграции рабочих нагрузок по одной области или функции за раз.
Постепенный подход — это не робость. Это признание того, что понимание сложной устаревшей системы развивается на протяжении всего процесса модернизации, и что программа, структурированная таким образом, чтобы учитывать это растущее понимание на каждом этапе, позволит принимать более взвешенные решения, чем программа, в которой все решения принимаются на этапе планирования, который неизбежно предшествует полному пониманию.
Программы модернизации, обеспечивающие прогнозируемую окупаемость инвестиций, — это те, успех которых определяется на уровне отдельных этапов, когда каждый этап предусматривает поставку проверенных, готовых к внедрению компонентов, а не на уровне всей программы, где успех определяется только на этапе окончательного перехода. Каждый этап укрепляет уверенность в организации, выявляет сложности интеграции до того, как они станут препятствием, и демонстрирует, что выбранный подход работает в конкретном контексте систем и ограничений данной организации.
