Платформа для работы в условиях неопределенности

Региональная экспансия, изменения в поведении потребителей и глобальные вызовы, подобные локдауну, оказывают сильное воздействие на бизнес компаний розничной торговли, включая и предприятия сегмента «Сделай сам» (Do It Yourself, DIY), в котором работает компания «Леруа Мерлен». В ситуации, когда за один день могут закрыться три четверти магазинов от Владивостока до Калининграда, сложно говорить о долгосрочном планировании. Работа в условиях неопределенности в обществе, на потребительском рынке и в сфере регулирования предпринимательской деятельности требует новых подходов и инструментов, позволяющих оперативно и эффективно решать бизнес-задачи.

Рис. 1. Бизнес-модель «Платформа и экосистема»

Некоторое время назад в компании «Леруа Мерлен» было принято решение об отказе от бизнес-модели классического ретейлера — развития сети физических магазинов и широкого, но все же ограниченного торговой площадью ассортимента. Компания инициировала движение сначала в сторону омниканальности, а затем и к бизнес-модели «Платформа и экосистема» (рис. 1), исключающей барьеры между компанией и ее партнерами за счет создания единой экосистемы вокруг «бесшовного клиентского пути». В рамках этой модели посетителю магазина в одной точке должно быть доступно все необходимое для строительства и обустройства дома — от услуг планирования и расчетов до закупки материалов и выполнения работ.

Для реализации такой бизнес-модели была инициирована серия проектов: маркетплейс с расширенным товарным предложением, не ограниченным полкой в физическом магазине; предоставление услуг по установке оборудования и ремонту; расширение сотрудничества с B2B-клиентами; предоставление услуг по проектированию жилых помещений и инженерных систем и пр. Продукты были объединены в одну экосистему, а их оркестрация осуществляется в соответствии с принципом бесшовного пути клиента магазина.

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

Все это стимулировало проведение кардинальных изменений в организационной структуре компании. Существовавшее ранее обособленное ИТ-подразделение было реорганизовано: его сотрудников распределили по продуктовым командам, объединенным с операционными командами, которые отвечают за определенные части клиентского пути (омниканальные продажи, платежи и другие) или стратегические процессы компании. Команды автономно работают над своими целями, имеют свой план действий и руководствуются собственными метриками оценки эффективности работы. В состав каждой команды входят специалисты по бизнес-процессам и ИТ, что, с одной стороны, исключает посредников между постановщиками операционной задачи и разработчиками решения, а с другой — погружает ИТ-специалистов в специфику ведения бизнеса, благодаря чему контекст работы становится прозрачен и понятен всем членам команды.

Для поддержки продуктовых команд, ускорения и улучшения ИТ-процессов были созданы три базисных департамента:

— департамент ИТ-платформы (инфраструктура, облако, контейнеры, мониторинг, CI/CD);
— департамент платформы данных (корпоративное озеро данных и аналитика);
— департамент интеграции и поддержки микросервисного ландшафта.

Все предоставляемые департаментами сервисы доступны продуктовым командам в режиме самообслуживания либо по запросу.

Переход к бизнес-модели «Платформа и экосистема» подразумевает, что покупателю доступны как товары, так и услуги, которые он заказывает и приобретает любым удобным для него способом. По сути, речь идет о переходе от разовых контактов клиента с магазином для покупки отдельных материалов к его непрерывному сопровождению на всех этапах ремонта или строительства. С точки зрения ИТ-систем это означает запуск множества сервисов, оркестрацию процессов, построение композитных сервисов и большой объем работ по интеграции с различными внутренними сущностями: мастер-данными, микросервисами, системами оркестрации бизнес-процессов, а также с окружающей компанию экосистемой. При этом у бизнеса имеются определенные требования к скорости изменений бизнес-процессов и систем, расходам и качеству внутренних продуктов, выражаемых через метрики (время вывода продукта на рынок; надежность, доступность и простота сервисов; совокупная стоимость внесения изменений в бизнес-процессы; прозрачность и прогнозируемость). 

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

Рис. 2. Грануляризация сервисов, переход от IaaS к FaaS

Современная ИТ-инфраструктура «Леруа Мерлен» основана на грануляризации сервисов (рис. 2), предполагающей смену акцентов от виртуализации к контейнеризации и FaaS (Function as a Service) [1]. Виртуализация остается, но появляется новый уровень абстракции, доступный командам. Сервисы становятся более специализированными, и появляется возможность независимо проводить изменения, масштабируя их разработку и развитие. Однако грануляризация усложняет управление и оркестрацию множества различных сервисов. Кроме того, поскольку невозможно сразу перейти к микросервисному ландшафту, неизбежно, на протяжении некоторого времени, параллельное существование унаследованных монолитных приложений.

На уровне глобальной группы компаний ADEO, в которую входит сеть «Леруа Мерлен», были сформулированы основные принципы архитектуры поддержки бизнес-модели «Платформа и экосистема»:

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

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

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

Рис. 3. Трехслойная модель API

Все API разделены на три слоя (рис. 3), что в конечном счете определяет топологию всех сервисов.

• Слой объектных интерфейсов (Object API) — набор небольших, линейно независимых функций доступа к данным. На этом слое находятся репозитории CRUD (create, read, update, delete) мастер-данных, унаследованные приложения, лицензионное коммерческое коробочное ПО и части глобальных ИТ-продуктов группы ADEO.
• Слой бизнес-процессов и оркестрации (Process API) — функционал единых бизнес-правил компании.
• Слой адаптации (Experience API) — средства адаптации к конкретным прикладным задачам: сервисы класса Back-End-for-Front-End; ПО для мобильных и десктоп-приложений; функционал композитных сервисов (mash-up); средства интеграции с партнерами, клиентами и окружающей компанию экосистемой; бизнес-логика приложений, специфичных для конкретных видов бизнеса.

К разным уровням применяются разные требования и процессы контроля. Например, за ПО мобильного приложения для клиентов из слоя Experience API отвечает команда мобильного приложения, в то время как к приложениям учета запасов товара на складе слоя Object API предъявляются достаточно высокие требования к качеству и предусмотрен жесткий контроль со стороны корпоративных архитекторов.

Таким образом, в компании появился набор линейно независимых сервисов, доступных из единого каталога, на базе которых команды сами могут строить свои процессы, используя облачные технологии, инструменты медиации (работа с ПО разного уровня, «прослойками») и управления API, в полной мере применяя подход low-code, ускоряющий путь от формулировки бизнес-задачи до готового решения. Не требуется ждать, пока разработчик реализует соответствующий сервис, — бизнес-пользователь может самостоятельно создавать требуемое приложение.

Для управления интеграцией используется инструментарий API Management для работы с распределенными интерфейсами. В «Леруа Мерлен» имеется свой единый хаб, позволяющий интегрировать различные медиаторы (посредники — шаблоны для обеспечения взаимодействия объектов, избавляющие их от необходимости явно ссылаться друг на друга): шлюзы, сервисную сеть (Service mesh, уровень поддержки межсетевого взаимодействия сервисов) и брокеры сообщений (рис. 4).

Рис. 4. API Management

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

В ИТ-ландшафте «Леруа Мерлен» не предполагается имплементация какой-либо логики в интеграционных медиаторах: вся логика строится самими командами, а остатки унаследованной корпоративной шины данных плавно выводятся из эксплуатации. Все публикации и подписки на интеграционные потоки выполняются командами самостоятельно.

На портале публикуются не только интерфейсы на базе HTTP-протоколов, но также gRPC, топики (классификаторы событий брокера Kafka) и очереди на брокерах сообщений.

Архитектура портала дает возможность одновременно использовать различные медиаторы: Istio, API Gateway, Kafkа, RabbitMQ и брокеры NATS. Для оркестрации, разработки API и микросервисов используется подход low-code (рис. 5). 

Большой объем бизнес-задач в «Леруа Мерлен» до недавнего времени не удавалось оперативно решать в рамках имеющихся ресурсов, поэтому возникла необходимость в поиске новых подходов. Однако ни одно из доступных на рынке интеграционных решений (Mule, Software AG, WSO2 и пр.) не позволяло в полном объеме решать все задачи компании, поэтому было принято решение создать свою корпоративную облачную платформу Platformeco, доступную продуктовым командам в режиме PaaS и позволяющую разрабатывать микросервисы, формировать интеграционные потоки и API в графическом интерфейсе, а затем разворачивать их в облаке, получая функциональность непрерывной интеграции и непрерывной доставки (CI/CD), автомасштабирования, транспорта между средами, мониторинга и пр.

Рис. 5. Platformeco: имплементация low-code

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

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

В целом для платформы было разработано более 120 единиц потоков бизнес-логики и API — сегодня Platformeco ежедневно обеспечивает выполнение более 5 млн операций; с ней работают более 30 тыс. пользователей из более сотни магазинов торговой сети. Время запуска нового функционала и внесения изменения сократилось более чем в 15 раз по сравнению с предыдущими подходами, и более чем в 20 раз уменьшилось время на локализацию инцидентов за счет встроенного сквозного мониторинга. В конечном счете втрое сократилось время вывода на рынок новых бизнес-проектов. Кроме того, за счет стандартизации существенно упростилось проведение организационных изменений: передача функций между командами, перераспределение сотрудников по командам, подрядчикам и т. д. 

Полный инструментарий Platformeco используется более чем 30 продуктовыми командами «Леруа Мерлен». Сегодня платформа обрабатывает более 8 млрд бизнес-транзакций в месяц.

***

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

Литература

1. Симон Айсманн, Максимилиан Швингер, Йоханнес Громанн, Николас Хербст, Джоэл Шойнер, Эрвин Ван Эйк, Александру Йосуп, Кристина Абад. Бессерверные приложения: почему, когда, как? // Открытые системы.СУБД. — 2021. — № 1. — С. 14–16. URL: www.osp.ru/os/2021/01/13055828 (дата обращения: 21.04.2021).

Александр Бондарик (Aleksandr.Bondarik@leroymerlin.ru) — руководитель интеграционной платформы, LM Tech, компания «Леруа Мерлен» (Москва).