Переезд
на сервисные IT-решения
⟶ Особенности, стратегии и последовательность действий при переезде на сервисные IT-решения.
Содержание
- Как комплексные решения появились в e-commerce
- Особенности продуктов enterprise-вендоров в e-commerce
- Критерии решений с пониженным риском
- Стратегии переезда с платформ ушедших вендоров
- Постепенный переезд
- Технические особенности постепенного переезда
- Единовременный переезд
- Последовательность действий при переезде
- Мини-книга в PDF ⚡
Как комплексные enterprise-решения появились в e-commerce
В девяностые и двухтысячные российский рынок корпоративных IT-решений был без боя занят западными вендорами. Из отечественных продуктов существенную долю удалось занять только 1С и Касперскому.
Электронная коммерция — молодая отрасль, но в ней происходили те же самые процессы. Большинство компаний рано или поздно приходили к решению внедрить продукты энтерпрайз-вендоров по различным причинам:
Электронная коммерция — молодая отрасль, но в ней происходили те же самые процессы. Большинство компаний рано или поздно приходили к решению внедрить продукты энтерпрайз-вендоров по различным причинам:
- Маркетинг и репутация западных вендоров;
- Использование внедрения, как способа подняться по карьерной лестнице, или с целью привлечения внимания акционеров;
- Давление штаб-квартир зарубежных ритейлеров;
- IPO и привлечение инвестиций: внедренное комплексное enterprise-решение — положительный фактор при выходе на биржу.
☞ Одна из главных причин господства комплексных enterprise-продуктов — высокий уровень требований к внедрению.
Компании, выбирая западные решения, ожидали получить инъекцию практик высокого уровня. Бизнес в нашей стране молодой, поэтому такой способ компенсировать десятки лет развития был весьма популярен.
Компании, выбирая западные решения, ожидали получить инъекцию практик высокого уровня. Бизнес в нашей стране молодой, поэтому такой способ компенсировать десятки лет развития был весьма популярен.
Особенности продуктов enterprise-вендоров в e-commerce
В открытых источниках нет развернутых отзывов о внедрении в екоме комплексных enterprise-решений. Можно найти либо официальные пресс-релизы, либо комплиментарные статьи от pr-подразделений ритейлеров.
О реальных результатах внедрений можно судить только по той информации, которую компании дают на тендерах по замещению комплексных enterprise-платформ.
О реальных результатах внедрений можно судить только по той информации, которую компании дают на тендерах по замещению комплексных 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. Например, ожидается повышенная нагрузка перед новогодними праздниками, которую гарантировано не выдержит платформа. Другая распространненная причина — отключение сервисов вендором.
Сценарий актуален, если существует риск внезапной остановки бизнеса из-за IT. Например, ожидается повышенная нагрузка перед новогодними праздниками, которую гарантировано не выдержит платформа. Другая распространненная причина — отключение сервисов вендором.
Поэтапный перенос, начиная с наиболее критической функциональности
Частичный перенос фронта
Полный перенос фронта — это трудоемкая задача, требующая много времени. Как правило, гораздо больше допустимого срока избавления от рисков или заморозки развития.
Задачу по переносу фронта можно разбить на этапы: сайт или мобильное приложение, замещаются по кусочкам. Например, сначала процесс оформления заказа, затем каталог, а потом главная страница.
Задачу по переносу фронта можно разбить на этапы: сайт или мобильное приложение, замещаются по кусочкам. Например, сначала процесс оформления заказа, затем каталог, а потом главная страница.
Частичный перенос фронта с APIзацией бэка без переноса в сервисы
Частичный перенос фронта с переносом в сервисы
Полный перенос фронта
В электронной коммерции сайт и мобильное приложение — подверженные наиболее частым изменениям компоненты платформы. Наибольшая пользовательская нагрузка также падает на сервисы, связанные с фронтом. Поэтому перенос сайта и мобильного приложения — часто встречающаяся задача. В этой стратегии рядом с уже работающим фронтом создается новый.
Полный перенос фронта только с APIзацией бэка, без переноса в сервисы
Полный перенос фронта с переносом в сервисы
Технические особенности постепенного переезда
Частный переезд фронта
Пользователь, перемещаясь по сайту, не должен замечать, что перед ним не единый фронт, а разные приложения. Для этого нужно настраивать маршрутизацию между разными частями фронта, а это нетривиальная задача.
Нередко переезд фронта совмещен с редизайном, во время которого меняются сквозные элементы: хедер, футер, формы и т. д. Можно ничего с этим не делать, но тогда пользователь будет работать с витриной, на которой стандартные элементы выглядят по-разному. Чтобы избежать этого, придется включить в план приведение всех частей витрины к единому виду.
Нередко переезд фронта совмещен с редизайном, во время которого меняются сквозные элементы: хедер, футер, формы и т. д. Можно ничего с этим не делать, но тогда пользователь будет работать с витриной, на которой стандартные элементы выглядят по-разному. Чтобы избежать этого, придется включить в план приведение всех частей витрины к единому виду.
☞ Если у компании нет возможности как-либо дорабатывать старое решение и в нем не реализовано API достаточно высокого уровня, от стратегии постепенного переезда придется отказаться.
API-изация старого решения
✨ API-изация
Обеспечение решения API, которым смогут пользоваться внешние для этого решения системы.
При постепенном переносе функциональности нужно решить вопрос, как старое решение будет взаимодействовать с новым. Старое решение не обязательно имеет хорошее API, а значит нужно заложить трудозатраты на его доработку или разработку с нуля.
Единовременный переезд
В некоторых ситуациях постепенный переезд невозможен или затруднен. Например, текущее монолитное решение нужно API-изировать, чтобы появилась возможность строить рядом заменяющие его функциональность сервисы. Такая доработка старого решения может быть сравнима по трудоемкости с единовременным переездом на новую платформу.
✨ Монолитное решение
Cтандартные модули, пользовательский интерфейс (UI), бизнес-логика и дата-слой в программном обеспечении объединены в единый сервис.
☞ Если развитие старого решения не заморожено, то с единовременным переездом могут возникнуть сложности. Переезд будет все время откладываться, так как новое решение будет постоянно отставать от старого.
С деградацией функциональности
Есть две основных причины, когда бизнес жертвует частью функциональности во время переезда:
- 1Есть необходимость переехать как можно быстрее;
- 2Часть функций старой платформы больше не нужны.
Единовременный переезд с деградацией функциональности
Самое сложное в этой стратегии — сформулировать и защитить то, в каком виде будет запущено новое решение.
С момента фиксации требований конечного продукта разные бизнес-подразделения будут стараться протолкнуть нужные им функции, не вошедшие в финальный скоуп.
С момента фиксации требований конечного продукта разные бизнес-подразделения будут стараться протолкнуть нужные им функции, не вошедшие в финальный скоуп.
С полным сохранением функциональности
Эта наиболее трудозатратная стратегия. К ней прибегают, когда бизнес готов на большие инвестиции и значительные сроки.
Ожидаемый результат — технологическое обновление и снижение time-to-value.
Ожидаемый результат — технологическое обновление и снижение time-to-value.
Единовременный переезд с полным сохранением функциональности
Последовательность действий при переезде ↘
1
Определить список процессов (любым удобным способом: story, feature и т. д.), которые затронет переезд.
2
Определить, как процессы распределяются между внедряемыми сервисами и старым решением. Решить, в каких сервисах будут реализованы те или иные stories/features.
3
Описать потоки данных между старым решением и новыми сервисами. Выставить методы для команды, дорабатывающей старое решение.
4
Разработать и запустить.
6 декабря 2022
Авторы статьи
- Сергей МелиховДиректор новых проектов
- Мария СозонтоваАккаунт-директор
- Павел КанАрхитектор IT-решений
Эта статья в мини-книге
Нажимая на кнопку «Скачать», вы соглашаетесь с условиями обработки персональных данных.
подписывайтесь и будьте в курсе
Факты из жизни электронной коммерции
Новости от разработчиков платформы
Официальный новостной канал платформы
Блог в расширенном формате