Развитие платформы управления жизненным циклом автомобилей
Задача
О проекте
Полгода наша команда работала на платформе Solera Audatex. Это система управления жизненным циклом автомобилей, которую используют страховые компании и автосервисы в десятках стран. Расскажем, как устроена разработка в конфигурируемой архитектуре enterprise-масштаба, во что она обходится и какие решения экономят бюджет заказчика.
Клиент и задача
Solera - международный разработчик программного обеспечения для автомобильной и страховой отрасли. Платформа Audatex ведёт автомобиль по всему жизненному циклу: страховой случай, оценка ущерба, ремонт, заказ запчастей, выплата.
Платформа работает в десятках стран. У каждой страны своё законодательство и свой процесс урегулирования убытков, поэтому система построена как мультитенантный монолит. Тенант - это изолированная конфигурация платформы для конкретной страны или заказчика. Для каждой страны собирается отдельная версия ПО, и её курирует отдельная команда.
Solera пригласила нас по модели аутстаффинга: наши разработчики вошли в распределённые команды вместе с лидами и product owner со стороны клиента и инженерами других подрядчиков. Задача: развивать и поддерживать действующую систему: настраивать тенанты, чинить баги, добавлять функции.
Как устроена система
Работает это так. Почти у каждого элемента интерфейса (кнопки, поля, этапа процесса) есть свой конфиг. Правила отображения и поведения элемента описывают на текстовом DSL: языке настройки, встроенном в админку. Правила выстраиваются в иерархию, перекрывают друг друга и содержат ветвления на булевой логике.
Конфигурация становится артефактом в коде и уходит в релиз. В результате каждый тенант получает собственную версию продукта: с нужными этапами процесса, кнопками и полями - без переписывания ядра.
80% задач на проекте - конфигурирование тенантов. Например, одной стране нужен этап заказа деталей после аварии, другой - нет. Разработчик убирает, заменяет или настраивает этап через конфиг.
Остальные 20% - исправление багов и новые функции. Новая функция - это новый блок конструктора: разработчик пишет бэкенд, фронтенд и связывает их тегами в конфигурации. После этого блок можно включать в бизнес-процесс любого тенанта.
Главная сложность: цена входа в систему
С чем мы столкнулись на практике:
- Задачи занимали до двух раз больше времени, чем аналогичные задачи в классической разработке на Spring Boot. Время уходило не на код, а на поиск нужного места в конфигурации и проверку, как правила перекрывают друг друга.
- Часть сборки выполнял Apache Ant - инструмент 2000-х годов. Никто из команд не знал в деталях, что именно он делает на своих этапах. Знание о сборке ушло вместе с авторами.
- В систему входил модуль на Unity для работы с 3D-моделями автомобилей и взрыв-схемами запчастей. Готовые компоненты (ассеты) утяжеляли сборку и удлиняли каждый прогон CI/CD.
Эти трудности не решаются на уровне отдельной задачи, нужно полностью погружаться во всю архитектуру решения. Мы закладывали онбординг в оценки сроков и предупреждали о них клиента, но в итоге наша команда стала владеть данными о работе системе на уровне внутренней команды.
Пример одной из десятков задач на проекте:
разработка платёжного бланка для швейцарского банка
По исходной оценке бланк предстояло разработать с нуля: формат, валидация, генерация QR-кода. Наш разработчик нашёл открытую Java-библиотеку SwissQRBill, которая уже реализует стандарт. Объём реализации сократился на 70%. Освободившееся время ушло на главную сложность задачи: встроить обновление в нужный этап бизнес-процесса и собрать корректные данные через конфигурацию.
Результат
- вела поток десятков задач по конфигурированию тенантов для нескольких стран;
- оперативно исправляла баги в продакшене;
- вывела в релиз новые функции, включая генерацию QR-счетов для швейцарского рынка с сокращением объёма разработки на 70% за счёт открытой библиотеки.
Клиент получил внешнюю команду, которая быстро встроилась в распределённый процесс и закрыла задачи наравне с собственными командами Solera.