Проблема Legacy — головная боль любого крупного бизнеса. За последние десятилетия ключевые бизнес-процессы выстраивались вокруг корсистем, которым сегодня по
Живее всех живых: что такое Legacy
Часто ключевые системы работают на старых стеках, которые поддерживает лишь узкий круг специалистов. В производстве оборудование жестко привязано к устаревшим базам и протоколам, либо к системам, которые ушли с российского рынка — например, Oracle. Критическую инфраструктуру зачастую поддерживают устаревшие системы, настроенные под специфические приборы: от счетчиков до производственного оборудования. Попытка их заменить обернулась бы дорогостоящим федеральным инфраструктурным проектом, который занял бы годы — и в итоге новые решения снова оказались бы устаревшими.
Поэтому за годы вокруг таких ядер вырастают «костыли» — модули и интеграции, которые решают новые задачи, но усложняют модернизацию. Полная замена требует миллиардных инвестиций и планирования на десятилетия — такую роскошь могут позволить себе единицы. Большинство же компаний мыслят сроками
Распиливаем монолиты: как бизнес работает с Legacy сегодня
То, как образуется Legacy, и как компании с ним борются, ярко видно на примере e-commerce. В период бурного роста онлайн-торговли основной задачей было быстро выходить на рынок с новым продуктом, минимизируя риски. Поэтому многие пользовались готовыми коробочными решениями или простыми конструкторами, которые можно было быстро развернуть, не задумываясь о продуктовой архитектуре. В итоге почти все интернет-магазины, которые массово запускались с
Когда началась пандемия, интернет-магазин вдруг стал единственным каналом доступа к товарам: конкуренция повысилась в разы, и бизнесу пришлось гнаться за скоростью, качеством сервиса и гибкостью. Компании начали задумываться о таких вещах, как доставка в Dark Store, Last Mile, трекинг логистики до последнего метра. Поэтому бизнес начал разбирать свои монолиты и выносить из них отдельные сервисы.
Появились отдельные сервисы логистики, чтобы отслеживать доставку. Появились сервисы оплат, чтобы можно было подключить разные платежные инструменты, кредитование, оплату долями. Началась работа с управлением стоками: с ростом товарооборота магазинам понадобилась максимально актуальная информация о наличии товара. Даже простая авторизация изменилась: если раньше она строилось на классической схеме «логин/пароль», то сейчас популярны одноразовые коды через SMS — и это тоже отдельный сервис, который нужно интегрировать. Многого из этого старые коробочные решения просто не умели. Добавим к этому еще и фактор импортозамещения — 2022 год ускорил процесс.
Все это постепенно привело к тому, что рынок задумался о сложной архитектуре: десятки отдельных сервисов должны работать по общим правилам, через единые каналы обмена данными, с согласованными форматами и единой бизнес-логикой. В итоге последние несколько лет мы шаг за шагом разбираем старые монолитные решения, которые массово строились до пандемии.
Здравый бизнес-смысл: когда стоит задуматься о замене
Есть важный нюанс: инициатива пересмотра Legacy всегда должна исходить именно от ИТ, потому что именно технические команды видят, где слабые места архитектуры. Однако согласовываться трансформация должна совместно с бизнесом: любые изменения должны начинаться с бизнес-анализа и четкого расчета целесообразности. Часто приходят люди с лозунгом «сейчас все перепишем» и рушат вполне жизнеспособные системы — но замена Legacy не должна становиться вопросом энтузиазма.
Есть несколько признаков, по которым компания может понять, что нуждается в модернизации, а не в бесконечной поддержке Legacy:
- Растущая стоимость обслуживания. Чем старше система, тем дороже специалисты, которые умеют с ней работать. Этих людей мало, а с годами их становится еще меньше — кто-то просто уходит с рынка, кто-то выходит на пенсию.
- Невозможность развивать систему. Если бизнес хочет внедрить новую функцию или отвечает на изменения законодательства, но старая архитектура это не позволяет, приходится городить новые надстройки или менять ядро.
- Невозможность справляться с нагрузкой. Системы, рассчитанные на 10 пользователей, не выдерживают современные потоки — особенно когда речь идет о тысячах транзакций или массовой работе с карточками и платежами. Многие старые решения работают в однопоточном режиме — и даже современные процессоры не помогут, если архитектура не поддерживает многопоточность.
Любой проект по модернизации должен опираться на конкретные цели — экономию, рост доходов, снижение рисков или выполнение требований закона. Цель нужно закрепить документально и согласовать с ключевыми ЛПР. Иначе проект быстро буксует: через полгода кто-то спросит, зачем тратятся десятки миллионов, если «и так все работает».
Успехи и провалы: кейсы из практики
Трансформация оправдывает себя только тогда, когда заранее просчитаны все эффекты и есть понятный бэклог развития. Отличная иллюстрация грамотной замены Legacy — разработка собственных систем андеррайтинга с нуля в крупном банке. Еще несколько лет назад банк мог бы просто «прикрутить» сторонние модули или покупать расчеты у внешних сервисов. Но с ростом бизнеса и появлением суперприложений расчет показал, что выгоднее построить собственные сервисы оценки рисков: это колоссальная экономия в долгосрочной перспективе.
В небольшой компании даже проще посчитать эффект. Например, поступает предложение автоматизировать выдачу ДМС — для этого не нужно держать отдельного специалиста — бухгалтерия высвобождает часть времени. В итоге экономика понятна: потратили 800 тысяч, сэкономили три миллиона. В корпорации все расчеты гораздо сложнее: согласования, амортизация денег, внутренние коэффициенты — в итоге реальный эффект не всегда очевиден и трудно выделяется в общих цифрах. Поэтому многие менеджеры в крупных компаниях пытаются «продавать» проекты через личные связи, а не через расчеты — и это часто оборачивается мертвыми решениями, которые годами дорабатываются «заплатками».
Поэтому на рынке нередко встречаются и кейсы провальной трансформации. Например, представим ситуацию: компания решает «распилить» фронтенд ради красивой архитектуры, но забывает про реальную бизнес-ценность. Инициатива может идти от нескольких топ-менеджеров, которым хочется «сделать красиво», но без четкого понимания, какую пользу это даст. В итоге разные подразделения ждут разного: ИТ-команда рассчитывает ускорить разработку за счет разделения фронта и бэка, но не учитывает, что это требует больше людей и ресурсов. Бизнес ждет ускорения отклика сайта — а, например, из-за особенностей архитектуры SSR все может даже замедлиться. Собственник хочет быстрее запускать новые гипотезы, но никто не говорит ему, что без доработок бэка это нереализуемо. В итоге все три группы стейкхолдеров не получают ожидаемого эффекта: теряются миллионы рублей, команда демотивируется, проект растягивается и достраивается по кускам. Это типичная история, когда внутрикорпоративная бюрократия подменяет здравый смысл.
Что будет дальше: есть ли шанс избежать Legacy?
Можно ли сразу построить систему так, чтобы через 10 лет не упираться в те же проблемы? Теоретически — да. Современные подходы — API, микросервисы, гибкая архитектура — позволяют обновлять куски системы независимо друг от друга. Некоторые компании уже внедряют такой подход: у каждой команды есть свой «кусочек» продукта, который они могут дорабатывать без риска сломать все остальное. Это дороже на старте, но дешевле в перспективе.
Есть и простые практические рекомендации:
- Выбирать современный стек. Сегодня, начиная любой проект, важно смотреть не только на то, что удобно здесь и сейчас, но и предвидеть, что будет востребовано через пять лет. Это видно по тому, какие технологии выбирают большие игроки вроде Google, Amazon и других глобальных лидеров — обычно их подходы потом становятся массовыми. Если вы пишете новый продукт на стеке, который уже устарел или слабо поддерживается, — например, на старом «голом» PHP без актуальных библиотек, — это путь в никуда.
- Смотреть на рынок труда. Нужно понимать, что специалистов, которые смогут поддерживать и развивать ваш продукт, должно быть достаточно и завтра, и через пять лет. Бизнесу стоит инвестировать не только в переписывание кода, но и в обучение, поиск и привлечение разработчиков, которые умеют работать с актуальными стеками.
- Еще на старте трезво оценивать свои реальные потребности и соотносить их с возможностями стека и инструментария. Например, «Битрикс» и другие коробочные системы — вполне рабочее решение, если объем задач соответствует его возможностям. Но интернет-магазин с объемом 10 тысяч заказов в день на «Битриксе» — это заведомо плохая идея.
Любая система со временем превращается в Legacy — это закон ИТ-жизни. Важно не бояться старого кода, а уметь управлять им грамотно: монолиты резать на сервисы, архитектуру — обновлять, команду — развивать, и всегда помнить, что главное — не красивая новая витрина, а обоснованный расчет и четко работающий бизнес-процесс.
