Полтора года работы с SAP hybris: полет нормальный. Самое важное, что вам надо знать о разработке на eCommerce-платформах

Так получилось, что последние полтора года я плотно работаю с SAP hybris ^[1]. В России к ecommerce-платформам наблюдается большой интерес, поэтому я решил данной статьей на основе своего опыта рассказать просто и доступно об этой теме.

Самое важное о eСommerce-платформах

Фундамент. Для создания любого сложного ПО нужно подготовить «фундамент», который впоследствии сделает разработку управляемой, а всю систему обозримой и понятной для архитектора. Этот фундамент представляет собой «многослойный пирог» из универсальных, стандартных и хорошо зарекомендовавших себя технологий и продуктов. Правильный выбор этого набора во многом определяет развитие системы на ближайшие годы. Примеры составляющих такого «пирога» — ORM ^[2], CMS ^[3], PCM ^[4], Search Engine, из конкретных технологий — Hadoop ^[5], Apache ServiceMix ^[6], NodeJS ^[7] и другие. Набор этих технологий зачастую определяется опытом команды разработчиков, а не только и не столько потребностями бизнеса, поэтому часто можно встретить системы на Scala ^[8], Erlang ^[9] или Haskell ^[10]. В eCommerce-платформах нередко встречается такой зоопарк технологий — Java, C++, Perl, C#. Так выходит, когда вендор приобретает различные компоненты у третьих компаний или сами компании целиком. Нам с платформой повезло — там только Java.

Таким образом, eCommerce-платформа представляет собой органичный, подготовленный, настроенный, отлаженный, упакованный и документированный набор таких технологий. Под многие типичные задачи в e-commerce вендором разработаны готовые блоки, которые требуют лишь небольшой «подгонки» под задачу, а некоторые реализованы на абстрактном уровне и требуют «допиливания напильником». Чем органичнее переплетены между собой технологии, чем продуманнее архитектура, тем легче будет расширять ее под свои задачи все ближайшие годы.

Напишем все сами? Конечно, можно разработать магазин и без промышленной платформы, собрав «пирог» самому. Вопрос в том, сколько это займет времени и удастся ли сохранить через год-два хорошую архитектуру, масштабируемость, производительность, безопасность, расширяемость, надежность, документированность. Хороший и редкий пример, когда это удалось для крупного e-commerce — Amazon.com ^[11]. Опыт говорит о том, что при сегодняшних требованиях к качеству, безопасности, функциональности и темпам развития писать все «с нуля» в итоге выходит очень дорого, долго и рискованно.

Нужна ли вам eCommerce-платформа? Владельцам интернет-магазинов перед принятием решения о платформе стоит подумать о том, где им видится их бизнес через лет пять. Если в этом будущем есть слова «мультирегиональность», «мультиязычность», «мультивалютность», «огромный ассортимент», «большой траффик», «персонализация», «сотни складов», «сотни сотрудников в процессе», то уже сегодня нужно искать платформу, поддерживающую все перечисленное.

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

Сроки. Невозможно назвать даже среднее время, но можно назвать минимальное по собственному опыту. У нашей команды есть успешный опыт, когда система выведена в продакшн через 3 месяца после подписания контракта. Первый релиз в «продакшн» был через два месяца после начала работ — каталог без возможности заказа товара. Команда на таком проекте насчитывала шесть человек, включая меня. Есть и другие примеры, где команда и сроки больше.

Для e-commerce срок проекта очень важен. Если есть возможность увеличить команду, сократив сроки — это надо делать (как рассказывал ^[12] Ф.Брукс, так не всегда). Пока мы разрабатываем новый сайт, развитие существующего заказчик останавливать никогда не будет. Поэтому каждый дополнительный месяц создает огромные риски того, что проект так и не будет запущен.

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

Как выбирать ecommerce-платформу?

Чтобы не ошибиться с выбором eCommerce-платформы, стоит обратить внимание на

• западные успешные проекты. Почему на западные? Потому что они существуют дольше российских, и они давно прошли тот путь, по которому идет сегодня российский e-commerce.
• число внедрений в России за 2-3 последних года. Многие платформы в мире получили высокий рейтинг потому, что они разработаны очень давно, и собрали за историю своего существования много внедрений. Другие появились недавно. Богатая история может быть признаком как хорошего накопленного опыта, так и большого объема кода «из девяностых». Почему в России? eCommerce в России сильно отличается от западного.
• «открытость» и доступность составляющих «пирог» технологий. Плохо, когда у заказчика нет других альтернатив, чем обратиться к вендору или партнеру за поддержкой запущенного сайта. Хорошо, когда есть быть выбор — собрать и обучить свою команду или работать с опытным партнером.
• число компаний и специалистов на рынке. Оценить потенциал, сколько их будет с учетом существующего темпа развития через год или два.
• частоту выпуска версий вендором. Если платформа обновляется всего раз в год или реже, стоит задуматься, каков у нее приоритет среди прочих продуктов вендора.
• стандартные механизмы интеграции. Если платформа имеет API, это очень облегчает работу по интеграции.
• сложность и стоимость масштабирования. Увеличьте все свои цифры по траффику и объему SKU раз в сто и оцените, сколько будут стоить лицензии, сколько нужно будет серверов, и справится ли платформа с этим вообще. Будьте уверены, ну не в сто, но в десять раз ваш бизнес должен вырасти по этим показателям лет через пять. Если нет таких амбиций, вам вряд ли нужна платформа)
• качество документации. Важно, чтобы документация включала как блок для бизнес-пользователей, так и для программистов, отражала разницу в версиях, была актуальной, полной, доступной и хорошо структурированной.
• рейтинги Gartner ^[13] и Forrester ^[14]. Эти компании являются признанными лидерами, мнению которых на рынке доверяют.

Я бы не советовал обращать много внимания на:

• Готовые модули. eCommerce в России настолько разный и настолько динамичный, что готовые модули больше головная боль, чем благо. Лучше искать готовые «фреймворки» под задачу + документированные прототипы решения конкретных задач на них. Например, модуль интеграции с платежными системами «в общем» с примером для одной ПС лучше, чем набор разрозненных модулей интеграции с какими-нибудь конкретными платежными системами.
• Готовые дизайн-шаблоны. Внешний вид в крупном e-commerce никогда не является расширением демо-магазинов, он всегда заменяется новым, специфичным под клиента. Брать за основу стандартные визуальные шаблоны всегда сложнее, неправильнее, да и дольше, чем создавать их заново под конкретный дизайн и конкретные функциональные требования. Но такой подход требует большего опыта, чем доработка готовых шаблонов.

Быстрый старт?

С одной стороны, использование платформы позволяет запустить магазин за считанные месяцы. C другой стороны, ни одна e-commerce-платформа не представляет собой готовый шаблон магазина, который сегодня купили, галочки в «админке» покликали и — запустили. То есть, технически это можно, конечно… Но в 100% случаев нужно допрограммирование под особенности — как внутренние информационные системы клиента, его процессы, нашего рынка, нашего пользовательского опыта, автоматизацию миграции данных и т.д.

Что представляет собой проект на ecommerce-платформе?

eCommerce-система включает в себя взаимодействие с покупателем по разным каналам — от колл-центра и веб-витрины до мобильного приложения и киосков.

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

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

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

Прочие каналы взаимодействия с клиентом. Мобильное приложение поставляется в виде рабочего прототипа и набора API. Версия для киосков и версия для мобильных устройств представляют собой дополнительные версии веб-витрины, использующие почти тот же функционал и те же данные, что и основной веб-сайт, но в другой «обертке».

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

Архитектура

Каждая из вышеперечисленных тем имеет в платформе «заготовку» разной степени проработанности, это может быть готовый к подключению модуль, а может быть «полуфабрикат». У готовых модулей есть минус в том, что их не всегда можно легко изменить под специфичные требования, да и изучать их сложнее — неясность и непрозрачность логики требует большего времени на изучение и прототипирование. У «полуфабрикатов» этой проблемы нет, но они требуют большего времени на настройку и доработку. Зато у них есть плюс в том, что система получается стройнее, безопаснее и надежнее за счет более цельной и масштабируемой архитектуры.

На основе одного «полуфабриката» можно сделать сотни различных вариантов реализации функционала, и только один из них может быть реализован в демо-магазине, который презентуют клиентам на первых встречах. Именно поэтому нельзя называть увиденное в демо-магазине «best practice», так как это всего лишь одна из возможных реализаций очень гибкого механизма.

Профессионализм архитектора eCommerce-системы заключается в том числе и в понимании этой гибкости, ограничений и возможностей. Мы почти никогда не говорим клиентам «нет, это сделать нельзя», потому что на современных ecommerce-системах можно сделать абсолютно всё той или иной ценой.

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

Крупные платформы изначально спроектированы на большие объемы данных, на сложные бизнес-процессы, на высокую посещаемость, производительность и доступность. Например, кластеризация и кэширование в них выполнены на промышленном уровне.

Основные принципы разработки

Платформа имеет тысячи мест, куда можно «вклиниться» программисту со своей логикой, переопределить или расширить стандартное поведение системы. Разработка интернет-магазина представляет собой проектирование, разработку и тестирование таких модулей отдельно и в составе платформы. Как видно, тут есть два граничных варианта — заменить всю бизнес-логику на свою или использовать поставляемую в дистрибутиве.
В разработке используются известные технологии типа JSP/Spring/Java, что упрощает подключение к проекту программистов без опыта с конкретной eCommerce-платформой.

Поиск

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

Можно написать поиск самим «с нуля». Так делает подавляющее большинство интернет-магазинов с маленьким ассортиментом и траффиком. Но с ростом товарной базы и траффика поиск работает медленнее, интернет-магазин теряет покупателей, и, начиная с какого-то момента, становится ясно, что нужно полностью переписывать механизм на более сложный или подключать внешний «поисковый движок» (search engine).

Упрощенно, «поисковый движок» — это специализированная база данных, которая укладывает информацию о товарах и страницах так, что ее потом можно вынимать быстро и часто, используя при надобности довольно сложные запросы. Эта возможность позволяет применять «поисковые движки» не только для поиска по ключевым словам, но и для поиска, например, по характеристикам товаров или для отображения списка товаров выбранной рубрики. Поиск с постепенным уточнением запроса через удобный интерфейс покупателя — must have для любого крупного магазина. Для «неплатформенных» магазинов эта функциональность — одно из самых узких мест с точки зрения производительности и гибкости.

Среди «поисковых движков» в области e-commerce пользуются уважением Apache SOLR, ElasticSearch, Endeca, Sphinx. Подключение к интернет-магазину поискового движка может быть достаточно трудоемкой процедурой, если все делать как следует. В e-commerce-платформах обычно этот вопрос решен с одним из продуктов в версии «из коробки».
Например, во всех наших проектах используется Apache SOLR, и все листинги товаров также построены на запросах к нему. Такой подход позволяет иметь громадный запас по производительности.

Управление товарами

Каталог товаров — основное, с чего начинается интернет-магазин. Данные о товарах могут быть использованы, например, на ценниках в магазине или в печатном каталоге. Хорошей практикой является хранение т.н. «обогащенных данных о товарах» — изображений, технических характеристик (в т.ч. динамических), приложенных файлов — в отдельной системе, специализированной базе знаний по товарам. Такие системы могут являться отдельным продуктом, а могут поставляться в составе платформ.

Общеупотребительное название для таких систем — PIM (Product Information management) или PCM (Product Content Management).

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

В типичный проект по разработке интернет-магазина на eCommerce-платформе входит настройка и внедрение PIM/PCM, а также интеграция с внутренними учетными системами. Обычно разработка каталога — это первое, с чего начинается проект.

Например, в интернет-магазине РИВ ГОШ ^[15] часть товаров имеет единицу измерения «граммы», есть варианты по цвету и объему, товар может быть привязан к нескольким рубрикам из различных иерархий рубрик, часть из которых не являются навигационными. Товары могут быть сложно связаны друг с другом, а часть информации может подгружаться из различных источников автоматически.

Система управления контентом

За компоновку и отображение страниц отвечает система управления контентом. Это тоже обязательный компонент любой eCommerce-платформы, так как, как уже говорилось выше, интернет-магазин — это еще и просто большой сайт. Такие задачи, как размещение баннеров, добавление пункта меню, добавление страницы с информацией, персонализация отображения отдельных блоков и многие другие выполняются в CMS.

В eCommerce-платформу уже входят многие готовые компоненты («виджеты»), которые очень вероятно пригодятся в любом магазине, такие как «корзина», «листинг товаров», «карточка товара» и другие. Также с помощью CMS управляют и триггерными рассылками, и страницами мобильной версии.

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

В типичный проект по разработке интернет-магазина на eCommerce-платформе входит разработка, переработка или настройка перечисленных выше компонентов-виджетов.

Например, в проекте 1Платформа для компании Технониколь CMS выдает разные шаблоны страниц и компонентов-виджетов для мобильной версии / версии для десктопа, при этом функциональность страниц и компонентов идентична.

Фулфилмент и бизнес-процессы, связанные с заказом

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

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

В типичный проект по разработке интернет-магазина на eCommerce-платформе входит проектирование или изучение бизнес-процессов, настройка логики обработки заказа, интеграция с WMS, с платежными шлюзами, выгрузка заказа в ERP или внешнюю систему управления заказами.

Автор: raliev

Источник ^[16]