Архитектура в масштабе обычно ломается не на диаграмме, а в момент принятия дорогого решения: когда контекст не собран, альтернативы не зафиксированы, а нужные люди появляются слишком поздно. Эта глава показывает, как сделать такой момент управляемым, а не случайным.
Для команды здесь особенно полезна сборка из RFC, ADR, decision log и легкого governance, обкатанная в Т-Банке. Она помогает принимать важные решения быстрее, не терять причины выбора и не превращать архитектуру в центральную бюрократию.
В design review и на интервью этот материал ценен тем, что переводит разговор с картинки на процесс: кто владеет решением, как сравнивались варианты, где проходят границы ответственности и по каким сигналам выбор нужно пересмотреть.
Практическая польза главы
Decision process
Показывает, как масштабировать архитектурные решения через RFC/ADR и прозрачные критерии.
Governance без бюрократии
Помогает выстроить контроль качества решений, не блокируя скорость продуктовых команд.
Трассируемость
Дает практику фиксировать мотивы, предположения и последствия, чтобы возвращаться к решению осознанно.
Interview seniority
На интервью помогает показать системное мышление про процесс принятия решений, а не только про схему.
Источник
Архитектура в масштабе
Доклад Александра Поломодова, автора system-design.space, на конференции ArchDays 2020. Этот процесс раскатан и используется в Т-Банке.
Этот материал основан на докладе Александра Поломодова (автора system-design.space) на ArchDays 2020. Описанный в нём процесс принятия архитектурных решений раскатан и используется в Т-Банке. Когда продукт и команды растут, архитектура перестаёт быть «личной зоной» одного архитектора. Нужен процесс, который помогает принимать и фиксировать важные решения, сохраняя скорость и контекст.
Зачем масштабировать принятие решений
Много клиентов и продуктовых направлений: решения пересекают границы команд.
Быстрый рост продукта и команды повышает стоимость неправильных решений.
Распределённые команды с разными контекстами усложняют коммуникацию.
Две оптики архитектуры
Архитектура = дорогие решения
Архитектурными считаются те решения, которые дороги в изменении. Стоимость изменения — практичный фильтр.
Архитектура = границы и траектория
Архитектура задаёт коридор допустимых решений и направление эволюции системы.
Три уровня архитектуры
Software Architecture
Структура и ключевые решения конкретных систем и продуктов.
Solution Architecture
Решения на уровне продукта или кластера систем под бизнес-задачу.
Enterprise Architecture
Рамки для технологий и подходов в масштабе компании.
Различаются уровнем абстракции, нотациями, инструментами и контекстом взаимодействия.
Роль архитектора в организации
Где роль оправдана
- Есть решения, влияющие на многие команды и продукты.
- Стоимость изменения высока и требует осознанного выбора.
- Нужны рамки для баланса скорости и устойчивости.
Чего не делает архитектор
Архитектор не «рисует стрелочки». Он помогает определить, какие решения действительно архитектурные и как их фиксировать.
Книга
Software Architecture: The Hard Parts (short summary)
Практический разбор сложных архитектурных компромиссов, trade-offs и decision frameworks.
Принятие решений в масштабе
Принцип
Решения принимаются децентрализованно, но с прозрачными границами и правилами. Это снижает бюрократию и сохраняет скорость.
Артефакты решений
RFC
Черновик решения, обсуждение с заинтересованными командами.
ADR
Фиксация решения, контекста и альтернатив.
Decision log
История решений и их причин — для повторного понимания.
Визуальная карта решений
Decision flow
Сигнал
1/5Рост, боль или риск, который требует обсуждения.
RFC
2/5Контекст, варианты и заинтересованные команды.
ADR
3/5Фиксация выбора, последствий и компромиссов.
Decision log
4/5Память решений и основания для пересмотра.
Technology Radar
5/5Легкий governance и общая траектория.
Уровень влияния
Software
Команды и конкретные системы.
Solution
Продуктовые решения и интеграции.
Enterprise
Стандарты, платформы, траектория.
Проблемы и практики
Типичные проблемы
- Слишком позднее вовлечение нужных участников.
- Решения не фиксируются и теряется контекст.
- Централизованная бюрократия тормозит команды.
- Смешение design-решений и архитектурных.
Что помогает
- Децентрализация: решения принимают команды с понятными границами.
- RFC/ADR как лёгкие артефакты для обсуждения и памяти.
- Прозрачные правила: что считается архитектурным решением.
- Минимальный governance вместо тяжёлых комитетов.
Enterprise-архитектура без бюрократии
Проблема восприятия
Классические модели enterprise-архитектуры часто выглядят бюрократично и отталкивают команды.
Лёгкий governance
Technology Radar помогает видеть, что используется, что выходит из оборота и куда движется платформа.
Книга
Building Evolutionary Architectures (short summary)
Практика fitness functions и управляемой эволюции архитектуры через проверяемые ограничения.
Связь с эволюционной архитектурой
Эволюционная архитектура = управляемые изменения
Процесс решений снижает стоимость изменений и предотвращает деградацию.
Decision log как механизм эволюции
Решения можно пересматривать, версионировать и сохранять контекст.
Децентрализация с границами
Скорость команд сохраняется, если есть ясные рамки и артефакты.
Кейс
Эволюция архитектуры Т-Банка (2006 -2025)
Практический пример, где видно, как в реальности работают RFC/ADR, governance и эволюционная траектория.
Кейс, где эти принципы видны вживую
Если хотите увидеть, как RFC/ADR, decision log, границы ответственности и эволюционный подход работают в реальной большой компании, посмотрите главу «Эволюция архитектуры Т-Банка (2006 -2025)». Это практический пример применения всех принципов из этого материала на длинной временной дистанции.
References
Связанные главы
- Эволюционная архитектура на практике - показывает, как переводить архитектурные решения в проверяемые ограничения и повседневную инженерную практику.
- Building Evolutionary Architectures - даёт основу по fitness functions и управляемой эволюции, чтобы решения не устаревали при росте системы.
- Continuous Architecture in Practice - объясняет, как принимать архитектурные решения непрерывно и не терять скорость product delivery.
- Стратегии декомпозиции - помогает выбирать границы модулей и сервисов, чтобы решения масштаба были реализуемы на уровне команд.
- Эволюция архитектуры Т-Банка (2006 -2025) - даёт реальный кейс длинной эволюции, где видно, как decision log, governance и пересмотр решений работают на дистанции.