Модернизация legacy ИТ: карта рисков для руководителя
Как думать о модернизации устаревших систем, не разрушив бизнес-процессы, которые на них держатся.
Почти у каждой компании, которая работает больше десяти лет, есть своя "система, которую нельзя трогать". Это может быть написанный в девяностые или нулевых учётный модуль, система управления производством на уже неподдерживаемой платформе, или CRM на самописном движке, который знает только один человек в компании. Эти системы работают. Они делают что-то важное. И все боятся их трогать.
Проблема в том, что "не трогать" - это тоже решение, со своими рисками. И в какой-то момент накопленные риски простоя перевешивают риски изменения.
Почему legacy сложнее, чем кажется
Legacy-система - это не просто старый код. Это накопленная бизнес-логика, которую часто никто полностью не документировал. Правила, обходные пути, исключения из исключений - всё это живёт в коде и в головах нескольких людей. Когда начинается модернизация, первое открытие почти всегда одно: то, что казалось простым, оказывается сложнее.
Второй момент: legacy-системы часто являются "source of truth" для других систем. Вокруг них за годы выросли интеграции, выгрузки, отчёты, ручные процессы. Замена одного компонента тянет за собой изменения во всём, что к нему присоединено.
Четыре стратегии и когда применять каждую
Замена ("big bang") - полная разработка нового решения с переводом в один момент. Наибольший риск: долгий проект, параллельная поддержка двух систем, высокая вероятность что новое решение повторит проблемы старого, поскольку логика не была полностью понята.
Применяется когда: система мала, процесс хорошо задокументирован, есть возможность остановить работу на период перехода.
Постепенная замена (strangler fig) - новые функции пишутся в новой системе, старая выводится постепенно по мере переноса функциональности. Более безопасный путь для критичных систем.
Применяется когда: система большая, работать нужно непрерывно, есть возможность чётко разграничить старую и новую части.
Обёртка (wrap and extend) - старая система остаётся, вокруг неё строится API-слой, новые функции реализуются поверх. Часто временное решение, но иногда оно становится постоянным.
Применяется когда: бизнес-риск замены высок, ядро системы работает стабильно, нужны новые интеграции без изменения ядра.
Отказ от функциональности - некоторые возможности legacy-системы больше не нужны. Прежде чем переносить всё, стоит спросить: что из этого мы реально используем?
Что идёт не так в большинстве проектов
Главная ошибка: недооценка скрытой сложности и переоценка скорости. Проект, оцениваемый в шесть месяцев, занимает два года - потому что в процессе обнаруживается логика, о существовании которой никто не знал.
Вторая ошибка: фокус на технологии, а не на бизнес-логике. Команда концентрируется на выборе нового фреймворка и архитектуры, а работа по пониманию и документированию текущей логики остаётся непроделанной.
Третья ошибка: отсутствие владельца со стороны бизнеса. Модернизация legacy - это не ИТ-проект. Это бизнес-проект с ИТ-составляющей. Без человека, который понимает бизнес-процессы и принимает решения о том, что сохранять, а что менять, проект неизбежно буксует.
Вопросы перед запуском проекта
- Мы полностью задокументировали логику текущей системы - включая все исключения и обходные пути?
- Кто является бизнес-владельцем проекта и имеет ли он полномочия принимать решения о бизнес-логике?
- Как выглядит план работы в период перехода - что происходит с процессами, пока две системы работают параллельно?
- Что является критерием успешного завершения - не "система запущена", а "бизнес-процессы работают корректно"?
- Есть ли план отката и при каких условиях мы им воспользуемся?
Модернизация legacy - это инвестиция с отложенной отдачей и высоким операционным риском в процессе. Управлять этим риском нужно осознанно, а не надеяться на то, что "всё пройдёт гладко".