Архитектура в крупном финтехе: вчера, сегодня, завтра

В начале компания строила продукты поверх готовых систем, включая Oracle Siebel. Это снижало первоначальные затраты и позволяло опереться на документацию, поддержку и обновления поставщиков. Бизнесовые процессы проектировали технологи, совмещавшие задачи аналитиков и руководителей проектов. Их работа связывала готовые системы так, чтобы быстро запускать нужные клиентам сценарии.

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

К 2020 году самостоятельное строительство инфраструктуры каждой командой стало экономической проблемой. Автор приводит исторические данные коллеги: команды разработки выросли в восемь раз, а около четверти инженеров занимались настройкой поставки, поддержкой инфраструктуры и надёжностью приложений. Разнообразие локальных технологий затрудняло использование общих решений. Эти цифры описывают конкретный этап компании, а не отраслевую норму.

Ответом стала внутренняя платформа Spirit. Её принципы включали повторяемый и прозрачный жизненный цикл кода, контроль качества, совместную разработку внутренних компонентов и ориентацию на результат. Автор отдельно отмечает поворот к удобству инженеров. Полезность платформы определяется тем, какие реальные сценарии она упрощает, а не только наличием общего набора инструментов или централизованной команды.

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

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