Архитектура большой компании почти никогда не развивается по генеральному плану. Эта глава показывает более честную траекторию: как Т-Банк проходил через этапы коробочных решений, собственной разработки, платформенной инженерии и распределённого архитектурного управления под давлением роста, цены изменений и новых ограничений.
Ценность материала в том, что он учит смотреть на архитектуру как на последовательность состояний, а не как на одну правильную конечную схему. На этой траектории хорошо видно, почему решения для стартапа, платформенной компании и мегапроекта с десятками команд принципиально различаются.
В архитектурных обсуждениях этот кейс особенно полезен как живая история эволюции: через него удобно объяснять, как масштаб бизнеса, устройство команд и инженерные ограничения постепенно меняют приоритеты, роли и способы принятия решений.
Практическая польза главы
Эволюция платформы
Разбирает, как архитектура меняется вместе с масштабом бизнеса, оргструктурой и регуляторными ограничениями.
Мышление миграциями
Учит планировать переходы между архитектурными состояниями без остановки продуктовой разработки.
Платформенные инвестиции
Помогает понять, когда инвестиции в общую платформу действительно окупаются, а где лучше сохранить локальную автономию.
Реалистичность на интервью
Дает реальные эволюционные кейсы, которыми удобно подкреплять аргументацию в интервью.
Источник
ArchDays 2024
Текстовая версия доклада «Архитектура в Т-Банке: вчера, сегодня, завтра».
История архитектурной эволюции Т-Банка за 18 лет: от стартапа на коробочных решениях до большой технологической компании с собственной платформой разработки и распределённым архитектурным управлением.
На этом кейсе хорошо видно, как меняется вместе с бизнесом: сначала доминируют и риск , затем на первый план выходят , , и накопленный . Точно так же на практике начинают расходиться и , когда компания строит общие платформенные сервисы и расширяет их через .
Эволюция архитектуры Т-Банка
Разбор доклада Александра Поломодова на ArchDays 2024
Связанная книга
Continuous Architecture in Practice
Непрерывная архитектура, качественные характеристики и решения, которые откладывают до нужного момента.
Что здесь понимается под архитектурой
Перед историей полезно зафиксировать саму оптику. В докладе архитектура не сводится к одной диаграмме или набору технологий: это способ договориться о границах системы, зафиксировать дорогие решения и удержать траекторию изменений по мере роста компании.
Как устроена система, из каких частей она состоит и как эти части взаимодействуют.
Какие детали мы скрываем и на каком уровне описываем взаимодействия между компонентами.
Несколько взаимосвязанных представлений, через которые систему можно обсуждать и развивать.
Политики, стандарты и договорённости, которые удерживают архитектуру в согласованных границах.
Выборы, которые особенно дороги в пересмотре и поэтому требуют явной фиксации.
Повторно используемые подходы, которые помогают не собирать систему заново с нуля.
Способ объяснить ключевые решения командам, бизнесу и другим заинтересованным сторонам.
"Перефразируя Джорджа Бокса: все определения неправильные, но некоторые полезны."
Связанное обсуждение
A Philosophy of Software Design
Разговор о книге Джона Остерхаута и о том, почему архитектура живёт дольше любой локальной реализации.
Ключевая метафора
❌ Строительная метафора
В строительстве редко бывает так, что заказчик посреди пути решает сделать разворот и достраивать небоскрёб в другую сторону. В ИТ такие повороты происходят постоянно, поэтому слишком буквальная аналогия со стройкой быстро ломается.
✓ Растительная метафора
Точнее думать об архитектуре как о живом поле: его выращивают, перестраивают и поддерживают постепенно, часто не зная заранее, какие ограничения обнаружатся под ногами по мере роста системы.
Четыре фазы развития
Фазы развития архитектуры Т-Банка
2006–2014
Коробочные решения
Стартап-этап: быстрый выход на рынок за счёт готовых коробочных систем.
1. Коробочные решения (COTS)
В ранние годы Тинькофф развивался как быстрый стартап. В такой ситуации готовые решения дают фору: позволяют быстрее выйти на рынок и не тратить силы на то, что уже умеют зрелые вендорские продукты.
Почему этот этап работал
- +Низкие начальные затраты на запуск.
- +Быстрое внедрение типовых процессов.
- +Проверенная надёжность зрелых решений.
- +Техническая поддержка со стороны вендора.
- +Регулярные обновления без полной собственной разработки.
TDD — Technologist Driven Development
За продукты отвечали технологи — роли на стыке бизнес-анализа и управления проектами. Это важный контекст: на этапе коробочных решений архитектура ещё тесно связана с продуктовым запуском, а не с самостоятельной платформенной инженерией.
2. Переход к собственной разработке
По мере роста компании коробочные системы начали упираться в реальные ограничения бизнеса. Стоимость владения росла, гибкости становилось меньше, а геополитические изменения 2014 года сделали внешние зависимости ещё заметнее.
Что перестало устраивать
- −Ограниченная гибкость — коробочные системы плохо подстраивались под быстро меняющиеся продуктовые сценарии.
- −Растущая стоимость — лицензии на пользователей и ядра увеличивались вместе с масштабом бизнеса.
- −Зависимость от вендора — важные изменения приходилось ждать по чужому дорожному плану.
- −Интеграционная сложность — вокруг коробок начинало накапливаться всё больше промежуточного кода и адаптеров.
- −Риски безопасности — популярные решения оставались привлекательной мишенью для массовых атак.
Собственная разработка оказалась не волшебной кнопкой. Она открыла гибкость, но принесла новую цену: миграции, переосмысление старых решений и неизбежные слои легаси, которые ещё долго сосуществовали с новыми системами.
Spirit
Платформа Spirit
Официальная страница внутренней платформы разработки.
Фундамент
Контейнеризация
Платформенные среды обычно строятся вокруг контейнеров и оркестрации.
3. Платформенная инженерия
К 2020 году стало понятно, что бесконечно размножать локальные инфраструктурные решения дорого. Команды могли быстро делать своё, но компания теряла эффект масштаба и воспроизводимость инженерной среды.
Рост числа инженерных команд
Инженеров были заняты инфраструктурой вместо продукта
Слишком разнородный технологический ландшафт
Принципы платформы Spirit
- Воспроизводимый и прозрачный жизненный цикл кода.
- Единый подход к качеству и управлению кодовой базой на всех этапах.
- Развитие внутреннего обмена кодом и повторного использования решений.
- Фокус на инженерном результате, а не на локальных инфраструктурных компромиссах.
4. Мегапроекты и архитектурное управление
События 2022 года резко ускорили переход к более зрелому архитектурному управлению. Теперь нужно было не просто развивать платформу, а одновременно проводить крупные миграции, снижать внешние зависимости и готовить систему к следующему скачку масштаба.
🔥 Проект «Прометей»
Программа импортозамещения: уход от Oracle и других критически зависимых технологий. Она ускорила накопление технического долга, который затем пришлось разбирать уже в условиях продолжающегося роста компании.
📈 Программа «100М»
Подготовка к следующей фазе роста: больше клиентов, больше продуктов на клиента и больше ежедневных пользовательских сценариев внутри экосистемы.
Что стало рабочим ответом
- Последовательный перевод команд на платформенные сервисы по модели XaaS там, где это действительно окупается.
- Расширение платформенных возможностей под требования масштабирования и импортозамещения.
- Эволюционные изменения вместо одной большой революционной перестройки.
Связанная книга
Fundamentals of Software Architecture
Подробнее о роли архитектора, качественных характеристиках и зрелом архитектурном мышлении.
Кто занимается архитектурой
Кто занимается архитектурой?
Отвечают за темп разработки, координацию и инженерную среду
Берут на себя сложные архитектурные решения и доводят их до кода
Проектируют и пишут код на том уровне сложности, который действительно нужен команде и продукту
Фундамент
Виртуализация: гипервизоры и VM
Дата-центры и внутренние платформы по-прежнему опираются на виртуализацию и гипервизоры.
Куда движется Т-Банк
Главный вывод доклада простой: на длинной дистанции банк вынужден инвестировать не только в продуктовые фичи, но и в собственную технологичность. Без этого следующая фаза роста начинает обходиться слишком дорого.
Инфраструктурная база
Собственные дата-центры, внутренняя платформа разработки и общий слой платформенных сервисов.
Распределение ответственности
Архитектурные решения принимаются ближе к командам, но внутри общих правил и стандартов.
Зрелое повторное использование
Платформа, стандарты и общие сервисы должны помогать командам, а не отнимать у них автономию.
Дополнительные материалы
Связанные главы
- Continuous Architecture in Practice - показывает, как превращать архитектуру в непрерывный процесс решений, а не в разовую проектную фазу.
- Fundamentals of Software Architecture - даёт базу по качественным характеристикам, ролям архитектора и цене архитектурных компромиссов.
- Архитектура в масштабе: как мы принимаем архитектурные решения - добавляет организационный слой: RFC-документы, записи архитектурных решений, журнал решений и лёгкий процесс архитектурного управления.
- Контейнеризация - объясняет инфраструктурную основу платформенного подхода и стандартизации окружений разработки.
- Виртуализация - помогает понять фундамент дата-центров и инфраструктурных решений, на которых строится платформенная база.
- Infrastructure as Code - показывает, как масштабировать инфраструктурные изменения через код, ревью и воспроизводимость.
- GitOps - дополняет платформенный подход прозрачным управлением развёртываниями и эксплуатацией через Git.
- Краткий обзор платформы данных Т-Банка - показывает, как та же эволюционная логика проявляется в больших данных, контрактах и платформенных сервисах.
- ML-платформа в Т-Банке: всеобщее благо или лучше не надо - добавляет ML-контекст: как платформенные инвестиции превращаются в продукт для внутренних инженерных команд.