В корпоративном ИТ до сих пор довольно распространено представление, что технологическая зрелость напрямую связана с переходом на новые платформы, актуальные версии и современные архитектурные подходы. Если есть новая версия платформы – то надо обновляться, если есть современное решение — обязательно переходить на него, монолит желательно распилить, а legacy (унаследованные системы со значимыми ограничениями по развитию, поддержке или эксплуатации) заменить, архитектуру привести к актуальному виду.

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

Старое не обязательно значит устаревшее

Возьмем условную ERP конца 2000-х — начала 2010-х. Да, система старая, и если бы сегодня все строилось с нуля, никто бы ее уже не выбрал. Но крупная компания почти никогда не находится в ситуации «строим с нуля». За годы эксплуатации такая ERP успевает обрасти бизнес-логикой, интеграциями, отчетностью, данными, исключениями и конкретными процессами компании.

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

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

Модернизация по частям

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

Практический смысл такого подхода в том, что зависимость от старого ядра сокращается постепенно, по мере появления технологических или экономических оснований.

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

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

На практике такой сценарий вполне работает, в ритейле у меня был как раз такой опыт. ERP продолжала нормально выполнять учетную функцию, но развивать в ней инструменты для сотрудников магазинов становилось все сложнее. Мы вынесли сопровождение и оформление продаж в отдельное мобильное приложение на Android, связав его с учетным контуром через API и микросервисы. При этом сам учет и отражение операций остались в ERP — ломать работающий учетный контур необходимости не было.

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

У разных частей ландшафта разный срок жизни

У разных частей корпоративного ИТ-ландшафта изначально разный жизненный цикл. Клиентские интерфейсы, мобильные приложения, аналитика, AI-инструменты (решения на базе искусственного интеллекта) могут меняться очень быстро. Интеграционный слой живет по другому циклу, а ERP, учетные и другие ключевые системы обычно имеют заметно более длинный жизненный цикл.

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

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

За годы эксплуатации вокруг них уже построена нормальная инфраструктура, накоплены компетенции, настроены интеграции, понятны реальные ограничения. Кроме того, часть ограничений, существовавших в момент появления таких систем, сегодня существенно смягчена более производительным железом, современными СУБД, интеграционными средствами и инфраструктурой. А значит, возраст прикладной системы и ее реальные технологические ограничения — далеко не одно и то же.

А сколько на самом деле стоит новая платформа?

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

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

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

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

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

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

Гибрид тоже имеет свою цену

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

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

Если вокруг старого ядра приходится постоянно строить обходные решения, усложнять интеграции и поддерживать отдельные процессы только ради его сохранения, в какой-то момент экономика действительно перестает сходиться.

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

Когда менять все-таки нужно

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

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

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

У меня был как раз такой пример с DWH/OLAP-платформой. Когда мы ее запускали, это была фактически первая полноценная DWH и система отчетности в компании. За семь лет бизнес вырос примерно в три раза, ИТ-ландшафт успел пройти путь от монолита к микросервисам и новым цифровым платформам, количество источников данных выросло примерно втрое, а количество отчетов и показателей — более чем в четыре раза. За это время система пережила три серьезных рефакторинга, огромное количество локальных доработок, расширение отчетности. В какой-то момент стало понятно, что архитектура дошла до своего предела. Перед нами был довольно простой выбор: потратить серьезные ресурсы на очередную перестройку решения на старой платформе или сопоставимые усилия вложить уже в новую. Мы выбрали второй вариант. Объем работ был примерно одинаковым, но старая платформа к тому моменту уже заметно ограничивала дальнейшее развитие, тогда как новый технологический стек давал и новую функциональность, и больший запас на последующие годы.

Современная архитектура сама по себе еще не дает бизнес-эффекта. У смены технологии или архитектуры должен быть понятный и измеримый результат. Например, автоматизируем процесс и сокращаем ручной труд или количество FTE (эквивалент полной занятости), ускоряем запуск продукта, снижаем операционные расходы, увеличиваем пропускную способность, снижаем значимый для бизнеса риск или получаем дополнительную выручку. Если эффект не просчитывается или несопоставим со стоимостью и сроками миграции, сложно обосновать, зачем компании инвестировать в такой переход именно сейчас.

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

Источник: IT World.

Больше новостей читайте в сообществе SAPLAND в ВК и телеграм-канале SAPLAND: Новости экосистемы.