Привет! Добро пожаловать на канал про разработку в retail. Рассказываем про новые подходы в построении ecom-проектов: headless, composable commerce, SOA и другие. Начнем с глоссария.

Composable Commerce, или композитный e-com — архитектурный подход к построению интернет-магазинов или маркетплейсов. В нем продукт не разрабатывается с нуля, а компонуется из готовых решений от разных вендоров. Например, авторизацию берем от Ensi.tech, управление заказами — от RetailCRM, поиск — от Яндекса. Так создается нужная для бизнеса композиция. #composable

Headless commerce — подход в разработке, в котором фронтенд и бэкенд интернет-магазина отделяются друг от друга и становятся независимыми частями. Бэкенд API проектируется как универсальный механизм для взаимодействия с разными пользовательскими каналами или точками касания аудитории. #headless

Точка контакта с аудиторией (touch point) — любой канал, где пользователь взаимодействует с брендом/продуктом. Например: фронтенд сайта, терминальное решение, мобильное приложение, виджет на другом сайте, соцсеть.

MACH — аббревиатура принципов построения современных е-com проектов: Microservices-based, API-first, Cloud-native, Headless. #mach

В чем плюсы композитного екома?

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

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

Основные преимущества подхода:
— Уникальность — проект компонуется исходя из уникальных бизнес-потребностей;
— Отсутствие вендорлока, или зависимости от одного разработчика ПО;
— Скорость разработки увеличивается за счет использования готовых решений;
— Гибкость — благодаря «сервисной природе» композитного е-com, бизнесы могут быстро добавлять/менять функционал и быстро адаптироваться к меняющимся трендам.

#composable

Зачем екому нужен headless

Headless (буквально «безголовый») — концепт построения систем, который давно используется в современной разработке. В интернет-магазине, разработанном по этому принципу, логическая часть системы независима от интерфейсов или точек взаимодействия с пользователем.

Часто headless путают с простым разделением frontend и backend сайта. Идея headless в том, чтобы логически и идейно оторвать API от интерфейсов. Так вы создаете универсальное внешнее API, которое затем используется различными фронтами: сайт и лендинги, мобильное приложение, терминалы в офлайн-магазинах.

Зачем это нужно?

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

Каналы эволюционируют: продолжат меняться существующие, добавятся новые. Headless-архитектура — это способ быть готовыми к такому.

Проверочный вопрос. Придется ли вам переделывать API, если нужно поменять frontend сайта (не просто перекрасить кнопки, а изменить логику)? Если ваш ответ да, то скорее у вас не headless. #headless

Почему не всегда нужно придерживаться composable

При всех преимуществах использования «составного» подхода в разработке магазина есть три ситуации, когда он только усложнит запуск:

1. Требуется MVP для тестирования идеи. Магазину не нужны серьезные интеграции и отдельный визуальный ряд. В этом случае рекомендуем по максимуму использовать готовые решения, например, InSales от Сбер.

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

3. Если интернет-магазин запускается на небольшом рынке, нет планов по быстрому масштабированию, но требуется особая логика. Тогда стоит обратиться к проверенному, хоть и устаревшему решению по примеру 1С-Битрикс, где будут доступны модификации, но не придется создавать сложную инфраструктуру и тратить деньги.

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

#composable

Скорость интернет-магазина — один из ключевых факторов эффективности

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

Под скоростью мы имеем ввиду:

🏃‍♂️ Скорость работы самого сервиса — загрузка интерфейсов, переключение между страницами, обновление информации, формирование заказа.

За счет таких гигантов как Ozon, Lamoda или Amazon мы привыкли к быстрым ecom-сервисам. При создании заказа ожидаем, что он уйдет в работу сразу же, а не на следующий день после звонка оператора. Готовы получить заказ через 1-2 дня, но если срок — неделя, то скорее всего пойдем искать аналогичный товар у конкурентов. За счет той же скорости мы можем быстро закрыть приложение одного магазина и заказать в другом.

🧪 Скорость внедрения новых решений и экспериментов.

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

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

Напоследок: чек-лист быстрого сервиса

— Моментальная загрузка интерфейсов и обновления данных. Мы живем в мире коротких рилсов. Если после открытия сайта пользователь ждет дозагрузки информации о товаре, он теряет к нему интерес.

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

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

Вопрос

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

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

Но и полностью отказаться от платформы не получается — это сложно, долго, непонятно, с чего начать.

Вывод

Старые платформы не только тянут ecom-сервис вниз и диктуют, как жить, но и могут быть «воротами» для хакеров.

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

То ли рыба, то ли мясо. Что такое полу-composable commerce

Построить полностью «составной» интернет-магазин в России невозможно. Нам не хватает решений, которые были бы достаточно гибкими, могли решать разные задачи и бесшовно встраиваться в работу сайтов. Самое главное — нет API-first каталога/корзины (аналога commercetools, как пример).

Некоторые компании пробуют создавать headless решения. Например, Ensi от Greensight. Но эти решения еще шлифуются и дорабатываются. И все же это не повод продолжать изобретать велосипеды и «пилить» полностью кастомный продукт.

💻 Что делать

На помощь приходит полу-composable commerce (наш авторский термин 😀). Подход предполагает, что вы изучаете рынок, смотрите, какие есть готовые сервисы, удовлетворяющие вашим требованиям — и внедряете их в бэкенд. А уже для тех функций, которых не хватает, можно создать собственные решения.

🔎 Пример, как сегодня разрабатывать магазин с нуля в России, используя полу-composable подход

— API Каталога — 1С-Битрикс со слоем Larаvel;
— OMS — RetailCRM;
— Рекомендательный сервис — RetailRocket;
— Программа лояльности — Mindbox/Manzana;
— Поиск — Ensi Cloud Search.

🔦 В любом случае

Даже несмотря на то, что в России не хватает решений для composable e-commerce, переход к нему в долгосрочной перспективе неизбежен. Каждый месяц появляется все больше полноценных сервисов для ecom, которые предоставляют открытое API и способны закрывать самые уникальные потребности. Это процесс не остановить, поскольку никто не хочет изобретать велосипед снова и снова.

Еще одна ecom-платформа. Зачем?

Интегратор Globus IT представил Compo — платформу для развития онлайн-торговли. Пишут, что продукт способен заменить 20+ западных решений — SAP Commerce Cloud (Hybris), Pimcore, Scallium, Magento и другие. Уже известны первые клиенты — X5 Group, Vprok.ru Перекрёсток, Chemexsol.

Судя по всему, Compo — модульно-сервисная платформа. Насколько она headless или API-first и можно ли использовать модули независимо друг от друга, пока не понятно.

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

Зачем нам еще одно решение? Мало 1С-Битрикса?

Запуск Compo и похожих решений в последнее время еще раз подтверждает, что старые технологии с трудом обеспечивают современные ecom-нужды. Можно сказать, вообще не справляются.

Грядет большой реплатформинг. Если вы еще сидите на старых технологиях и думаете, что просто не умете их «готовить», знайте — никто уже не умеет.

Нужно ли менять вашу ecom-платформу?

Если отвечать кратко, то не стоит. Это будет сложный процесс без гарантий на выходе.

Однако в этой скучной для руководителей ecommerce-теме важный момент: помогает ли ваша технологическая платформа меняться быстро? Разобраться может быть не просто. Но есть маркеры, при которых стоит задуматься.

🏷 Признаки, что точно пора что-то делать

1. «Пока мы это не можем». Если на запрос новой фичи разработчики вам говорят: «а может, попробуем по-другому» или «пока мы такое не можем сделать, нужно много менять» — это красный флаг. Вы стали заложником системы, подстраиваетесь под нее.

2. Редкие релизы. Если они проходят раз в неделю-месяц, с платформой что-то не так. В ecom’е нет времени на долгие циклы разработки. Через полгода все, что вы сделаете, может уже может устареть.

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

🔧 Можно ли это исправить? Да, можно. И нужно, иначе придется расстаться с надеждами на рост, развитие и прочее.

$90 миллионов на большой конструктор

Не так давно ElasticPath поднял $90 миллионов инвестиций на развитие своей платформы. Компания не часто мелькает в инфополе, но она сделала огромный вклад в развитие composable commerce. Gartner неоднократно называл ее визионером в области ecom.

Часть инвестиций будут потрачены на развитие хабов интеграции различных инструментов. Это нужно, чтобы сделать запуск и развитие сложных и кастомных магазинов более простой. Фактически, чтобы их можно было собирать как low-code решение.

Почему это важно?

Скорость развития технологической платформы — ключевая экспертиза в ecom.

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

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