Архитектурные решения, это не документы для галочки и не приказы сверху. Это способ сохранить память организации и легитимировать стандарты. Разбираю практику ADR с опорой на Нейгарда и Ричардса/Форда, добавляю собственный шаблон, рассказываю про критерии эскалации, антипаттерны и архитектурный комитет, который задаёт рамки, а не командует.
Зачем нужен корпоративный архитектурный слой
Представьте организацию с двадцатью сервисами. Когда их было три, всё работало. Каждая команда выбирала свой стек, свои форматы, свои протоколы. Быстро, автономно, без согласований. А потом сервисов стало десять, пятнадцать, двадцать, и начали всплывать вещи, которые ни одна команда не могла решить в одиночку.
Четыре проблемы накатывают одновременно: N команд дублируют одни и те же решения (аутентификация, логирование, секреты), системные свойства типа end-to-end трейсинга или единой модели идентичности невозможно обеспечить в одиночку, регуляторика требует выделенной функции перевода требований в техстандарты, а решения про данные и платформы переживают команды, которые их приняли, и кто-то должен думать на горизонте 3-5-10 лет. Для стартапа из трёх команд корпоративный слой вреден. Для двадцати плюс систем он неизбежен.
Я работал в компании, где из-за отсутствия архитектурных стандартов лишние траты на доработку качества сервиса измерялись сотнями миллионов рублей. Не теоретическая цифра, реальная стоимость ситуации, когда стандартов нет, каждая команда реализует по-своему, а стыки не работают, потому что некому задать рамки.
Вот конкретный пример из практики. Одна крупная организация. Сущность "клиент" живёт в пяти системах: CRM, биллинг, портал, аналитическая платформа, внешний реестр. В каждой системе своя модель данных клиента. Свой формат ФИО, своя обработка дат, своя логика привязки идентификатора. Когда нужно синхронизировать данные между системами, начинается ад. Команда А пишет костыль на ETL-пайплайне для трансформации формата X в формат Y. Команда Б пилит свой велосипед поверх брокера сообщений. Команда В вообще не синхронизирует, у них "свои клиенты". Результат: во внешний реестр улетают кривые данные, сверка с источниками ломается на расхождениях, а миграция на единый мастер-данные превращается в проект на три года и двести миллионов. И всё потому, что когда-то не было зафиксировано простое решение: единый формат идентификации клиента и единый источник истины по мастер-данным. Один ADR, и двадцать команд не писали бы двадцать разных костылей.
Контртезис: не башня из слоновой кости
Майкл Нейгард в "Release It!" критикует enterprise-архитекторов, которые пишут стандарты в отрыве от реальности эксплуатации. Его аргумент: архитектор, который не видел свою систему в три часа ночи под нагрузкой, не имеет морального права предписывать, как её строить. Архитектура должна расти из боли продакшена, а не из reference-моделей.
Он же против монокультуры. Монокультура технологий хрупка, один CVE кладёт весь ландшафт. Монокультура мышления хрупка, никто не оспаривает решения. Разнообразие в стеке и в командах, это устойчивость.
И его центральная формулировка: архитектура, это не документ, а набор решений, которые трудно изменить. Из этого следует, что решения должны принимать те, кто будет с ними жить, то есть команды. Роль корпоративного архитектора, не диктовать, а создавать условия. Ограничительные рамки, а не железные рельсы.
Синтез: комитет как инструмент принуждения с человеческим лицом
Тезис про корпоративный слой и тезис Нейгарда противоречат друг другу, и это противоречие не разрешается красивой формулировкой. Архитектура, это всегда жёсткий компромисс между башней из слоновой кости и анархией продуктовых команд. Корпоративный слой хочет единообразия. Команды хотят скорости. Комитет, это инструмент принуждения к стандартам, но с нормальным человеческим лицом: через RFC и ADR, а не через приказы и ревью-встречи.
Не "одобрить или запретить", а "снабдить команды рамками, в которых они принимают решения сами". Команды, которые понимают, зачем нужен стандарт, соблюдают его. Команды, которым стандарт навязали, обходят молча. Комитет работает, когда стандарты обоснованы, а не когда за ними стоит сила приказа.
ADR, это техническое воплощение нейгардовской философии в условиях, когда корпоративный слой всё-таки нужен. Архитектор, вынужденный написать раздел "Контекст" и раздел "Решение" с обоснованием, не может выдать догму, формат не позволяет.
Внутри комитета, набор функций: принципы, стандарты, радар технологий, реестр ADR, RFC-процесс, контроль соблюдения. Снаружи, команды разработки, подрядчики, бизнес и регуляторы. Команды могут оспорить любое решение через новый ADR. Молчание, не согласие, а сигнал, что процесс мёртв.
До первого ADR: положение о комитете
Это главный затык, на который натыкается любой, кто пытается завести ADR в зрелой организации: пишут первый ADR раньше, чем осмыслили, что такое сам орган, который его принимает. Получается вакуумный документ, подписан непонятно кем, по непонятным критериям, с непонятным сроком жизни.
Комитет без положения, как сервис без healthcheck'а. Вроде работает, а потом выясняется, что нет.
Первый ADR в реестре должен быть про сам комитет. ADR-001 "О создании архитектурного комитета и принципах его работы". Только после этого имеет смысл писать ADR-002 о чём угодно техническом. Это рекурсивная конструкция: документ, обосновывающий своё собственное существование.
Что входит в положение (или в ADR-001):
Легитимность и мандат. Кто учредил комитет, на каком основании, кому подотчётен. Без этого комитет, инициативная группа без полномочий.
Состав и роли. Кто входит. Председатель, секретарь (фиксирует решения, ведёт реестр), оппонент по умолчанию. Кто имеет право голоса, кто совещательный. Что делать при увольнении или отпуске, заместители.
Границы. Что комитет регулирует, а что нет. Какие системы в скоупе, какие команды, какие подрядчики. Без явных границ комитет либо лезет везде, либо не лезет никуда.
Финансовый порог. На какие суммы комитет имеет право принимать решения. Что выше, идёт на наблюдательный совет или к спонсору. Это не формальность: когда комитет утвердил решение на 50 миллионов, а потом выясняется, что полномочий не было, это катастрофа.
Регламент работы. Частота заседаний, кворум, формат (очно, гибрид, асинхронно через RFC). Срок рассмотрения ADR, от подачи до решения.
Шаблон ADR. Тот самый шаблон из этой статьи. Но он должен быть зафиксирован как стандарт до того, как появится первый ADR.
Критерии эскалации. Стоимость, влияние, безопасность, обратимость, срочность, с явными порогами, утверждёнными до первого ADR.
Жизненный цикл и сроки. Срок действия ADR: бессрочные, с пересмотром через N лет, с триггерами (изменение регуляторики, смена технологии). Что происходит при отмене родительского ADR со ссылающимися документами.
Контроль соблюдения. Кто проверяет, что утверждённые ADR применяются. Метрики, аудит. Что происходит при несоблюдении, эскалация, исключения через RFC, или просто фиксация отклонения.
Каналы входа. Кто и как приносит идеи на новые ADR. Команды через бэклог. Архитекторы по результатам анализа. ИБ при инцидентах. Подрядчики при стыковке. Регуляторы при новых требованиях. Это проактивный канал, без которого комитет становится реактивным.
Отношение со стандартами. Стандарт, документ, описывающий требования. ADR, решение, которое могло привести к появлению стандарта или к его отмене. Разные жизненные циклы: стандарт пересматривается независимо от ADR, который его породил.
Архив и доступ. Где живут ADR, кто имеет доступ, public-by-default или ограниченный. Как искать, как ссылаться извне.
И ключевой тезис: если комитет не может написать ADR-001 с честным разделом "Последствия" и "Контроль соблюдения", значит, он сам себе не нужен. Это снимает антипаттерн Covering Your Assets на корню.
Откуда взялись ADR
Сам термин Architecture Decision Record ввёл Майкл Нейгард в посте "Documenting Architecture Decisions" 15 ноября 2011 года на блоге Cognitect. Это короткий пост, который положил начало целой практике. Базовая идея у него простая: agile-проектам не нужны большие документы, которые никто не читает и не обновляет, но им нужны короткие записи решений с указанием контекста и последствий.
Шаблон Нейгарда тоже минимальный: заголовок, статус, контекст, решение, последствия. Этого хватает, чтобы через год кто-то понял, почему система устроена именно так.
Развитую модель ADR с критериями эскалации, RFC-статусом, разделом контроля соблюдения и антипаттернами систематизировали Марк Ричардс и Нил Форд в книге "Fundamentals of Software Architecture" (2020, второе издание, 2025). Они же вернулись к теме в "Software Architecture: The Hard Parts" (2021, в соавторстве с Прамодом Садалаге и Жамак Дегани), там каждое решение в сквозной истории Sysops Squad заканчивается ADR.
Дальше я опираюсь в основном на эти три источника: оригинальный пост Нейгарда 2011 года и две книги Ричардса с соавторами. Где встретится мысль из их работ, укажу явно.
Три антипаттерна
Ричардс и Форд во втором издании "Fundamentals" описывают три антипаттерна архитектурных решений. Все три я наблюдал в реальной практике.
Groundhog Day
Команда переписывает сервис аутентификации. Раз, два, три. Каждый раз новая архитектура, каждый раз "вот теперь правильно". Проблема не в том, что они плохие разработчики. Проблема в том, что никто не записал, почему предыдущее решение не подошло. Нет истории. Нет выводов. Каждый новый заход начинается с нуля, как в фильме "День сурка".
Groundhog Day бывает разный. Иногда это слабый бизнес-анализ: требования меняются, и команда каждый раз переписывает под новый вариант. Иногда смена ландшафта инфраструктуры: пришёл новый DevOps, принёс свой стек, старый переписали. Иногда просто нет зрелости: команда пробует паттерны методом тыка.
ADR не решает все эти причины. Но он делает одну вещь: каждый следующий заход начинается не с нуля, а с записи "мы пробовали X, вот почему не подошло". Это экономит время. Иногда, месяцы.
Covering Your Assets
Компания растёт. Появляется архитектурный комитет. Принимает четыре-пять решений. И всё. Но бюджет выделен, нужно показывать результат. Начинается: комитет генерирует стандарты не потому, что они нужны, а потому, что нужно что-то производить. Появляются документы ради документов, ревью ради ревью, процесс ради процесса.
Комитет превращается в обложку: "Ребята, мы работаем, пожалуйста, не смотрите на это строго".
Как это распознать. Количество принятых ADR растёт, а количество реализованных, нет. Архитектурный комитет собирается раз в неделю, но за месяц не принял ни одного решения, влияющего на продукт. Стандарты пишутся для идеального мира, а не для текущей реальности.
Лечение. Архитектурный комитет должен принимать решения, а не документы. Если за квартал не было ни одного решения, которое изменило архитектуру продукта, комитет не нужен.
Email-Driven Architecture
Начальный уровень. Бывает до enterprise-опыта, до книг по архитектуре. Между отделами или компаниями договариваются о решении по почте. Кто-то реализовал, кто-то нет. Кто-то уволился. Переписка потерялась. Решения больше нет.
Особенно больно в трансграничных ситуациях: два отдела договариваются об интеграционном контракте, три месяца переписываются, приходят к варианту. Через полгода оба отдела поменяли лидов, а контракта в документации нет. Только в чьей-то почте, которая уже удалена.
ADR решает это радикально: если решения нет в репозитории, его не существует. Почта, это коммуникация, не документация.
Что считать архитектурно значимым решением
Не каждое решение нужно записывать. Где граница?
Ричардс и Форд используют формулировку Нейгарда: архитектурно значимое решение, это то, которое влияет на структуру системы, нефункциональные характеристики, зависимости, интерфейсы или приёмы реализации.
На практике это раскладывается так. Решение архитектурно значимо, если оно влияет на больше чем одну команду, имеет долгосрочные последствия (от полугода), его дорого изменить после реализации, и от него зависят другие решения.
Выбор библиотеки для логирования, вряд ли. Выбор между монолитом и микросервисами, безусловно. Выбор протокола общения между сервисами, зависит от масштаба.
Когда у организации меньше двадцати сервисов, почти все решения локальные, и команда справляется без формализации. Когда сервисов больше ста, нужен ландшафт и горизонт событий. Нужно понимать, как этим управлять, исходя из потребностей бизнеса, ограничений безопасности и горизонта планирования.
Жизненный цикл ADR
В исходном шаблоне Нейгарда есть только три статуса: предложено, принято, заменено. Этого мало для крупной организации, где между "написал черновик" и "принято комитетом" должна быть фаза публичного обсуждения.
Ричардс и Форд предлагают расширенную модель со статусом RFC (Request for Comments). Архитектор отправляет черновую запись на комментарии, указывает дедлайн, после которого собирает обратную связь и переводит ADR в "Предложено". Это снимает антипаттерн аналитического паралича, решение не висит вечно в подвешенном состоянии.
В моей практике пригодилась ещё одна ветка, срочные решения. Когда что-то горит в продакшене и нужно принять решение за час, проходить полный цикл невозможно. Срочный ADR идёт по fast-track: принимается ведущим архитектором или дежурным, реализуется немедленно, и потом проходит post-hoc review. Это не нарушение процесса, а признание того, что процесс должен жить с реальностью.
Шаблон ADR
Базовый формат Нейгарда минимален, заголовок, статус, контекст, решение, последствия. Этого достаточно для маленькой команды. В корпоративной среде шаблон обрастает деталями, не из любви к бюрократии, а потому что каждое поле закрывает конкретную дыру в процессе.
Ключевые поля, которые отличают мой шаблон от минимального:
Оппонент как обязательное поле, лекарство от группового мышления. Назначенный оппонент обязан искать дыры, и это легитимизует критику.
Тип задачи (стратегическая / тактическая / оперативная) сразу даёт маршрут эскалации. Стратегические, через комитет, тактические, через ведущего архитектора, оперативные, в зоне ответственности команды.
Заменяет / Заменено на, вшитая темпоральная связность. Реестр ADR становится графом, а не свалкой.
Контроль соблюдения как обязательный раздел с явным "не требуется + обоснование". Без него ADR, это обещание, а не решение.
Стоимость отката в drivers, один из самых недооценённых критериев. Решения с дешёвым откатом не должны проходить через комитет (пересекается с делением Безоса на type 1 / type 2 decisions: необратимые, через высокий уровень утверждения, обратимые, на уровне команды).
Компромиссы отдельным подразделом, не "минусы", а именно компромиссы. Осознанный обмен: мы что-то теряем ради чего-то.
Контекст или движущие факторы
В классическом шаблоне Ричардса и Форда раздел "Контекст" несёт двойную функцию: он описывает и проблемную ситуацию, и пространство решений. Перефразируя их пример: сервис заказов передаёт данные в сервис платежей, и архитектор должен выбрать между синхронным REST и асинхронным обменом сообщениями.
Это лаконично, но размывает анализ. Фраза про REST или async messaging, уже скрытый shortlist. А почему не gRPC? Не shared database? Не event sourcing? Контекст-как-варианты легитимизует люфт, но одновременно скрывает отсев.
В моём шаблоне drivers и варианты разнесены. Drivers (раздел 3) задают критерии отсева, НФР, регуляторика, эксплуатация, стоимость отката. Раздел 4 "Рассмотренные варианты" показывает результат отсева. Раздел 5 фиксирует выбор. Это методологически чище, но дороже в написании.
Когда какой подход выбрать. Для оперативных решений можно сжимать по Ричардсу, не разворачивать полстраницы анализа, если выбор между двумя очевидными опциями. Для стратегических, разворачивать. Через три года кто-то спросит "а почему не Kafka?", и в ADR должен быть ответ.
Последствия как инструмент проверки решения
Раздел "Последствия" в ADR, не отчёт после внедрения, а sanity check до утверждения. Ричардс и Форд формулируют прямо: если архитектор не может честно описать, где и как решение развалится под нагрузкой или при масштабировании, решение не готово к утверждению. Многие плохие идеи умирают именно на этапе, когда автор пытается сформулировать, что станет хуже.
Поэтому раздел "Компромиссы" в шаблоне сильнее, чем "Минусы" или "Отрицательные последствия". Компромисс подразумевает осознанный обмен: мы отдаём X, чтобы получить Y. В архитектуре не бывает "просто плохого", бывает выбор, что мы готовы пожертвовать.
Антипаттерн: ADR, в которых раздел "Минусы" содержит только "придётся потратить время на рефакторинг" или "повышенная сложность". Это мусорный документ, автор которого просто пытается протащить свою любимую технологию. Если в ADR про переход на микросервисы нет ни слова про сетевую задержку, distributed transactions и operational overhead, его нужно возвращать на RFC без обсуждения.
Связь с разделом "Контроль соблюдения" замыкает цикл: последствия описывают, что должно произойти, контроль соблюдения проверяет, что действительно произошло. ADR превращается из приговора в гипотезу с механизмом верификации.
Критерии эскалации
Не всякое архитектурное решение должно подниматься на уровень комитета. Ричардс и Форд предлагают три критерия, по которым определяется, может ли архитектор утвердить ADR сам или должен эскалировать: стоимость, кросс-командное влияние и безопасность.
Стоимость складывается из расходов на лицензии, дополнительных затрат на железо и общего уровня затрат на реализацию. Уровень затрат на усилия можно оценить, перемножив расчётное количество часов на стандартную часовую ставку. Если стоимость превышает определённый порог, ADR переходит в статус "Предложено" и требует утверждения вышестоящим органом. Порог фиксируется в положении о комитете, например, "затраты свыше 5000 EUR требуют одобрения наблюдательного совета".
Влияние на другие команды или системы, любое такое решение не может быть утверждено архитектором единолично. Оно поднимается на уровень ведущего архитектора или комитета.
Последствия для безопасности, аналогично. ИБ-офицер должен дать заключение, и без него ADR не может быть утверждён.
К этим трём базовым критериям я бы добавил ещё два, которые в книге явно не выделены, но на практике важны.
Обратимость как мета-критерий. Безос делит решения на type 1 (необратимые, как открытие двери в одну сторону) и type 2 (обратимые). Решения с высокой обратимостью не должны проходить через комитет вообще, независимо от стоимости. Решения необратимые, всегда через комитет, даже если кажутся дешёвыми.
Срочность. Аварийные ADR должны иметь fast-track с post-hoc review, иначе процесс блокирует реакцию на инциденты. Это та самая ветка "Срочное" из жизненного цикла.
Принципы и стандарты как ADR
Одна из функций ADR, которую часто упускают, введение стандартов через решения, а не через приказы. Ричардс и Форд формулируют это так: раздел "Решение" в ADR-стандарте используется не только для изложения сути стандарта, но и, что более важно, для обоснования необходимости его введения. Это прекрасный способ определить, имеет ли данный стандарт право на существование.
И их ключевой тезис: если архитектор не может обосновать необходимость стандарта, то, возможно, этот стандарт не так уж и хорош, чтобы настаивать на его введении. Более того, чем больше разработчиков поймёт, зачем вводится стандарт, тем выше шансы, что они ему последуют.
Это эмпирическое наблюдение работает как двойной фильтр.
Первый фильтр: невозможность обоснования, сигнал плохого стандарта. Если архитектор не может объяснить, зачем нужен стандарт, проблема не в коммуникации, а в самом стандарте. Акт формулирования обоснования отсеивает плохие стандарты до их введения.
Второй фильтр: понимание снижает сопротивление. Команды соблюдают стандарты, которые понимают; обходят те, которые навязаны. За этим эмпирическим наблюдением стоит более глубокая вещь: соблюдение через понимание устойчивее, чем соблюдение через принуждение, потому что не требует постоянного надзора.
И тут возникает естественное расширение, двухуровневая модель.
Уровень 1, архитектурный принцип. Это ADR, в котором фиксируется, что мы хотим от ландшафта на горизонте. Например: "межсистемные интеграции должны быть наблюдаемыми и трассируемыми end-to-end". Это не стандарт, это архитектурное свойство, которое мы выбираем как ценность.
Уровень 2, конкретные стандарты, реализующие принцип. Под этот принцип уже подвёрстываются стандарты: формат correlation-id, обязательность structured logging, обязательные поля в трейсах OpenTelemetry. Каждый стандарт ссылается на родительский ADR-принцип.
Уровень 3, ADR команд, применяющие стандарты. Решения внутри одной системы, какую библиотеку взять, как настроить, какой формат использовать.
Что это даёт.
Стандарты становятся опровержимыми не сами по себе, а через принцип. Если кто-то приходит и говорит "давайте перейдём с OpenTelemetry на Jaeger", спор идёт не о формате, а о том, удовлетворяет ли альтернатива принципу наблюдаемости. Это смещает дискуссию с религиозной на содержательную.
Стандарты можно осмысленно отменять. Если принцип меняется (например, регуляторика добавила требование), ясно, какие стандарты надо пересмотреть. Без принципа стандарты живут вечно, потому что никто не помнит, зачем их вводили.
Команды получают свободу в реализации. Принцип фиксирует "что", стандарт фиксирует "как". Если команда может реализовать наблюдаемость другим способом, она приходит с RFC и предлагает альтернативный стандарт под тем же принципом.
Радар технологий получает якорь. Технологии в радаре оцениваются не сами по себе, а через соответствие принципам. Adopt / Trial / Assess / Hold, это не про моду, а про то, помогает ли технология реализовать принципы, которые мы зафиксировали.
Двухуровневая модель добавляет накладные расходы. Для маленькой организации это избыточно, принцип и стандарт сольются в один документ. Для двадцати плюс систем разделение себя оправдывает. Это вопрос масштаба.
Где жить ADR
Ричардс и Форд рекомендуют хранить ADR в вики-системе с трёхуровневой структурой каталогов: Application (решения внутри одной системы), Integration (решения на стыках систем), Enterprise (решения уровня всего ландшафта). Имена каталогов носят рекомендательный характер, главное, чтобы они однозначно воспринимались всеми командами.
За этой рекомендацией скрывается важная архитектурная деталь. Это не просто папки, это неявная маршрутизация эскалации. Application-ADR утверждает team lead, Integration, комитет интеграционных архитекторов, Enterprise, архитектурный комитет. Структура хранения = структура власти.
Если у тебя плоский список ADR, у тебя нет дифференциации эскалации, и комитет будет рассматривать всё подряд (или не рассматривать ничего). Если структура есть, она автоматически разводит потоки.
В госсекторе есть смысл добавить четвёртый уровень, Regulatory или Cross-Enterprise, для решений, которые приходят сверху и не подлежат пересмотру внутри организации. Это полезно, чтобы отделить "наши решения" от "решений, с которыми мы обязаны жить".
Вики или Git
Если ADR живут в вики (Confluence, Notion) как просто страницы, это удобно для людей, но не машиночитаемо. Не получится автоматически сгенерировать граф зависимостей, посчитать метрики, собрать актуальный технологический радар из утверждённых ADR.
Альтернатива, ADR как Markdown в Git. Это идеально ложится на философию "архитектурный документ как single source of truth, генерирующий представления для всех стейкхолдеров". Тогда вики становится одним из представлений, а не первоисточником.
Контраргумент: вики ниже порог входа для нетехнических участников комитета (юристы, ИБ, бизнес). Markdown в Git их отпугнёт.
Гибридный подход, Markdown как источник, вики как представление, решает обе задачи, но требует автоматизации. Для крупной организации это окупается, для маленькой, нет.
Архитектурный комитет
Я сейчас формирую архитектурный комитет в реальном проекте. Поэтому статья, это в том числе способ структурировать собственный опыт и не наступить на грабли, которые уже описал.
Вот как это выглядит вживую.
Состав
Архитекторы как основной состав. Безопасник от ИБ. Старший SRE от инфраструктуры. Представители разработки, лиды фронта и бэка. Если решение влияет на бизнес (миграция, стоимость, регуляторика), представитель заказчика. На практике это значит, что в комнате сидят люди, которые понимают и специфику регулирования, и ограничения инфраструктуры, и реальную нагрузку на прод.
Размер, три-пять-семь человек. Больше десяти, это не комитет, а собрание.
Регламент
Комитет собирается раз в две недели. Формат, гибрид: очно для стратегических решений, асинхронно через RFC для оперативных. Повестка формируется из двух источников: проактивный (архитектор сканирует ландшафт, выявляет пробелы) и реактивный (команды приносят ADR на ревью). Срок рассмотрения ADR, от подачи до решения не больше двух недель. Если горит, fast-track через ведущего архитектора.
Шаблон ADR
Используется шаблон из этой статьи. Фиксирован как ADR-001 вместе с положением о комитете. Каждое поле шаблона закрывает конкретную дыру: оппонент защищает от echo chamber, раздел "Стоимость отката" заставляет думать про откат, "Контроль соблюдения" превращает ADR из приговора в гипотезу.
Связь с внешними командами
Когда в проекте участвуют внешние команды, ADR играет двойную роль: во-первых, задаёт технические рамки (внешняя команда получает стандарты, обоснованные через ADR, а не через "потому что я так решил"), во-вторых, создаёт легитимную базу для согласований. Если внешняя команда не соблюдает стандарт, обоснованный через утверждённый ADR, это документальная основа для эскалации. Если стандарт не обоснован, комитет сам должен его пересмотреть.
Что комитет делает
Не ревьюит каждую фичу. Комитет задаёт рамки и следит, чтобы рамки были разумными. Команды работают внутри рамок автономно.
Конкретно:
- утверждает архитектурные принципы (мало, на годы);
- утверждает стандарты под принципы (умеренно, на месяцы-годы);
- ведёт радар технологий;
- рассматривает ADR, попадающие под критерии эскалации (стоимость, влияние, безопасность);
- проверяет соблюдение через метрики и аудит;
- собирает обратную связь от команд и обновляет принципы и стандарты, когда контекст меняется.
Проактивные функции, не реактивные
Это, пожалуй, главное отличие живого комитета от мёртвого. Реактивный комитет ждёт, пока команды принесут ему ADR на ревью. Проактивный сам сканирует ландшафт, смотрит на радар технологий, идентифицирует пробелы в стандартах, выявляет повторяющиеся проблемы и пишет ADR-стандарты до того, как боль возникнет в десяти местах одновременно.
Реактивный комитет легко превращается в бюрократический барьер. Проактивный, вот что значит работать как enabling function.
Как распознать мёртвый комитет
Если за квартал не было ни одного решения, которое изменило архитектуру продукта, комитет не нужен. Если все ADR утверждаются единогласно за пять минут, оппоненты не работают. Если стандарты вводятся, но никто не проверяет соблюдение, это театр. Если команды обходят стандарты молча, это не их вина, это сигнал, что обоснование не дошло.
Реальный ADR из практики
Чтобы не быть голословным, вот ADR из реального проекта (анонимизированный).
ADR-003. Единая модель идентификации клиента Статус: УТВЕРЖДЕНО Тип: Стратегический
Контекст. Сущность "клиент" фигурирует в пяти системах: CRM, биллинг, портал, аналитическая платформа, внешний реестр. В каждой системе свой формат ФИО, своя обработка дат, своя логика привязки идентификатора. При синхронизации данные расходятся. Во внешний реестр улетают кривые записи, сверка с источниками ломается.
Drivers. Требования к качеству данных, инциденты с расхождением записей за квартал.
Рассмотренные варианты:
- Единый MDM-сервис как мастер-данных.
- MDM-платформа поверх существующих систем.
- Децентрализованная схема с point-to-point трансформациями.
Решение. Вариант 1. MDM-сервис с единой моделью клиента. Все системы обязаны обращаться к сервису при создании/обновлении записи. Формат обмена, стандартизированный протокол.
Компромиссы. Добавляется единая точка отказа, требуется кластеризация. Рост latency на операциях создания записи (+50-80 мс на вызов). Команды теряют автономию в модели данных, это боль, но обоснованная.
Стоимость отката. Высокая. После миграции откат означает рассинхрон уже выровненных данных. Оценка: 3-6 месяцев работы на откат.
Контроль соблюдения. Метрика: доля записей с расхождением между системами. Целевое значение: <1% через 6 месяцев после внедрения. Аудит, ежеквартально.
Этот ADR приняли за два заседания. На первом обсудили варианты и критиковали MDM-сервис (оппонент справедливо указал на точку отказа). На втором утвердили с условием кластеризации. Через полгода расхождения между системами практически исчезли.
Когда ADR, антипаттерн
Три антипаттерна выше, про ситуацию "ADR нет". Но бывает и наоборот: ADR слишком много, и они приносят вред.
Architecture by Committee. Когда каждое техническое решение, включая выбор библиотеки для логирования, должно пройти через ADR и комитет, это не архитектура, это паралич. Комитет превращается в gatekeeper, команды обходят его теневыми решениями, а скорость доставки падает. Правило: если решение затрагивает одну команду и его можно откатить за неделю, это не ADR.
ADR как оружие. Когда ADR используется, чтобы заблокировать чужое решение, а не обосновать своё. Приём: оппонент пишет встречный ADR, в котором "Компромиссы" состоят из критики чужого подхода. Это не оппонирование, это война. Лечится правилом: встречный ADR обязан содержать собственное решение, а не только критику чужого.
Вечные ADR. Приняли ADR три года назад. Технология устарела. Контекст изменился. А ADR всё ещё "утверждён" и команда обязана ему следовать. Это не стабильность, это окостенение. Решение: каждый ADR должен иметь срок пересмотра или триггер пересмотра (смена мажорной версии, изменение регуляторики, новый вендор в радаре).
Чего ADR не должен делать
ADR, это не приговор. Не санкция. Не бюрократический замок.
Худшее, что можно сделать с ADR, превратить его в фиксированный документ, который запрещает менять архитектуру. Реалии изменились, пишется новый ADR, который ссылается на старый и объясняет, что изменилось.
ADR, это лог, не закон. Запись того, как мы думали в момент принятия решения. Через два года условия будут другими, и это нормально. Главное, чтобы следующий человек, принимающий решение, знал, как думал предыдущий.
Практика для тех, кто начинает
Начните с одного ADR. Найдите архитектурное решение, которое ваша команда принимает прямо сейчас. Запишите: контекст, варианты, выбор, последствия. Положите там, где все найдут. Через три месяца проверьте, помогло ли. Если формируете комитет, три-пять человек, раз в две недели, только значимые решения, обязательный оппонент, обязательный контроль соблюдения. И если за квартал ни одно решение не изменило продукт, комитет не нужен.
Источники
-
Documenting Architecture Decisions, Michael Nygard, 2011. Оригинальный пост, с которого всё началось. Минимальный шаблон: заголовок, статус, контекст, решение, последствия. Читать первым, остальное надстройка над этой базой.
-
Release It!, Michael Nygard, Pragmatic Bookshelf, 2-е изд. 2018. Критика enterprise-архитекторов, которые пишут стандарты в отрыве от продакшена. Философия "архитектура снизу-вверх". Если вы архитектор и не читали, обязательно.
-
Fundamentals of Software Architecture, Mark Richards, Neal Ford, O'Reilly, 2020/2025. Критерии эскалации, статус RFC, три антипаттерна (Groundhog Day, Covering Your Assets, Email-Driven Architecture), обязательный раздел Compliance. Главный практический справочник по теме.
-
Software Architecture: The Hard Parts, Ford, Richards, Sadalage, Dehghani, O'Reilly, 2021. ADR как инструмент фиксации trade-offs в распределённых системах. Полезна для тех, кто выбирает между микросервисами, модулями и событийной архитектурой.
-
ThoughtWorks Technology Radar, публичный пример того, как организация фиксирует технологические оценки. Adopt / Trial / Assess / Hold, модель, которую стоит взять для своего радара технологий и привязать к архитектурным принципам через ADR.