FINN FLARE

IT-стратегия в электронной коммерции для интернет-магазина одежды

Цель бизнеса

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

Работаем с клиентом

2022 г. — по настоящее время.

О проекте

Команда

3 человека.

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

1,4 млн

150

посетителей на сайте в месяц

магазинов по России и СНГ

108 тысяч

товарных SKU

В связи с ростом компании FINN FLARE и расширением её IT-отдела появилась потребность в описании всего ecom-контура в разрезе серверов, сервисов и потоков данных, чтобы оценить текущее состояние архитектуры и спланировать её развитие.

Зачем FINN FLARE обратилась к Userstory?

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

FINN FLARE столкнулась с проблемой скорости разработки и масштабирования монолитной системы при увеличении нагрузки.

Отсутствовала техническая документация.

Существующий комплекс IT-систем и процессов разработки был ограничивающим фактором для развития бизнеса FINN FLARE.

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

Цель проекта и проектное решение

Вячеслав Смирнов

Технический директор по электронной коммерции, FINN FLARE

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

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

Что такое IT-стратегия?

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

IT-стратегия отвечает на вопросы: как развивать IT-системы дальше? Что нужно развивать в первую очередь, а что может подождать?

Результат IT-стратегии

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

IT-стратегия для FINN FLARE

Мы обсудили с FINN FLARE их стратегию и планы развития в области электронной коммерции. Мы спроектировали новую IT-архитектуру — подобрали сторонние системы, разработали схемы и способы их взаимодействия, построили целевую схему компонентов и целевую диаграмму потоков данных.

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

Мы зафиксировали в дорожной карте изменения в IT-системе и процессах разработки, которые не будут блокировать работу бизнеса из-за изменений в IT-архитектуре. Дорожную карту разбили на 4 этапа, для каждого из которых оценили сроки и трудозатраты. Отдельными этапами выделили внедрение PIM-системы и CRM.

Дорожная карта перехода к целевой системе

Примеры предложенных архитектурных изменений

Предложили провести рефакторинг
и объединить два приложения

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

Для устранения этой проблемы предложили провести рефакторинг и объединить оба приложения в одно, чтобы:

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

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

Сократить время на внедрение, так как обновлять и тестировать нужно будет только одну систему.

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

Определили системы, которые должны выполнять роль мастер-данных

Для управления большим объемом информации по товарам рекомендовали внедрить PIM-систему.

Внедрение PIM-системы позволит Finn Flare:

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

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

Обеспечить единообразие и консистентность информации о продуктах на различных каналах продаж.

PIM (Product Information Management или Управление Продуктовой Информацией) — это приложение, которое позволяет управлять большими объемами данных о продуктах со сложными атрибутами и распределять информацию о товарах по разным каналам продаж (интернет-магазины, маркетплейсы, витрины).

Рекомендовали выделить микросервисы

Микросервисная архитектура — это способ организации архитектуры на разных независимых сервисах. Каждый сервис имеет свою бизнес-логику и базу данных, выполняет обновление, тестирование, развертывание и масштабирование внутри себя.

Микросервисная архитектура обладает рядом преимуществ по сравнению с традиционными монолитными системами:

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

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

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

Масштабируемость — при необходимости можно масштабировать отдельные сервисы, а не всю систему в целом.

Уменьшение Time-To-Market — достигается за счет того, что сервисы являются небольшими и независимыми друг от друга.

Предложили внедрить подход Headless E-commerce в архитектуру

Headless eCommerce означает, что у нас есть серверная часть (backend), которая реализует все необходимые функции и всю бизнес-логику. А внешний вид (frontend) может быть любым, причем frontend’ов может быть несколько (сайт, мобильные приложения, чат-боты и другие). Все frontend’ы общаются с backend’ом через один и тот же набор API.

Преимуществами Headless eCommerce являются:

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

Снижается нагрузка на сервер за счет того, что формирование HTML происходит на стороне клиента (в SPA-приложении), а не на сервере.

Создание интерактивных и отзывчивых интерфейсов значительно упрощается.

Данный подход расширяет возможности для персонализации внешнего вида и содержания каждого frontend’a, что позволяет более эффективно проводить маркетинговые кампании. Он также увеличивает возможности для организации омниканальной электронной коммерции и позволяет компаниям быстрее адаптироваться к новым рыночным трендам и изменениям в поведении потребителей.

Разработка backend и frontend может вестись параллельно и независимо друг от друга, что ускоряет процесс разработки.

Кэширование данных на backend становится более простым, что приводит к увеличению скорости.

Фасадирование API

Фасадирование API — это механизм, при котором внедряется помежуточное звено (API-шлюз) между клиентом и сервисом.

Фасадирование скрывает внутреннюю реализацию системы от клиентов. Отсутствие API-шлюза может вызывать следующие проблемы:

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

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

Проблемы безопасности. Без шлюза все сервисы будут доступны извне, что значительно увеличивает уязвимую зон. Чем меньше уязвимая зона, тем надежнее будет приложение.

Данный подход расширяет возможности для персонализации внешнего вида и содержания каждого frontend’a, что позволяет более эффективно проводить маркетинговые кампании. Он также увеличивает возможности для организации омниканальной электронной коммерции и позволяет компаниям быстрее адаптироваться к новым рыночным трендам и изменениям в поведении потребителей.

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

Усложняет логику клиента. Каждый сервис может быть реализован на своем технологическом стеке и предоставлять API в своем протоколе (REST, SOAP, GraphQL и т. д.). Клиенту необходимо будет знать не только о самом сервисе, но и реализовать протокол взаимодействия для каждого сервиса. API-шлюз позволяет универсализировать и создать единое API для всех клиентов, независимо от особенностей протокола и формата данных каждого из сервисов.

Целевая архитектура и процессы, предложенные Userstory, позволят обеспечить развитие IT-архитектуры, повысить ее отказоустойчивость
и обеспечить дальнейший рост
онлайн-продаж компании Finn Flare.

Результаты для FINN FLARE

Описанный нами IT-контур в разрезе серверов, компонентов и потоков данных позволил организовать мониторинг и обеспечение работоспособности системы 24/7.

Внедрение предложенных изменений по процессам разработки и практикам DevOps позволит сократить time-to-market и повысить качество разработки. IT-система перестанет являться сдерживающим фактором развития бизнеса.

Отчет

Отчет на 18 страниц с 6 приложениями:

Сергей Макаров

Директор по маркетингу

«Мы пришли к Userstory за услугой IT-обследование с пониманием, что некоторые наши процессы работают неправильно. И речь шла не только о кодинге, но и о постановке задач, тестировании и других процессах разработки. Нам нужно было, чтобы кто-то с помощью специальной методологии все проверил. Благодаря IT-обследованию мы поняли, в каком направлении двигаться, какие процессы нужно улучшать, а что менять. Оказалось, что IT-аудит крайне полезен, а на основании отчета можно сделать много выводов.

Отзыв о работе с компанией Userstory

Мы остались довольны работой с компанией Userstory. Все работы были выполнены в оговоренные сроки. Мы получили тот результаты, который обговаривали заранее, поэтому все ожидания оправдались».