Смена архитектуры: технологическая и организационная сторона

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

Так было у нас в Самокате.

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

Но бизнес не стоял на месте: сейчас с помощью Самоката, кроме продуктов, можно заказать косметику, лекарства и впереди ещё много всего интересного. Для продуктов есть не только сценарий “хочу этот айтем, заказываю его скорее”, но становится всё больше “заходил сюда без мысли об этом айтеме, но теперь вижу, что он мне нужен”.

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

И тут мы натолкнулись на ограничения архитектуры с монолитом центральной витрины приложения.

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