Реплатформинг в электронной коммерции. Простыми словами о переезде с решений, которые мешают расти

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

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

В девяностые и двухтысячные российский рынок корпоративных IT-решении был без боя занят западными вендорами. Из отечественных продуктов существенную долю удалось занять только 1С и Касперскому.

Электронная коммерция — молодая отрасль, но в ней происходили те же самые процессы. Большинство компании рано или поздно приходили к решению внедрить продукты enterprise-вендоров по различным причинам:

• Маркетинг и репутация западных вендоров;
• Использование внедрения, как способа подняться по карьерной лестнице, или с целью привлечения внимания акционеров;
• Давление штаб-квартир зарубежных ритейлеров;
• IPO и привлечение инвестиций: внедренное комплексное enterprise-решение — положительныи фактор при выходе на биржу.

В открытых источниках нет развернутых отзывов о внедрении в екоме комплексных enterprise-решении. Можно найти либо официальные пресс-релизы, либо комплиментарные статьи от pr-подразделений ритейлеров.

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

Развивать комплексные enteprise-платформы дорого, при этом даже небольшие изменения делаются долго по ряду причин:

• Монолитная архитектура;
• Сложность кастомизации под нестандартные бизнес-процессы;
• Технологический стэк, под которыи сложно и дорого искать специалистов.

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

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

• Распределение бизнес-функций по разным приложениям. Каждое можно развивать независимо от других, например, за счет сервисной архитектуры.
• Разные приложения могут поддерживаться разными командами. Большое количество подходящих специалистов и компаний на рынке.
• Отсутствие лицензионных рисков. Например, Open Source или On-premise с разовой оплатой.

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

• Новое решение — полный аналог, или функциональность замещаемой платформы размазывается по нескольким системам?
• Функции в новых решениях воссоздаются as is или реализуются по-новому?
• Переезд происходит одномоментно или в несколько этапов?
• Готова ли компания жертвовать бизнес-функциями во время переезда?

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

Стратегия постепенного переезда (Ice cream scoop strategy) предлагает выделять один или несколько бизнес-доменов, которые будут вырезаны из текущего решения и реализованы на вновь создаваемых сервисах. Эта стратегия предполагает, что старая платформа работает параллельно с новой.

Резервирование критических процессов

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

Сценарий актуален, если существует риск внезапной остановки бизнеса из-за IT. Например, ожидается повышенная нагрузка перед новогодними праздниками, которую гарантировано не выдержит платформа. Другая распространненная причина — отключение сервисов вендором.

Частичный перенос фронта

Полныи перенос фронта — это трудоемкая задача, требующая много времени. Как правило, гораздо больше допустимого срока избавления от рисков или заморозки развития.

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

Полный перенос фронта

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

Частичный переезд фронта

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

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

API-изация старого решения

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

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

С деградацией функциональности

Есть две основных причины, когда бизнес жертвует частью функциональности во время переезда:

• Есть необходимость переехать как можно быстрее;
• Часть функций старой платформы больше не нужны.

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

С полным сохранением функциональности

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

• Определить список процессов (любым удобным способом: story, feature и т. д.) , которые затронет переезд.
• Определить, как процессы распределяются между внедряемыми сервисами и старым решением. Решить, в каких сервисах будут реализованы те или иные stories/features.
• Описать потоки данных между старым решением и новыми сервисами. Выставить методы для команды, дорабатывающеи старое решение.
• Разработать и запустить.

Материал основан на большом опыте разрезания монолитов и переезда с enterprise-решений на сервисную платформу электронной коммерции Ensi. tech.