Сравнение платформ электронной коммерции
⟶ Сравнили популярные платформы для создания и развития электронной коммерции в России.
Содержание
О платформах электронной коммерции
- «Платформа — это архитектурный фреймворк для создания приложений и набор компонент, позволяющий получать готовые и разрабатывать собственные стандартизированные сервисы.»Алексей ЛипчанскийСбербанк
- «Традиционная платформа появляется для реализации групп приложений (продуктов, сценариев для разных групп пользо- вателей и т. п.) на основе общего набора компонент.»Максим СмирновКонсультант, автор и преподаватель курсов по ИТ-архитектуре
В электронной коммерции под платформой понимается система или набор систем, автоматизирующих основные процессы, связанные с товарами, клиентами и заказами. Такие комплексные решения могут одновременно содержать функциональность целых классов систем: PIM, CRM, OMS, CMS и других.
Выбор платформы через заложенные в ней подходы и архитектуру определяет стратегию развития IT ритейлера. Мы сравнили платформы по основным параметрам, которые влияют на этот выбор.
В исследовании не оцениваются бизнес-функции каждой из платформ. В ритейле, какой бы функциональной ни была платформа, существенная часть ресурсов тратится на ее кастомизацию и адаптацию к бизнес-процессам конкретной компании. Наличие той или иной фичи может как сокращать, так и увеличивать time-to-value, поскольку нередко требуется преодолевать заложенную в платформу бизнес-логику при кастомизации.
Выбор платформы через заложенные в ней подходы и архитектуру определяет стратегию развития IT ритейлера. Мы сравнили платформы по основным параметрам, которые влияют на этот выбор.
В исследовании не оцениваются бизнес-функции каждой из платформ. В ритейле, какой бы функциональной ни была платформа, существенная часть ресурсов тратится на ее кастомизацию и адаптацию к бизнес-процессам конкретной компании. Наличие той или иной фичи может как сокращать, так и увеличивать time-to-value, поскольку нередко требуется преодолевать заложенную в платформу бизнес-логику при кастомизации.
✨ PIM (Product Information Management)
Система для централизованного управления большими массивами данных о товарах. Подробнее
✨ CRM (Customer Relationship Management)
Система управления взаимоотношениями с клиентами.
✨ OMS (Order Management System)
Система для работы с заказами. Подробнее
✨ CMS (Content Management System)
Система управления контентом сайта или мобильного приложения.
Таблица сравнения платформ
Технологический стек
Рассматриваемые платформы распространены и актуальны. В том числе это касается и технологического стека, на котором они написаны. Конечно, каждый из языков и фреймворков — PHP 8, Java, .Net и др. — имеют свои важные особенности. Но ни одна из их характеристик не является существенным препятствием для использования в e-commerce платформах любого масштаба.
Языки важны не только своими техническими свойствами. Стоит также рассматривать стек с точки зрения рынка труда и подрядчиков. Ключевые вопросы:
Языки важны не только своими техническими свойствами. Стоит также рассматривать стек с точки зрения рынка труда и подрядчиков. Ключевые вопросы:
- 1Достаточно ли на рынке компаний, специализирующихся на избранном стеке?
- 2Соответствуют ли эти компании вашему ценовому сегменту?
- 3Развит ли рынок труда специалистов на этом стеке?
- 4Готовы ли вы к конкуренции за разработчиков, если решите
развивать собственную команду?
Некоторые решения, популярные в других странах, в России внедряются всего парой компаний. Это существенно повышает риск попасть в зависимость от подрядчиков или просто остаться без поддержки и возможности развивать решение на такой платформе.
А вот медианные значения зарплат разработчиков на популярных языках в зависимости от грейда:
А вот медианные значения зарплат разработчиков на популярных языках в зависимости от грейда:
Зарплаты бэкенд-разработчиков по данным калькулятора зарплат Хабр Карьеры на 15 июня 2023
Мы не стали уделять внимание технологическому стеку фронтовой части платформ. Вместо этого мы говорим об API-изации и Headless-подходе, то есть о характеристиках, которые в том числе помогают выделить фронт в отдельное приложение.
Особенности стека Ensi в сравнении с конкурентами
- Производительность PHP последних версий (8.х) выросла в разы, по сравнению со старыми версиями, когда формировалась репутация языка. Да, в некоторых аспектах PHP все еще проигрывает в производительности node. js, Go и даже Java (стек SAP CC). Но этот проигрыш не является критическим, к тому же для таких случаев давно разработаны решения.
- PHP и Laravel делают Ensi доступной и бизнесу, и разработчикам. Первые могут обращаться к огромному и доступному комьюнити, а разработчики получают удобный, современный open source фреймворк, на котором они могут автоматизировать процессы екома.
- PHP дает возможность быстро реализовывать и затем качественно поддерживать разнообразную бизнес-логику.
Кто может поддерживать и развивать
Ensi — самая молодая и наименее известная из сравниваемых платформ. Это в том числе означает, что рынок пока не накопил достаточного опыта решения типовых задач на этой платформе.
С другой стороны, Ensi изначально задумывалась как открытая платформа, использующая современные практики разработки и популярный стек с низким порогом входа в комьюнити для хороших специалистов. Прямо сейчас экосистема партнеров не очень широкая, но зато рынок насыщен специалистами, которые могут быстро разобраться и в самой платформе, и в уже внедренных на базе нее решениях.
У остальных платформ есть свои особенности поддержки:
С другой стороны, Ensi изначально задумывалась как открытая платформа, использующая современные практики разработки и популярный стек с низким порогом входа в комьюнити для хороших специалистов. Прямо сейчас экосистема партнеров не очень широкая, но зато рынок насыщен специалистами, которые могут быстро разобраться и в самой платформе, и в уже внедренных на базе нее решениях.
У остальных платформ есть свои особенности поддержки:
-
SAP СС требует глубоких знаний платформы. Поддерживать решения могут в основном enterprise-интеграторы высокого ценового сегмента. Практика работы с небольшими внешними или внутренними командами не так распространена, в том числе из-за политики самого вендора.
-
Magento — более открытая по сравнению с SAP платформа с развитым международным комьюнити. Но так как она из коробки обладает очень широкой функциональностью, развитие решений на ее базе так же требует опыта работы именно с этим продуктом. В России всего несколько компаний специализируются на Magento, из-за этого выбор исполнителей довольно узкий. -
Битрикс Управление сайтом — чрезвычайно распространенное решение среди разработчиков. Но некоторая технологическая отсталость и достаточность компетенций невысокого уровня для работы с ним приводят к тому, что внедренное решение не всегда легко поддерживать. К тому же, в сообществе разработчиков у Битрикса не очень хорошая репутация, и лучшие специалисты и интеграторы имеют тенденцию переходить в другой стек.
Архитектура
Архитектура платформы — ключевой фактор, определяющий подход к развитию IT ритейлера. Диапазон возможных вариантов здесь лежит между двумя крайними положениями:
- Замкнутая на себе монолитная коробка
- Мелко гранулированные микросервисы
Рассмотрим каждый из пунктов подробнее.
Замкнутая на себе монолитная коробка (Monolith)
В этом случае платформа — это единое приложение, где функциональность всех классов систем (PIM, CRM, OMS, CMS и т. д.) зашита внутрь коробки так, что отделить одну группу функций от другой невозможно или очень сложно.
Платформы с такой архитектурой диктуют то, как именно автоматизировать те или иные процессы. А бизнес сосредотачивается не на формулировании задач и поиске решений, а на ожиданиях, что многофункциональная платформа решит любые проблемы.
Платформы с такой архитектурой диктуют то, как именно автоматизировать те или иные процессы. А бизнес сосредотачивается не на формулировании задач и поиске решений, а на ожиданиях, что многофункциональная платформа решит любые проблемы.
Мелко гранулированные микросервисы (MSA)
При этом подходе платформа состоит из большого количества микросервисов, каждый из которых автоматизирует небольшое количество бизнес- (или системных-) функций. Например, отдельный микросервис может отвечать за доступность товара к продаже, другой — за его видимость на той или иной витрине, а третий — за список поставщиков, которые могут быть источником стока по этому товару.
Такой вид архитектуры подразумевает рассинхронизацию между бизнес-командами и командами IT. Чтобы реализовать бизнес-идею, нужно привлекать к разработке и тестированию множество микросервисов и их команды поддержки.
Такой вид архитектуры подразумевает рассинхронизацию между бизнес-командами и командами IT. Чтобы реализовать бизнес-идею, нужно привлекать к разработке и тестированию множество микросервисов и их команды поддержки.
Сервисный подход (SOA)
Отдельно стоит упомянуть сервисную архитектуру (в узком смысле этого термина). SOA-платформы состоят из отдельных приложений-сервисов, каждое из которых автоматизирует определенную группу процессов, как правило соответствующих бизнес-подразделениям ритейлеров. Отделу товарного контента — PIM, менеджерам по заказам — OMS, закупщикам — SRM и т. д.
Итого
Границы между разными типами архитектур размыты. Строго говоря, микросервисы — это подвид сервисной архитектуры. Одновременно с этим монолитные системы могут быть частью сложного SOA-ландшафта IT-систем, особенно, если они API-изированы из коробки или в рамках конкретного внедрения. Этот важный аспект мы рассмотрим ниже.
Решения на базе сервисов можно назвать инструментами следующего, более высокого уровня. Их использование требует бо́льших компетенций и времени для изначального разворота, но зато обеспечивают бизнесу нужную гибкость.
Но и монолиты с полным покрытием API и поддержкой headless могут быстро стать частью сервисной архитектуры, то есть перейти на другой уровень сложности. Это относится к решениям SAP и Magento. Битрикс требует создания API с нуля, и это большая работа. Зато для внедрения MVP он зачастую подходит больше.
Решения на базе сервисов можно назвать инструментами следующего, более высокого уровня. Их использование требует бо́льших компетенций и времени для изначального разворота, но зато обеспечивают бизнесу нужную гибкость.
Но и монолиты с полным покрытием API и поддержкой headless могут быстро стать частью сервисной архитектуры, то есть перейти на другой уровень сложности. Это относится к решениям SAP и Magento. Битрикс требует создания API с нуля, и это большая работа. Зато для внедрения MVP он зачастую подходит больше.
Расширение функциональности
Рассмотрим концепцию компании Gartner Pace-layered Application Strategy — удобную модель эволюции систем в организации.
Простое изложение концепции Максима Смирнова
В ритейле и электронной коммерции большая часть систем относятся к группе инноваций или конкурентных отличий. То есть, это либо зона быстрых экспериментов с минимальным time-to-market (например, в клиентском опыте или маркетинге), либо зона уникальных, а не универсальных процессов, которые являются конкурентным преимуществом одного ритейлера над другими (например, скорость обработки заказов или процессы доставки).
Ключевой особенностью платформ в такой ситуации является скорость и стоимость реализации новых функций и проведения экспериментов, а не объем предварительно реализованной бизнес-логики.
Ключевой особенностью платформ в такой ситуации является скорость и стоимость реализации новых функций и проведения экспериментов, а не объем предварительно реализованной бизнес-логики.
Особенности расширения функциональности Ensi в сравнении с SAP CC, Magento и Битрикс
В этом вопросе Ensi сильно отличается от остальных платформ. Стратегия последних заключается в стремлении добавить в коробку как можно больше специфической функциональности.
Делается ставка на то, что такой подход позволит автоматизировать процессы быстро и без разработки. Отчасти так и происходит, но, во-первых, коробочные функции все равно требуют адаптации, во-вторых, система начинает диктовать то, каким должны быть процессы.
Концепция Ensi предлагает противоположный подход: предоставляет фреймворк для разработки функциональности на основе сформулированных бизнес-требований. То есть не система определяет реализацию, а наоборот процессы определяют то, какой должна быть система.
Делается ставка на то, что такой подход позволит автоматизировать процессы быстро и без разработки. Отчасти так и происходит, но, во-первых, коробочные функции все равно требуют адаптации, во-вторых, система начинает диктовать то, каким должны быть процессы.
Концепция Ensi предлагает противоположный подход: предоставляет фреймворк для разработки функциональности на основе сформулированных бизнес-требований. То есть не система определяет реализацию, а наоборот процессы определяют то, какой должна быть система.
Лицензия
Затраты на первичное внедрение — существенная часть CapEx. Другой заметной частью таких затрат может быть стоимость лицензии. Но в некоторых случаях затраты на лицензию могут быть и частью постоянных затрат OpEx. Особенно, если она привязывает платформу к SaaS-инфраструктуре вендора и/или к объему продаж ритейлера. Кроме финансов, лицензия может влиять и на другие аспекты:
- Ограничивать распространение внедренной платформы на другие филиалы и представительства;
- Запрещать развертывание на определенной конфигурации серверов;
- Создавать риск блокировки из-за санкций.
Итого
- 1SAP Commerce CC и платные версии Magento (Adobe Commerce) требуют постоянных и заметных затрат на продление лицензии.
- 2Использование Битрикса так же требует ежегодных платежей, правда, значительно более низких даже в случае enterprise-лицензии. Однако, на рынке распространена практика непродления лицензии, что ведет только к потере возможности обновляться.
- 3Ensi и комьюнити-версия Magento распространяются бесплатно по open source лицензии.
API-изация
Покрытие функций платформы API позволяет быстро интегрировать ее с различными сервисами. Это позволяет как расширять функциональность за счет сторонних приложений, так и заменять части платформы другими сервисами. То есть, фактически, перейти от монолитной архитектуры к сервис-ориентированной и микросервисной.
Отдельно стоит отметить важность покрытия API для выделения в отдельное приложение фронтов. Витрины и административные интерфейсы — наиболее кастомизируемые и часто меняющиеся части IT-систем.
Отдельно стоит отметить важность покрытия API для выделения в отдельное приложение фронтов. Витрины и административные интерфейсы — наиболее кастомизируемые и часто меняющиеся части IT-систем.
Итого
Ensi использует API-first подход к разработке, а в SAP Commerce и Magento API реализовано как часть богатой функциональности. Битрикс долгое время не имел покрытие функций API, и разработчики каждый раз были вынуждены писать его с нуля. Но с какого-то момент модуль API, ранее появившийся в «Битрикс24», есть и в «Битрикс Управление сайтом».
Headless
Headless-приложения не имеют собственного человеческого интерфейса. Функциональность такого ПО доступно по API. Для того, чтобы пользователи могли работать с функциями headless-сервиса, нужно предварительно вывести их в какой-то интерфейс, то есть создать frontend-приложение.
Если платформа поддерживает headless-подход, значит все функции, нужные для работы публичного и административного интерфейса, покрыты API. В противном случае фронты являются неотъемлемой частью платформы.
Если платформа поддерживает headless-подход, значит все функции, нужные для работы публичного и административного интерфейса, покрыты API. В противном случае фронты являются неотъемлемой частью платформы.
Реализация Headless в Ensi в сравнении с другими платформами
Ensi — headless платформа. Составной частью системы является API Gateway и фронтовые фреймворки для быстрого создания административного интерфейса, рабочего места менеджера и клиентских витрин.
В Magento и SAP Commerce — административный интерфейс является частью монолита. Клиентские витрины — выделены в модули. Полное покрытие функциональности API позволяет создавать и собственные клиентские фронтовые приложения.
В Битриксе и административный, и клиентский фронт является частью монолита.
В Magento и SAP Commerce — административный интерфейс является частью монолита. Клиентские витрины — выделены в модули. Полное покрытие функциональности API позволяет создавать и собственные клиентские фронтовые приложения.
В Битриксе и административный, и клиентский фронт является частью монолита.
Безопасность
☞ Безопасность — это зона ответственности прежде всего команды внедрения. Причем не только в вопросах разработанной функциональности, но и в зоне программно-аппаратных средств, на которых работает внедренное решение, а также общей организации процессов внедрения.
Платформы могут придерживаться определенных подходов к безопасности, но то, насколько следуют им команды в каждом случае внедрения, больше зависит от самих команд и того, насколько вендор жестко регулирует процесс внедрения. Open source платформы могут внедряться как угодно, тогда как облачные enterprise-решения реализуются в строго определенных вендором рамках.
Подход к обновлениям
Как именно в платформе обновляется функциональность — один из часто задаваемых вопросов. Вероятно это связано с переносом ожиданий от обычных клиентских сервисов на бизнес-системы. Мы привыкли, что приложения в телефонах регулярно обновляются и обзаводятся новыми функциями, и ждем того же самого от ПО, автоматизириующего бизнес-процессы компаний.
Однако, ожидания от обновления платформ часто бывают завышенными и переоцененными. У зрелого ритейлера сначала идут требования, а затем их реализация в системах. Ожидать роста бизнеса за счет появления извне новой функции в той или иной системе вряд ли стоит. Кроме случаев, связанных с дырами в безопасности и техническими функциями, но не с новой бизнес-логикой.
Однако, ожидания от обновления платформ часто бывают завышенными и переоцененными. У зрелого ритейлера сначала идут требования, а затем их реализация в системах. Ожидать роста бизнеса за счет появления извне новой функции в той или иной системе вряд ли стоит. Кроме случаев, связанных с дырами в безопасности и техническими функциями, но не с новой бизнес-логикой.
Внедрение обновлений в Ensi в сравнении с другими платформами
Автоматические обновления в Ensi не предусмотрены. Решение о довнедрении функций, появившихся в новых релизах Ensi, принимает команда, ответственная за поддержку и развитие платформы каждого конкретного ритейлера.
В остальных платформах предусмотрены полуавтоматические обновления. В зависимости от того, как внедрен продукт, обновления могут пройти автоматически, либо с привлечением команды разработки для решения конфликтов.
В остальных платформах предусмотрены полуавтоматические обновления. В зависимости от того, как внедрен продукт, обновления могут пройти автоматически, либо с привлечением команды разработки для решения конфликтов.
Статус в России
Многие платформы, в том числе участники этого обзора, прекратили официальную деятельность в России. В зависимости от лицензии это может частично или полностью блокировать использование таких платформ в нашей стране.
Полностью безопасным с точки зрения лицензионных и санкционных рисков можно считать только Ensi, Битрикс, и отчасти комьюнити версию Magento. SAP Commerce и enterprise-продукцию Adobe официально приобрести в России нельзя, а уже внедренные решения находятся под угрозой блокировки, особенно SaaS-варианты.
Полностью безопасным с точки зрения лицензионных и санкционных рисков можно считать только Ensi, Битрикс, и отчасти комьюнити версию Magento. SAP Commerce и enterprise-продукцию Adobe официально приобрести в России нельзя, а уже внедренные решения находятся под угрозой блокировки, особенно SaaS-варианты.
26 сентября 2023
В статье использованы материалы Кусочков екома, Николая Воробьева
Автор статьи
- Сергей МелиховДиректор новых проектов
Мини-книга «Сравнение платформ электронной коммерции»
Нажимая на кнопку «Скачать», вы соглашаетесь с условиями обработки персональных данных.
подписывайтесь и будьте в курсе
Факты из жизни электронной коммерции
Новости от разработчиков платформы
Официальный новостной канал платформы
Блог в расширенном формате