Модернизация унаследованных приложений является критически важной задачей для многих организаций, пишет на портале TechBeacon Митен Марфатия, основатель и генеральный директор EvolveWare.
По данным независимого исследования «The State of Application Modernization 2023: Insights into IT Teams’ Strategies and Preparedness», проведенного по заказу EvolveWare, 51% ИТ-руководителей сталкиваются или ожидают столкнуться с критическими проблемами при обслуживании устаревших приложений. Это делает их организации кандидатами на модернизацию.
Однако модернизация приложений может оказаться сложной задачей — не только потому, что эти инициативы сложны, но и потому, что растет нехватка специалистов со знанием устаревших технологий и языков программирования.
Поэтому неудивительно, что 55% респондентов, принявших участие в опросе, планируют модернизировать только те приложения, которые находятся под угрозой критического отказа. Кроме того, 55% респондентов указали, что они сосредоточат свои усилия по модернизации на приложениях с небольшим количеством или отсутствием зависимостей.
Другими словами, планируется действовать осторожно, так как ИТ-руководители слишком хорошо знают, что такое неудачи и перерасход бюджета при подходе «большого скачка» к крупномасштабным проектам. Но даже в этом случае организации могут столкнуться с риском несоответствия ожиданий. Это приводит к плохому планированию выделения ресурсов и выбора инструментов, а также к недостаточной тщательности при выполнении критически важных задач и процессов.
Организации должны настроить себя на успех в этой важной и все более актуальной инициативе. В этом поможет поэтапный подход к модернизации приложений. Вот пять шагов, которые следует предпринять.
1. Добейтесь консенсуса по целям и ресурсам
Различные заинтересованные стороны могут иметь разные цели в отношении инициатив по модернизации. Как правило, бизнес-лидеры могут захотеть приступить к модернизации приложений ради перехода в облако, рассматривая миграцию в облако как способ улучшить качество обслуживания клиентов и потенциально сократить расходы. Но только 22% ИТ-руководителей указали миграцию в облако в качестве мотивации для модернизации приложений. Наиболее распространенным мотивирующим фактором в опросе ИТ-руководителей — 40% — оказалось повышение производительности труда сотрудников.
Такое несоответствие между бизнес- и ИТ-сторонами, по-видимому, возникает из-за разницы в фокусе этих двух групп: ИТ-руководители, скорее всего, обеспокоены проблемами, с которыми они сталкиваются при обслуживании приложений, в то время как руководители высшего звена, как правило, озабочены повышением эффективности для увеличения доходов и прибыльности. Другой способ взглянуть на это заключается в том, что бизнес-лидеры рассматривают, как модернизация может обеспечить прямой вклад в доход, в то время как ИТ-лидеры рассматривают, как модернизация может помочь справиться с конкретными проблемами.
Важнейшим первым шагом для ИТ-команд и заинтересованных бизнес-подразделений является совместная работа по определению болевых точек, расчету последствий перехода приложения в автономный режим и оценке того, как их конкурирующие интересы и действия могут помешать достижению стратегических целей. Используя эту информацию, обе стороны могут определить, какие приложения наиболее важны для модернизации, а затем начать распределять финансирование и ресурсы для достижения согласованных целей.
2. Оцените приложения, выбранные для модернизации
После определения приложений, которые необходимо модернизировать, ИТ-команды должны убедиться, что они имеют глубокое понимание этих приложений. Знание этих унаследованных систем имеет решающее значение для создания прочной основы для реализации инициатив по модернизации. Это позволит спланировать проект с промежуточными результатами, которые позволят организациям разработать последующие шаги и измерить прогресс в достижении целей преобразования.
В ходе опроса 41% респондентов заявили, что чувствуют себя очень уверенно в отношении своего понимания унаследованных систем при планировании их модернизации. Однако среди тех, кто уже начал процесс, это число снизилось до 28%, что убедительно свидетельствует о том, что ИТ-команды не до конца понимают уровень знаний, необходимых для этих усилий.
Многие из респондентов указали, что они основывают свой уровень уверенности на способности своего вспомогательного персонала запоминать информацию. В то же время, 81% респондентов выразили обеспокоенность тем, что им не удастся нанять или удержать достаточное количество талантливых специалистов с достаточными навыками программирования унаследованных приложений для понимания таких приложений и поддержки инициатив по модернизации. Без достаточного количества квалифицированных специалистов может быть трудно создать полный набор подробной документации, необходимой для поддержки принятия решений по модернизации.
Платформы автоматизации являются важной частью этих усилий, ускоряя и снижая риски для задач, которые подвержены человеческим ошибкам. Эти платформы извлекают метаданные из исходного кода и генерируют полный набор артефактов документации, включая отчеты, диаграммы и различные представления бизнес-логики. Эта информация также позволяет выявить зависимости, сложность и код приложения, который необходимо отключить или оптимизировать.
Обладая этими знаниями, ИТ-команды могут создавать модули или подсистемы — так, чтобы каждая подсистема стала управляемым мини-проектом, который может быть назначен для извлечения правил или оптимизации для переноса кода. Они также могут выявить внешние приложения, требующие одновременной модернизации, а также определить или подтвердить наиболее подходящий подход к модернизации для каждого приложения.
3. Определите или подтвердите наилучший путь модернизации
Существует несколько путей модернизации. Они включают замену, перестройку и рефакторинг приложений.
Замена приложений на коммерческие готовые продукты (commercial off-the-shelf, COTS) — самый быстрый способ модернизации. Однако если для существующего приложения требуются существенные улучшения, организации могут решить перестроить такие приложения на современных языках программирования и архитектурах. Если подходящий COTS-продукт недоступен, а приложение не нуждается в значительных улучшениях, такие приложения можно рефакторить, оптимизировав код и переведя его на современный язык и архитектуру.
4. Окончательно определите необходимые процессы и ресурсы
После того как для каждого приложения определен путь модернизации, следующим шагом будет окончательное определение процессов, которые наилучшим образом реализуют выбранную стратегию. Поскольку каждый процесс потребует как человеческих ресурсов, так и средств автоматизации, на этом этапе необходимо определить затраты, предпочтительных поставщиков технологий, сроки и стратегии снижения рисков. Чтобы получить одобрение и поддержку, необходимо использовать обратную связь с руководством для уточнения плана.
5. Реализуйте пилотный проект, чтобы удостовериться в возможности его масштабирования
Последним подготовительным шагом является проведение пилотного проекта на одном из модулей модернизируемого приложения. В ходе этого оценочного и обучающего проекта важно убедиться, что выбранные процессы повторяемы и масштабируемы, промежуточные результаты соответствуют ожиданиям, риски снижены, как ожидалось, а сроки реализации более крупного проекта могут быть соблюдены в рамках утвержденного бюджета.
Помните: ключевым моментом является поэтапный подход к модернизации. Как только вы выполните все эти шаги, ваш проект модернизации приложений будет настроен на успех.