Канал. Продукт. Платформа.
Эволюция мобильного банка Тинькофф
Эволюция мобильного банка Тинькофф
Эволюция мобильного банка Тинькофф
Technical Director, Т-Технологии
Архитектура mobile bank at scale
Канал → продукт → платформа
Подкаст «Code of Leadership», канал @book_cube
4 вопроса
Как mobile становится платформой?
Как растут команда и архитектура?
Что меняется от канала к продукту?
Где Конвей помогает или мешает?
16 лет эволюции
Шесть точек
2006–2008 — remote bank + web
2011 — Mobile: канал и монолит
2015 — Mobile: owner, команда, backend
2019–2022 — platform, verticals, trains
Capital One модель в России
Capital One модель
Карты по почте и direct mail
Call center — главный клиентский канал
ИТ поддерживает процессы
Цель — low cost-to-serve
Первый цифровой канал самообслуживания
Самообслуживание: выписки и платежи
Меньше нагрузки на call center
Маленькая web-команда, монолит
Редкие ночные релизы, web становится digital-каналом
Маленькая команда, большой потенциал
iPhone и Android меняют ожидания клиентов
~5 человек: iOS, Android, mobile backend
Монолит, общий с web-bank
Фичи догоняют web
Нагрузка растёт быстрее команды
Появляется отдельный заказчик и команда
Появляются заказчик, команда, процессы и архитектура
Product owner со стратегией
20–30 человек по платформам
Собственные процессы и release cycles
Backend for mobile + DAU/revenue focus
Несколько факторов сошлись вместе
Один app, один заказчик
Автономная команда
Архитектура следует структуре команды
P&L и экспертиза внутри продукта
Superapp и vertical-команды
Группа выросла, бизнес-вертикалей стало больше
Сотни mobile-инженеров
Банк, инвестиции, страхование, lifestyle
Каждая vertical хочет дорожная карта в superapp
Mobile Platform как общая основа
Матрица масштаба
Verticals быстро выпускают фичи
Platform владеет shell/shared services
Infrastructure не дублируется
Единый release train платформы
Один app, много модулей
Один app снаружи
Vertical module + owning team
Platform owns shell/services
Dynamic loading + isolation
Как команды повлияли на код
Архитектура следует коммуникациям
Было — монолит, потому что одна команда
Потом — модули внутри монолита
Цель — modules, releases, shared platform
Команды меняем раньше архитектуры
Сотни фич в одном app
Поезд уходит каждые 1–2 недели
Verticals садятся в ближайший поезд
Flags отделяют поставку от релиза
Predictability важнее локальной скорости
Иначе платформа становится обузой
RFC/ADR фиксируют решения
Performance budgets + contract tests
Meetups / radar держат контекст
Platform служит verticals
Канал → продукт → платформа
Канал — интерфейс к backend
Продукт — owner, команда, P&L
Платформа — много vertical teams
Conway масштабирует продукт
Case experience + оргдизайн
Conway's Law + Team Topologies
Accelerate / DORA: dora.dev/research/
Thoughtworks Radar: thoughtworks.com/radar
ADR/RFC practices: adr.github.io
polomodov.tech
Все слайды и ссылки — в Telegram-канале
Александр Поломодов, Technical Director & Fellow, Т-Технологии
@book_cube