Архитектура в масштабе обычно ломается не на диаграмме, а в момент принятия дорогого решения: когда контекст не собран, альтернативы не зафиксированы, а нужные люди появляются слишком поздно. Эта глава показывает, как сделать такой момент управляемым, а не случайным.
Для команды здесь особенно полезна сборка из RFC, ADR, журнала решений и легковесного архитектурного управления, обкатанная в Т-Банке. Она помогает принимать важные решения быстрее, не терять причины выбора и не превращать архитектуру в центральную бюрократию.
В инженерных разборах и на интервью этот материал ценен тем, что переводит разговор с картинки на процесс: кто владеет решением, как сравнивались варианты, где проходят границы ответственности и по каким сигналам выбор нужно пересмотреть.
Практическая польза главы
Процесс принятия решений
Показывает, как масштабировать архитектурные решения через короткие RFC-документы, записи решений и прозрачные критерии выбора.
Управление без бюрократии
Помогает выстроить контроль качества решений, не блокируя скорость продуктовых команд.
Трассируемость
Дает практику фиксировать мотивы, предположения и последствия, чтобы возвращаться к решению осознанно.
Уровень сеньорности
На интервью помогает показать системное мышление про процесс принятия решений, а не только про схему.
Источник
Архитектура в масштабе
Доклад Александра Поломодова на ArchDays 2020 о том, как сделать архитектурные решения воспроизводимыми и масштабируемыми в большой компании.
Этот материал основан на докладе Александра Поломодова, автора system-design.space, на ArchDays 2020. В нём показано, как превратить архитектурные решения из неформального разговора в понятный процесс, который работает и при росте продукта, и при росте числа команд. Такой процесс уже раскатан и используется в Т-Банке.
в масштабе перестаёт быть задачей одного человека. Здесь важно различать, где начинается и где включается . На практике это держится на коротком , , , понятном , , явных и , которые помогают не терять курс по мере изменений.
Зачем масштабировать принятие архитектурных решений
Решения начинают пересекать границы нескольких команд, продуктов и платформ.
Цена неудачного выбора растёт быстрее, чем скорость локального исправления.
Разным командам нужен общий процесс, который сохраняет контекст и не душит темп.
Две оптики архитектуры
Архитектура как дорогие в изменении решения
Архитектурными обычно становятся решения, которые особенно дороги в изменении. Цена переделки — практичный фильтр.
Архитектура как границы и траектория
Архитектура задаёт коридор допустимых решений и направление, в котором система может безопасно развиваться.
Три уровня архитектуры
Архитектура системы
Структура и ключевые решения конкретной системы, сервиса или продукта.
Архитектура решения
Сквозное решение на уровне продукта или группы систем под конкретную бизнес-задачу.
Корпоративная архитектура
Правила и ориентиры для технологий и подходов в масштабе всей компании.
Различаются уровнем абстракции, нотациями, инструментами и контекстом взаимодействия.
Роль архитектора в организации
Где роль оправдана
- Есть решения, которые затрагивают многие команды, продукты и платформы.
- Цена изменения высока и требует осознанного сравнения вариантов.
- Нужны рамки, которые удерживают баланс между скоростью и устойчивостью.
Чего не делает архитектор
Архитектор не сводит работу к красивой схеме. Его задача — понять, какие решения действительно архитектурные, кого нужно вовлечь и как сохранить логику выбора.
Книга
Software Architecture: The Hard Parts (краткий обзор)
Практический разбор сложных архитектурных компромиссов, границ сервисов и рабочих рамок для выбора между вариантами.
Как принимать решения в масштабе
Принцип
Архитектурные решения принимаются ближе к командам, но внутри прозрачных границ и понятных правил. Так удаётся сохранять и скорость, и общий курс.
Артефакты решений
RFC-документ
Черновик решения с контекстом, вариантами и вопросами для обсуждения.
Запись архитектурного решения (ADR)
Краткая фиксация выбора, альтернатив и причин, по которым они были отвергнуты.
Журнал решений
История ключевых решений и поводов для их последующего пересмотра.
Визуальная карта процесса
Поток решения
Сигнал
1/5Повод пересмотреть текущий подход: рост системы, боль команды или новый риск.
RFC-документ
2/5Формулировка контекста, вариантов и круга участников обсуждения.
Запись решения
3/5Фиксация выбранного варианта, причин выбора и ожидаемых последствий.
Журнал решений
4/5Общая память о решениях, к которой можно вернуться при пересмотре.
Технологический радар
5/5Общий обзор того, что стоит развивать, ограничивать или выводить из использования.
Уровень влияния
Архитектура системы
Решения внутри отдельной системы или сервиса.
Архитектура решения
Сквозные продуктовые решения и интеграции между системами.
Корпоративная архитектура
Общие технологические правила, платформы и направление развития.
Типичные проблемы и полезные практики
Типичные проблемы
- Нужные участники подключаются слишком поздно.
- Решение принято, но контекст и аргументы не зафиксированы.
- Архитектурные вопросы смешиваются с локальными дизайн-обсуждениями.
- Централизованный контроль превращается в узкое место для команд.
Что помогает
- Оставлять право принимать решения как можно ближе к командам, но внутри понятных границ ответственности.
- Коротко фиксировать контекст, варианты и последствия, чтобы к решению можно было вернуться позже.
- Явно договариваться, какие вопросы считаются архитектурными и кто должен участвовать в обсуждении.
- Держать архитектурное управление лёгким: достаточно правил, чтобы не терять курс, но не душить скорость.
Корпоративная архитектура без бюрократии
Проблема восприятия
Классические модели корпоративной архитектуры часто воспринимаются как бюрократия ради бюрократии и отталкивают команды.
Лёгкое архитектурное управление
Технологический радар помогает видеть, что компания уже использует, что пора ограничивать и в каком направлении движется платформа.
Книга
Building Evolutionary Architectures (краткий обзор)
Практика функций архитектурной проверки и управляемой эволюции через проверяемые ограничения.
Связь с эволюционной архитектурой
Управляемая эволюция вместо разовых реформ
Хороший процесс принятия решений снижает стоимость изменений и не даёт системе деградировать незаметно.
Журнал решений как опора для пересмотра
Команда может пересматривать решение осознанно, а не заново восстанавливать забытый контекст.
Децентрализация держится на ясных границах
Скорость команд сохраняется, когда есть понятные рамки, артефакты и сигналы для пересмотра.
Кейс
Эволюция архитектуры Т-Банка (2006–2024)
Практический пример того, как в большой компании работают архитектурные документы, границы ответственности и длительная эволюция решений.
Где эти принципы видны вживую
Если хотите увидеть, как RFC-документы, записи архитектурных решений, журнал решений и ясные границы ответственности работают в реальной большой компании, посмотрите главу «Эволюция архитектуры Т-Банка (2006–2024)». Это длинный производственный кейс, где те же принципы показаны не в абстракции, а на многолетней траектории развития платформы.
Источники
Связанные главы
- Эволюционная архитектура на практике - показывает, как превращать архитектурные решения в проверяемые ограничения и повседневные инженерные ритуалы.
- Building Evolutionary Architectures - даёт основу по функциям архитектурной проверки и управляемой эволюции, чтобы решения не устаревали вместе с ростом системы.
- Continuous Architecture in Practice - объясняет, как принимать архитектурные решения непрерывно и не терять темп поставки изменений.
- Стратегии декомпозиции - помогает выбирать границы модулей и сервисов так, чтобы решения масштаба оставались реализуемыми для команд.
- Эволюция архитектуры Т-Банка (2006–2024) - даёт длинный производственный кейс, где видно, как журнал решений, архитектурное управление и пересмотр выбора работают на дистанции.