Доктор, у меня легаси: лечим устаревшие ИТ-системы

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

Нормальная практика — постоянная актуализация ИТ-систем до их серьёзного устаревания. Однако многие процессы идут в старых системах, которые трудно и дорого (и страшно) модернизировать. Мы в заложниках, но будь наша воля, ничего бы с этим не делали.

Стокгольмский синдром или причины фиксации на легаси

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

Миграционные расходы

Переход от устаревшей ИТ-системы к современной обычно становится дорогим и трудоёмким процессом. Если правильно рассчитана возвратность инвестиций, осовремененное ПО в итоге компенсирует затраты. Но загвоздка в том, что сперва нужно найти деньги на модернизацию, заложить возможные простои, обучение сотрудников, ряд других косвенных издержек и внутренне принять разумные риски.

Разрыв в навыках

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

Боязнь крушения

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

Простота обслуживания

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

Специфическая функциональность

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

Отсечки легаси: когда пора действовать

Конец жизни (End of life, EOL): устаревшие системы достигли точки, когда поставщик считает их бесполезными и прекращает эксплуатацию. Без поддержки производителя нужно либо организовать её своими силами, либо переходить на что-то другое. Хотя бы из соображений безопасности.

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

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

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

Стратегии модернизации

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

Обновление существующей системы

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

Поэтапное и частичное замещение

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

Разработка новой системы

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

Ещё по теме: Дорожная карта проекта: как создать главный план и правильно им поделиться

Для успешного перехода

1. Кто займётся делом

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

2. Оценка текущей ситуации

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

3. Ранжируем подходы по скорости

Долгий переход можно вообще не пережить. На основе тщательной оценки выберите подход к модернизации, который соответствует вашим потребностям и обещает быстрые результаты. Согласно плану стратегического развития, внедрите SaaS там, где приходится изобретать велосипед; займитесь индивидуальной разработкой там, где никто не предлагает нужное решение.

4. Простота и приоритеты

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

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

5. Оптимальный стек технологий

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

6. Документируем всё, вообще всё

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

7. График поддержки и жизненного цикла

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

8. Бюджет на обучение людей и обновление софта

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

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

9. Гибкое движение по строгому ТЗ

Здесь нет ошибки. С масштабом проекта растёт вероятность неожиданностей. В техзадании продуман максимум деталей, но применение гибкой методологии разработки позволит обойти препятствия, которые учесть не удалось.

В завершение — успокоительное

Всё перечисленное является абсолютно нормальной практикой в крупных ИТ-проектах. Даже если у вас такая практика не ведётся, опытная наёмная команда принесёт с собой нужные компетенции. Ваша задача — потребовать их, убедившись в том, что подрядчик имеет должный уровень.

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

Далее: Разработка, управляемая данными: data driven в жизненном цикле ПО

В Spider Group на вас работает более чем двадцатилетний опыт в разработке мобильных приложений, веб-разработке, серверных проектах, дополненной реальности, искусственном интеллекте и интернете вещей.