Реплатформинг в электронной коммерции. Простыми словами о переезде с решений, которые мешают расти
Если внедрение новых фич и процессов сопровождается болью, падением сервисов и бесконечными сроками, значит настало время эволюционировать и переходить на более эффективные решения.
В этой статье мы систематизировали наш опыт и описали возможные стратегии ухода с коробочных продуктов. В том числе и ухода с них из-за санкций.
Как комплексные enterprise-решения появились в e-commerce
В девяностые и двухтысячные российский рынок корпоративных IT-решении был без боя занят западными вендорами. Из отечественных продуктов существенную долю удалось занять только 1С и Касперскому.
Электронная коммерция — молодая отрасль, но в ней происходили те же самые процессы. Большинство компании рано или поздно приходили к решению внедрить продукты enterprise-вендоров по различным причинам:
- Маркетинг и репутация западных вендоров;
- Использование внедрения, как способа подняться по карьерной лестнице, или с целью привлечения внимания акционеров;
- Давление штаб-квартир зарубежных ритейлеров;
- IPO и привлечение инвестиций: внедренное комплексное enterprise-решение — положительныи фактор при выходе на биржу.
Одна из главных причин господства комплексных enterprise-продуктов — высокий уровень требований к внедрению.
Компании, выбирая западные решения, ожидали получить инъекцию практик высокого уровня. Бизнес в нашей стране молодой, поэтому такои способ компенсировать десятки лет развития был весьма популярен.
Особенности продуктов enterprise-вендоров в e-commerce
В открытых источниках нет развернутых отзывов о внедрении в екоме комплексных enterprise-решении. Можно найти либо официальные пресс-релизы, либо комплиментарные статьи от pr-подразделений ритейлеров.
О реальных результатах внедрений можно судить только по той информации, которую компании дают на тендерах по замещению комплексных enterprise-платформ.
Многие компании, внедрившие такие платформы, думают о замене. Чаще всего это вызвано слишком высокими OpEx и time-to-value.
Развивать комплексные enteprise-платформы дорого, при этом даже небольшие изменения делаются долго по ряду причин:
- Монолитная архитектура;
- Сложность кастомизации под нестандартные бизнес-процессы;
- Технологический стэк, под которыи сложно и дорого искать специалистов.
В электроннои коммерции высокая скорость изменений. Бизнесу необходимо уметь быстро внедрять новые решения, а исходный потенциал любой платформы не так важен: большая часть функциональности все равно разрабатывается с нуля под конкретный бизнес.
Критерии решений с пониженным риском
После введения санкций, большинство западных вендоров покинули российский рынок. Ритейлеры перестали рассматривать их решения в качестве целевых. Те, кто уже внедрил западные entreprise-платформы, разрабатывают стратегии перехода на независимые решения. Такие решения должны обладать следующими своиствами:
- Распределение бизнес-функций по разным приложениям. Каждое можно развивать независимо от других, например, за счет сервисной архитектуры.
- Разные приложения могут поддерживаться разными командами. Большое количество подходящих специалистов и компаний на рынке.
- Отсутствие лицензионных рисков. Например, Open Source или On-premise с разовой оплатой.
Стратегии переезда с платформ ушедших вендоров
Переезд — замещение функциональности одних решении функциями других. Определяясь со стратегией, компании отвечают на несколько вопросов:
- Новое решение — полный аналог, или функциональность замещаемой платформы размазывается по нескольким системам?
- Функции в новых решениях воссоздаются as is или реализуются по-новому?
- Переезд происходит одномоментно или в несколько этапов?
- Готова ли компания жертвовать бизнес-функциями во время переезда?
В зависимости от ответов, компания может выбрать ту или иную стратегию переезда. Все они сводятся к двум вариантам: постепенныи переезд или единовременныи переезд.
Постепенныи переезд
Стратегия постепенного переезда (Ice cream scoop strategy) предлагает выделять один или несколько бизнес-доменов, которые будут вырезаны из текущего решения и реализованы на вновь создаваемых сервисах. Эта стратегия предполагает, что старая платформа работает параллельно с новой.
Резервирование критических процессов
Перенос происходит поэтапно, начиная с наиболее критической функциональности, например, сервисов оплаты. После того, как основные риски купированы, можно сменить стратегию.
Сценарий актуален, если существует риск внезапной остановки бизнеса из-за IT. Например, ожидается повышенная нагрузка перед новогодними праздниками, которую гарантировано не выдержит платформа. Другая распространненная причина — отключение сервисов вендором.
Частичный перенос фронта
Полныи перенос фронта — это трудоемкая задача, требующая много времени. Как правило, гораздо больше допустимого срока избавления от рисков или заморозки развития.
Задачу по переносу фронта на сайте или в мобильном приложении можно разбить на этапы и замещать по кусочкам. Например, сначала процесс оформления заказа, затем каталог, а потом главная страница.
Полный перенос фронта
В электронной коммерции сайт и мобильное приложение — подверженные наиболее частым изменениям компоненты платформы. Наибольшая пользовательская нагрузка также падает на сервисы, связанные с фронтом. Поэтому перенос сайта и мобильного приложения — часто встречающаяся задача. В этой стратегии рядом с уже работающим фронтом создается новый.
Технические особенности постепенного переезда
Частичный переезд фронта
Пользователь, перемещаясь по сайту, не должен замечать, что перед ним не единый фронт, а разные приложения. Для этого нужно настраивать маршрутизацию между разными частями фронта, а это нетривиальная задача.
Нередко переезд фронта совмещен с редизайном, во время которого меняются сквозные элементы: хедер, футер, формы и т. д. Можно ничего с этим не делать, но тогда пользователь будет работать с витриной, на которой стандартные элементы выглядят по-разному. Чтобы избежать этого, придется включить в план приведение всех частей витрины к единому виду.
Если у компании нет возможности как-либо дорабатывать старое решение, и в нем не реализовано API достаточно высокого уровня, от стратегии постепенного переезда придется отказаться.
API-изация старого решения
При постепенном переносе функциональности нужно решить вопрос, как старое решение будет взаимодеиствовать с новым. Старое решение не обязательно имеет хорошее API, а значит нужно заложить трудозатраты на его доработкуили разработку с нуля.
Единовременный переезд
В некоторых ситуациях постепенный переезд невозможен или затруднен. Например, текущее монолитное решение нужно API-изировать, чтобы появилась возможность строить рядом заменяющие его функциональность сервисы. Такая доработка старого решения может быть сравнима по трудоемкости с единовременным переездом на новую платформу.
Если развитие старого решения не заморожено, то с единовременным переездом могут возникнуть сложности. Переезд будет все время откладываться, так как новое решение будет постоянно отставать от старого.
С деградацией функциональности
Есть две основных причины, когда бизнес жертвует частью функциональности во время переезда:
- Есть необходимость переехать как можно быстрее;
- Часть функций старой платформы больше не нужны.
Самое сложное в этой стратегии — сформулировать и защитить то, в каком виде будет запущено новое решение. С момента фиксации требований конечного продукта разные бизнес-подразделения будут стараться протолкнуть нужные им функции, не вошедшие в финальный скоуп.
С полным сохранением функциональности
Эта наиболее трудозатратная стратегия. К ней прибегают, когда бизнес готов на большие инвестиции и значительные сроки. Ожидаемый результат — технологическое обновление и снижение time-to-value.
Последовательность деиствий при переезде
- Определить список процессов (любым удобным способом: story, feature и т. д.) , которые затронет переезд.
- Определить, как процессы распределяются между внедряемыми сервисами и старым решением. Решить, в каких сервисах будут реализованы те или иные stories/features.
- Описать потоки данных между старым решением и новыми сервисами. Выставить методы для команды, дорабатывающеи старое решение.
- Разработать и запустить.
Материал основан на большом опыте разрезания монолитов и переезда с enterprise-решений на сервисную платформу электронной коммерции Ensi. tech.