IT-стратегия в электронной коммерции для FINN FLARE
О том, как Userstory нашла решение для развития комплекса IT-систем в электронной коммерции с оптимальным количеством интеграций и масштабируемой архитектурой для высокой нагрузки.
Клиент: FINN FLARE – международный бренд, который отражает скандинавские ценности отношения к жизни и к одежде. Компанияй с более чем 50-летней историей, которая началась с небольшой финской фабрики. Сегодня FINN FLARE представляет собой международную торговую марку уникальной повседневной одежды для мужчин и женщин.
Задача для Userstory: Найти решение для развития комплекса IT-систем в электронной коммерции с оптимальным количеством интеграций и масштабируемой архитектурой для высокой нагрузки.
Решение: Спроектировали новую архитектуру систем и их взаимодействия, которая будет успешно развиваться вместе с компанией и выдержит требуемую нагрузку.
Команда: 3 человека.
Срок реализации: 2 месяца.
Зачем FINN FLARE обратилась к Userstory?
- В связи с ростом компании FINN FLARE и расширением её IT-отдела появилась потребность в описании всего ecom-контура в разрезе серверов, сервисов и потоков данных, чтобы оценить текущее состояние архитектуры и спланировать её развитие.
- FINN FLARE столкнулась с проблемой скорости разработки и масштабирования монолитной системы при увеличении нагрузки.
- Интеграции смежных систем разрабатывались «исторически и по потребностям», без следования какой-либо выработанной архитектуре или принципам. Это приводило к увеличению сложности системы и росту трудозатрат на её развитие.
- Отсутствовала техническая документация.
👉 Существующий комплекс IT-систем и процессов разработки был ограничивающим фактором для развития бизнеса FINN FLARE.
Цель проекта и проектное решение
В соответствии с поставленными целями FINN FLARE мы предложили разработать IT-стратегию, провести обследование существующей IT-инфраструктуры с последующим документированием. Результатом стратегии является проект целевой архитектуры, который обеспечит развитие компании, а также решение для развития IT-направления с учетом планов FINN FLARE.
Ранее мы обращались к Userstory за услугой IT-обследования, но только части нашей структуры. Результатами обследования мы остались довольны, после чего решили запросить полное обследование всех наших систем. Нам также было необходимо получить текущее описание серверного контура, для передачи в поддержку.
Что такое IT-стратегия?
IT-стратегия — это набор принципов и план развития комплекса IT-систем и информационных технологий в целом, направленный на удовлетворение потребностей бизнеса и достижение поставленных целей по развитию используемого IT-комплекса.
Цель разработки IT-стратегии — приобретение преимущественной позиции Компании с использованием современных систем, технологий и практик, позволяющих эффективно решать задачи бизнеса и учитывающих цели и перспективы развития Компании.
IT-стратегия отвечает на вопросы: как развивать IT-системы дальше? Что нужно развивать в первую очередь, а что может подождать?
Как происходит разработка IT-стратегии?
- Вводная встреча с представителями бизнеса, чтобы понять тактические и стратегические планы на его развитие, выявить нарекания бизнеса к разработке, сформировать ожидания от IT-стратегии.
- Обследование текущих IT-систем. Сначала необходимо понять и задокументировать то, что сейчас есть. На этом этапе мы изучаем исходный код, архитектуру, интеграции и протоколы взаимодействия систем между собой.
- Обследование ИТ-инфраструктуры. Прежде чем формировать план развития, необходимо понять и задокументировать текущую ситуацию: какие технические инструменты используются для развития, как внедряются изменения, какие настройки серверов и отраслевые решения используются для разработки и внедрения изменений. На этапе анализа следует обратить внимание на репозиторий, CI/CD, контейнеризацию, prod-окружение, процесс работы с ветками, наличие stage-сервера и т.д.
- Обследование процессов разработки. Важно понимать процессы управления проектами. Часто случается, что именно процессы разработки становятся самым узким местом в развитии IT. На этом этапе мы изучаем, кто и как ставит задачи, какой таск-трекер используется, как контролируется выполнение задач, как происходит тестирование и приемка, и ведется ли документация.
- Серия интервью с техническими специалистами и менеджерами разработки, чтобы задать уточняющие вопросы.
- Серия интервью с представителями бизнеса, чтобы уточнить и дополнить тактические и стратегические планы на развитие бизнеса, выяснить процессы бизнеса и взаимодействия с разработкой.
- Проектирование целевой архитектуры комплекса ИТ-систем. Разработка документов, описывающих целевую архитектуру на разных уровнях.
- Формирование рекомендаций по улучшению процессов разработки, инструментов, систем и архитектуры. Рекомендации будут иметь приоритеты и обоснование их важности для бизнеса.
- Формирование дорожной карты перехода от текущего состояния «as is» к желаемому «to be» с ориентировочными сроками и трудозатратами.
- Презентация результатов работы заказчику.
Результат IT-стратегии
При создании IT-стратегии создаются несколько документов. Количество документов может отличаться в зависимости от ситуации, но обычно это:
- Текущая физическая схема серверов.
- Текущая компонентная схема сервисов, систем и их взаимодействия.
- Текущая логическая схема потоков данных между сервисами и компонентами.
- Целевая физическая схема серверов.
- Целевая компонентная схема сервисов, систем и их взаимодействия.
- Целевая логическая схема потоков данных между сервисами и компонентами.
- Роадмап перехода «as is» → «to be» с разбиением на этапы.
- Ориентировочные сроки и трудозатраты на каждый этап.
- Пояснительный документ с рекомендациями.
- Документ с описанием предлагаемой архитектуры.
IT-стратегия для FINN FLARE
В рамках стратегии было выполнено обследование существующих систем и интеграций, задокументировано текущее состояние систем в виде физической схемы серверов, компонентной схемы и схемы потоков данных.
Спроектировали целевое состояние системы
Мы обсудили с FINN FLARE их стратегию и планы развития в области электронной коммерции. Мы спроектировали новую IT-архитектуру – подобрали сторонние системы, разработали схемы и способы их взаимодействия, построили целевую схему компонентов и целевую диаграмму потоков данных.
Дорожная карта перехода к целевой системе
Мы зафиксировали в дорожной карте изменения в IT-системе и процессах разработки, которые не будут блокировать работу бизнеса из-за изменений в IT-архитектуре. Дорожную карту разбили на 4 этапа, для каждого из которых оценили сроки и трудозатраты. Отдельными этапами выделили внедрение PIM-системы и CRM.
Примеры предложенных архитектурных изменений
Предложили провести рефакторинг и объединить два приложения
При анализе системы было обнаружено, что для зон .ru и .kz реализовано два приложения, отличающихся не только оформлением заказов, но и механизмами взаимодействия с внешними системами. Несмотря на то, что большая часть функционала обоих приложений была общей, были также существенные отличия, которые приводили к необходимости двойной разработки и траты времени высококвалифицированных сотрудников.
Для устранения этой проблемы предложили провести рефакторинг и объединить оба приложения в одно, чтобы:
- Снизить количество дублирующегося кода, что позволит уменьшить время на разработку и обслуживание системы.
- Уменьшить нагрузку на высококвалифицированных сотрудников – они больше не будут тратить время на синхронизацию двух разных приложений и могут сосредоточиться на более важных задачах.
- Сократить время на внедрение, так как обновлять и тестировать нужно будет только одну систему.
Таким образом, в ситуации Finn Flare проведение рефакторинга и объединение двух приложений в одно позволят оптимизировать затраты на разработку и обслуживание системы, а также выделить больше времени на новые стратегические задачи по развитию продукта.
Определили системы, которые должны выполнять роль мастер-данных
Для управления большим объемом информации по товарам рекомендовали внедрить PIM-систему.
PIM (Product Information Management или Управление Продуктовой Информацией) — это приложение, которое позволяет управлять большими объемами данных о продуктах со сложными атрибутами и распределять информацию о товарах по разным каналам продаж (интернет-магазины, маркетплейсы, витрины).
Внедрение PIM-системы позволит Finn Flare:
- Уменьшить время, затрачиваемое на внесение изменений в информацию о продуктах, благодаря централизованному управлению мастер-данными;
- Ускорить выведение товаров на сток и оборачиваемость склада, благодаря ускорению процесса размещения продуктов по различным каналам продаж;
- Обеспечить единообразие и консистентность информации о продуктах на различных каналах продаж.
Рекомендовали выделить микросервисы
Микросервисная архитектура – это способ организации архитектуры на разных независимых сервисах. Каждый сервис имеет свою бизнес-логику и базу данных, выполняет обновление, тестирование, развертывание и масштабирование внутри себя.
Микросервисная архитектура обладает рядом преимуществ по сравнению с традиционными монолитными системами:
- Отказоустойчивость – при «падении» одного из сервисов, все остальные продолжают работать, и только часть системы становится недоступной для пользователей.
- Гибкость – можно развивать один сервис, не затрагивая другие. Кроме того, каждый сервис может быть написан на своем технологическом стеке, который лучше всего подходит для решения задачи.
- Простота – каждый сервис содержит относительно небольшой объем программного кода (по сравнению с монолитными системами). Как следствие, новые разработчики могут быстрее ознакомиться с логикой сервиса.
- Масштабируемость – при необходимости можно масштабировать отдельные сервисы, а не всю систему в целом.
- Уменьшение Time-To-Market – достигается за счет того, что сервисы являются небольшими и независимыми друг от друга.
Предложили внедрить подход Headless E-commerce в архитектуру
Headless eCommerce означает, что у нас есть серверная часть (backend), которая реализует все необходимые функции и всю бизнес-логику. А внешний вид (frontend) может быть любым, причем frontend'ов может быть несколько (сайт, мобильные приложения, чат-боты и другие). Все frontend'ы общаются с backend'ом через один и тот же набор API.
Преимуществами Headless eCommerce являются:
- Скорость работы сайта значительно выше благодаря тому, что браузер и сервер обмениваются только данными, а не способом их отображения.
- Снижается нагрузка на сервер за счет того, что формирование HTML происходит на стороне клиента (в SPA-приложении), а не на сервере.
- Создание интерактивных и отзывчивых интерфейсов значительно упрощается.
- Разработка backend и frontend может вестись параллельно и независимо друг от друга, что ускоряет процесс разработки.
- Кэширование данных на backend становится более простым, что приводит к увеличению скорости.
Данный подход расширяет возможности для персонализации внешнего вида и содержания каждого frontend'a, что позволяет более эффективно проводить маркетинговые кампании. Он также увеличивает возможности для организации омниканальной электронной коммерции и позволяет компаниям быстрее адаптироваться к новым рыночным трендам и изменениям в поведении потребителей.
Фасадирование API
Фасадирование API – это механизм, при котором внедряется помежуточное звено (API-шлюз) между клиентом и сервисом.
Фасадирование скрывает внутреннюю реализацию системы от клиентов. Отсутствие API-шлюза может вызывать следующие проблемы:
- Взаимозависимость. Без API-шлюза клиентские приложения тесно связаны с внутренними сервисами. Клиенту нужно знать, как обрабатываются в сервисах разные функции приложения. По мере развития и рефакторинга сервисов все действия с ними воздействуют на обслуживание, так как приводят к критическим изменениям клиентских приложений, которые обращаются напрямую к сервисам. Частое обновление клиентских приложений усложняет процесс развития решения.
- Большое количество запросов. Для одной страницы (экрана) в клиентском приложении может потребоваться несколько вызовов к разным сервисам. Это приводит к созданию нескольких круговых путей по сети между клиентом и сервером, что значительно увеличивает задержку. Объединения ответов на промежуточном уровне позволяют повысить производительность и улучшить взаимодействие с пользователем для клиентского приложения.
- Проблемы безопасности. Без шлюза все сервисы будут доступны извне, что значительно увеличивает уязвимую зон. Чем меньше уязвимая зона, тем надежнее будет приложение.
- Проблемы сквозной функциональности. Каждый общедоступный сервис должен самостоятельно обрабатывать такие задачи, как авторизация и шифрование SSL. Во многих случаях эти задачи можно вынести на общий уровень, что позволяет упростить внутренние сервисы.
- Усложняет логику клиента. Каждый сервис может быть реализован на своем технологическом стеке и предоставлять API в своем протоколе (REST, SOAP, GraphQL и т.д.). Клиенту необходимо будет знать не только о самом сервисе, но и реализовать протокол взаимодействия для каждого сервиса. API-шлюз позволяет универсализировать и создать единое API для всех клиентов, независимо от особенностей протокола и формата данных каждого из сервисов.
Данный подход расширит возможности для развития бэкенда и фронтенда не зависимо друг от друга, что позволит ускорить разработку и внедрение новой функциональности. Он также увеличит возможности для организации омниканальной электронной коммерции для FINN FLARE.
Результат для FINN FLARE
- Целевая архитектура и процессы, предложенные Userstory, позволят обеспечить развитие IT-архитектуры, повысить ее отказоустойчивость и обеспечить дальнейший рост онлайн-продаж компании FINN FLARE.
- Описанный нами IT-контур в разрезе серверов, компонентов и потоков данных позволил организовать мониторинг и обеспечение работоспособности системы 24/7.
- Внедрение предложенных изменений по процессам разработки и практикам DevOps позволит сократить time-to-market и повысить качество разработки. IT-система перестанет являться сдерживающим фактором развития бизнеса.
Отзыв о работе с Userstory
Мы остались довольны работой с Userstory. Все работы были выполнены в оговоренные сроки. Мы получили тот результат, который обговаривали заранее, поэтому все ожидания оправдались.