Переезд
на сервисные IT-решения

⟶ Особенности, стратегии и последовательность действий при переезде на сервисные IT-решения.

Содержание


Как комплексные enterprise-решения появились в e-commerce

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

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

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

Особенности продуктов enterprise-вендоров в e-commerce

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

О реальных результатах внедрений можно судить только по той информации, которую компании дают на тендерах по замещению комплексных enterprise-платформ.
☞ Многие компании, внедрившие такие платформы, думают о замене. Чаще всего это вызвано слишком высокими OpEx и time-to-value.
✨ OpEx
Расходы на поддержание всей системы в рабочем состоянии
✨ Time-to-value
Указывает на время, которое требуется на внедрение решения, до момента, когда оно начнет приносить выручку.
Развивать комплексные enteprise-платформы дорого, при этом даже небольшие изменения делаются долго по ряду причин:
  • 1
    Монолитная архитектура;
  • 2
    Сложность кастомизации под нестандартные бизнес-процессы;
  • 3
    Технологический стек, под который сложно и дорого найти специалистов.
В электронной коммерции высокая скорость изменений. Бизнесу необходимо уметь быстро внедрять новые решения, а исходный потенциал любой платформы не так важен: большая часть функциональности все равно разрабатывается с нуля под конкретный бизнес.

Критерии решений с пониженным риском

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

Стратегии переезда с платформ ушедших вендоров

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

Постепенный переезд

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

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

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

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

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

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

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

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

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

Технические особенности постепенного переезда

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

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

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

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

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

Единовременный переезд

В некоторых ситуациях постепенный переезд невозможен или затруднен. Например, текущее монолитное решение нужно API-изировать, чтобы появилась возможность строить рядом заменяющие его функциональность сервисы. Такая доработка старого решения может быть сравнима по трудоемкости с единовременным переездом на новую платформу.
✨ Монолитное решение
Cтандартные модули, пользовательский интерфейс (UI), бизнес-логика и дата-слой в программном обеспечении объединены в единый сервис.
☞ Если развитие старого решения не заморожено, то с единовременным переездом могут возникнуть сложности. Переезд будет все время откладываться, так как новое решение будет постоянно отставать от старого.

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

Есть две основных причины, когда бизнес жертвует частью функциональности во время переезда:
  • 1
    Есть необходимость переехать как можно быстрее;
  • 2
    Часть функций старой платформы больше не нужны.
Единовременный переезд с деградацией функциональности
Самое сложное в этой стратегии — сформулировать и защитить то, в каком виде будет запущено новое решение.

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

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

Эта наиболее трудозатратная стратегия. К ней прибегают, когда бизнес готов на большие инвестиции и значительные сроки.

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

Последовательность действий при переезде

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

Авторы статьи

  • Сергей Мелихов
    Директор новых проектов
  • Мария Созонтова
    Аккаунт-директор
  • Павел Кан
    Архитектор IT-решений
ЭТА СТАТЬЯ В МИНИ-КНИГЕ · Переезд на сервисные IT-решения. Особенности, стратегии и последовательность действий при переезде на сервисные IT-решения.

подписывайтесь и будьте в курсе

Оставить заявку на демо платформы

Нажимая на кнопку «Отправить», вы соглашаетесь с условиями обработки персональных данных.