Источник
Архитектура в масштабе
Расшифровка доклада ArchDays 2020 о масштабировании архитектурных решений.
Когда продукт и команды растут, архитектура перестаёт быть «личной зоной» одного архитектора. Нужен процесс, который помогает принимать и фиксировать важные решения, сохраняя скорость и контекст.
Зачем масштабировать принятие решений
Много клиентов и продуктовых направлений: решения пересекают границы команд.
Быстрый рост продукта и команды повышает стоимость неправильных решений.
Распределённые команды с разными контекстами усложняют коммуникацию.
Две оптики архитектуры
Архитектура = дорогие решения
Архитектурными считаются те решения, которые дороги в изменении. Стоимость изменения — практичный фильтр.
Архитектура = границы и траектория
Архитектура задаёт коридор допустимых решений и направление эволюции системы.
Три уровня архитектуры
Software Architecture
Структура и ключевые решения конкретных систем и продуктов.
Solution Architecture
Решения на уровне продукта или кластера систем под бизнес-задачу.
Enterprise Architecture
Рамки для технологий и подходов в масштабе компании.
Различаются уровнем абстракции, нотациями, инструментами и контекстом взаимодействия.
Роль архитектора в организации
Где роль оправдана
- Есть решения, влияющие на многие команды и продукты.
- Стоимость изменения высока и требует осознанного выбора.
- Нужны рамки для баланса скорости и устойчивости.
Чего не делает архитектор
Архитектор не «рисует стрелочки». Он помогает определить, какие решения действительно архитектурные и как их фиксировать.
Принятие решений в масштабе
Принцип
Решения принимаются децентрализованно, но с прозрачными границами и правилами. Это снижает бюрократию и сохраняет скорость.
Артефакты решений
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 помогает видеть, что используется, что выходит из оборота и куда движется платформа.
Связь с эволюционной архитектурой
Эволюционная архитектура = управляемые изменения
Процесс решений снижает стоимость изменений и предотвращает деградацию.
Decision log как механизм эволюции
Решения можно пересматривать, версионировать и сохранять контекст.
Децентрализация с границами
Скорость команд сохраняется, если есть ясные рамки и артефакты.